Perl Doesn't Suck

What follows is a long, detailed summary of an attempt to install JDK 1.2.2
on FreeBSD today.  FreeBSD/JDK 1.2.2 is an unsupported configuration for Sun,
although patches exist to get the JDK to work under FreeBSD.

Skip to the last two paragraphs if you want to see how this installation
compares to a standard Perl installation, and what this means for Perl.
Please read the rest if you want to see what a 'simple' installation took
for this version of Java.  (Note: JDK 1.1.8 is supported, but JDK 1.2.2 isn't,
and some software requires JDK 1.2.2 (Java2)).

Comments welcome.

Z.

-------------------------------------------------------

I recently had occasion to upgrade Java on my FreeBSD installation at
home.  I have both the Java Runtime Environment (JRE), v1.1.8 and Kaffe
1.0.6.  I deal with XSLT a lot, so keeping these around is a necessity
when dealing with XSLT engines, such as Michael Kay's Saxon and James
Clark's xt.

The JRE apparently comes directly from Sun and contains only the virtual
machine required to execute Java programs.  It lacks things like
documentation and javac, the Java compiler (written in Java).  JRE 1.1.8
implements the Java 1.1 specification, which appears to be useful, but
out of date compared to the current Java 2 specification (JDK 1.2 and
above), and the imminent Java 1.3 release.  (I'm going on memory here;
there's so much *stuff* on java.sun.com, it's quite difficult to
easily determine whether Java 1.3 is shipping, in a late beta cycle
or in an early PR cycle.)

As the name would imply, the JRE is just that - a runtime environment.
Unfortunately, it's not the kind of "run anywhere" environment you would
expect from Java.  To be fair, it's only Java 1.1, and that's OK.  But
it's insufficient for running applets in my favorite web browser du
jour, Konqueror.  So I installed an Open Source reimplementation of Java
1.1, Kaffe.  Now, whenever I visit java.sun.com, Konqueror loads and
runs the applets through Kaffe, and I get a familiar grey box which says
"Loading Applet".  And a core file from Kaffe whenever it's invoked.
But Kaffe also runs Java programs without a hitch, just like the JRE.
(Note: Kaffe may not be fully compliant, but it runs what it's supposed
to run, and it doesn't crash, except within Konqueror and running
applets.)


At this point, you probably think this is another rant about Java being
a bad language, unsuitable for software development, or an example of
immature software being thrust upon the uncaring public.  It's not.
Java is a fine environment, and until today, I never had to think about
it, even though I use programs written in Java every day.  The fact that
Saxon is implemented in Java is an unimportant fact that sits buried in
a Makefile or two.  It's as unimportant a detail as cvsup being
implemented in Modula-3.

In a sense, that's the hallmark of good software -- it should do a job,
do it well, and stay out of the way.  The JRE and Kaffe do that with
Java 1.1 software.

If only Java 2 would be so unobtrusive.


I installed Java 1.2.2 today because I want to start using other XML
technologies, like SVG.  The Apache XML project is working on a project
called Batik that will do pretty much anything with images in the SVG
format.  All I really want to do is generate SVG files using XSLT, and
translate vectorized SVG files into rasterized PNG images.  Batik
promises to do that, and much, much more.

As I said before, I'm running FreeBSD.  This should be a simple pair of
commands: 'cd /usr/ports/java/jdk12-beta; make install'.  The native JDK 1.2
port appeared within the last few weeks or so; previously, to run JDK
1.2 applications, the Linux JDK needed to be run, and that was one too
many levels of emulation to consider.  

So I start with the obvious.  And it doesn't work.  To install the
jdk12-beta port, the JDK sources and patches need to be downloaded
manually; this is because of some licensing issues with Sun, where the
sources are available only to registered developers.  Annoyed, I
register and get the sources, and then the patches.  Due to poor web
design on Sun's site, it took a while to actually find the links for
downloading the sources -- it's almost like Sun doesn't want you to find
them.  Getting the patches was easier, although it also involved a
clickwrap check, since the patches are only available to developers who
have registered with Sun's developer program.  (Who *else* would be
interested in patches to the JDK?)

Having downloaded, about 18MB of software, I start the build process.
Yes, the JDK sources are about 18MB.  Compressed.  Now time to let the
port build itself.

