Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of george.c.harley@googlemail.com
 designates 64.233.162.206 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=googlemail.com;
        h=received:message-id:date:from:reply-to:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=DYAEK2khNifLuD80WTyT7wYD+A6Hmwg98pPLtodcL5FytTs+KjfuqF7ZpnOJG5d25YIC61XN1BHnf/Nmoa67ujkf+IkqipW+/uiWu9a8FLfHH4gnSWd3CtVB0Mq3GRraDpsZRZHmAOGB7TyX0P/qsHU1nYa5e/e9EfuhHcZ+SLM=
Message-ID: <44215394.4040709@googlemail.com>
Date: Wed, 22 Mar 2006 13:39:32 +0000
From: George Harley <george.c.harley@googlemail.com>
Reply-To: harmony-dev@incubator.apache.org
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] where to put mods that make classlib more portable
References: <4dd1f3f00603211748nff9d9e0i6cf9f82f935fc74a@mail.gmail.com>
 <4420BB41.3080908@gmail.com>
In-Reply-To: <4420BB41.3080908@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

+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
>>
>>   
>
>