The BileBlog

It’s really astounding how easy it is to pull the wool over the java kids’ eyes and amuse them for hours on end by merely dangling a shiny object in front of them.

The latest example of this is the one of the ‘ajax’ poster boys, json-rpc-java.

I am truly baffled that people take this crap seriously. At best, it’s a cute toy with a couple of neat tricks that one could copy. At worst, it’s a evil evil implementation that’ll bite you in the ass if you ever expect more than 3 users or would ever like to cluster, use declarative security, fine grained access, method level anything in fact.

The idea itself is not that bad. The implementation however is almost like some kind of sick sick joke. For those who have so far been wise enough to avoid this shiny bauble, it’s basically a clever hack built around xmlhttprequest and some javascript to java serialization that allows you to invoke arbitrarily methods on serverside java objects.

So how is this done? For reasons best known to to the authors themselves (and no doubt applauded by the shit-eating-grin sporting ajax crowd), they basically bung everything into a session. Now, you might be forgiven into thinking that ‘everything’ here is just lightweight stateless information. You’d be so so depressingly wrong. Every means that each user gets their own JSONRPCBridge. This class is so incredibly session-unfriendly that it doesn’t even implement Serializable. Even if it did, mind you, you’d be even further up shit creek sans paddle. Said class contains every exposed object, every exposed method, and every exposed class. Persisting this to anything other than memory is likely to take a few days at best, while your hapless user is left sitting there with any number of thumbs inserted into any number of orifices. Adding to the general hilarity within this class, we also have a static classCache map. It’s the gift that keeps on giving!

Of course, should you to refuse to use said session object, you’re forced to use the ‘global’ bridge. Of course, when asshats like these say global, you just know they mean ’static’. Of course, of all classes they could have possibly stuck the static, which did they pick? Yep, you guessed it, the very object they’re shoving in the session!

The documentation of course is in the fine tradition of open sores. It starts off well enough, but halfway through the manual, the author simply lost interest in the whole thing and just gave up, leaving 4 sections totally blank. Just imagine the hue and cry if a commercial vendor dared have empty swathes in their documentation. Why on earth is such incompetence tolerated and nudgenudgewinkwink-ed away in the opensores world?

It’s quite a shame really, the project is a cute little gizmo, and to the authors’ credit, it has no dependencies and does not use maven, so they’re not completely braindamaged. They do try and go out of their way to make up for that foresight though by forcing their hapless victims to edit build.xml and specify twatty tomcat values. It is truly astounding how few people seem to know how to use ant, or how others expect to use it. The developers’ real downfall however seems to be that they were never beaten with the scalability mallet as children. So if you kids know what’s best for you, let the beatings commence!

This entry was posted on Wednesday, March 23rd, 2005 at 9:19 pm and is filed under Java. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.