You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/03/22 02:48:22 UTC
[classlib] where to put mods that make classlib more portable
Now that JCHEVM licensing issues are resolved, I would like to find a
home for mods that make Harmony Classlib more portable. The files
are:
nio/src/main/java/com/ibm/platform/OSMemory.java
nio/src/main/java/com/ibm/platform/OSFileSystem.java
luni/src/main/java/java/io/FileDescriptor.java
All of the above files contain native method declarations. To get
"hello world" on JCHEVM working, I temporarily commented out the
"native" keyword and turned the code into method definitions with a
few simple hacks.
Since the above files declare native methods, one possibility is to
move them into the kernel directory. Another possibility is to leave
the above files where they are and have them call into
"kernel/src/main/java/java/lang/kernel_OSMemory.java". The idea is to
move all the native method declarations into the kernel directory.
Thoughts on the above?
--
Weldon Washburn
Intel Middleware Products Division
Re: [classlib] where to put mods that make classlib more portable
Posted by Tim Ellison <t....@gmail.com>.
Weldon Washburn wrote:
> On 3/23/06, Tim Ellison <t....@gmail.com> wrote:
>> Weldon Washburn wrote:
>>> Now that JCHEVM licensing issues are resolved, I would like to find a
>>> home for mods that make Harmony Classlib more portable. The files
>>> are:
>>>
>>> nio/src/main/java/com/ibm/platform/OSMemory.java
>>> nio/src/main/java/com/ibm/platform/OSFileSystem.java
>>> luni/src/main/java/java/io/FileDescriptor.java
>>>
>>> All of the above files contain native method declarations. To get
>>> "hello world" on JCHEVM working, I temporarily commented out the
>>> "native" keyword and turned the code into method definitions with a
>>> few simple hacks.
>> That's cool -- as Leo said, it is fair game to create hacks to bring up
>> "hello world". It's a step towards the full integration of JCHEVM and
>> classlib.
>>
>>> Since the above files declare native methods, one possibility is to
>>> move them into the kernel directory. Another possibility is to leave
>>> the above files where they are and have them call into
>>> "kernel/src/main/java/java/lang/kernel_OSMemory.java". The idea is to
>>> move all the native method declarations into the kernel directory.
>>>
>>> Thoughts on the above?
>> As Paulex said elsewhere, you are going to have to do 'the right thing'
>> in terms of the VMI if you expect other natives to work.
>
> Yes, I agree. The problem will be resolving GNU Classpath hard
> requirements and the Harmony ClassLib hard requirements.
Are Harmony's VMI requirements in some way incompatible with Classpath's
VM requirements?
>> I'm surprised that these are the only natives that you need to change
>> (to avoid the PORT_ACCESS_FROM_ENV and hy* macros) outside the kernel today.
>
> More accurately, these are the only natives required to get "hello
> world" working.
Understood, that's goodness, I'm just surprised.
>> Are you using the Harmony launcher for starting JCHEVM? I ask because
>> the launcher sets up the portlib and passes it in as a vm arg when the
>> VM is created.
>
> Harmony launcher is not used. I suspect the typical GNU Classpath
> ready JVM does not know about Harmony launcher.
The VMs should not need to know about the launcher, they'll just get
created by JNI_CreateJavaVM. If you used the Harmony launcher it would
help by giving you the portlib etc. required by the VMI. That may be
easier than adding the functionality to whatever launcher you are using
or the VM directly.
(I'm thinking beyond the 'hello world' hack here.)
Regards,
Tim
>> p.s. I don't think putting these hacks into the existing mainline
>> classlib code makes sense, but I have no problem with it being off to
>> the side if that helps with collaboration.
>
> Yes. Agreed. I will keep them off to the side.
>
>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>
>
> --
> Weldon Washburn
> Intel Middleware Products Division
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib] where to put mods that make classlib more portable
Posted by Weldon Washburn <we...@gmail.com>.
On 3/23/06, Tim Ellison <t....@gmail.com> wrote:
> Weldon Washburn wrote:
> > Now that JCHEVM licensing issues are resolved, I would like to find a
> > home for mods that make Harmony Classlib more portable. The files
> > are:
> >
> > nio/src/main/java/com/ibm/platform/OSMemory.java
> > nio/src/main/java/com/ibm/platform/OSFileSystem.java
> > luni/src/main/java/java/io/FileDescriptor.java
> >
> > All of the above files contain native method declarations. To get
> > "hello world" on JCHEVM working, I temporarily commented out the
> > "native" keyword and turned the code into method definitions with a
> > few simple hacks.
>
> That's cool -- as Leo said, it is fair game to create hacks to bring up
> "hello world". It's a step towards the full integration of JCHEVM and
> classlib.
>
> > Since the above files declare native methods, one possibility is to
> > move them into the kernel directory. Another possibility is to leave
> > the above files where they are and have them call into
> > "kernel/src/main/java/java/lang/kernel_OSMemory.java". The idea is to
> > move all the native method declarations into the kernel directory.
> >
> > Thoughts on the above?
>
> As Paulex said elsewhere, you are going to have to do 'the right thing'
> in terms of the VMI if you expect other natives to work.
Yes, I agree. The problem will be resolving GNU Classpath hard
requirements and the Harmony ClassLib hard requirements.
>
> I'm surprised that these are the only natives that you need to change
> (to avoid the PORT_ACCESS_FROM_ENV and hy* macros) outside the kernel today.
More accurately, these are the only natives required to get "hello
world" working.
>
> Are you using the Harmony launcher for starting JCHEVM? I ask because
> the launcher sets up the portlib and passes it in as a vm arg when the
> VM is created.
Harmony launcher is not used. I suspect the typical GNU Classpath
ready JVM does not know about Harmony launcher.
>
> Regards,
> Tim
>
> p.s. I don't think putting these hacks into the existing mainline
> classlib code makes sense, but I have no problem with it being off to
> the side if that helps with collaboration.
Yes. Agreed. I will keep them off to the side.
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [classlib] where to put mods that make classlib more portable
Posted by Tim Ellison <t....@gmail.com>.
Weldon Washburn wrote:
> Now that JCHEVM licensing issues are resolved, I would like to find a
> home for mods that make Harmony Classlib more portable. The files
> are:
>
> nio/src/main/java/com/ibm/platform/OSMemory.java
> nio/src/main/java/com/ibm/platform/OSFileSystem.java
> luni/src/main/java/java/io/FileDescriptor.java
>
> All of the above files contain native method declarations. To get
> "hello world" on JCHEVM working, I temporarily commented out the
> "native" keyword and turned the code into method definitions with a
> few simple hacks.
That's cool -- as Leo said, it is fair game to create hacks to bring up
"hello world". It's a step towards the full integration of JCHEVM and
classlib.
> Since the above files declare native methods, one possibility is to
> move them into the kernel directory. Another possibility is to leave
> the above files where they are and have them call into
> "kernel/src/main/java/java/lang/kernel_OSMemory.java". The idea is to
> move all the native method declarations into the kernel directory.
>
> Thoughts on the above?
As Paulex said elsewhere, you are going to have to do 'the right thing'
in terms of the VMI if you expect other natives to work.
I'm surprised that these are the only natives that you need to change
(to avoid the PORT_ACCESS_FROM_ENV and hy* macros) outside the kernel today.
Are you using the Harmony launcher for starting JCHEVM? I ask because
the launcher sets up the portlib and passes it in as a vm arg when the
VM is created.
Regards,
Tim
p.s. I don't think putting these hacks into the existing mainline
classlib code makes sense, but I have no problem with it being off to
the side if that helps with collaboration.
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib] where to put mods that make classlib more portable
Posted by Leo Simons <ma...@leosimons.com>.
I detect a difference in approach between "doing things right" and
"doing the least amount of work to get things running". I think both
are good ways to make progress, and we should do both.
On Wed, Mar 22, 2006 at 10:49:37AM +0800, Paulex Yang wrote:
> There has been a VM/classlib interface definition named as VMI [1] , it
> is concise and a *much* smaller interface than *all* native codes
> classlib needs. If only the alternative VM implements the VMI and kernel
> classes, the sample Java launcher current in SVN should can be used by
> it to load classlib native libraries as well as VM libraries, so that
> not only java codes but all the classlib specific native codes can be
> used on alternate VM without modification, this make sense to me as
> *portable*.
Yeah it does! (to me)
To make my comment above a little more concrete, From a very practical point
of view, search-replacing all "native" keywords with '/* native */' is a much
lazier/quicker way to get some stuff running (I mean, making JCHEVM implement
this VMI sounds like lots of work, and it already implements another abstraction
layer (the GNU classpath one), so the best way to do it is probably not so
straight-forward), which is not without its merits either.
Is there a good reason not to just go and try both ways?
Man, who is this guy from the peanut gallery who keeps popping his head around
the corner? O wait, its me. Carry on people, carry on...
- LSD
Re: [classlib] where to put mods that make classlib more portable
Posted by George Harley <ge...@googlemail.com>.
+1 for Paulex.
Weldon, you might also find the documentation about the Harmony kernel
classes interesting...
http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/kernel_doc/html/index.html#KernelJavaClasses
Best regards,
George
Paulex Yang wrote:
> Weldon
>
> First FYI, the OSMemory.java and OSFileSystem.java have been moved
> into o.a.h.luni.platform package in LUNI component.
>
> And then, I'm afraid I cannot agree with you. Only the VM specific
> codes should be put in kernel module. And these three files are not
> related with any VM implementation details at all, while they are
> tightly coupling with class library implementation. And I cannot see
> why they are impair the portability. Furthermore, there are at least 5
> directories coupling with specific class library component in SVN's
> native project(prefs, archive, luni, archive, math), and I believe
> there will be more. Do you suggest all of them should be the interface
> between VM and classlib? then how large and unstable the interface
> will be? And how difficult for the VM vendor to support such a large
> and unstable interface?
>
> There has been a VM/classlib interface definition named as VMI [1] ,
> it is concise and a *much* smaller interface than *all* native codes
> classlib needs. If only the alternative VM implements the VMI and
> kernel classes, the sample Java launcher current in SVN should can be
> used by it to load classlib native libraries as well as VM libraries,
> so that not only java codes but all the classlib specific native codes
> can be used on alternate VM without modification, this make sense to
> me as *portable*.
>
> Pls. refer to Harmony Class Library Porting Documentation[2] for details.
>
> [1]
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__VMInterface.html
>
> [2]
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/index.html
>
>
> Weldon Washburn wrote:
>> Now that JCHEVM licensing issues are resolved, I would like to find aa
>> home for mods that make Harmony Classlib more portable. The files
>> are:
>>
>> nio/src/main/java/com/ibm/platform/OSMemory.java
>> nio/src/main/java/com/ibm/platform/OSFileSystem.java
>> luni/src/main/java/java/io/FileDescriptor.java
>>
>> All of the above files contain native method declarations. To get
>> "hello world" on JCHEVM working, I temporarily commented out the
>> "native" keyword and turned the code into method definitions with a
>> few simple hacks.
>>
>> Since the above files declare native methods, one possibility is to
>> move them into the kernel directory. Another possibility is to leave
>> the above files where they are and have them call into
>> "kernel/src/main/java/java/lang/kernel_OSMemory.java". The idea is to
>> move all the native method declarations into the kernel directory.
>>
>> Thoughts on the above?
>>
>> --
>> Weldon Washburn
>> Intel Middleware Products Division
>>
>>
>
>
Re: [classlib] where to put mods that make classlib more portable
Posted by Paulex Yang <pa...@gmail.com>.
Weldon
First FYI, the OSMemory.java and OSFileSystem.java have been moved into
o.a.h.luni.platform package in LUNI component.
And then, I'm afraid I cannot agree with you. Only the VM specific codes
should be put in kernel module. And these three files are not related
with any VM implementation details at all, while they are tightly
coupling with class library implementation. And I cannot see why they
are impair the portability. Furthermore, there are at least 5
directories coupling with specific class library component in SVN's
native project(prefs, archive, luni, archive, math), and I believe there
will be more. Do you suggest all of them should be the interface between
VM and classlib? then how large and unstable the interface will be? And
how difficult for the VM vendor to support such a large and unstable
interface?
There has been a VM/classlib interface definition named as VMI [1] , it
is concise and a *much* smaller interface than *all* native codes
classlib needs. If only the alternative VM implements the VMI and kernel
classes, the sample Java launcher current in SVN should can be used by
it to load classlib native libraries as well as VM libraries, so that
not only java codes but all the classlib specific native codes can be
used on alternate VM without modification, this make sense to me as
*portable*.
Pls. refer to Harmony Class Library Porting Documentation[2] for details.
[1]
http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__VMInterface.html
[2]
http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/index.html
Weldon Washburn wrote:
> Now that JCHEVM licensing issues are resolved, I would like to find aa
> home for mods that make Harmony Classlib more portable. The files
> are:
>
> nio/src/main/java/com/ibm/platform/OSMemory.java
> nio/src/main/java/com/ibm/platform/OSFileSystem.java
> luni/src/main/java/java/io/FileDescriptor.java
>
> All of the above files contain native method declarations. To get
> "hello world" on JCHEVM working, I temporarily commented out the
> "native" keyword and turned the code into method definitions with a
> few simple hacks.
>
> Since the above files declare native methods, one possibility is to
> move them into the kernel directory. Another possibility is to leave
> the above files where they are and have them call into
> "kernel/src/main/java/java/lang/kernel_OSMemory.java". The idea is to
> move all the native method declarations into the kernel directory.
>
> Thoughts on the above?
>
> --
> Weldon Washburn
> Intel Middleware Products Division
>
>
--
Paulex Yang
China Software Development Lab
IBM