I have previously questioned the what seem like weird method names in Java’s newish ProcessBuilder API. It turns out that its not-newish-at-all close personal friend Process is little strange too: it has getOutputStream and getInputStream which respectively get you pipes to the process’ standard input and output. Data comes out of the Process and you want an InputStream, so it has to be getInputStream. But how can getOutput get you the input while getError gets you the error? OK, call me anal, I can take it. But I’m writing a class right now kinda like Process, and I simply absolutely can’t bring myself to call the input the output and vice versa. So I have getTaskInput, getTaskOutput, and getTaskError, which produce output, input, and input streams respectively. We all have to deal with the confusing nature of reality in our own ways.
[NOTE: When you get to the end of this post hopefully the title will make a bit more sense... For now, just go with it :)]
One of the pleasentries of working on the Saxon.NET project came when I discovered the beautiful simplicity that is used in Java's JAXP XML processing extension project (it now ships as part of Java 1.5, but previous to that it was an extension project.)
Of course before the official 0.10[1] release of IKVM, to gain the benefit of JAXP it required some "creative-splicing" of various open source projects to get this to work [this changed in the 0.10 release, made evident by this response to an email response Jeroen sent confirming that JAXP was now a part of IKVM.Gnu.Classpath.dll, something he would later reveal was the fantastic effort of Mark Wielaard(the GNU Classpath developer/admin that imported GNU JAXP.)] Before this blessed event took place the previously mention spliced-libraries had to be compiled as part of the Saxon.NET assembly to gain the JAXP functionality (and even the spliced-libraries required some extra hacking here and there to get things to sit right.)
Why not just make them their own assembly? Too long of an explanation with very little value given that this is simply no longer a requirement. The point of even going through this painful explanation is this:
When I first discovered the beautiful simplicity that JAXP's Source/Result implementation brought to the XML document type table I realized then that no matter how many sleepless nights of hacking it took, I was going to get JAXP integrated into Saxon.NET, or quite possibly die trying... Coming from the .NET world where, even though the entire framework was built on an XML foundation, you were always fumbling with conversion from one XML document type (reader, writer, reader/writer combo, forward only, backwards only, 'only if a child with the attribute of "whodahellcameupwiththisnastiness" existed' reader, writer, and reader/writer combo of his royal nastiness, etc...) to another.
While I cant really say for sure, I'm guessing the desire(and in all honestly, need!) for extensive optimization was the reason that so many XML document type's, the oodles and oodles of constructors for things like XslTransform(), etc... etc... etc... came about in the first place. But with optimization particular to each situation encountered came the price of increased complexity.
But no matther the reason, I'm sure you can easily understand why the concept of one input document type and one output document type made available via the Source/Result implementation of JAXP was a .NET XML hackers dream come true. But unfortunately it doesn't seem as if the inclusion of JAXP as an official part of the Java language had any real effect on the rest of the language. I would have hoped that maybe the rest of the Java Platform and Class Library development team would learn a thing or two from the JAXP extension project, embracing its simplicity and extending this into the Java platform even further.
But as made apparent in this post, it doesn't seem that XML is really something that is seen as a crucial element in Java's future, at least from the standpoint of the original creator of the language, James Gosling. Don't get me wrong... The man is flat out amazing... I just don't think he's sees much need for XML in the long term picture and as such has taken a "well, lets see how the future plays out" standpoint.
That's fine. But I'm not sure he's going to like what he sees when that future arrives. Actually, in terms of the Java language, I'm guessing that XML will probably win over in the end. But when you have one side of the development language pioneer world questioning the value of XML in the future of the Java language, and on the other side you have language pioneers, visionaries, and all-together software legends at the very top of the software legend stack who have not only shown their commitment to XML from .NET's very beginning, but have continued down the XML path, pushing things 1000 XMiLes (eXtraMiLes for those wondering... shhhussh... just smile and go with it :) further by bringing XML to the top of the data type stack, making it a first class data type within C# and VB.NET, ridding the framework of the complexities of XML data types nearly in one gigantic swoosh of the language pioneers broom.
But lets not stop there! Now that we can treat XML just like XML why not take it even further by bringing forth Linq and XLinq, which in a nutshell allows you to use either a SQL or XQuery-styled (or both if you'd like) syntax embedded directly into your code-base and as a result not only has the XML document type all but been eliminated thus ridding us of the inherent document type conversion complexity, but they've added to this the ability to query, transform, requery, retransform, pipe it in, pipe it out, shaka, shaka, shaka, your XML all about (thus, the title... Hey, I never said you would agree with it. Just that it would make a bit more sense... :) and then start the process all over again if your heart so desires without ever having the need to leave the cozy and well understood site of your original XML document structure.
I like it! :)
[1] 1.0 for those not accustom to the [Unix | Linux | OSS | I-am-sure-it-doesn't-stop-here | chances-are-good-others-use-this-version-variant-as-well] form of versioning... It took some convincing, but it grows on you... at which point it tends to be preferable.