harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Tromey <tro...@redhat.com>
Subject State of the World
Date Mon, 09 May 2005 19:10:45 GMT
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

* 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

* 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


View raw message