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
