harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [general] revisiting structure of SVN
Date Tue, 06 Jun 2006 09:03:55 GMT
Mikhail Loenko wrote:
> They are not just stubs, I remember I've fixed a bug there [1].

Even though you fixed the code there, it wont be getting used when you 
run with
the classlib launcher. The luni-kernel and security-kernel classes under 
modules are
only used to compile against, and the luni-kernel-stubs.jar and 
security-kernel-stubs.jar
that they are packaged up into are never put on the bootclasspath (see
depends/files/bootclasspath.properties).

When you unpack the IBM VME it already contains luni-kernel.jar and
security-kernel.jar files that contain binaries of the J9 specific 
implementations of
the kernel classes, and these are added onto the bootclasspath by the VM
at startup.

The implementations of some of the classes that can be found under
modules/luni-kernel and modules/security-kernel  were contributed to 
classlib just
as examples that could be used to help other VM writers to more easily 
create a
set of kernel classes for their particular VM.

>
> They are not VM-independent, DRLVM's kernel classes differ [2]

And this is expected - this set of classes was chosen to be in the 
kernel because
they were likely to be VM dependent.
As I say, the classes in modules/*-kernel are only there for compiling 
against
and using as example implementations - they are not intended to be generic,
use-on-any-VM classes.

Regards,
Oliver

>
> Thanks,
> Mikhail
>
> [1] http://issues.apache.org/jira/browse/HARMONY-121
> [2] 
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/kernel_classes/javasrc/java/lang/System.java?revision=411782&view=markup

>
>
>
> 2006/6/6, Mark Hindess <mark.hindess@googlemail.com>:
>>
>> On 6 June 2006 at 9:40, "Mikhail Loenko" <mloenko@gmail.com> wrote:
>> > 6) move kernel classes out of classlib
>> >
>> > possibly create /j9 directory in a root, where j9 binaries and kernel
>> > classes will live
>>
>> Aren't these just compile against stubs?  They aren't really j9
>> specific.  If we remove them, we'd need to compile against a specific
>> vm?  Personally I'd prefer to keep the stubs and loose coupling.
>>
>> Regards,
>>  Mark.
>>
>>
>> > 2006/6/6, Geir Magnusson Jr <geir@pobox.com>:
>> > > I'd like to discuss how we start to bring together the pieces of 
>> Harmony
>> > > given our goal is Java SE with all the fixin's.
>> > >
>> > > We now have
>> > >
>> > >  /classlib
>> > >  /jchevm
>> > >  /drlvm
>> > >
>> > > DRLVM and classlib work together (as I think we all like to see 
>> jchevm
>> > > do too...)
>> > >
>> > > But given that we are a Java SE project (and not a VM project or a
>> > > classlibrary project) I think it behooves us to start thinking 
>> how to
>> > > organize at a higher level.  We've been very focused on the classlib
>> > > area, but that's only one part.
>> > >
>> > > So, I'd like to propose something like
>> > >
>> > > 1) a /deploy directory in root, as a peer to /classlib and /drlvm
>> > >
>> > >  /classlib
>> > >  /deploy
>> > >  /drlvm
>> > >
>> > > 2) Maybe move the launcher out from classlib to
>> > >
>> > >  /launcher
>> > >
>> > > 3) Maybe create
>> > >
>> > >  /tools
>> > >
>> > >  where the tool work can happen?
>> > >
>> > > 4) Have /drlvm and /classlib build-deploy into /deploy, rather 
>> than the
>> > > local one
>> > >
>> > > 3) create a top level script such that
>> > >
>> > >     build drlvm-jdk
>> > >  or
>> > >     build jchevm-jdk
>> > >
>> > > does what you expect, namely build the classlib artifacts and put in
>> > > /deploy, build the VM of choice and drop in /deploy, builds the
>> > > toolset,etc and go from there.  We can create our HDK snapshots 
>> from it,
>> > > and drop HDKs into it for use :
>> > >
>> > >  /deploy
>> > >     /hdk/
>> > >        /hdk1/
>> > >        /hdk2/
>> > >     /jdk
>> > >        /jre
>> > >
>> > > etc
>> > >
>> > > Comments?
>> > >
>> > > geir
>> > >
>> > >
>> > >
>> > >
>> > > 
>> ---------------------------------------------------------------------
>> > > 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
>> > >
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
>
>

-- 
Oliver Deakin
IBM United Kingdom Limited


---------------------------------------------------------------------
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


Mime
View raw message