On Thu, 10 Jul 2003, Jim Wise wrote:

: When we have a native JDK of a more recent vintage, this problem (and
: the installation of these packages from binary distributions) should go
: away, allowing the type of local customization (compiler used,
: optimization options, etc) which come with a source-based pkg install.

Optimization?  What optimization?  8-)

I'm actually half serious there.  Java quite different from C in that you
don't gain all that much from using a different compiler or different
compile options -- except if recompiling for an *earlier* JVM when the
original .jar creator explicitly compiled with "-target 1.3" or similar.
JAR files are meant to be compiled only once and run on whatever JVM is
desired; there is little point to recompiling them in pkgsrc.

(This has been one thing that has irked me about the Java packages in pkgsrc
that *do* build from source, such as Ant.  "What the hell for?"  Ant, in
particular, has "optional" tasks that won't even be compiled into the JAR
files if the optional dependencies are not available.  As a binary
distribution, however, Ant can use these optional dependencies simply by
installing the appropriate extra JARs in parallel.)

There are other things, too, like optional dependencies.  Java classes can
reference external class libraries, even if they are not available in a
given installation (and thus they can be ignored).  Whereas this would be a
link-time error in C, it is only a compile-time problem in Java; linking at
runtime only requires what the user really needs to run the desired features
of the main program.

So, in most cases, I'd still recommend using binaries as-is if they are
supplied, regardless of JVM in use.

-- 
-- Todd Vierling <tv@pobox.com>