You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/06/05 19:00:20 UTC
[general] revisiting structure of SVN
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
Re: [general] revisiting structure of SVN
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Oliver Deakin wrote:
>
> 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)?
>
>
+1
Also, a note making it clear or a pointer to existing docs would help too...
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
Re: [general] revisiting structure of SVN
Posted by Oliver Deakin <ol...@googlemail.com>.
Vladimir Gorr wrote:
> On 6/7/06, Ivan Volosyuk <iv...@gmail.com> wrote:
>>
>> 2006/6/6, Oliver Deakin <ol...@googlemail.com>:
>> > Ivan Volosyuk wrote:
>> > > 2006/6/6, Oliver Deakin <ol...@googlemail.com>:
>> > >> <SNIP>
>> > >> 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)?
>> > >>
>> > >
>> > > A small note.
>> > > As a writter of classlib adapter for jchevm I can say that the stubs
>> > > was quite useful for writting kernel classes specific for jchevm.
>> > > There are also some troubles with them: number of functions
>> fallbacks
>> > > to null value, while it can be something like RuntimeException("not
>> > > implemented"). Some of the classes has better implementation in
>> drlvm,
>> > > which can also be used as default implementation.
>> > >
>> >
>> > Yes, you're right - not all of the classes in luni-kernel and
>> > security-kernel
>> > contain implementation code. Some literally are stub classes that just
>> > return
>> > null, or throw an exception from every method. From a quick look, the
>> > implemented classes are:
>> >
>> > luni-kernel:
>> > java.lang.StackTraceElement
>> > java.lang.System
>> > java.lang.ThreadGroup
>> > java.lang.Throwable
>> > java.lang.ref.SoftReference
>> > java.lang.ref.WeakReference
>> >
>> > security-kernel:
>> > java.security.AccessControlContext
>> > java.security.AccessController
>> >
>> > Ivan, are you proposing that we "fill in the gaps" with some of the
>> kernel
>> > classes from drlvm so that we have a complete set of reference kernel
>> > classes to help future VM writers?
>>
>> Well, after a bit of thinking, no.
>> The stubbed version of kernel classes should be as clean as possible.
>> Any implementation in this classes can add false dependencies to other
>> classes which (the dependencies) can be absent in the other vm
>> implementation. As the drlvm is already in svn the initial
>> implementation for some classes can be taken directly from there.
>
>
> Not sure this thing is right to do. The kernel classes use the
> VM-specific
> interfaces and have a lot of internal dependencies.
> Only VM writer can define them in accordance with own design. It's
> clear he
> can look at the existent implementation
> (as example) and no more than.
Agreed - the kernel classes that are provided in Harmony
(classlib/drlvm/other)
shouldn't drive the implementation of the VM. They're there for example
only,
and how the VM writer uses them is their choice - but they should not feel
they have to copy them exactly or implement any part of their VM to fit
in with them. However, developers are free to take as much inspiration
from them as they like :)
The bottom line is, the kernel is intended as a VM-specific Java part of
the
whole VMI, and VM developers are free to implement it as they wish within
the API spec.
Regards,
Oliver
>
> Thanks,
> Vladimir.
>
>
> --
>> Ivan
>> Intel Middleware Products Division
>>
>> ---------------------------------------------------------------------
>> 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
Re: [general] revisiting structure of SVN
Posted by Vladimir Gorr <vv...@gmail.com>.
On 6/7/06, Ivan Volosyuk <iv...@gmail.com> wrote:
>
> 2006/6/6, Oliver Deakin <ol...@googlemail.com>:
> > Ivan Volosyuk wrote:
> > > 2006/6/6, Oliver Deakin <ol...@googlemail.com>:
> > >> <SNIP>
> > >> 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)?
> > >>
> > >
> > > A small note.
> > > As a writter of classlib adapter for jchevm I can say that the stubs
> > > was quite useful for writting kernel classes specific for jchevm.
> > > There are also some troubles with them: number of functions fallbacks
> > > to null value, while it can be something like RuntimeException("not
> > > implemented"). Some of the classes has better implementation in drlvm,
> > > which can also be used as default implementation.
> > >
> >
> > Yes, you're right - not all of the classes in luni-kernel and
> > security-kernel
> > contain implementation code. Some literally are stub classes that just
> > return
> > null, or throw an exception from every method. From a quick look, the
> > implemented classes are:
> >
> > luni-kernel:
> > java.lang.StackTraceElement
> > java.lang.System
> > java.lang.ThreadGroup
> > java.lang.Throwable
> > java.lang.ref.SoftReference
> > java.lang.ref.WeakReference
> >
> > security-kernel:
> > java.security.AccessControlContext
> > java.security.AccessController
> >
> > Ivan, are you proposing that we "fill in the gaps" with some of the
> kernel
> > classes from drlvm so that we have a complete set of reference kernel
> > classes to help future VM writers?
>
> Well, after a bit of thinking, no.
> The stubbed version of kernel classes should be as clean as possible.
> Any implementation in this classes can add false dependencies to other
> classes which (the dependencies) can be absent in the other vm
> implementation. As the drlvm is already in svn the initial
> implementation for some classes can be taken directly from there.
Not sure this thing is right to do. The kernel classes use the VM-specific
interfaces and have a lot of internal dependencies.
Only VM writer can define them in accordance with own design. It's clear he
can look at the existent implementation
(as example) and no more than.
Thanks,
Vladimir.
--
> Ivan
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> 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
>
>
Re: [general] revisiting structure of SVN
Posted by Ivan Volosyuk <iv...@gmail.com>.
2006/6/6, Oliver Deakin <ol...@googlemail.com>:
> Ivan Volosyuk wrote:
> > 2006/6/6, Oliver Deakin <ol...@googlemail.com>:
> >> <SNIP>
> >> 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)?
> >>
> >
> > A small note.
> > As a writter of classlib adapter for jchevm I can say that the stubs
> > was quite useful for writting kernel classes specific for jchevm.
> > There are also some troubles with them: number of functions fallbacks
> > to null value, while it can be something like RuntimeException("not
> > implemented"). Some of the classes has better implementation in drlvm,
> > which can also be used as default implementation.
> >
>
> Yes, you're right - not all of the classes in luni-kernel and
> security-kernel
> contain implementation code. Some literally are stub classes that just
> return
> null, or throw an exception from every method. From a quick look, the
> implemented classes are:
>
> luni-kernel:
> java.lang.StackTraceElement
> java.lang.System
> java.lang.ThreadGroup
> java.lang.Throwable
> java.lang.ref.SoftReference
> java.lang.ref.WeakReference
>
> security-kernel:
> java.security.AccessControlContext
> java.security.AccessController
>
> Ivan, are you proposing that we "fill in the gaps" with some of the kernel
> classes from drlvm so that we have a complete set of reference kernel
> classes to help future VM writers?
Well, after a bit of thinking, no.
The stubbed version of kernel classes should be as clean as possible.
Any implementation in this classes can add false dependencies to other
classes which (the dependencies) can be absent in the other vm
implementation. As the drlvm is already in svn the initial
implementation for some classes can be taken directly from there.
--
Ivan
Intel Middleware Products Division
---------------------------------------------------------------------
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
Re: [general] revisiting structure of SVN
Posted by Oliver Deakin <ol...@googlemail.com>.
Ivan Volosyuk wrote:
> 2006/6/6, Oliver Deakin <ol...@googlemail.com>:
>> <SNIP>
>> 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)?
>>
>
> A small note.
> As a writter of classlib adapter for jchevm I can say that the stubs
> was quite useful for writting kernel classes specific for jchevm.
> There are also some troubles with them: number of functions fallbacks
> to null value, while it can be something like RuntimeException("not
> implemented"). Some of the classes has better implementation in drlvm,
> which can also be used as default implementation.
>
Yes, you're right - not all of the classes in luni-kernel and
security-kernel
contain implementation code. Some literally are stub classes that just
return
null, or throw an exception from every method. From a quick look, the
implemented classes are:
luni-kernel:
java.lang.StackTraceElement
java.lang.System
java.lang.ThreadGroup
java.lang.Throwable
java.lang.ref.SoftReference
java.lang.ref.WeakReference
security-kernel:
java.security.AccessControlContext
java.security.AccessController
Ivan, are you proposing that we "fill in the gaps" with some of the kernel
classes from drlvm so that we have a complete set of reference kernel
classes to help future VM writers?
Regards,
Oliver
--
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
Re: [general] revisiting structure of SVN
Posted by Ivan Volosyuk <iv...@gmail.com>.
2006/6/6, Oliver Deakin <ol...@googlemail.com>:
> Mikhail Loenko wrote:
> > 2006/6/6, Oliver Deakin <ol...@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
A small note.
As a writter of classlib adapter for jchevm I can say that the stubs
was quite useful for writting kernel classes specific for jchevm.
There are also some troubles with them: number of functions fallbacks
to null value, while it can be something like RuntimeException("not
implemented"). Some of the classes has better implementation in drlvm,
which can also be used as default implementation.
--
Ivan
Intel Middleware Products Division
---------------------------------------------------------------------
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
Re: [general] revisiting structure of SVN
Posted by Oliver Deakin <ol...@googlemail.com>.
Mikhail Loenko wrote:
> 2006/6/6, Oliver Deakin <ol...@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 <ma...@googlemail.com>:
>> >>
>> >> On 6 June 2006 at 9:40, "Mikhail Loenko" <ml...@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 <ge...@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
Re: [general] revisiting structure of SVN
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/6/6, Oliver Deakin <ol...@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 :)
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 <ma...@googlemail.com>:
> >>
> >> On 6 June 2006 at 9:40, "Mikhail Loenko" <ml...@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 <ge...@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
Re: [general] revisiting structure of SVN
Posted by Oliver Deakin <ol...@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).
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 <ma...@googlemail.com>:
>>
>> On 6 June 2006 at 9:40, "Mikhail Loenko" <ml...@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 <ge...@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
Re: [general] revisiting structure of SVN
Posted by Mikhail Loenko <ml...@gmail.com>.
They are not just stubs, I remember I've fixed a bug there [1].
They are not VM-independent, DRLVM's kernel classes differ [2]
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 <ma...@googlemail.com>:
>
> On 6 June 2006 at 9:40, "Mikhail Loenko" <ml...@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 <ge...@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
Re: [general] revisiting structure of SVN
Posted by Mikhail Loenko <ml...@gmail.com>.
6) move kernel classes out of classlib
possibly create /j9 directory in a root, where j9 binaries and kernel
classes will live
Thanks,
Mikhail
2006/6/6, Geir Magnusson Jr <ge...@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