Building the JDK on Debian GNU/Linux

Ivan Tarasov writes "Ever wanted to hack the JDK sources to get rid of some nasty bug which bothered you for so long, but was embarrassed by the complexity of the JDK build process? Now you have a good tutorial on how to do it on Debian GNU/Linux: last night I posted a blog entry on how to build the JDK 6 (sources of which are available at the Peabody site). This entry describes in detail which packages you need installed, how do you tweak the sources to make them buildable and how to proceed with the build. The build process for other Linux distributions must be very similar, so don't turn away if you don't use Debian. There is also a nice blog entry by Cay Horstmann "Honey, I built the JDK! (on Ubuntu)"."

Comments

Honestly?

[zBoD]

> "Ever wanted to hack the JDK sources to get rid of some nasty bug which bothered you for so long, but was embarrassed by the complexity of the JDK build process?"

=> no.

Re:That's all well and good, but ...

[Doctor Memory]

Well, duh. You've got the source, debug it!

Kids these days...

GCJ

[legoburner]

Just want to mention GCJ, the java native compiler, part of the GNU tools. It still has quite a way to go, but for some standalone applications it is getting quite nifty. I am not sure what niche it fills yet but linking a native binary built from java source code feels strange.

Re:GCJ

[kwark]

Once I thought that using gcj might be fine for running cli java programs but I found that gcj had the following problems:
-the ahead of time compiling requires ALL sources to be compiled even though they are not needed at runtime. eg commons-cli.jar depends on commons-lang.jar in gcj as opposed to use in the Sun JVM.
-it is very slow in some areas (about 3 times slower during disk IO and md5 checksumming)
-I couldn't get it to create static binaries (dev. on Debian/unstable to run on Debian/stable), but this could be my fault.

The only good thing was the slightly faster launch times (about 0.2ms on a process that runs 1.2ms total) compared to the Sun JVM. But since the program is only launched about 5 times per hour why bother.

This was with gcj-4.0 some months ago.

Re:That's all well and good, but ...

[ximenes]

I just hold the hard drive up to my ear to figure out JDK problems.

Re:License?

[ForumTroll]

IIRC you can modify it as much as you like for your own personal use but you can't redistribute it.

Re:Not the real problem

[kwark]

"I eventually solved this by using dpkg to build a one-on-one package from the JDK binary tree and told it to provide "java-virtual-machine, java2-runtime" and to make it conflict with: "kaffe, java1-runtime, java-compiler, fastjar, libjessie-java, java-common, gcj-4.0, ecj, ecj-bootstrap-gcj" after which I finally managed to get rid of the open source abominations once and for all."

Why do it the easy way with make-jpkg and the alternatives system when you can do above :)

Re:Not the real problem

[BigFootApe]

Are you thinking that Sun JDK will conflict with, say, SableVM? Milarky! You just use update-alternatives to point javac, java, javaw, etc. at Sun JDK as the primary provider of said facility.

e.g.

update-alternatives --config java
 
There are 4 alternatives which provide `java'.
 
Selection Alternative
  1 /usr/bin/gij-wrapper-4.0
*2 /usr/lib/j2sdk1.5-sun/bin/java
+3 /usr/lib/jvm/java-gcj/jre/bin/java
  4 /usr/bin/gij-wrapper-4.1
 
Press enter to keep the default[*], or type selection number: 2
Using `/usr/lib/j2sdk1.5-sun/bin/java' to provide `java'.

Simple, no?

Sorry, it would look nicer if slashdot accepted preformatted text :(