I've started writing, and then deleted, a few messages to this list
about different aspects of what I see as the solution -- using
Classpath, notes on licenses, etc. But this proved unsatisfactory and
I decided instead to start with a note about what I see as the
problems in the free java space.
First a few non-problems:
* The class library. Classpath already has a ton of code and a
reasonable approach to VM independence. The VM layer still changes
from release to release, but that will quiet down as we move toward
completion.
* Licensing. The intent of the Classpath license was that it be
acceptable for use in proprietary projects. This should probably be
its own thread, but basically, if this isn't acceptable, I think we
can work on it.
* The tool space is likewise fairly full. There are free compilers of
various sorts; also jar, javadoc, rmic, etc.
* Virtual machines (as distinct from execution engines fwiw). There
are a lot of VMs out there, suiting a wide range of needs; kaffe
alone has probably been ported to every conceivable niche twice.
Open problems
* The class library is incomplete. I tend to dump this in the 'bug'
category. Anyway, the reason the class library appears in both the
non-problem and problem lists is that it seems unlikely that a new
project would address this more efficiently than just hacking on
Classpath.
* Fragmentation. I think there are too many free JVMs. In particular
the "C/C++-based VM" niche is over-full. It ought to be possible,
though difficult, to write a configurable core VM that can be reused
by other projects. The idea here is, have a reusable reference
implementation, and reduce writing a VM to writing an execution
engine (and perhaps a GC).
* Parts of testing. While our class library tests are manageable (we
probably have fewer tests than we need, but we have a lot and adding
more is trivial), there are still entire areas (VM level tests for
instance) where there is not even the start of a shared test suite.
This becomes particularly important when you starting looking at,
say, writing a Mozilla plugin and executing untrusted code.
* TCK access. Dalibor is working on this, but this seems like an area
where Apache's insider status and superior connections could really
expedite things.
* J2ME. There has been talk about approaches to supporting both J2ME
and J2SE in Classpath using the same source base, but no real
action. This might be an interesting problem.
* Publicity. Though we try, and though we're starting to see some
successes, it does seem that just the announcement of Harmony has
generated more PR than Classpath got over the last year.
* com.sun.*. Those pesky java programmers often end up using unfree
APIs. I'm not sure what Harmony could do here; maybe pressure Sun
into make it much more difficult to do this?
As a thought experiment, look at the free JVM space from, say, the
gcj/Linux distro perspective. What is left undone? It is basically:
"where is JDWP?" (or whatever lets us debug from inside Eclipse) and
"we need a complete library".
Or, if you're interested in a more hotspot-like execution approach,
look from the JikesRVM angle... I won't speculate here, though, since
I'm not really involved with that project.
Maybe it seems like a grim environment for starting a new project.
Well, considered on technical grounds alone, it is. One needs a
pretty compelling technical story to do better than already existing
projects.
Tom
|