HDF-Java Overview
Download as PPTX, PDF0 likes912 views
The presentation provided an overview of HDF-Java and HDFView. It discussed the history and architecture of HDF-Java, including the Java Object Layer API and format-specific Java Native Interface implementations. HDFView was described as providing image, table, and metadata views and editing capabilities for HDF-EOS2/5 and netCDF files through a plug-in architecture. While currently functional, HDFView has an outdated interface and scope issues. The future direction is to fully realize HDF data types and functionality in the layers, decouple the layers, redesign the memory model, and prepare for HDF5 1.10 features.
HDF-Java Overview
- 1. www.hdfgroup.org The HDF Group ESIP Summer Meeting HDF-Java Overview Joel Plutchak The HDF Group 1July 8 – 11, 2014
- 2. www.hdfgroup.orgESIP Summer MeetingJuly 8 – 11, 2014 2 Jan 1996 Java 1.0 JHV & JHI 1996 Fall 1997 Java Proposal HDF5 Object Layer Spring 1999 Summer 2002 Common Object Model Editing Spring 2003 Summer 2003 Abstract Interfaces & plug-in framework NPOESS: regions references & bitfields Summer 2009 Summer 2013 CF Conven- tions An HDF-Java Timeline
- 3. www.hdfgroup.orgESIP Summer Meeting HDF-Java Architecture High-level architecture: • Java Application • Java Object Layer API • Format-specific / Java Native Interface (JNI) implementations • HDFView July 8 – 11, 2014 3
- 4. www.hdfgroup.orgESIP Summer Meeting HDFView July 8 – 11, 2014 4
- 5. www.hdfgroup.orgESIP Summer Meeting Current Status Basic capabilities & limitations HDFView: • Image & table views, editing, animation, some metadata convention support • Plug-in architecture for I/O and GUI (netCDF, FITS, HDF-EOS2/5) • Outdated graphical interface; scope creep Java Object Layer: • Abstraction of HDF & generic dataset concepts • Data type mapping issues from HDF representation to Java • Memory model: monolithic HDF4/HDF5 JNI Layer: • Most HDF functionality and data types supported • Some missing: e.g., variable length types, compound compound July 8 – 11, 2014 5 http://www.hdfgroup.org/products/java/
- 6. www.hdfgroup.orgESIP Summer Meeting Future Direction July 8 – 11, 2014 6 Near-term work • Data types & functionality: fully realize in HDF Object and JNI Layers • Decouple layers: easier packaging and distribution • Memory model: redesign to support large(r) datasets • Prepare to support new HDF5 features: HDF5 1.10 The Future
- 7. www.hdfgroup.orgESIP Summer Meeting Questions? Thank you! July 8 – 11, 2014 7 This work was supported by subcontract 114820 under prime contract NNG10HP02C, funded by the National Aeronautics and Space Administration (NASA). Any opinions, findings, or conclusions expressed in this material are those of the author and do not necessarily reflect the views of NASA. Joel Plutchak plutchak@hdfgroup.org
- 8. www.hdfgroup.orgESIP Summer Meeting Supplemental Slides July 8 – 11, 2014 8
- 9. www.hdfgroup.orgESIP Summer Meeting HDF-Java Object Classes July 8 – 11, 2014 9
- 10. www.hdfgroup.orgESIP Summer Meeting HDFView July 8 – 11, 2014 10
- 11. www.hdfgroup.org The HDF Group ESIP Summer Meeting Earth Science Group Ted Habermann Aleksandar Jelenak H. Joe Lee Joel Plutchak Kent Yang 11July 8 – 11, 2014
Editor's Notes
- #2: Providing a brief roadmap of Java development at The HDF Group. History, current status, possible future direction.
- #3: mention HDF-EOS plug-in, FITS I/O module, netCDF (native Java) The JHV and JHI grew out of (was influenced by?) work on the NASA-funded Project Horizon, in conjunction with the Univ of Illinois departments of Astronomy and Atmospheric Sciences. They led to the proposal for what is now collectively known as HDF-Java. The original work was based on the original Hierarchical File Format, now known as HDF4. The first version of HDF5 was released in 1998; support for HDF5 followed in 1999 with a separate object model parallel to that of HDF4. By summer of 2002 the two models were abstracted into a single object model with different implementations, adding to the sustainability of the software by bridging the gap between HDF4 and HDF5, and allowing support for additional file formats A bit later editing capabilities were added to the main functionality. Building on the abstraction of the underlying object model and I/O, GUI components of the HDFView application were abstracted and redesigned as interfaces, allowing overriding of those components (tree, image, table, palette, ??????). A lot of small enhancements and fixes took place after 2003; a couple of note were additions to support the NPOESS (now JPSS) project, and the ESDIS project. In August of 2013 the Java task lead and programmer left the company.
- #4: A Java application that accesses HDF (or other) format files is built on top of an Object Layer interface (aka Common Object Package) that encapsulates data format objects; plus a lower layer that includes: An implementation for each file format supported A JNI interface to each native library (if necessary) for each file format Additional file formats include a netCDF (pure Java) interface, a FITS interface, HDF-EOS2, HDF-EOS5 (Raytheon/ESDIS) The plug-in architecture for HDFView also includes the GUI interfaces, in order to add capabilities that extend or differ from the default implementations (Tree, Image, Table, Text, Palette) Combined HDF-EOS2/5 implementations for Tree, Image, Table
- #5: Add from 1 to 3 screen captures: image view (with graph?), table view, HDF-EOS plug-in? Animate?
- #6: Views for image, table, palette, attributes, and text; editing of everything (attribute and dataset values, group and dataset names, etc.) Scope creep without considering redesign/rescope has led to some delicate code interconnections Data type: Java supports more restricted set of data types, so mapping necessary; e.g., Extended ASCII Unicode/ASCII Abstraction and plug-in architecture promotes sustainability by allowing to keep up with changing and new formats and display options Data type mapping in some cases one-way; can’t save changes, etc. Monolithic memory model, so limited by system and/or Java VM memory.
- #7: - Decouple layers: easier to use for Java programming; more nimble with releases (currently once per year, all components simultaneously)
- #8: Flashback to 1995 with the original Java mascot, “Duke”
- #11: Add from 1 to 3 screen captures: image view (with graph?), table view, HDF-EOS plug-in? Animate?
- #12: The Earth Science Group is a subgroup within The HDF Group formed to concentrate on issues like these. We’re excited by the opportunity to join in the conversation and help form the emerging landscape in Earth Sciences software, data and metadata conventions and their uses in current and upcoming missions.