+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
