NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Arlindo da Silva wrote:
On Tue, Dec 23, 2008 at 10:59 PM, John Caron <caron@xxxxxxxxxxxxxxxx> wrote:Hi Arlindo: There is no such low level C-like API in the netcdf-Java library. However, the Java API has a pretty close correspondence, but an automatic conversion is not likely.I was thinking about doing this by hand...If what you need is netcdf + opendap in C, then you can use netcdf-4. Im not sure what the release status of that is, but i know you could get a preliminary version. OTOH, Im not sure exactly what you are trying to accomplish. Take existing C code using netCDF C library and turn into Java? For what purpose?The NestedVM project http://nestedvm.ibex.org/ provides means of compiling C sources into Java byte code. This is accomplished by compiling C sources into mips machine code and then translating this into java byte code. In this sense, the JVM becomes another platform to build for; no translation .c to .java is necessary. There is only one set of sources to maintain, and a java version of your application comes with very little development overhead. With relatively moderate effort, I've been able to produce a very functional build of the latest GrADS v2 release that runs entirely under the JVM; no JNI involved, 100% pure JVM. This includes full NetCDF-3, HDF-4, GRIB-1, GRIB-2 and PNG support. Except for rewriting the low level graphics primitives to use awt/swing, no manual java recoding was necessary. The only major feature missing in this build is OPeNDAP support. Of the OPeNDAP dependencies, I've been able to build xml2, but curl has been a bit trick because some of the syscalls needed are yet to be implemented in NestedVM (I'm getting close, though: curl builds and runs under the JVM but does not quite work yet.)
So if i understand, one compiles C apps into Java. The limiting problem are system calls and other libraries that your app uses. These are possibly hard to code in a platform-neutral way. The goal is simply to have a 100% Java version of your already coded C app, mostly for portability (?)
As a stop-gap measure, I was considering wrapping your NetCDF-Java classes to provide an implementation of the few low-level nc-dap calls that are used by grads. (Nested VM allows for you to call Java native methods from your "C" code.) Since other folks might have already done this work, I was trying not to duplicate any effort. As you indicate, there is good correspondence between the Java and C APIs, and although tedious this seems quite doable. At some point I'd interested in benchmarking my NestedVM build of NetCDF-3 against our native implementation. I've been very surprised by the performance of NestedVM.
yes, that would be quite interesting. Is the Java code readable? I suppose you wouldnt have the same OO features as if you did the design yourself? very cool, thanks for the heads up!
netcdf-java archives: