difference between jdk16 and diablo 1.6

[cuongvt]

Hi all
I just still not understand difference between jdk16 and jdk diablo 1.6.
And in which case should I use one over another one?
And Which one are you prefer?

thanks and regards,

[BSDKaffee]

Use jdk16 if you want to build from source.
Use diablo-jdk16 if you just want the pre-built binaries.

You need a jdk installed as a bootstrap to build jdk16.

I usually just build from source, but it is much less hassle to just use the binaries. The biggest hassle with building from source is manually downloading the files and needing an account (free) with Sun to download some of them. Plus, if you have a slow machine, any jdk will take a while to build.

[gistenjunge]

Hello,

I installed eclipse 3.3 but when I launch it, it crashes. I searched a bit and it seems, eclipse doesn't work with the diablo jdk on freebsd 7.
The solution is to build a native jdk16, but I couldn't find how to build it.
If I go in the /usr/ports/java/jdk16 directory and do a 'make install clean' it always installs the diablo jdk16.

$> java -version
java version "1.6.0_07"
Diablo Java(TM) SE Runtime Environment (build 1.6.0_07-b02)
Diablo Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode, sharing)

I also tried the linux-sun-jdk which installed without errors, but didn't work at all (I have the linux compatibility enabled).

If anyone has a solution, I'd appreciate it. I guess I simply need to add an option, but I'm new to freebsd and so far my search hasn't been successful.

[TerryP]

If you get a crash message on eclipse start up about being unable to find a suitable JVM, set JAVA_HOME or call /usr/local/eclipse/eclipse directly.

[mdh]

Interesting advice, Terry... I wish I'd had it before I went off upgrading boatloads of ports (as other resources I found via googling suggested)... in the end, eclipse worked just fine, but it took a lot more effort than just setting an env var...

[TerryP]

Perhaps post it for the next sap ;-)


I've tested Eclipse on a few systems, but found getting it into a usable *and* updated state to painful to bother with under FreeBSD.

[mdh]

Originally Posted by TerryP

Perhaps post it for the next sap ;-)


I've tested Eclipse on a few systems, but found getting it into a usable *and* updated state to painful to bother with under FreeBSD.

I've got it working fine now. I think the eclipse port may have a lot more issues than the eclipse-devel port. There was one bug in eclipse-devel which I tested the patches for from the maintainer, but iirc he's got them in the ports tree now. You may want to try that one and see how it works - I know you'll need jdk16.

I even hacked the other plugin ports to work with it, since it installs to /usr/local/eclipse-devel (so you must create a symlink to it from /usr/local/eclipse for the other plugin ports to install.) I also got subclipse installed just fine externally, since there isn't even a port for that.

[robbak]

For others having problems with diablo/JDK, I'll explain.

Building java is a chicken-and-egg problem. The java build process requires java. Although this sounds strange, it is a normal procedure - most C/C++ compilers are written in C/C++.

So you need a copy of java installed to build and install java.

Here is where it gets tricky. Sun, the company that holds copyrights on the java code, refuses to allow distribution of pre-compiled java binaries that have not been through their rigorous and expensive testing. While this is meant to provide a uniform java experience, it tends to provide for a uniformly annoying java experience. So, I guess it succeeds! It means that you cannot just go and grab the current JDK16 build from your nearest FreeBSD package mirror, because Sun says we cannot provide it for you.

Enter the FreeBSD Foundation. They funded the work to produce patchsets to allow java to build on FreeBSD, and funded the testing to get Sun's stamp of approval on the resultant binaries. Those binaries are the diablo ports. If you install diablo, you are getting a copy of the Sun-approved binaries.

The downside of this testing process rapidly becomes apparent. See, diablo has bugs, like all software. Normally, we'd just throw a patch in the /files directory of the port, rebuild, and the regular ports building cluster would throw a new fixed binary onto the mirrors. But we cannot do that. In order to distribute the fixed binary, we'd have to get it re-certified by Sun. So the certification procedure just ensures that a broken build (even a very slightly broken build) must remain there, causing problems.

So, the procedure is:
1. Get diablo.
2. Use diablo to build jdk16 (after manually fetching the source files, so you can click the "I agree" button. You have to agree to something, I'm not sure what. It's all thoroughly meaningless, but all part of that uniform java experience I talked about.)
3. Uninstall the broken diablo, which we never wanted in the first place.

The solution will come when Sun finally releases java under a truly Open Source license. (It will probably be GPLish, which we will have to grin and bear.) Then getting java will be a matter of a simple pkg_add command, like it should have always been.

Bitter? Not me.

[mdh]

Originally Posted by robbak

While this is meant to provide a uniform java experience, it tends to provide for a uniformly annoying java experience. So, I guess it succeeds!

Bitter? Not me.

I lol'd.