Geir Magnusson Jr wrote:


Jim Jagielski wrote:

On Feb 10, 2006, at 9:54 AM, Stefano Mazzocchi wrote:

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?


Tomcat is APR aware via JNI (for connectors), and when it uses APR
has some *very* appreciable enhancements :)

Heh. The reason is because they are taking a different approach to IO, right?

IOW, my guess is that if the Sun JVM used APR, nothing would change, because the problem is the standard Java APIs, not the integration of the VM w/ the OS services. My understanding is that the Tomcat peeps just found a more optimal path to the OS services they needed for their specific problem.

Geir, I'm not proposed we expose a java APR API instead of the standard java API, that's not the point.

My point is that a JVM has a lot of native hooks, by design. And that those native hooks will have to be ported across operating systems and that APR was designed to separate those OS dependencies from the Apache 2 codebase so that the web server could be built with some sort of 'OS abstraction' in mind.

therefore, my suggestion is: instead of hooking our native stuff to the OS directly (or to the standard C libraries) we should hook them up to something that is a little more abstract and therefore reduces the effort of porting across OSes.

As you note, if we do this right, the java users wouldn't be able to tell a difference (if not, maybe, performance), but the difference would be in lowing the costs of porting the native code across different OSes.

But then again, since I'm not the one doing the coding, I'll be happy to let do-ocracy take place.. I just thought I mentioned it since others might not know of APR's existance and Apache HTTPD and Tomcat connectors's dependency on it (which means it's there to stay and it's heavily maintained and licensing compatible)

--
Stefano.

Reply via email to