JAVA and dynamically loaded filters (LZO)

Hello,

I am working on a project to write/read hdf5 files with LZO compression. I
have figured out the writing part. It is done by dynamically registering
the LZO filter callbacks. The writing is all in C.

For the reading, I need to integrate this with JAVA. I checked the HDF5
JAVA API, unfortunately the H5Zregister() function is not supported. (
http://www.hdfgroup.org/products/java/JNI/jhi5/jhi5_unsupported_functions.html).

I do not have much experience with Jave Native Interface, but it may be
feasible to write a JAVA Native Interface wrapper class around a C reader
class.

Any one has dealt with this problem before?

The problem with wrapping this function in Java is that the argument is a
structure with references to function pointers. It is these function pointers
that cannot be easily matched within Java. The void* argument itself can
easily be specified for Java to C conversion.

Suggestions are welcomed.

Allen

···

On Wednesday, December 24, 2014 06:27:11 PM Ching-Chia Wang wrote:

Hello,

I am working on a project to write/read hdf5 files with LZO compression. I
have figured out the writing part. It is done by dynamically registering
the LZO filter callbacks. The writing is all in C.

For the reading, I need to integrate this with JAVA. I checked the HDF5
JAVA API, unfortunately the H5Zregister() function is not supported. (
http://www.hdfgroup.org/products/java/JNI/jhi5/jhi5_unsupported_functions.ht
ml).

I do not have much experience with Jave Native Interface, but it may be
feasible to write a JAVA Native Interface wrapper class around a C reader
class.

Any one has dealt with this problem before?

I've dealt with similar problems when using callbacks from the National Instruments API. I resolved it with a little C code and some special handling for threads. The National Instruments library spawns its own threads which have to be registered with the JVM post-hoc.

It would be possible to create a native method transform of a static function "on the fly" using one of the byte code engineering libraries (Javassist, BCEL, ASM4) + a little stack management magic. If I have time to come up with a functional example, I'll post it. No guarantees. It is not hard to do this for a few specific functions if you are willing to add some C wrappers. Tricky for the general case, but not impossible either.

So, this can be done in the existing JVM. But there is also a lot of talk around new tools and standard libraries for Java Foreign Function Interface. We'll see if anything significantly new comes of that. You can get some hints regarding ongoing development through github in the jnr-ffi project. I realize this project is focused on Java calling foreign functions, but the data structures work the same in both directions.

It all depends on how badly you want to do it.

bbaker

···

-----Original Message-----
From: Hdf-forum [mailto:hdf-forum-bounces@lists.hdfgroup.org] On Behalf Of Allen Byrne
Sent: Monday, January 05, 2015 12:46 PM
To: hdf-forum@lists.hdfgroup.org
Subject: Re: [Hdf-forum] JAVA and dynamically loaded filters (LZO)

The problem with wrapping this function in Java is that the argument is a structure with references
to function pointers. It is these function pointers that cannot be easily matched within Java. The void*
argument itself can easily be specified for Java to C conversion.

Suggestions are welcomed.

Allen

On Wednesday, December 24, 2014 06:27:11 PM Ching-Chia Wang wrote:

Hello,

I am working on a project to write/read hdf5 files with LZO
compression. I have figured out the writing part. It is done by
dynamically registering the LZO filter callbacks. The writing is all in C.

For the reading, I need to integrate this with JAVA. I checked the
HDF5 JAVA API, unfortunately the H5Zregister() function is not
supported. (
http://www.hdfgroup.org/products/java/JNI/jhi5/jhi5_unsupported_functi
ons.ht
ml).

I do not have much experience with Jave Native Interface, but it may
be feasible to write a JAVA Native Interface wrapper class around a C
reader class.

Any one has dealt with this problem before?