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 20:55:32 GMT


Stefano Mazzocchi wrote:
> 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.

I know.

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

Yes - understood.


That's the notion of the "OS Portability Interface" as part of the 
modularity story.  "If you implement these calls/interfaces/whatever, 
you can plug that into the VM"

So I don't imagine we'd ever tie the VM to any given OS, but rather let 
it be a pluggable thing, and I'd imagine that the "pluggable things" 
that we write and distribute would be APR-powered.  This lets us 
leverage APR (we're fundamentally lazy, after all) yet still allow 
people who dont' want to use APR or can't because of some issue on the 
platform they are porting to to do what they need to.


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

Right.

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

I think that you are right on the money (modulo the VM's interface) and 
I'd bet real money that we will be heavily dependent on - and 
contributors to - APR  in the near future.

geir


> 

Mime
View raw message