Geir Magnusson Jr wrote:
>> I agree. How about "classlibadapter/trunk" -> "adapter/gnu/trunk"?
>
> I'd keep it specific to classlib yet simple and mimic the classlib
> structure with
>
> classlibadapter/trunk/module/gnu
>
> or something.
OK... although I'm not sure what purpose the "module" part serves.
We can of course always insert it later.
>> Now next questions... let's talk about how we want to build and
>> package this. It looks like basically we need to build two things,
>> (a) a ZIP/JAR file containing the adapter classes, and (b) a native
>> libarary for java.io.File.
>>
>> #1. It's possible to get rid of (b) because Classpath already contains
>> native libraries that implement java.io.File functionality.
>
> Classpath? The assumption here is that you don't need to have GNU
> Classpath, right?
Argh, my apologies, for some reason I was thinking completely backwards.
Ignore most of what I said :-)
We don't need Classpath to build and it won't be available at runtime
of course. We could do that, but then that kindof defeats the whole
purpose... I think I was imagining this on my laptop which has Classpath
but that would be a special case...
We will be providing VMFoo classes that define the same API to the
VM that Classpath does. Essentially we'll have replacements for all of
Classpath's vm/reference classes, plus the glue that goes on top of
that to hook it all up to classlib.
Hope that makes more sense...
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org