The wonderful thing about ports is that build and runtime dependencies
will be checked, and installed as required.  After downloading,
extracting and patching the 18MB JDK 1.2.2 sources, the very next thing
that happens is that the full JDK 1.1.8 is installed as a build
dependency (Sun's JDK, as binaries, including 'javac').  

Then the Linux version of the JDK 1.2.2 (binaries again, including
another 'javac', this time from the Blackdown group).  

Then UNIX ODBC drivers.  I don't care about database connectivity,
I just want to run Batik, which doesn't use any databases whatsoever.

Then the OpenMotif binaries are downloaded.  This makes some sense,
since the Java supports platform agnostic GUI development.  Do I care?  No.

At this point, I haven't even started compiling the JDK sources, but
I've downloaded an additional 35MB of software, some of it for build
dependencies (two *additional* JDKs), some of it for runtime
dependencies (ODBC, Motif).

So far, 54MB downloaded.  Slowly.  Over a dialup modem.  Perhaps the
port is broken.  Perhaps not.  Like many compilers, javac is written in
the language it compiles, so there's a bootstrapping problem.  I can see
why at least one JDK is required.  Perhaps there's a reason why both JDK
1.1.8 and JDK 1.2.2 are both required to compile the JDK.  But I'm not a
Java programmer, and I don't really care.

Now it's time to build and compile the JDK from Sun's sources.  Except
there's one glitch: we also need the JFC, also available from Sun, and
downloadable as source once you've hunted long enough.  Another 12MB
download that must be done by hand due to licensing reasons.  The
download doesn't complete in time, and when the JDK compilation fails,
and must be restarted.  Not a big deal, but this is getting annoying.
And we're not out of the woods yet.


Finally, with all 65MB of the sources downloaded (and licensed), and all
of the build prerequisites downloaded and installed, it's time to start
compiling the sources.  The build dependencies take up some disk space,
about 89MB.  And compiling the JDK (a mixture of C and Java sources)
takes up some space too -- about 259MB.  Thank goodness disk is cheap;
this is about half as much disk space as it takes to compile *all* of
user-mode FreeBSD-CURRENT (the standard binaries in /bin, /usr/local,
etc.).

Eventually this process finishes, with one more runtime dependency, the
URW font collection.


As I'm sure you can imagine, this was a disgustingly slow process.  It
would have helped to have a high-speed connection to the internet, but
that would only address some of the issues.  As AT&T is quite fond of
pointing out, only 8% of the population of the US has high speed
internet access at home, and that number isn't likely to increase
significantly or quickly.  And what about the rest of the world?

And what about the larger problem?  Java is supposed to be a
write-once-run-anywhere environment.  From looking at Sun's website,
their definition of "anywhere" is somewhat limited.  It used to be
the adjective "cross-platform" when applied to software meant any
commercial UNIX running on one of a half-dozen CPU architectures,
and possibly non-UNIX environments like VMS, OS390, MacOS and some
varieties of Windows.  Today, "cross-platform" has been co-opted to mean
*both* platforms: Windows and Linux on an x86 CPU.  In Sun's case, it
means all *three* platforms, Windows, Linux and Solaris.  Somehow, this
definition of "cross-platform" and "anywhere" doesn't fit in well with my
view of reality, running FreeBSD on x86.  I hesitate to think what would
happen on other operating systems like VMS, or other CPU architectures
like Alpha or PowerPC.


Now, at the end of the day, I have no fewer than five JVMs installed,
all completely different implementations of two Java standards.  As a
Perl programmer, I find this abhorrent.  Installing any version of Perl
release in the last 7 years is no different from installing any other
release: download, extract, ./configure -des, make, make test, make
install.  Done.  All self contained (modulo a C compiler, shell and make
utility).  All truly cross platform.  Furthermore, very recent version
of Perl are getting a bit weighty at 7MB, still shy from the 18MB source
distribution for an old JDK (30MB if you include the JFC sources).  And
with Perl, cross platform still means cross platform,
write-once-run-anywhere still means write-once-run-anywhere.  For those
who don't want source distributions, there are a small number of binary
distributions for the more popular platforms, such as Windows, Linux and
Solaris, all typically smaller than 15MB.

What does this mean to the average Perl user?  If my experiences are any
measure, Perl is much easier to install and support than Java,
especially on "boutique" platforms that are outside of what one
controlling vendor considers mainstream.  Would I want to deploy an
enterprise class application written in Java on network of *BSD
machines?  Not if I need to go through this mess again.  Would I want to
deploy an enterprise class application written in Perl on a network of
*BSD machines?  Yes, without a moment's hesitation.