Stefano Mazzocchi wrote:
[EMAIL PROTECTED] 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
2. ease portability to different OS's and platforms (embedded
systems included)
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.
Enrico
