There’s more noise from Gosling
about open-sourcing Java. You can also read about it on sys-con.com
and, of course, SlashDot.

Gosling usually dissembles a little when talking on this subject,
and some things are usually unclear, so I’m going to go point by
point. Also on SlashDot we see the usual misperceptions, but since
they are very common in the Java development community I’ll take them
on as well.

Why does IBM send open letters?

I don’t know why they send them. Gosling’s claim is that this is
“kindergarten-ish”, but we don’t really know that IBM hasn’t already
tried direct talks with no resolution. Also take a look at IBM’s
comments on most of the JSRs they participate in…

One might also reasonably ask: why doesn’t IBM just write a free
Java themselves? They already have a lot of the parts: two excellent
compilers (jikes and the one in Eclipse), the JikesRVM virtual
machine, contributions to Classpath, ICU, plus lots of other bits they
hold more closely (the J9 VM). The answer to this question can only
be that they’ve signed something with Sun preventing them from doing
so. The reality is that IBM could easily write the missing parts of
Classpath, if it liked.

BTW, for those following along, I never did get a reply from Bob
Sutor. I’m not really surprised, but it is a bit disappointing.

Doesn’t IBM already have the source?

Gosling is at his most deceptive here: “Which means that about the
only thing that they could get from liberalization is to be able to
skip testing.” To hear him say it, the JVM licensing is just like
open source, except for a testing requirement. If only this were
true. The truth is, the TCK costs money. It has never been available
to any free software implementation under an acceptable license.

As I’ve said many times before: it would be great if Sun opened
their implementation. That would be really wonderful (even though it
would probably kill literally years of my work :-). However, it
isn’t strictly needed. Instead we really just need three things to
make a Free Java:

• Access to the TCK on acceptable terms
• Involvement in the JCP without contamination or other
  unacceptable constraints
• Easing of the requirements on subsetting

Hasn’t IBM helped with Java already?

Well, sure they have. Gosling makes a big deal out of the
Swing/SWT thing, but I see that as just a technical dispute, not a
major political one. It’s a mistake to assume any company like IBM
acts with a single mind; I’m sure even in the Eclipse project there
are dissenting voices. For instance, the VEP plugin works with Swing.
And, as for IBM championing Swing and then going with SWT, which looks
more AWT-ish (but isn’t), well, we all make mistakes. So what?

In the bigger picture, I don’t care why IBM wants Java to be free
software. Their motivations are their own. Mine are the same ones
that have been my passion for nearly 14 years now: the ability to fix
bugs that affect me, to add features I think are needed, to work on
projects in cooperation with like-minded comrades, to avoid being
locked in to any one company’s view of the world. Personally I find
APIs wonderful, but even good documentation is no substitute for an
occasional (contamination-free) look underneath the hood.

If you look around at the commercialization of free software, one
thing you’ll see is that different companies come along and try to own
some critical piece of infrastructure. They want to impose a private
tax on free software, setting themselves up in a privileged position.
To my mind this is antithetical to the goals of the movement as a
whole. The point is to avoid these taxes — the infrastructure must
be free. We have to fight these wherever we find them; unfortunately
a fair part of the free Java world has fallen for Sun’s bait.

Will IBM open DB2 and WebSphere?

Gosling throws this in, in an attempt to change the subject. We
aren’t talking about DB2 or WebSphere, we’re talking about Java. For
all we know, IBM doesn’t even own all the IP in these and couldn’t
free them if it wanted to. Heck, companies have lost the
source to their programs before, maybe that happened and
they’re just too embarrassed 🙂

Developers are afraid that Java will fork

This is one of the big ones, the real reasons that we can’t blow
off and that aren’t mere spy-vs-spy stuff.

What does it mean to fork Java? Or to fork anything? I know this
sounds metaphysical and sort of stupid, but I’m serious. Suppose we
all take the Java source and just go crazy, adding features, removing
APIs, all those bad things. Well, Sun — or, hopefully, some more
neutral entity like a nonprofit set up for that purpose — will still
control the branding. Remember the flap about “gcc 2.96”? I still hear
about that from time to time (and I don’t recall ever once hearing
anything nice). That was all a branding problem, not a forking
problem per se. There’s a strong sentiment in the community that the
upstream project controls the brand, and you violate this at your
peril.

Second, the truth is, Java has already suffered most of the bad
effects of a fork. While Sun has in general done an excellent job of
keeping Java compatible, there are still places where it is not.
There is valid bytecode that will verify in some releases but not
others. All releases have bugs of various flavors. There are APIs
that never quite worked, or that are underspecified. There are even
a couple cases where Sun has violated binary compatibility by
changing constants or interfaces. Java programmers already have to
pick specific target versions and test on multiple platforms.

(Don’t get me wrong. In this area Java’s promises are, generally,
on target. When developing libgcj, we’ve noticed that most pure Java
changes are much simpler than changing target library code in other
languages, simply because the portability story is so much simpler.
You just don’t have to do as much work, and the idea of an
autoconf-like tool for Java is delightfully absurd.)

