harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Using APR for Harmony's native link to the OS?
Date Fri, 10 Feb 2006 20:30:32 GMT
Enrico Migliore wrote:
> 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).
>> 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?
>> [1] http://apr.apache.org/
> I haven't gone through the APR library therefore I don't know how many 
> layers (i.e. function calls)
> it puts between Apache and the underlying OS.
> As far as the the native code of the Classlib and the VM is concerned, I 
> think that we should keep it
> as thinner as possible in order to:
>        1. have Java programs run fast

I agree this is the goal, but since performance is *also* one of the 
needs for the Apache HTTPD 2.x project, I doubt they went very light on 
that front (especially after 5 years of development!)

>        2. ease portability to different OS's and platforms (embedded 
> systems included)

APR was designed to ease OS portability.

> The GNU/Classpath guys, for example, have defined a standard interface 
> to underlying OS
> and that's it. Therefore I don't think we really need the APR layer.

I disagree. I think we would gain a lot of value by using APR instead of 
reinventing something that 5 years from now will look just like it.


View raw message