Java XML "support"

Like many software projects written these days, I'm finding using XML unavoidable. I'd always wondered why Java programmers always seemed so grumpy about XML, and now I know.

Java XML support sucks.

I'd never really appreciated .NET's support for XML. A few pain-in-the-ass points, but for the most part pretty easy to use. Ruby makes it way too easy, and comes closest to how it "should" be done.

It started with serialization. I need some way to store the state of an object so I can send it over the wire. Java has a built-in binary serializer which works very well. It doesn't matter if the fields are private, or whatever, it'll dump them out and read them back in. A couple of pain points, but pretty easy to use, much like .NET's serialization. I figured that serializing to XML would be just as easy.

I can be so naive.

Everyplace I looked said to use XMLEncoder. Okee dokee, except that the equivalent code doesn't give equivalent results. Do some digging, and it turns out the binary and XML serializers use completely different mechanisms. Now, there's probably some pointy-headed academic someplace who is satisfied that the XML serializer meets some standard. If it means re-writing your code in such a way as to make it more difficult to maintain, then you're doing it wrong. Especially when a not only do competing languages do it in an elegantish manner, but you have an implementation which does it well, too.

You know, the source code is open. Someone with more time oughta look into that.

Anyways, since it all blows so hard, I've got some extra work implementing my own serialization conventions. I've got it implemented about halfway through at the time of this writing. It shouldn't take much longer to finish.

Learning Java, Still

I've been hammering away at both getting the project along (and it is coming along nicely), while learning Java (also coming along nicely). I've done enough that I've got some opinions about Java. Maybe I'm just doing things wrong, and whatever old Java sages stumble across this post will just shake their heads at the n00b.

Today's complaint - exceptions

First, I wanna complain about exceptions in Java. I like exceptions. I like code that blows up in a predictable, informative, and containable manner. At first, when I was having to declare all the potential exceptions a method could throw, I was annoyed. Then, I came to appreciate it. I had a detailed list of broad categories of things that could go kerblooie.

That is totally awesome.

So, there I was, hard at work, not understanding why I wasn't getting the results I was expecting. Then I noticed the log saying something about an exception, and continuing.

I looked, but I wasn't catching it anywhere. It was an unhandled exception, or at least I wasn't handling it, and I'm the only person I care about when it comes to code.

Dammit, things should blow up, not just continue. What the hell kind of "exception" is that, anyway? They call it "unchecked" (or is it the other way around?). I guess I'm just not smart enough for Java.

All is not suckitude

I'm using NetBeans, this go-round. It runs really well, handles my multi-mon just fine, and holds my hand without getting in the way too much. It isn't as good as Visual Studio - VS just has a bit more "polish" to it (much better autocomplete, for example), but it is easier to get to the guts of NetBeans.

Refactoring in Java is awesome. I have absolutely no fear about renaming things, moving them around, whatever. Since laying things out in both agiley and enterprisey fashion means a lot of little files, this is pretty important. I've been burned by refactoring in VS (but not a recent version), but not once in NetBeans.

Things could be easier, dammit!

Documentation is all over the map. The linux distros used to have this problem (they've gotten much better), where there were just so many options, and no clear consolidated approach. NetBeans packages as much as it can together, of course. This doesn't cover moving to production, or anything like that. I guess it is expecting too much to find documentation geared towards someone who is intent on learning an entire stack at once.

I'll get over the smell

As usual, I'm having fun learning. I've got enough of the basic patterns down that I'm getting a lot done fairly quickly. I'm sure I'm making dozens of beginner mistakes, but hopefully I'm doing a good enough job that those things are easy to find and fix.

I keep getting stuck on the server deployment scenarios. There's just too many of them. Not just app servers, but what those app servers need to provide. The acronyms are very thick.

Just more stuff to hammer on through. I'll keep you posted, of course.

Learning Java

Okay, so here I am, learning Java. I've put it off for many years. Learning Java has always been compelling, but more along academic lines: As pervasive as it is, I should just know it.

I tend to need to write stuff fairly quickly (misc tools don't need to be particularly well-written). So, I usually script my way out of trouble. When I need a GUI app, or just need to show additional polish, I reached for DevStudio - Microsoft makes those one-off apps easy.

My goals are pretty simple: learn enough to

• Administer java application containers
• Diagnose Java application problems
• Understand it well enough to use a high-level language (Groovy, JRuby) effectively
  

I'm not unfamiliar with configuring Java containers, but I'm in no way an expert. I like the overall...explicitness?...of it. So far, I haven't seen anything that I couldn't really pull off on other platforms (Apache or IIS), and there is a cost of initial complexity.

However, as the overall configuration becomes more complex, java containers simplify things - all that explicitness pays off. Part of the appeal, given my current path, is that I can take a couple of these java based OSS projects (OpenNMS, ActiveMQ, Solr), and stuff them all into one JVM. Or not. (and I really look forward to learning how many problems doing it causes :) )

One thing Java got right was that it was all-Java right from the beginning. If you were coding a Java EE app, you were writing in Java. Microsoft's decision to foster backward-compatibility by encouraging interop wrappers around existing Win32 dlls has been a huge headache. While appserver admins were wrestling with classpaths (and arguing with devs about the location of physical files which are being written to), MS admins were building dozens of small machines because native.dll from vendor A's ".NET application" collided with native.dll from vendor B, who actually went out of business three years ago. I've dumped too many things into VMs because of that crap.

MS and it's ecosphere has certainly gotten better, but there's still sticking points (do we really need a Global Assembly Cache?).

What about the language? Surely I can't talk about "Learning Java" without talking about the language!

Well, I can't talk much; I've only been at it for about eight hours. A nice chunk of that was spent learning about classpaths, and changing the location of where apps were writing files on the physical disk. I'm being all old-skool about it, too. I've got Notepad++, the JDK, and a couple of powershell scripts as my dev environment. I know there's better and easier ways to do get things done, and I'll get to using them eventually. For now, I want to know what's going on under the covers.

For my first trick, I created a bunch of unnecessary abstraction ultimately resulting in getting some rows from a database, and dumping them to the console.

Why do I have to declare my potential exceptions? If the compiler knows enough to know that I didn't declare an exception when I should have, why doesn't it just stick it in there for me?

I thought it was neat that I didn't necessarily have to include, er, import namespaces. (At least I didn't need to with the Postgres adapter; I don't know all the rules to this, yet.) It was neat until I had to start adding "throw ClassNotFoundException" on all of my functions, anyway.

Having one general abstraction for databases is nice, too ("java.sql.*", vs. "SQL and OLEDB" everything). In fact, there's some nice generalizations for just about everything to accomodate that EE specification.

Anyway, I'm having fun, and I'll keep y'all posted.