ROTFL

OMG!!11 ITZ AWSUM!!

(No, the blog hasn't been hacked. Yes, click the link. See for yourself.)

IM OUTTA YR LOOP

No online Ant API?!

(Warning: disgruntled rant below.)

Ok, so I'm writing an Ant task. I'd need the Ant API. Google "Ant API". First link is http://ant.apache.org/manual/api/index.html. Yeah, sounds about right; click. To my surprise, instead of the familiar JavaDoc page, I get this:

Apache Ant API has not been generated

If you see this page online at ant.apache.org, it is not a bug, but on purpose. We do not provide an online version of the API docs, they are included with all our distributions.

Now, just how arrogant is that? "On purpose"? Just exactly what purpose is that? Are you guys really this much bandwidth starved?

Just for the record, the JavaDoc is not included in all distributions. Y'know dear Ant team, since the Apache license pretty much takes away the power from you to dictate what's in a distribution, some distributions won't come with JavaDoc.

Like that obscure one that ships with XCode for Mac OS X, installed in /Developer/Java/Ant directory. I guess no one uses that anyway, right? I mean, what Java developer would be as insane to use Mac OS X, let alone the development tools that ship with it, right? I'm probably the only such loser on the planet, I can't imagine anything else can explain why noone has noticed this yet and told you about it, so you removed that silly claim from the page where the API docs should have been, and replaced it with, well, with the API docs. Give me a break.

You could say how that's Apple's fault, and I'd agree with you. But that you aren't helping at all is ridiculous, with as little as to keep an online accessible API docs for one of your highest-profile Java projects. In 2007, what Java open source project aspiring to claims of professionalism would purposefully refrains from hosting its JavaDocs on its site? If for nothing else, then all other factors being equal, people want to use their computers with least effort. With a computer connected to the Internet, the easiest way to get to an API is punch "$projectName API" into the browser's built-in Google search box and then hit the first link. Compare this to trying to find the relevant index.html on one's hard drive. Yeah, we're that spoiled.

Anyway, the first site on Google's search results list that can afford the horrid bandwidth and storage burden of hosting the Ant API is http://www.jajakarta.org/ant/ant-1.6.1/docs/ja/manual/api/help-doc.html. Kudos to them, and shame on whoever is responsible for this lameness in the Apache Ant team.

XStream

Whenever I'm faced with a programming problem to solve, the logical first thing I do is to rummage around the 'Net, trying to find an open-source library (preferrably non-GPL, i.e CPL or BSD licensed) that already solves it. Because reinventing the wheel is costly, and most of the time the problems are such that I can't imagine to be the first to have came across them.

Few months ago, I had a requirements for passing objects between JVMs. "Doh, serialization", you'd say. Right. Except that the other people on the project felt it'd be very helpful from the diagnostics perspective if we could inspect the objects. So the logical idea - serialize using XML instead of Sun's binary serialization format. Turns out that the JavaBeans API actually provides support for something similar in the java.beans.XMLEncoder and XMLDecoder classes. It will serialize/deserialize JavaBeans using their public property getters and setters. But we really wanted something that operates on the ObjectInputStream/ObjectOutputStream idiom and serializes fields.

Eventually, I found the XStream project at CodeHaus.

The logical second thing I do when I found an open-source library is examine it. Unfortunately, lots of stuff floating out there isn't of particularly high quality, and branding also doesn't guarantee quality, be it "Apache" or "Codehaus" or anything else.

Now, after using XStream for quite a while now, I must say: well done! It delivers on its promises, the code is architecturally sound, and is insanely customizable. The generated XML is rather compact - i.e. if a value of the serialized field is exactly the same type as the declared type of the field, the type is not written out in the XML. Only if a subclass is used as the actual value. What's more, types can be aliased both on serialization and deserialization. This allowed us to ship objects from a GUI frontend JVM to a DB backend JVM, and have them being serialized/deserialized as different subclasses of a common abstract superclass hierarchy. In the GUI frontend, they were deserialized as classes with GUI operations, on the DB backend, they were deserialized as Hibernate enabled classes. Just brilliant.

I know you can do it with Sun's default serialization as well, but you must override resolveClass or replaceObject in the object input stream. Whereas with XStream, you could just configure the aliases in a factory once, and be done with it. Very elegant.

It is also possible to plug in custom serializers for certain types - i.e. we had to make sure Hibernate-specific collection classes were serialized as plain Java collection classes. It probably took me all of a 20 minutes to implement it, relying on documentation and the XStream (quite clear) source code.

Then there's a rather ingenious default mechanism for backreferencing objects. You can configure XStream to slap an "id" attribute on each element representing a serialized object, and when you need to reference it from a later written object, refer it by the ID. Anyone could come up with that, it's rather trivial. But XStream doesn't do that by default. Instead, by default it doesn't write any ID, but if a later written object needs to backreference an earlier written one, it'll use an XPath expression that selects the earlier object's element! (You even have a choice between absolute XPath or XPath relative to the referencing element.) Again, very elegant.

And to top it all, XStream is not for XML only any longer. Since the serializers are pluggable, they currently also have a JSON serializer, which sure can come in handy if you're AJAXing. (I'm not, so can't give an account of experience in this regard.)

All in all, I'm currently very happy with XStream; if you need to serialize/deserialize your Java objects to/from XML or JSON, I recommend you give it a try.

My current open-source TODOs

I'll admit that I feel a bit thin-spread lately regarding my open source activities. There's just too much stuff going on that I'd need to attend to one way or the other. Of course, this is all competing for whatever leftover bits of my time after paid work ("urgent/important"), family, an attempt to reinstantiate a regular workout habit (both "not urgent/important") and the also inevitable everyday interruptions ("urgent/not important"). Just to make it clear, OSS work is to me in the same "not urgent/important" quadrant where family and workout take place.

In no particular order my current OSS activity goals are:

• Implement support for invoking Java vararg methods from FreeMarker (this actually goes off the list, as I completed it on the quiet sunday afternoon while kids were at a birthday party)
• Implement support for JSP 2.0 SimpleTag interface in FreeMarker's JSP taglib runtime
  
• Fix the JSP taglib lookup mechanism in FreeMarker's JSP taglib runtime
• Make the overloaded method invocation + varargs into a reusable library so I can support vararg methods in Rhino and also have other open-source dynalang communities leverage it
• Support vararg methods in Rhino
• Cleanup the LiveConnect implementation in Rhino (primitive booleans not coerced automatically, and in general overloaded method resolution could be better, and it doesn't use JavaBeans bean info, and...)
• Just generally try to attend to bug reports in Rhino
• Attempt to refactor Rhino-in-Spring to reuse Spring WebFlow as much as possible, 'cause having two webflow implementations on the same base code would really help it emerge into a flexible foundation worth submitting as a "Java Web Flow" JSR

There you go - I actually feel a bit better having written down all of this. If you wonder why I haven't answered a Rhino question for a week or so, it might be because I was busy working on a FreeMarker issue, or vice versa. Or just there were no birthdays lately, so I didn't have a quiet sunday afternoon at my disposal for some immersive hacking. But rest assured, I'm going forward with all this stuff, just not exactly on "Internet time" speed :-)

Fish Tank

I'm an avid reader of about a dozen different webcomics. Today, I just discovered another one, and it's just incredible in its originality. It's the Fish Tank, about adventures of three fish living in an aquarium (and quite often venturing outside of it). What's original about it? Well, these fishes occasionally get rid of piranhas (on an occasional visit to Brazil) by deorbiting a communication satelite on top of them using a satelite telephone, or get rid of a cat using explosives. Or are (in the current storyline) kidnapped by, of all things, telepath moths. Rooms, houses, or city blocks sometimes get demolished, or Alaskan wild forests set to fire. In general, there's lots of "Mission impossible" action going on, with fish improvising all sorts of devices from stuff found in their tanks and household items (not necessarily plausibly, but that's really not the point of it; they actually have laptops too!). The drawing is loveably sketchy (but consistent), and the characters are incredibly well built, complete with their love/hate relationships and plenty of ingenious throwaway jokes and inspired dialogue. Totally love it.

Dynamic language interop plans in .Net world too

I've recently explored the topic of in-process cross-language interoperability (think Python program using Ruby created objects etc.) in my "Adapters or Navigators" article.

Interestingly, I stumbled across posts in Jim Hugunin's (Jython and IronPython founder) blog recently about the exact same topic in the context of .Net - they seem to already have some implementation ready as part of their Silverlight initiative. Here are the posts:

A Dynamic Language Runtime

The new Dynamic Language Runtime (DLR) adds a small set of key features to the CLR to make it dramatically better. It adds to the platform a set of services designed explicitly for the needs of dynamic languages. These include a shared dynamic type system, standard hosting model and support to make it easy to generate fast dynamic code. With these additional features it becomes dramatically easier to build high-quality dynamic language implementations on .NET. More importantly, these features enable all of the dynamic languages which use the DLR to freely share code with other dynamic languages as well as with the existing powerful static languages on the platform such as VB.NET and C#.

Next two posts deal with a sort of "universal adapter", a common object model required for cross-language interop:

One True Object (Part 1)
One True Object (Part 2)

In the part 2, he illustrates how a dynamic language runtime queries an object "Do you have member X?", and the object thinks "I'm a Python object, so I'll look it up by Python rules". He envisions the IDynamicObject interface that all object implementations of all languages must implement for interoperability.

This is exactly what I claim to not necessarily be the best approach in my "Adapters or navigators" article, but that having pluggable metaobject protocols instead of an expected interface might be a more flexible solution.

It's nice to see though that other people also have this problem in their crosshairs :-)

Parents of kids with Down syndrome campaign against prenatal testing for it

The New York Times carries an article today titled "Prenatal Test Puts Down Syndrome in Hard Focus".

It reports how in US, families rising kids with Down syndrome are campaigning against a new, widely usable prenatal test that can be used to screen for it. 90% percent of pregnancies where the fetus is diagnosed with Down get aborted. Some parents are worried that as population of people affected with Down syndrome dwindles, the care programs for them will also disappear.

But they are also worried about a much more serious problem than that. The practice is well within the area of eugenics, trying to draw a line between eliminating a genetic condition undesired by the would-be parents versus lessening the diversity of the human race. The genetic condition can be viewed as undesired since Down syndrome results in having somewhat weaker physical features, being slightly mentally challenged, and having shorter life expectancy (49 years average), but most of these individuals are still able to live fully enjoyable lives in a loving family, even if they're placing a bigger burden on their parents, and parents who actually raise such kids and therefore have first-hand experience believe how Down is not a sufficient reason to deny those kids existence. I tend to sympathise with this point of view. From the article:

Sarah Itoh, a self-described “almost-eleven-and-a-half,” betrayed no trace of nervousness as she told a roomful of genetic counselors and obstetricians about herself one recent afternoon. She likes to read, she said. Math used to be hard, but it is getting easier. She plays clarinet in her school band. She is a junior girl scout and an aunt, and she likes to organize, so her room is very clean. Last year, she won three medals in the Special Olympics.

“I am so lucky I get to do so many things,” she concluded. “I just want you to know, even though I have Down syndrome, it is O.K.”

In-process cross-language object interaction: adapters or navigators?

There's a new article on my website titled "In-process cross-language object interaction: adapters or navigators?".

I'm discussing two typical approaches for object interaction between a "higher level runtime" (HLR - i.e. a scripting language runtime) and "lower level runtime" (LLR - runtime for whatever language the high-level runtime is implemented in, i.e. JVM or CLR, or even straight C).

The two approaches discussed are the somewhat more common "adapter" pattern, and the somewhat less common "navigator" pattern.

HLR implementations usually go for the adapter approach, but I argue that the navigator approach is superior to it, especially when you want to extend the object interaction from the HLR-LLR dimension (i.e. representing native Java objects in a JavaScript runtime written in Java) to an orthogonal dimension, namely have interoperability between two distinct HLRs running on the same LLR in a decently intuitive manner, without knowing of one another in advance (i.e. use objects created in JRuby from within Jython, without Jython knowing about JRuby at all).

This level of interoperability opens up new possibilities for people implementing software systems, as they become free to implement different subsystems in languages that fit the job most.

Discussion welcome in comments.