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 :)
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?
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]
