Bob,
This is true. One must have the native library (and dependencies) available
for a given target platform (OS and CPU architecture). We are currently
developing the JNA based binding as a jar that will auto-extract a
statically-linked native library for x86 and amd64 linux platforms. Using this
on other platforms would require compilation of the native library for the
desired platform. With JNA the java-to-native binding effectively introspects
the the native library and binds the appropriate method based on the java class
method by convention by mapping the method name and argument list. As long as
the native library calls used don't change the JNA binding will work.
Tom
On Oct 17, 2011, at 12:50 PM, Bob Simons wrote:
> Perhaps JNI is the best approach. I don't know.
>
> But I do know that using JNI makes Java code not write-once-run-anywhere.
> That is partly because the non-Java code must be available for all target
> platforms. Even if it is available, JNI can be very picky -- code has to be
> compiled with certain versions of compilers and with certain flags. So, using
> JNI can seem relatively straight-forward for the initial developer ("it works
> for me"), but be an installation headache for others trying to reuse the code.
>
>
> On 10/17/2011 10:35 AM, Christopher Mueller wrote:
>> NetCDF-Java Folks,
>>
>> We have a need to write NetCDF4/HDF5 files from within a project that
>> already has a significant framework developed in Java. We also have a
>> firm requirement to be able to "append" to existing files - which
>> (unfortunately) takes the Nujan library off the table (at least in it's
>> current incarnation). I see from the NetCDF-Java FAQ
>> (http://www.unidata.ucar.edu/software/netcdf-java/reference/faq.html#Writing)
>> that you are considering a JNI approach for writing NetCDF4 from NJ, and
>> I'd like to put my vote in for that. The HDF Team supports JNI Java
>> modules for Windows, Linux and Mac - wouldn't it be relatively
>> straightforward to integrate those into the NetCDF-Java distro to give
>> it NC4 writing capability?
>>
>> As part of such an addition (including & using the JHI & JHI5
>> libraries), would you also consider refactoring the current HDF read
>> support to utilize the JNI libraries?
>>
>> Best,
>> Chris
>>
>>
>> --
>> *Christopher Mueller* | Scientific Developer
>> Applied Science Associates
>> 55 Village Square Drive | South Kingston, RI 02879 USA
>> p: +1 401-789-6224 | c: +1 401-219-2490 | f: +1 401-789-1932
>> e: cmueller@xxxxxxxxxxxxxx | www.asascience.com
>>
>> *ASA | Science. Services. Solutions*
>>
>> Consider the environment before printing this email.
>>
>>
>> _______________________________________________
>> netcdf-java mailing list
>> netcdf-java@xxxxxxxxxxxxxxxx
>> For list information or to unsubscribe, visit:
>> http://www.unidata.ucar.edu/mailing_lists/
>
> --
> Sincerely,
>
> Bob Simons
> IT Specialist
> Environmental Research Division
> NOAA Southwest Fisheries Science Center
> 1352 Lighthouse Ave
> Pacific Grove, CA 93950-2079
> Phone: (831)658-3205
> Fax: (831)648-8440
> Email: bob.simons@xxxxxxxx
>
> The contents of this message are mine personally and
> do not necessarily reflect any position of the
> Government or the National Oceanic and Atmospheric
> Administration.
> <>< <>< <>< <>< <>< <>< <>< <>< <><
>
> _______________________________________________
> netcdf-java mailing list
> netcdf-java@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
