On Thu, 20 Nov 2014, Mark Taylor wrote:
> On Thu, 20 Nov 2014, Malcolm J. Currie wrote:
>
> > > 4. Native support for tables (which may well make FITS2NDF a much easier
> > > proposition). Might require an equivalent of CHI though.
> >
> > What about TOPCAT access to HDF5/HDSV5 tables?
>
> Problematic. Although there is a java HDF5 access library, it
> relies on native code (JNI). My policy on native code in the
> public topcat release is to avoid it completely (e.g. no AST in
> topcat) because of the additional build and distribution
> complications it brings.
>
> I've talked to the HDF5 developers before about the possibility
> of me writing a pure java implementation of the HDF5 access
> functions that I'd need. They didn't seem to think this was
> a good/sensible/feasible idea. Although internals of the the HDF5
> format are, unlike HDS, properly documented, having looked at the
> relevant documentation, I agree with them. The format is clearly
> not designed to facilitate re-implementation from scratch.
>
> [For this reason I am nervous about the pro-HDF5 direction that some
> of the astrodataformat discussion has taken.]
>
> It's possible that given we now have an HDF5 expert to hand,
> it might be possible to implement with moderate effort
> a pure-java HDF5 library with the following restrictions:
> (a) read-only, (b) tables only, (c) only HDF5 variants that HDSv5
> is known to write. It would require some investigation to work
> out whether that's the case.
>
> Alternatively, it might not be too hard to have pluggable
> HDF5 table access using the official JNI library, built
> within starjava. Since SPLAT already uses native code, most
> of the build mechanics are already in place. In that case the
> majority of topcat users wouldn't see it, but it could be used
> by those that are prepared to put in some extra installation work.
Following a bit of reading round HDF5 I'll add something to my
earlier comments: I see there is a non-official Java library for
HDF5 access called JHDF5. This still uses JNI code to talk
to the official HDF access library, but it comes with a
"batteries-included" jar file that apparently handles
building/packaging/loading of the relevant system-dependent
(i.e. non-pure-java) binary libraries without client applications
having to know anything about it. If that's as easy to use as
it sounds, then I might (no promises) consider breaking my
no-native-code rule in topcat.
Mark
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
[log in to unmask] +44-117-9288776 http://www.star.bris.ac.uk/~mbt/
|