As I understand it there is no TCK coverage for Swing (which will
probably make that a long trip frankly) and well AWT is what AWT is. It
is unlikely that we'll achieve a satisfactory swing implementation for
some time (though there are approaches that I've seen for automating
unit tests for it). Secondly, Java applications and applets more or
less suck. There are exceptions, I agree, I know, etc. However, the
approaches to GUI in the product called "Java" are simply not
competitive (and I've no real solid knowlege of SWT, but I've programmed
enough with other toolkits to know what I'm missing). So for an
achievable simplicity initial focus should be on #1 and #3. Obviously
we'll need to cover the rest eventually.
-Andy
Tom Tromey wrote:
"Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes:
Geir> In the meantime, any comments on architectures of some of the VMs?
Geir> I'm interest in having a balanced amount of upfront design that
Geir> prevents us from preventing participation from unexpected places in
Geir> the future...
This is too vague -- we don't know much about the unexpected. Plus,
in most cases, the "core" part of the VM is simply not very important.
There just isn't much code there -- JamVM is 20KLOC, anybody could
comfortably rewrite this.
Instead I think Harmony should look at 2, and possibly 3, use cases:
1. Server use, e.g., some J2EE thing.
2. Desktop / applet use.
3. Embedded use (maybe).
For 1, the execution engine and GC is really crucial. This is an area
where hotspot-like dynamic recompilation implementations shine, IMO.
For 2, again IMO, a gcj-like shared library approach is probably more
useful. This is especially true if you expect to run more than one
program using a given library, since in this case you are talking
about controlling memory costs of the user environment as a whole.
For 3 ... "embedded" covers a lot of ground, but I wanted to emphasize
size-critical applications. In this arena you sometimes see folks who
care more about size than performance. This affects choice of
execution engine.
I think it is possible to work well in all 3 environments with a
single VM source base (though perhaps with different compilations of
it).
I think one way to do this would be an LLVM-based approach. This
would require LLVM improvements, but let's be very clear about this --
*any* approach we take to get to #1 and #2 is going to require a lot
of compiler hacking. First, JITs have to be upgraded over time.
Second, even with JikesRVM I think we're talking about at least
writing new ports and an infrastructure for debuggers.
One nice thing about the LLVM approach is that, hopefully, we could
leverage other people's work. This is one reason gcj has been as
widely ported as it is; the core gcj developers hardly ever do any
architecture-specific work but instead we just inherit it from GCC.
Tom
.
--
Andrew C. Oliver
SuperLink Software, Inc.
Java to Excel using POI
http://www.superlinksoftware.com/services/poi
Commercial support including features added/implemented, bugs fixed.
