harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: JIRA and SVN
Date Mon, 23 May 2005 12:08:52 GMT

On May 21, 2005, at 12:11 AM, acoliver@apache.org wrote:

> As I understand it there is no TCK coverage for Swing

I'm not so sure w/ the TCK for J2SE 5.

> (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).

One fantasy is that Sun might be so good as to donate an  
implementation, so that we can be sure that we have something that is  
compatible for our users.

Think happy thoughts on this one...

> 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 <geirm@apache.org> 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.

Geir Magnusson Jr                                  +1-203-665-6437

View raw message