the corner office

Eclipse Galileo has been released. I commented on Ben Poole's site but thought I'd save most of my moaning for here.

Since about 2007, each release has seen me fall further out of love with Eclipse. Sure, each release adds useful new functionality, but the core Java IDE lacks focus and often as not adds 'features' which can only have been implemented in response to corporate sponsor diktat.

Ironically, I've very recently started using Intellij IDEA at work. I've tried it in the past, but always gave up after a few hours and went back to the comfort of Eclipse. After months of Visual Studio development, a new machine that didn't have a Java IDE, and me getting that little bit hazier with all the Eclipse Java shortcuts and tricks, I thought I may as well give it a real go. The jury's still out but it's slowly winning me over. Not as pretty as Eclipse (all praise SWT), but refreshing to use an IDE that has what you need, when you need it, and which just works, consistently and cleanly.

Anyway, I still use Eclipse at home, so I'll be trying out Galileo and I'll see whether there's anything new and exciting about it. In the meantime, I noticed, if my memory serves me correctly, that this is the first new Eclipse release where they didn't get around to updating the splash screen. Assuming I'm not wrong about my observation, I wonder if that's somehow significant.

I saw a quiet article a few pages into the City A.M. this morning: is IBM going to buy Sun?

Interesting to see how that pans out, if it does. It would mean, amongst others:

1. IBM owns the Sun JVM
2. IBM owns MySQL
3. IBM owns Netbeans
4. IBM owns Glassfish
5. IBM owns Solaris

Hrm indeed.

Aw man. Why do these things have to get so complicated? I wanted to whip up a simple webapp using Hibernate. But when I fired up the app, I got:

Exception in thread "main" java.lang.AbstractMethodError: org.slf4j.impl.JDK14LoggerAdapter.trace(Ljava/lang/String;)V
	at org.hibernate.cfg.annotations.PropertyBinder.make(PropertyBinder.java:184)
... etc etc...

I found this discussion and a comment that it was an slf4j version mismatch with hibernate-annotations. So the solution is to explicitly include slf4j-log4j12 in your maven dependency list, before your hibernate-annotations dependency.

So with that sorted, I ran into the next problem:

Exception in thread "main" java.lang.NoClassDefFoundError: javassist/util/proxy/MethodFilter
	at org.hibernate.bytecode.javassist. BytecodeProviderImpl.getProxyFactoryFactory(BytecodeProviderImpl.java:49)
... etc etc...

To resolve that, you have to add javassist as an explicit Maven dependency.

That cost me the better part of tonight's tinkering time. Bah.

A gotcha. I was trying to load a native library, and to speed things up when fiddling with a test app I tried to set the java.library.path system property directly in the code, before anything else was loaded or instantiated, a la:

System.setProperty("java.library.path", "/usr/lib:/usr/local/lib");

This didn't work, and I still got an error saying:

Exception in thread "main" java.lang.UnsatisfiedLinkError: no myspeciallib in java.library.path

I had to specify the system property on the command line with -Djava.library.path=/usr/lib:/usr/local/lib. Presumably the JVM resolves the library path a lot earlier in life, not just when you try to explicitly load a .dll or .so. Stands to reason I suppose.

An annoying preference conflict in Eclipse 3.4 (and possibly earlier). I had a problem in that despite having ticked 'Preferences | General | Editors | Text Editor | Insert Spaces for Tabs', my Java code was still being generated with tabs.

Turns out that to really get spaces for tabs functionality, you also have to edit your code formatter options. Maybe the default profile is more intelligent, but I have a custom profile, and I also had to go to 'Preferences | Java | Code style | Formatter', edit my active profile and change 'Indentation | General settings | Tab policy', which had been set to 'tabs only'. Changing this to 'spaces only' solved my problem.

Bah!

There's an interesting discussion at TSS about the Servlet 3.0 spec. Two noteworthy things coming from the new spec are continuations, and annotations.

Continuations are great... they're already implemented in Jetty and Tomcat - subjectively, Jetty's approach looks better - and are a brilliant way to break away from thread-per-request processing, allowing better scalability and interesting new ways of doing things.

Annotations... eeeeh, not so much. Annotations are great when used judiciously but they must have turned into one of the most abused features in Java. Sure it might be convenient to specify your paths and mappings in a POJO and start specifying arbitrary methods as GET and POST handlers, but by the time you do that, you no longer have a POJO... you just have lots of hard-coded configuration in the guts of your code. Thumbs down from me.

Java generics are really powerful and clean compared to the cast-and-pray way of doing things before, but by golly, type erasure sucks.

The whole Java world reads Charles Miller's blog. He's that famous; I'm not sure why. But I read his blog too. And his latest post Recommended Reading for Java developers refers to a post from 2002 where he listed 5 books Java developers should read.

Now, 6 years ago I was just starting to learn Java in a university course, writing my shitty classes in Textpad and getting to grips with javac and class paths and thinking that VisualAge was crap with its stupid-ass way of dragging lines between 'beans'. Thankfully I'm come a little further down the road since then (although man, Visual Age was crap).

Miller mentions Effective Java Second Edition. Somewhat coincidentally (not really since the damned thing was only recently published), Joshua Bloch's Effective Java is what I'm finishing off right now. It's an excellent book. It's not always geared towards what application developers do, with a much stronger focus on API design. Still, the principle is that if you see and design your components in terms of APIs they'll work better, and that's true. And beyond that, it's just a great big heap of Java experience and knowledge about the language and libraries, coming to you in little aphoristic bites that you can digest and apply to write less crap code.

In addition to Enlightenment, (capital E and all), the nice thing about Effective Java is that when it comes down to 'should I do A or B to solve this problem', as is so often the case, you can now choose a course of action safe in the knowledge that if anyone ever calls you on your decision you can just reply 'EJ item 71,' and that's the end of the conversation. Sometimes 'Josh Bloch said so' is all the justification you need.

I've been doing a lot of multithreaded work recently, so this is rather apropos (via):

What I would have learned had I been more dedicated to my education were the two fundamental facts about multi-threading with locks:

1. You're going to fuck it up.
2. If you think that you haven't fucked it up, you have. You just don't know it yet.

Multithreading is difficult, even with the right kind of help. The problem is that common wisdom circa 2008 is that core counts are going to keep climbing, so concurrency matters and is going to keep mattering. I don't know much about transactional memory, but it looks rather interesting.

I was looking at some sample code today, and found a Java file with about 5 classes in the file - one public, and another 4 default-scoped classes. Although it's perfectly legal, my experience is that you hardly ever see this in production code. You'll see enough inner classes, member and static, often a healthy dose of anonymous inner classes (and almost never a local class), but bundling a number of classes into a Java file? It just doesn't happen.

I wonder why that is. I suspect it has a lot to do with how people work with IDEs. In the old days when crazy people coded Java in Notepad or vi, it might have made sense (and been more convenient) to have multiple classes in the same file (it's common enough in C++ code). With an IDE like Eclipse, and using something like the Package Explorer, files are the top level of abstraction within a package, and I think developers make an easy file = class equivalence.

Arguably, multiple classes in a file allows an extra level of organisation, logically grouping related classes. Whenever I want to do that, though, I favour inner classes. I can scope the classes more tightly, and associations are more explicit. The down side is you can lose some encapsulation. To be honest, I just never think about anything other than class-per-file with inner classes as needed. So is there a place for multiple classes in a file? Is this a useful but much-neglected feature in Java, or does it hurt readability for developers who don't expect to see it? Not sure...