Free JavaOne

I read that there will be a Open
Source Java
panel at JavaOne this year. Thanks to Wes Felter for this,
and for pointing out that Sun failed to invite any actual Free Java
hackers to talk about this.

I really messed up by not going to the conference this year.
Bummer. So, on the off chance that someone attending JavaOne might
read this, I’ve come up with some questions you might want to ask and
some things to bring up.

No funny business

The aforementioned article quotes Gosling as saying, “Most of the
folks in the open-source world have a pretty simplistic view of the
landscape”. Oh, come on. Let’s name names, let’s not make
unverifiable assertions about what “most” of any group wants, etc. In
other words, let’s be really honest with each other.

So, if Gosling, or anybody, says something like this at JavaOne,
please push back strongly. An argument like this is just a way to
make it hard to refute what someone is asserting.

Forking

You’re certain to hear the forking argument from someone on the
panel. This argument goes, compatibility is one of Java’s biggest
selling points, and if Java is made open source, this property will
be lost. This argument is wrong on several counts.

First, Sun will still control the “Java” brand. So a fork won’t
be called Java, just as White
Box Linux
isn’t called “Red Hat Linux”.

Second, Linux vendors won’t fork Java anyway, just like they don’t
fork Perl, Python, Eclipse, or hundreds of other things. True, there
is “forking” in the kernel, but this is explicitly encouraged by the
kernel development model. And there is some forking in gcc, but if
you look at what actually happens, all the changes are closely
coordinated with the upstream developers — and gcc’s various ABI
stability problems will not be inherited by Java, as gcc’s problems
originate upstream.

Problems? What problems?

Sun invariably says that they can’t think of what problems open
source Java would solve that aren’t already solved. Of course that’s
ridiculous. It is pretty hard for Linux vendors to ship a working JRE
on their platform if they make any sort of changes at all — the Java
vendors are just too slow. And Debian can’t ship a complete Java at
all, so lots of Java software ends up in unfree.

On top of this, non-free core software is something to be avoided
in the community. This overly-controlled approach on Sun’s part is
losing the Linux desktop to .NET. I’m curious to hear what Sun has to
say about this. Do they notice this? Do they care? Do they think
there is some other strategy to change this?

What we want

Instead of listening to various uninvolved people project their
beliefs onto Free Java developers, how about standing up and giving a
little speech about what it is we really want? This is pretty
simple, and it would be a nice community service.

  • While open sourcing Sun’s implementation would be wonderful, it
    isn’t actually necessary. I do think that opening their
    implementation would help both Sun and Java, perhaps not in the short
    run but certainly in the medium-to-long term.
  • We would like open access to the TCK for free implementations.
    We also believe in compatibility, and go out of our way to provide it.
    In fact, sometimes Sun makes this harder than it needs to be, see this
    thread
    . I’ve occasionally read statements indicating that the TCK
    is available, but it simply isn’t true.
  • We would like the subsetting restrictions to be lifted a bit.
    They are basically incompatible with the open source development
    process. I’m sure we could work out some kind of viable compromise
    in this area, preserving both our ability to hack how we like and
    Sun’s desires for completeness and compatibility.

Be the first to leave a comment. Don’t be shy.

Join the Discussion

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.