My first reaction was: "Why?". I already answered to use the tool if it fits your needs, or the indicated libraries otherwise.
But your message made me to have a second look at Protovis, its example. And I must say the home page don't give justice to the software: it has a much greater variety of graphs than I thought, even JFreeChart doesn't come close (but might have more advantages). Using libraries in Processing would need to mix and match to get this variety, handling various styles of API, and so on.
And why not use the tool? Well, I can think of some reasons, like speed (although it is excellent on a modern computer, I should try on an older one), working on IE flavor of browsers (a glaring hole), ability to get raw (binary) data from more sources (databases, sensors, etc.), and so on.
Technically, it shouldn't be hard to build such library in Processing, since we have the source and Protovis has a liberal license allowing such adaptation.
Well, still it would have some pitfalls, like the
height(function(d) d * 80) snippet which dynamically set a function to scale data to pixel number (could use log or other more complex stuff). Well, I suppose it can be done by taking a class following a given interface, or even the JavaScript engine of Java...
The main obstacle to such work is just... time! There is there some 500KB of JavaScript code to adapt. Well, a good part of it is just (doc) comments, the code is very clean and extensively documented, that's some 100KB of pure code (the minified version), still a sizable chunk...
While it would be a super interesting task, it would take some money to make somebody to work on it full time, or lot of time diluted on free time of a would be developer. That should be also an experienced developer to make a proper API from JS to Java.
