Tag: java-hate

$ strace -f ant > out.txt 2>&1
$ grep "stat.*java" out.txt | wc -l
32933

WTF? No wonder our build times suck. I still have yet to hear a rationale for the existence of ant that had any more substance than “but make uses tabs!”

Is it too much to ask of a compiler that if it decides to blare warnings at you for no reason at all, that you can turn the !@#$ thing off? In a move that rivals the stupidity of certain gcc warnings, we have this:

[javac] file: java:519: warning: com.sun.rowset.CachedRowSetImpl is Sun proprietary API and may be removed in a future release

Well, hey that’s a nice heads-up to give me 600 times when compiling our tree. Let me go find the non-com.sun equivalent of that. Oh wait, there isn’t one! And, the freaking javadoc even tells you to do it that way. Okay, well, maybe @SuppressWarnings({"deprecation"}) will work? Nope, haha! Sigh. Time for a wrapper script.

Request of persons who wish to write a better javac: can I have plugins that let me muck with the AST? Custom static checking would be nice…

Dear lazy web,

It would be nice if you could tell me a non-hacky way to do progress dialogs from within the event-dispatch thread in Swing, where all of our application logic happens to reside.

This doesn’t work:
display modal dialog
start worker thread (won’t run because event thread is blocked)

Nor does this:
start worker thread
display modal dialog (race condition hiding the dialog)

Joining in the event thread won’t work because it blocks updates. Using a non-modal dialog and passing the bottom-half of the rest of the event thread to the worker thread to execute at completion will work, but is obscenely messy. Or, one can spin in the beginning of the thread waiting for the modal dialog to appear to avoid the race condition, but that is still gross. One could subclass Dialog and have it also signal a condition variable once it blocks… ugh.

Allow me to enumerate the many ways I hate JAXB. JAXB is an XML data binding tool for Java; that is, it generates code to make using XML more Java-like. This is great in concept. In reality it is not so great:

• Two days away from your project due date, JAXB lets you know that it isn’t mindful of the method size limits in the JVM. Javac tells you: “code too large.”
• There’s a limit to method sizes in the JVM?
• Upon examining a generated class, you discover 25k lines of utter garbage. Things like the same if-then clause being repeated twice in a row.
• Turning off generation of the validator, or the unmarshaller, or the validating unmarshaller does have the effect of reducing code size, at a cost of generating code that doesn’t compile.
• Or if it compiles, it throws a runtime exception when you use it.
• The object hierarchy is all screwed up, such that a concrete implementation type may implement a (JAXB internal) interface that is not also implemented by the corresponding abstract interface (the two are supposed to be interchangeable).
• You have to do naughty proprietary things to make type substitution work.
• Creates a new namespace prefix for practically every element even though I only use 3 namespaces in the entire document.

I only just learned about XMLBeans. Dammit.