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 10:16:17 GMT
Mikhail Loenko wrote:
> 2006/6/6, Oliver Deakin <oliver.deakin@googlemail.com>:
>> 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).
>
> It's funny because my fix had solved the problem :)

I was thinking about that, so I had a look back at the mail archives and
the JIRA you linked. It looks like a new version of the VME came out
around the time that you were working on the bug. I think there might
have been a massive coincidence that you got the new VME, which
contained a similar fix in its kernel classes, and used this to make
a final run of the test against Harmony code, which then passed.
Quite impressive timing! ;)

>
> If they are just stubs why not remove code from them? And why not to 
> put them
> to depends or whatever to not confuse people?

I think it's worth keeping the code there, just as a starting point for VM
writers to implement their own kernel classes. It should be possible for
a VM writer to adapt them for their own kernel, thus lessening the initial
amount of time it takes to get the VM working with Harmony classlib.

I can see how confusion could be caused by their location, however
IMHO it would cause more confusion to have the kernel stubs
located separate to the rest of the Java code.
Perhaps it would be clearer if the directories were renamed
luni-kernel-stubs and security-kernel-stubs (which would also match
the jar names they generate)?

Regards,
Oliver

>
> Thanks,
> Mikhail
>
>>
>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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