Debian java confusion

On my Debian laptop, I've been having several java apps hang up on me and need to be killed. Primarily, these have been UI apps, like MagicDraw and UI installers, Like Metro 1.4, which I needed for NHIN Connect.

Looking into this, I found two versions of java installed, the 1.5 Gnu Compiler for java, and the 1.6.0 JDK from sun.

/usr/lib/jvm$ ls
java-1.5.0-gcj-4.3-1.5.0.0 java-6-sun java-6-sun-1.6.0.12 java-gcj

So which am I running?

/usr/lib/jvm$ which java
/usr/bin/java

Which is a symbolic link to /etc/alternatives/java. Looking further, looks as though /etc/alternatives is pointing to a mix of 1.5gcj/1.6jdk. This is somewhat less than ideal.

/etc/alternatives$ ls -lgo ja* | grep gcj | cut -c34-
jar -> /usr/lib/jvm/java-gcj/jre/bin/jar
jar.1.gz -> /usr/lib/jvm/java-gcj/man/man1/jar.1.gz
java -> /usr/lib/jvm/java-gcj/jre/bin/java

jeff@oci1412:/etc/alternatives$ ls -lgo ja* | grep sun | cut -c34-
jarsigner -> /usr/lib/jvm/java-6-sun/bin/jarsigner
jarsigner.1.gz -> /usr/lib/jvm/java-6-sun/man/man1/jarsigner.1.gz
javac -> /usr/lib/jvm/java-6-sun/bin/javac
javac.1.gz -> /usr/lib/jvm/java-6-sun/man/man1/javac.1.gz
javadoc -> /usr/lib/jvm/java-6-sun/bin/javadoc
javadoc.1.gz -> /usr/lib/jvm/java-6-sun/man/man1/javadoc.1.gz
javah -> /usr/lib/jvm/java-6-sun/bin/javah
javah.1.gz -> /usr/lib/jvm/java-6-sun/man/man1/javah.1.gz
javap -> /usr/lib/jvm/java-6-sun/bin/javap
javap.1.gz -> /usr/lib/jvm/java-6-sun/man/man1/javap.1.gz
java-rmi.cgi -> /usr/lib/jvm/java-6-sun/bin/java-rmi.cgi
java_vm -> /usr/lib/jvm/java-6-sun/jre/bin/java_vm
javaws -> /usr/lib/jvm/java-6-sun/jre/bin/javaws
javaws.1.gz -> /usr/lib/jvm/java-6-sun/jre/man/man1/javaws.1.gz

Easy enough to (attempt to) fix:
/etc/alternatives$ sudo rm jar
/etc/alternatives$ sudo ln -s /usr/lib/jvm/java-6-sun/bin/jar ./jar
/etc/alternatives$ sudo rm java
/etc/alternatives$ sudo ln -s /usr/lib/jvm/java-6-sun/bin/java ./java
/etc/alternatives$ sudo rm jar.1.gz
/etc/alternatives$ sudo ln -s /usr/lib/jvm/java-6-sun/man/man1/jar.1.gz

And verify:
/etc/alternatives$ ls -lgo ja* | grep gcj | cut -c34-

Problem Solved!

Java Web Services using BPEL

I've been exploring the Web Services implementation in Java, specifically within the GlassFish container.

I ran across this screencast of a Simple BPEL Process with a Web Service Binding. I'm curious what you think of this screencast. Many RESTful Rails and SOAP/ASP.NET developers will laugh at what has to be done to build this "simple" process.

Here are my takes:

A simply insane number of mouse clicks to create the process. I tried counting all the necessary mouse clicks and came up with:
* Create BPEL module project: 9 clicks
* Import XSDs: 14 clicks
* Create WSDL: 18 clicks
* Create BPEL process: 54 clicks
* Create and deploy composite application project: 26 clicks
Or a quick 121 clicks total. I was absolutely stunned at how complex this is. If this seems normal to you, find an ASP.NET web service screencast, or Creating a weblog in 15 minutes, which uses Ruby on Rails.

Tight coupling between the technology and the tool makes for heavy reliance on a vendor. Watching this video, could anybody create this without Netbeans? Recently the NHIN Connect project decided to drop GlassFish ESB and BPEL. Part of the reason cited was that the integrated solution could not keep up with the individual components - the integrated tool could not keep up with GlassFish, open ESB, and Netbeans.

How long would Hello World take in this process? Probably 20 minutes - unacceptable.

BPEL and WS-* seem to be a perfect match for each other. Developers hate the complexity of WS-* (nicknamrf WS-Death Star) , and similarly hate all the overhead/configuration in a Java project. Put two hated technologies together, and then you've got something.