Symbian Summit Tokyo

I attended the Symbian Summit Tokyo last week. The timing was good–the marketplace for cell phone operating systems has never been more interesting. Google announced its open source OS Android last November; then Nokia announced that it was acquiring the majority of the outstanding shares of Symbian last month and planned to open source the Symbian OS. And the week before this conference, Apple released its 3G iPhone, complete with a compelling developer SDK and enterprise strategy.

Symbian Summit Tokyo 2008 at the Westin Hotel in Ebisu

So I was curious to see what the response would be to these various developments, at a show hosted by Symbian.

Continue reading

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.

i got the flu… the happy flu

You’re not really blogging unless you’re involved in some random chain-letter variant. This one seems to be not too lame.

Achoo!


Edit – wow, I need some QA. Copy/pasting the code into the WP’s Visual Editor *so* did not work. Fixed.