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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
