Eclipse plus Mylyn = Productive

I tried Mylyn for the first time a year ago, and found it to be impressive, but the job I was working at had a relatively small team, and small codebase, and I was only using Eclipse/Java a portion of the time, so I found that I didn’t really use it too much. And after a couple of nasty crashes, I realized I had overloaded Eclipse with too many plugins, and yanked Mylyn out.

Now I’m working at a new gig, which is all Java all the time, and I am pretty much living inside Eclipse, flipping away only to check docs or go into DBVisualizer. And the code base is of a respectable size, divided into 50 or so source folders. My Package Explorer view just scrolls and scrolls and scrolls, and it is impossible to find anything. (Add to that that it is a new code base for me, and I just don’t know where stuff is, period.)

So suddenly, Mylyn is a lot more useful. It hooks into our issue tracker/ source repository (Trac/SVN). Which means I never have to leave Eclipse for information about what I am doing. I love the Planning tab on the tasks, where I can outline my approach to a problem, and which I can refer to when I lose track of what to do next.

My this is cool moment came when I discovered that Mylyn saved my workbench state for each task. Turning the task off cleans the workbench editor of all the files I had open—and making the task active again brings them all back. It’s fantastic to switch between issues, knowing that it won’t take you 15 minutes just to get everything set back up.

Best of all, Mylyn makes the Package Explorer usable again, by focusing me on just the files that I am using. I find Mylyn absolutely vital t o getting my job done these days.

One note: Getting started with Mylyn can be a little intimidating.  And for the first time user, the Mylyn project presentations are not especially helpful.  The 60 minute video done is a bit to long for the impatient to digest. There needs to be a simple 5 minute “here’s what’s cool, here’s how to get started”. If you are new to Mylyn, the best would be to get a demo from someone who has used it before. If you can’t get a live demo, I’d encourage you to stick with it though, it has definitely paid off for me.

Eclipse, Java3d, and java.library.path

In my new and continuing series on hair-pulling, teeth-gnashing Java error messages, I am proud to present:

java.lang.UnsatisfiedLinkError: no j3dcore-ogl in java.library.path

Just for fun, I’ve been working through Pro Java 6 3D Game Development: Java 3D, JOGL, JInput and JOAL APIs . I have been trying to rework the example code and make it my own as I go through the chapters.

Anyway, I built a small “Hello 3d” app but when I attempted to run it I get the above UnsatisfiedLinkError. What was odd was that the sample code from the book ran without any problems, but I was getting this error.

For some Java libraries, there are native code (C++ extensions, basically) that Java needs to work with that particular feature. Java3d is a prime example. You need to put the j3dcode.jar, j3dutils.jar, and vecmath.jar files on your CLASSPATH. Additionally, you need to put the native code, j3dcore-ogl.dll (j3dcore-ogl.so on Linux) onto the PATH. This can be in the JRE/bin folder, but the Java3d isntall file says to avoid sticking it in there, as it can cause problems. I choose to keep all my Java files in my D:\java\lib folder. — in this case the java3d-ogl.dll is in D:\java\lib\j3d\bin. And since I am using Eclipse, I configure Eclipse with a user library like this:

Eclipse dialog for User Libraries in the Java Build Path

Eclipse dialog for User Libraries in the Java Build Path

I focused on the “java.library.path” part of the error message. I configured Eclipse correctly above, and had my app spit out the System.getProperty (“java.library.path”) to the Console. It was correct.

But it didn’t work! At. All. Mysteriously, the sample code–which was configured to use that same Eclipse User Library, worked just fine.

After a lot of Googling and talking to myself (grr, I’ll show you unsatisfied…). I noted in my TaskBar that the icons for the sample Application (Life3d) and my little app where different. And a lightbulb went on. Sample code was running Java 1.6, and mine was running under Java 1.5. (I had chosen JDK 5 because I was thinking about redistribution to some non-geek friends, and figured more people would have Java 1.5 than 1.6.)

Now–in theory, there should be no difference. Not sure if this is a feature or a bug–the Eclipse stack is sometimes too big to tell. But my Eclipse is running on Java 1.6 (Vista x64), and perhaps the way it is creating the class loader for the 1.5 JVM it is not picking up that .dll, even though the .dll was on my PATH (or in my Eclipse native library location).

My fix: Inside Eclipse 3.4, swapping my project to use Java 1.6 as my JVM fixed the problem. Hurray! I have yet to test building a JAR and trying it outside of Eclipse… I’m just trying to get through a few more chapters so I can get to the fun stuff.

Hope this helps someone.

Eclipse 3.4: JVM Terminated. Exit Code=-1.

After several months of using mostly Visual Studio, I have some time now to shift gears back into Java. The timing is good–the annual release of Eclipse and all its subprojects happened while I was out of town on vacation last month.

I’m working on a new computer, running Vista 64bit. I reaped the rewards of Moore’s Law by obtaining a custom build box with a Quad processor and 4 gigs of ram and a fancy graphics card for about 130,000 JPY. Oh yeah, a terabyte of storage. Anyway, the Core 2 Quad CPU was so reasonable I couldn’t not get it.

I’ve been using Vista for about 8 months and am still getting used to it. I am far from a Windows expert. And the ins-and-outs of 64bit versions of software I am still getting used to.

I discovered I had 5 version of Java installed on Vista: 1.5 and 1.6 in 32 bit versions, a 64bit 1.5 JRE (installed by Web Start?), and the 64bit 1.5 and 1.6 SDKs. I figured I would clean out the 32 bit versions. In fact, I wound up uninstalling every single version of Java and re-installing just the latest 1.5 and 1.6 SDKs, as there were updates that I didn’t yet.

Then I started up Eclipse and I got this really annoying error:

JVM Terminated. Exit Code=-1.

My environment: 64bit Vista Ultimate, Java 1.6 x86_64, Eclipse Gandymede (JEE zip download).

Google returned a lot of problems around Exit codes but nothing that specifically addressed this issue. Turns out the exit code just means “you’re out of luck!” I tried to find a list of all exit codes but had no luck. A lot of the advice about the exit code problem seems specific to Eclipse 3.3 and messing with the eclipse.ini settings (I recall vaguely having to do this about 7 months ago). That didn’t work.

After banging my head against the wall (needlessly), I realized that the Eclipse Gandymede default download is a 32bit download.  I had to find the Eclipse v3.4 64bit Windows download (which is a little tricky, because they do a good job of steering you to the Gandymede stuff–what you want is the Eclipse Platform download link), and then use the Gandymede update site to get all the subprojects downloaded correctly. Hurray for fiber to the home—it was not too painful to download all of it.

To summarize, I was having JVM Terminated because I was using a 32-bit binary of Eclipse on a 64bit Vista (32 bit Eclipse is in the default Gandymede download). The solution was to download a 64 bit version of Eclipse. Go to the Eclipse Platform Download link, then click on the “3.4” Build link to get to all the various binaries for all the platforms, including Win 64.

(I also wound up reinstalling a 32bit version of Java. Turns out, that is the Java used by Firefox and IE. Need that for viewing applets.)

Edited Aug 8, 2008: to make it clearer that the solution was getting a 64bit-compatible version of the Eclipse binary. Reinstalling 32bit Java was justa convenience to get my applets working in Firefox.