Whither HDF Java?

Joel Plutchak, The HDF Group

The HDF Group’s support for and use of the Java Programming Language consists of Java wrappers for the HDF4 and HDF5 C libraries, an Object Model definition and implementation, and HDFView, a graphical file viewing application. In this article we’ll discuss what we’re doing now with Java, and look toward the future.

The screen capture shows some of the capabilities of the HDFView application. Displayed is a JPSS Mission VIIRS (Visible Infrared Imaging Radiometer Suite) Day-Night band dataset in table form and image form with false color palette attached.

By the time the first public version of the Java Programming Language was released in 1995, various groups at the University of Illinois were already experimenting with the then-new language.  Among these efforts was a collaboration among several departments; the goal was to produce data browsing tools for use in astronomy and other scientific fields.1  Because The HDF Group was formed to provide access to scientific and engineering data, it seemed natural to extend this early Java work to the display of HDF files and data products. 

Early Java Development

The HDF Group implemented a Java Native Interface (JNI) to the HDF library, along with a set of classes to display datasets in tabular and graphical form. The JNI wrappers allowed any Java programmer access to HDF files, while the display classes provided the basis for HDFView, a Java application that graphically displays structure and content of an HDF file in tabular (spreadsheet) or image form.

When the HDF5 format came along a couple of years later, the Java work was again extended to include an abstract Object Model to act as a common interface to any dataset-oriented file format, whether HDF4, HDF5, FITS, netCDF, or other format. A similar abstraction was added to the graphical layer of the HDFView application. Together, implementations of these abstract classes allowed the use of plugins—custom built Java modules that could interface with many different file formats, and add display functionality specific to individual data formats or conventions (e.g., HDF-EOS5).

Next, the ability to edit files was added to HDFView. In addition to changing values in datasets, we added the ability to add, modify, and remove attributes, datasets and groups – you could now edit the file structure in general.  By the summer of 2003, the whole package looked much as it does today.  Many small enhancements and bug fixes have taken place since then, but we’ve done no major new development.

Current and Future Efforts

During the past couple of years we’ve embarked on an effort to enhance maintainability of our Java products, modernize them, and in general step back and take a look at where we are and where we may be headed.

First, in order to better maintain our Java products, we are repackaging them. Until now, releases consisted of a single, monolithic “HDF-Java” product containing the HDFView application, the Object Model classes, and the underlying format- and operating system-specific wrappers.  This means you have to download and install the whole package, even if all you need is the HDF5 API Java native interface. Beginning in 2016, we will package the file format-specific components separately as part of the associated HDF release—the HDF4 Java interface will be included with the yearly HDF4 distribution, and the HDF5 interface will be included with the twice-yearly HDF5 release. HDFView, along with the closely-related Image Object Model interface will still be released as a standalone all-inclusive application. While there is not currently a fixed release schedule for HDFView, “unbundling” will make releases, as needed, far easier.

Next, we are anticipating the release of HDF5 version 1.10.0,2 scheduled for alpha release this fall and final release in March 2016. This is a major release that will include HDF5 API and file format changes. Going forward, all new development for the Object Model library and the new HDFView will be based on HDF5 version 1.10.0 and beyond. (The current HDFView application will be put into maintenance mode—bug fixes but no new development.)

Lastly, we have been considering changing the underlying graphical toolkit for the HDFView application, to better match its “look and feel” with the underlying operating system, and in anticipation of the deprecation of the currently-used Swing toolkit. We have built a semi-functional prototype using the SWT toolkit, and while we haven’t made any firm decisions, the results look promising. We plan to make the prototype available for evaluation in the near future—stayed tuned!

Still ahead is an evaluation of the memory model in the Object Model layer and HDFView to assess ways to make it fit better with the larger data files of today. We’ll also make a decision about the HDFView graphical interface—do we go forward with the SWT toolkit, or perhaps take a closer look at JavaFX? Also, there are significant new features in HDF5 version 1.10.0 that need to be incorporated into the HDF5 interface module; we’ve started to plan for those changes.

At the same time, we’ve reconnected with a few avid users of our Java HDF file format interfaces, and we are actively discussing improvements and further collaboration with them. We welcome your input and assistance in helping guide us in these efforts.

More information about our Java products can be found on our web site at

Let us know how you use our Java offerings and what you’d like to see in the future!  Please comment here, or send your thoughts to Joel at


1 Java, Image Browsing, and the NCSA Astronomy Digital Image Library, R. L. Plante, D. Goscha, R. M. Crutcher, J. Plutchak, R. E. M. McGrath, X. Lu, and M. Folk.

2 What’s coming in the HDF5 1.10.0 Release?, E. Pourmal and Q. Koziol.


  • Dan
    November 11, 2015 at 10:54 am

    I’ve had problems building and using filter plugins when using the current jhdf5.dll, particularly those plugins that use HDF5 API functions (e.g. the LZF plugin used by h5py).

    When repackaging the Java products, will you also be repackaging the jhdf5 DLL so it only contains the JNI bindings and supporting functions, and then depends on the regular hdf5.dll in much the same way that the CPP and Fortran DLLs do?

    Assuming the problems I’ve had are indeed due to the library structure, I hope this would make it easier to use the same plugins via the dynamic plugin loading mechanism in both C++ and Java.

    • Joel Plutchak
      November 25, 2015 at 12:08 pm


      Yes, we will be packaging the JNI bindings along with HDF5 releases starting with HDF5 version 1.10. These will then depend on the associated HDF5 dll (the HDF5 Java dll may be renamed to avoid confusion). We would like to do the same for future versions of the HDF5 1.8 releases but that decision is pending. One of our goals is to make it easier for our Java users, and we think this will help.

      Thank you for your input!

  • Trig Chen
    April 10, 2017 at 11:49 pm

    HDFView can’t open the hdf5 files which have unicode filenames or are beside in unicode named directories.

Leave a Comment