harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: GNU Classpath 0.16 "Harmony!" released
Date Fri, 08 Jul 2005 09:46:28 GMT
Geir Magnusson Jr. wrote:
> On Jul 6, 2005, at 12:55 PM, Mladen Turk wrote:
>> Geir Magnusson Jr. wrote:
>>> On Jul 5, 2005, at 7:04 AM, Mladen Turk wrote:
>>>> IMHO the major issue is to put all the requirements for the
>>>> classpath on the paper, and then to see if the GNU classpath is
>>>> usable, and if not, can it be adopted to fulfill all the  requirements.
>>> That's not an unreasonable idea.
>>> Thanks for volunteering :)
>>> Go for it!
>> Well It depends on the Harmony goals at the first place.
>> I hope the Harmony will offer more then just
>> Solaris/Sparc, Win/x86, Linux/i386/amd64.

Can we reach a concensus on getting something started on Windows/x86 and
Linux/i386 initially (as the popular development platforms)?  Then...

> I assume that whatever people want to do, we will do.  I hope that it 
> can be ported - if there's interest - to any platform out there.   BSD,
> for example, and embedded.  Also, a much wider hardware matrix, 
> including PPC, Itanium, etc...

... of course, pushing it out to other platforms will a key part of the
project growth.

>> Right now the GNU classpath is GNU tools only. Trying to
>> compile that on WIN32 or WIN64 is very painful without
>> going trough some posix layer.
>> Also the GUI part is GTK only, so even with using things like
>> gtk-win32 it adds an extra layer in between.
> Great - so factor this into the class library requirements paper that 
> you volunteered for :)
>> Anyhow, like said at the beginning, I think we should build our
>> own classpath. I can volunteer for that, using APR as a
>> OS abstraction layer. For me using GNU classpath could give
>> some jump start, but in the long run, we'll have to build
>> our own classpath.
> That's not unreasonable - we'll do it if there's interest.   As for 
> now, as you note, we can work w/ GNU Classpath as a jumpstart and see 
> where it takes us.
> I think that we should remain committed to making things as pluggable 
> as possible, and will re-kindle the VM/Classlibrary discussion we 
> started a while back.

This seems like the most prudent approach -- agreeing upon a particular
VM/ClassLibrary interface that will be suitable for all comers.

> We also want to be sure that if we do any class library work here,  that
> we modularize in such a way that parts can be repurposed  elsewhere -
> like swing or other such uglies...

Agreed.  A good modularity story will allow flexibility in combining
components from different sources, and flexibility in component development.


Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

View raw message