harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Harley <george.c.har...@googlemail.com>
Subject Re: [classlib] where to put mods that make classlib more portable
Date Wed, 22 Mar 2006 13:39:32 GMT
+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
>>
>>   
>
>


Mime
View raw message