Mikhail Loenko wrote:
2006/6/6, Oliver Deakin <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>:
>>
>> On 6 June 2006 at 9:40, "Mikhail Loenko" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
>> > > 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: [EMAIL PROTECTED]
>> > > For additional commands, e-mail:
>> [EMAIL PROTECTED]
>> > >
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

--
Oliver Deakin
IBM United Kingdom Limited


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
Oliver Deakin
IBM United Kingdom Limited


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to