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.
Hi Rich, You wrote: > In the APIs section of the new tutorial > <http://www.unidata.ucar.edu/software/netcdf/docs_beta/netcdf-tutorial.html#APIs> > it is stated that "The Java API is a complete implementation of netCDF in > Java." > > Unfortunately, as we found out when we tried to replace our C-based > Matlab-NetCDF interface with a Java version, this is not quite the > case -- the Java API lacks some of the basic features of the C & > Fortran interface, like the ability to put a file into redefine mode > to add or modify attributes or data. > > I know that this is inefficient because the file often has to be > entirely rewritten, but this functionality is still a very useful part > of the NetCDF interface. > > This type of "backwards compatibility" in the Java API would be > tremendously useful for us. Yes, thanks for pointing out the misunderstanding. The intended meaning of "complete implementation" was that any netCDF data could be accessed through the Java interface that could be accessed through the C-based interfaces. Another reasonable interpretation of "complete implementation" is that the Java interface provides methods corresponding to every function in the C interface, and as you've pointed out, that's not the case. We'll clarify this in the next version of the document. The intent in the design of the Java interface was to make it hard to unintentionally invoke expensive operations that would move all the data in the file. The ability to add new attributes once the schema for a file had already been defined and data written was omitted so that users would be encouraged to define attributes up front before writing data. But as you've pointed out, this makes it impractical to replace some existing C- or Fortran-based systems using Java. We intend to address this in the next version of netCDF Java, by adding the ability to make changes to the schema after data is written to a netCDF file, just as is now possible with the C-based interfaces. One of the benefits of the new netCDF-4 format is that such changes don't require moving data, so schema changes can be made efficiently. On the subject of resources for learning about netCDF, thanks to contributions by Jeff Whitaker, John Evans, and Heiko Klein, our netCDF program examples now include Python, MATLAB, and Perl examples: http://www.unidata.ucar.edu/software/netcdf/examples/programs/ --Russ _____________________________________________________________________ Russ Rew UCAR Unidata Program russ@xxxxxxxxxxxxxxxx http://www.unidata.ucar.edu ============================================================================== To unsubscribe netcdfgroup, visit: http://www.unidata.ucar.edu/mailing-list-delete-form.html ==============================================================================
netcdfgroup archives: