As I wrote earlier, I agree. Implementing the Harmony portability layer
to run on APR is a good idea (volunteers?).
The Harmony portlib [1] itself has some interesting characteristics that
I would not want to loose by programming Java natives straight to APR.
The portlib is a table of function pointers that is linked to a
particular VM instance. Each function in turn has a parameter that is
the function table it should use; and all this is wrapped up in some
syntactic sugar to make palatable to the programmer.
This means that an application that creates multiple VM's in the same
process (i.e. repeated calls to JNI_CreateJavaVM) has the option to keep
the resource management separated. It can ensure that one VM does not
grab the entire OS heap, or that the resources are allocated a given
security sandbox, or (heaven-forbid) if the VM abends it can clean-up
just that VM's resources. It also makes things like tracing much
easier, since you can augment a function at any given point by replacing
it in the function table, and have that augmented function used by all
downstream callers. This scenario will be familiar to the app server
crowd, who want to run multiple VMs inside a webserver for example.
Here's how it looks from a JNI programmer's pov [2]:
================================================
void JNICALL
Java_java_net_Socket_socketCloseImpl (JNIEnv * env,
jclass thisClz,
jobject fileDescriptor)
{
PORT_ACCESS_FROM_ENV (env);
hysocket_t socketP;
socketP = getJavaIoFileDescriptorContentsAsPointer (env,
fileDescriptor);
if (hysock_socketIsValid (socketP))
{
/* Set the file descriptor before closing so the select
polling loop will terminate. */
/* Some platforms wait in the socket close. */
setJavaIoFileDescriptorContentsAsPointer (env, fileDescriptor,
(void *) -1);
hysock_close (&socketP);
}
}
================================================
The "PORT_ACCESS_FROM_ENV(env)" is a macro that reaches into the JNIEnv
and gets the table of function pointers[3].
#define PORT_ACCESS_FROM_ENV(jniEnv) \
VMInterface *portPrivateVMI = VMI_GetVMIFromJNIEnv(jniEnv); \
HyPortLibrary *privatePortLibrary = \
(*portPrivateVMI)->GetPortLibrary(portPrivateVMI)
After that you could tweak it if you choose, but this function doesn't.
Then calls to 'functions' like "hysock_socketIsValid" and
"hysock_close" are actually macros that expand out into offsets into the
function table, and passing the function table down;
i.e.
hysock_socketIsValid (socketP)
expands as follows [3]
#define hysock_socketIsValid(param1) \
privatePortLibrary->sock_socketIsValid(privatePortLibrary,param1)
You can see where this is going. The implementation of
sock_socketIsValid inherits the caller's view of the portlib, and so on.
The on-line doc describes it here [1]. While we would normally also
use the portlayer as the OS porting layer, implementing this on APR
would be a GoodThing too.
[1]
http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html
[2] taken from
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/luni/socket.c?view=markup
[3] look in
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/include/hyport.h?view=markup
Regards,
Tim
Alexey Petrenko wrote:
>> What do you think?
> I think that's using Apache Portable Runtime in Apache Harmony is
> natural and good idea.
>
> However we should understand that APR does not have ALL the needed
> functionality. For example APR does not have graphical and window
> management functions. So at least awt will need to use OS dependent
> native code.
>
> --
> Alexey A. Petrenko
> Intel Middleware Products Division
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
