JavaOne Day One
My company is kind enough to shell out and send me to JavaOne this year. One of the may ways they are pretty decent. Since I'm here I figure I'll add to the infinite supply of JavaOne blogs and add my first impressions.
- Sun really has some sharp people doing presentations. The Ajaxian presentation was great and their SOA sessions have some decent perceptions that don't tow the "sun way" blargh.
- Java is still dead on the desktop. As much as Sun likes to show off Swing, etc. Ajax and the web is really killing any Java desktop apps (not to mention the windows techs by MS.)
- They have these cool smart cards. The registration id has a smart card with a chip with all your id info. So you can log into web terminals by just plugging in your card. No password to remember, pretty cool. What is not cool is that none of the vendors have readers to scan this info. They still want you to write your name, address, phone 1000 times to get their frisbee or whatever. It's definitely some Flintstones stuff that they don't just scan your badge. I was at some conference a few years ago (can't remember but I think it was TechEd or ApacheCon) where they had it so I don't know why Sun didn't use it.
- JavaOne loves lines and/or is run by a massive anal retentive person. Each session requires registering beforehand and then waiting in line to get into the room. This might work in theory, but here it sucks. So far, I've waited in over 90 minutes of lines today and I have yet to get into the room before the speakers start. My favorite is that at the end a session they actually announced "If you are attending the next session in this room, please exit and re-enter the room." So this means that if you are in the next session, you still must go out and wait in line for 30 minutes. Brilliant!
- The Moscone Center seems to love tweakers. I seem to constantly come in contact with event staff who look like they've been on meth for 48 hours. The Sun employees all seem pretty sharp, but the Moscone people are scary.
- Is Java racist? I swear I've only seen 1 African-American out of thousands of attendants. What is the deal with this?
- NetBeans 5.5 actually looks pretty decent. Good, OS UML tools, BPEL tools. I haven't tried it in years, but if it keeps me from having to use Together, I'll be happy.
- JavaOne really loves Diet Mug Root Beer. Every freaking drink cart only seems to have diet root beer and diet orange soda. They seriously need to restock these things quickly (and maybe some Coke too, only Pepsi is eh).
That's it for now. They have some pretty cool setups with 360s laying around, bean bags, movie nooks, vintage arcade machines. Nice set up.
dom4j Node adding headaches
So, my project does a lot of in-memory xml manipulations. This means we add, remove and even move xml nodes within a document. We chose dom4j because it has the fastest writes, edits and xpath (using jaxen) among dom4j, jdom, xerces+xalan and xerces+jaxen.
Anyway, I started running into some strange errors when I tried to move an element within a document. A move consists of detaching an element from it's parent and assigning it to a new parent either after or before a particular node.
Dom4j lets you position new nodes by providing a List interface to the underlying structure. So you get a particular parent element and then get the list using either Branch.content() or Element.elements(). content() gives you all of the child nodes, elements() gives you only the child nodes that are elements. Now that you have a list you can add an element using the standard List methods add(Object) add(int,Object).
The problem arose when on this line of code:
I started getting this exception:
java.lang.IndexOutOfBoundsException: Index: -1, Size: 12
This was pretty confusing because while debugging, parentElements.size() was equal to 6 and newPosition was equal to 2. This made the error message a bit confusing.
I ended up digging into the dom4j source and found out that whenever you call detach(), it changes the parent node's structure and empties out the element list. This isn't really intuitive, but makes sense. As if you try to move an element within a parent, it could cause problems. This sucks because if you try to move an element earlier in the parent, the detach shouldn't affect the operation.
But the good news is that when I moved the call to elements() after detach(), I stopped getting the error. I guess I'll add a new item to dom4j's tracker
and hope it gets fixed in a later version.