harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [classlib] where to put mods that make classlib more portable
Date Wed, 22 Mar 2006 02:49:37 GMT

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 

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 

Pls. refer to Harmony Class Library Porting Documentation[2] for details.


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

View raw message