Third, another truth in the free world is that the upstream
projects usually have significant control, and the Linux vendors
generally have a strong commitment to compatibility. Sure, you do get
some horse-race effects where one vendor or another will try to put
out a release with some feature or kernel version earlier than anybody
else. However, this isn’t a problem — this is a strength! For
instance, if Red Hat puts out NPTL, or SELinux, or whatever, this
gives the community a platform on which to test and modify their
applications in advance of general acceptance. And if a feature turns
out to be a bad idea, it just disappears.

For something like Java, everybody already recognizes that one of
its strengths is its cross-platform API compatibility. It would be
dumb to hurt that, sort of like adding a gratuitously incompatible
change to Perl or Python. Why would anyone do that? The whole point
of shipping the thing is to enable your customers to run the code they
already have, or code that they get elsewhere off the net.

So, I think an open Java would in fact not fork in any
significantly harmful way. I expect we would see some minor
implementation divergences, perhaps process ports of different quality
across distributions, different default UI themes, etc. That is,
mostly trivia, and the non-trivial would be merged upstream gracefully
(assuming upstream is in fact a graceful place with which to merge —
process matters).

Maybe Sun is worried about malicious entities out there, i.e.,
Microsoft. That’s sort of an absurd worry at this point, seeing that
MS now has .NET. (Sun could have plenty of other worries too; they
don’t share them with me 🙂

Patents

To my mind, the various tos and fros about Java are not very
important. It is a bit entertaining to see Sun put out Open Source
feelers occasionally, then watch everyone get riled up over nothing.
Whee! The various Free Java efforts will get there eventually — it
might not seem like it right now, but that’s how free software works.
It never seems real until suddenly it is better than what you’re
selling.

The real danger we’re facing comes from patents. Microsoft, IBM,
and seemingly everybody else is patenting things as fast as
possible. This is a huge hole for our community, and I’m really
concerned that in a few years we’ll be left unable to ship anything
meaningful. It seems that most new technologies come with a raft of
bad patents attached.

The solution? I think we need a Free Patent Foundation, that
helps free software developers file patents, and then uses them for
the benefit of the whole community. The goal would be to get a broad
enough range of patents that we could force cross-licensing with
everybody, sort of eliminating patents as a relevant force.

That’s the dream anyway. I have no clue how to set this up.

Tonight I’ve been thinking about making Nyquil-flavored ice
cream. I need sleep.

I just got back from the Red Hat world-wide meeting. That was
pretty cool, I met a lot of cool people, including many Java hackers,
talked to a lot of people I already knew, lost a lot of sleep, etc.
I also found out that I’m not the only Red Hatter in Colorado, which
is cool since it means I can get together with other folks to
complain from time to time 🙂

It turns out that some folks at Red Hat who did the recent “world
tour” event shot a lot of footage and are editing it into a movie. So
Red Hat is now officially making something approximating the movie
that the Red Hat Foundation rejected years ago… sigh.

GCC Summit

The GCC Summit is
fast approaching. I found out today that mjw will be there. A
lot of gcj folks will be there too, and hopefully gadek will be able to
make it. I really should finish that paper…

O’Reilly

It turns out that there will be a session on “Open
Source Java” at the upcoming O’Reilly open source conference.
Really there ought to be someone from the Free Java community on this
panel; as soon as I find some way to give feedback I’ll bring that up
with the conference folks.

GUADEC

At least one person from the gcj community ought to go to GUADEC and give a presentation on
gcj. If only we had figured this out before the paper submission
deadline. Perhaps we can get some sort of special dispensation.

I checked in a bunch of Eclipse-discovered Classpath cleanups
today. Fun.

I’ve also done a fair amount of Eclipse debugging. For various
reasons I don’t run FC 2 on my main machine, just on my old machine.
But it is old and doesn’t have enough memory; in fact, not enough
memory to run gdb on the gcj-compiled Eclipse. Sigh. So I’ve been
doing all my debugging remotely from Toronto, which is pretty
painful.

Meeting

This weekend I’m going to North Carolina for a big Red Hat
meeting. That should be pretty interesting, I’m looking forward to
seeing some, um, comrades. Every time I go to one of these things I
think about reviving the free software movie… maybe next time.

D

I look at the D
Programming Language a little, but stopped when I found out it
doesn’t support dynamic class loading. For me that is a very
interesting feature, basically required. I also think that the
ability to run untrusted code is cool, but in practice folks don’t
really seem to use it all that much. Also, nested
functions are gross, though D’s approach does remove some of the
implementation difficulties (scheme folks, go ahead and yell at me).

Still, overall D seems reasonable enough. With some minor-ish
changes it might be an acceptable Java/C# replacement for the free
world.

I didn’t see any info about licensing on the web site, except for
a weird statement about intellectual property and patents. That’s a
bad sign.

Surprisingly to me, there was some resistance from a couple
Classpath folks to checking in the two files needed to let Classpath
be checked out as an Eclipse project. Weird.

Eclipse’s compiler found a lot of minor problems with Classpath —
about 700 warnings, most of which are trivia like unused
import statements. Mixed in were a few outright bugs,
however.

Tonight I set up Classpath as an Eclipse project. This was
pretty easy, really, just fiddling with exclusion filters and other
build trivia until it worked.

I had to make a couple little hacks to get this to work. In
particular I had to make my own Configuration.java by
hand. There are a few plausible approaches to making this work in a
nicer way, maybe I’ll investigate that.

Unfortunately, Eclipse doesn’t seem to share the per-project
compiler settings. If true, that seems like a nuisance since it means
that everyone will have to go through the settings by hand. The same
seems to be true for project-specific editor settings, e.g. tab stops.

The Eclipse Java compiler has a number of nice warnings that will
help us clean up some parts of Classpath a bit. I’ll have to remember
to steal these for gcjx.

Anthony
writes about approaches to make distcc work well with gcj. This
is tricky because distcc works by preprocessing your C or C++ source
locally, then shipping the result to another machine for
compilation.

There seem to be a few plausible approaches to doing this. One
approach is to modify gcj itself. gcj could read your source, analyze
it, find all the dependencies, and then package up a jar file that you
could send remotely. At the remote site you could invoke gcj pointing
at just this jar file. The drawback of this approach is that it
requires invasive and complicated changes to gcj. You might think
there is also a performance problem here, but in practice parsing and
analyzing java source is pretty cheap, code generation is what takes
the most time.

Another approach Anthony puts forward is the idea of using
an LD_PRELOAD library to catch all open
calls and have the remote compiler ask your machine for the files in
question.

Actually I think this is kind of cool, though it does beg the
question of why you don’t just set up NFS, since after all you’re
serving files. This puts all the nasty potential security problems
into a known framework.

Anyway, I think that his approach will work ok. It would be
interesting to see how well it performs. It looks like his approach
caches the files it opens, meaning that for a large compilation the
number of files shipped over the network will dwindle. Another
benefit of this approach is that the debugging information will always
turn out right, since gcc will always request things by their real
names. Neat.

One remaining approach is to just write a wrapper for gcj that
ships everything mentioned on the class path to the remote server. If
the class path includes a directory, just ship all the java files.
You could use rsync for this to avoid shipping files more than once.

This was billed as a comedy, but in the end I laughed honestly
only at one point in the movie — the bit with the brown sauce. But
otherwise, when I laughed, I was laughing at the movie, or at the
incredible stupidity of its characters. I really disliked it, on the
order of Va Savoir or one of those other movies that some folks like
and rave about, but which I just find bafflingly boring.

I read an
interesting bit in Gosling’s blog. Check out the fourth bullet
about patent licenses and other legalities.

One suspects that perhaps he’s wrong about this, though, just as
he’s wrong about free software.

He writes: “[Stallman] has his own rather peculiar definition of
“Free” that I think violates the First Law of Thermodynamics (energy is
conserved)”. But that’s the case almost everywhere in the world we
live in — otherwise, where do profits come from? And anyway, I don’t
like these bad physics analogies. Intention, drive, dedication,
whatever — they aren’t like energy in the sense of physics and aren’t
subject to the same rules. This should be obvious.

Santa Fe

I forgot to mention something, which is that every time I’m in
Santa Fe I think about Christopher
Gabriel, who I met once while visiting Mark a few years back.

Panel and libgcj

My girlfriend, who still uses Windows (boo, hiss) downloaded some
program from the local TV station that will show the temperature and
weather conditions in a small box on the equivalent of the Gnome
panel.

It occurred to me that we should probably be able to write Gnome
panel applets in Java, ideally with security protection and minimum
fuss. Then, ideally, you could just drag jar files from Mozilla to
the panel and the applet would show up.

This could probably benefit from Michael Koch’s work on gcjwebplugin. It seems
like a fun project, but at the moment I’ve got too many other things
going on.

RMS posted his Java
Trap article. It is basically reasonable, the sorts of things
we’ve been talking about for a while. The reader comments are
amazingly trollish, about what I expect from the non-free Java world
these days. Personal favorite quote: “I mean, if GCJ is languishing
miserably and is continuing to bump along the bottom, that’s no one
else’s fault than the one of the bunch of idiots running that
show”.

Hello, fellow idiots. You know who you are.

Vacation

Santa Fe was cool, and it was great seeing Mark again, but while
I was gone my dogs got into another fight and Maude had to go to the
vet again. So their difficult situation is getting worse 🙁

It mostly snowed while we were there so we stayed inside and read
a lot.

Bryce

It should come as no surprise now that Bryce is working at Red
Hat. So, welcome Bryce. Now get to work!

Monotone

While playing with monotone again, I discovered
that there are a couple of duplicated “,v” files in the Classpath CVS
repository. For instance, we have both
javax/swing/plaf/UIResource.java,v and
javax/swing/plaf/Attic/UIResource.java,v. I wonder how
that happened… it is a “shouldn’t happen” situation.

The Attic copies of the files look like ancient dead versions
that were deleted. Which makes sense. What doesn’t make sense is
that the files weren’t moved out of Attic when resurrected.

I’ve also heard that NetBSD uses a hacked CVS that will create
situations like this on purpose. I wonder what use that serves. If
you know, tell me about it.