harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: Using APR for Harmony's native link to the OS?
Date Fri, 10 Feb 2006 15:08:32 GMT

Stefano Mazzocchi wrote:
> tellison@apache.org wrote:
>> Author: tellison
>> Date: Fri Feb 10 05:57:38 2006
>> New Revision: 376690
>> URL: http://svn.apache.org/viewcvs?rev=376690&view=rev
>> Log:
>> Applying patches received as HARMONY-42 (com.ibm.io.nio.FileChannel is 
>> not fully implemented)
>>  - refactoring of some java platform code
>>  - additional behavior on NIO file channels
>>  - refactoring of some IO code
>>  - work in progress on memory mapping
> Tim's commits made me think about something that I thought about a 
> loooooong time ago (probably 1999) in the "would be awesome" kind of 
> department but I put off for a future where we would have a project to 
> work on a JVM.
> turns out we do have one now and turns out that APR[1] is a library that 
> is now very solid and reached API stability over years of work by a lot 
> of people.
> so, here it is, does it make sense to have harmony depend on APR and 
> therefore abstract away all those OS-specificities? (I'm talking about 
> both the VM and the native part of the class library).

I've thought about this a while, and while I'm personally committed to 
using APR wherever and whenever we can, I don't think it's wise to let 
the APR tail wag the VM internal architecture dog, so to speak.

For example, the VM should have resource requirements that APR doesn't 
have, and that make no sense for general APR usage.  (For example, 
coordinating memory use between APR and the VM...)

I think that we need a clear 'interface' between the VM and the "OS 
Abstraction Component", which I expect will then be implemented using 
APR for every platform APR supports.

However, where there is no APR support for a platform, or someone wants 
to do something differently, they can just (re) implement the "OS 
Abstraction Compoment" as they see fit.

> It also has a major social side effects: it would create the ultimate 
> social bridge between the HTTPD/APR side of the foundation and the java 
> side of the foundation, maybe allowing people from one side to 
> contribute to the other, or, at least to help out in the interface 
> between them which naturally is the JVM.
> What do you think?

I think that doing our implementations using APR is a solid way to go. 
A good place to start looking is JCHEVM and BootVM...


View raw message