Antonio,
One reason we upgrade is that it's very nice as developers to be able to
use new features from the language, which are added to make our lives
easier, making it simpler (i.e. faster) to add more features. However, the
biggest reason we have moved from JRE 6 is that Oracle has stopped
supporting it (unless you pay them for extended support):
http://www.oracle.com/technetwork/java/eol-135779.html The last public
release of JRE 6 was April of 2013. Since then no bug fixes and, more
importantly, no security updates. Given that, it is irresponsible of us not
to move to JRE 7, especially since NetCDF-Java powers the THREDDS data
server.
You should also note that JRE 7 has scheduled end of life (i.e. end of
support) for April 2015--at some point following that release we will be
forced to move our last supported version to JRE 8.
If moving beyond JRE 6 is problematic for you (and you can live with the
lack of support and security fixes), NetCDF-Java 4.3 (for JRE 6) can still
be downloaded here:
http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/documentation.htm
Ryan
On Fri, Jan 16, 2015 at 10:56 AM, Antonio Rodriges <antonio.rrz@xxxxxxxxx>
wrote:
> John,
>
> I've just downloaded the latest NetCDF-Java 4.5 (since I am not sure
> whether I used 4.5.4 or earlier 4.5.* version). The problem is still
> there with my file
> https://www.dropbox.com/s/xa067an5xogrdyg/2014_ch.nc?dl=0
>
> By the way, NetCDF-Java 4.5 uses JRE 7 what is quite problematically
> for projects still under JRE 6. For a fixed version of NetCDF-Java one
> should also migrate all infrastructure to newer JRE what may be even
> impossible. Does NetCDF-Java 4.5 leverages JRE 7 specific features so
> the decision was taken to abandon JRE 6?
>
> 2015-01-15 3:39 GMT+03:00 John Caron <caron@xxxxxxxx>:
> > Hi Antonio:
> >
> > I think your problem is fixed in version 4.5.4. In any case its working
> for
> > me.
> >
> > John
> >
> > On Tue, Jan 13, 2015 at 2:14 AM, Antonio Rodriges <antonio.rrz@xxxxxxxxx
> >
> > wrote:
> >>
> >> Michael,
> >>
> >> You are not alone.
> >> I had the same issue and posted it on this mailing list on early
> November
> >> 2014:
> >>
> >>
> http://www.unidata.ucar.edu/support/help/MailArchives/netcdf-java/msg02075.html
> >>
> >> Some part of my problem:
> >> [ucar.nc2.NetcdfFile] DEBUG Using IOSP ucar.nc2.iosp.hdf5.H5iosp
> >> [ucar.nc2.iosp.hdf5.H5header] ERROR bad version 72 at filePos 22386
> >>
> >> I get this error after applying ncks for chunking NetCDF3 file and get
> >> NetCDF4 as output.
> >>
> >> At first I thought that it is an ncks issue, but another trouble like
> this
> >> http://sourceforge.net/p/nco/discussion/9830/thread/152db6f2/
> >> suggests of incompatibility of APIs throught NetCDFJava releases, not
> NCO
> >> issue.
> >>
> >> The trouble is both with NetCDF Java 4.3 and 4.5.
> >>
> >> I wrote about NetCDF4 issue on early November 2014 and I do not have a
> >> workaround or fix from NetCDF Java developers still.
> >>
> >> 2015-01-13 1:33 GMT+03:00 Gangl, Michael E (398H)
> >> <Michael.E.Gangl@xxxxxxxxxxxx>:
> >> > We’ve written some wrappers around the NetCDF java packages and are
> >> > running into some odd errors. We can successfully read the netCDF4 and
> >> > NetCDF4-classic files. But we have a new NetCDF4 file that is throwing
> >> > us
> >> > an interesting error:
> >> >
> >> > java.lang.IllegalStateException: MessageAttribute unknown version 72
> >> > at
> >> > ucar.nc2.iosp.hdf5.H5header$MessageAttribute.read(H5header.java:2645)
> >> > at
> >> >
> >> >
> ucar.nc2.iosp.hdf5.H5header$DataObject.processAttributeInfoMessage(H5header
> >> > .java:1579)
> >> > at
> >> > ucar.nc2.iosp.hdf5.H5header$DataObject.<init>(H5header.java:1548)
> >> > at
> >> > ucar.nc2.iosp.hdf5.H5header$DataObject.<init>(H5header.java:1441)
> >> > at
> ucar.nc2.iosp.hdf5.H5header.getDataObject(H5header.java:1291)
> >> > at ucar.nc2.iosp.hdf5.H5header.access$700(H5header.java:48)
> >> > at
> >> >
> ucar.nc2.iosp.hdf5.H5header$DataObjectFacade.<init>(H5header.java:1334)
> >> > at
> >> > ucar.nc2.iosp.hdf5.H5header.readSuperBlock2(H5header.java:301)
> >> > at ucar.nc2.iosp.hdf5.H5header.read(H5header.java:156)
> >> > at ucar.nc2.iosp.hdf5.H5iosp.open(H5iosp.java:86)
> >> > at ucar.nc2.NetcdfFile.<init>(NetcdfFile.java:1110)
> >> > at ucar.nc2.NetcdfFile.open(NetcdfFile.java:623)
> >> > at ucar.nc2.NetcdfFile.open(NetcdfFile.java:320)
> >> > at ucar.nc2.NetcdfFile.open(NetcdfFile.java:290)
> >> > at ucar.nc2.NetcdfFile.open(NetcdfFile.java:277)
> >> > at ucar.nc2.NetcdfFile.open(NetcdfFile.java:265)
> >> >
> >> >
> >> > The file is provided to us, so I don’t have any idea how it’s being
> >> > written, but would that matter? Is this a library issue? Is this some
> >> > configuration on my part that might be causing this issue?
> >> >
> >> > Thanks,
> >> > Mike Gangl
> >> >
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > netcdf-java mailing list
> >> > netcdf-java@xxxxxxxxxxxxxxxx
> >> > For list information or to unsubscribe, visit:
> >> > http://www.unidata.ucar.edu/mailing_lists/
> >>
> >> _______________________________________________
> >> netcdf-java mailing list
> >> netcdf-java@xxxxxxxxxxxxxxxx
> >> For list information or to unsubscribe, visit:
> >> http://www.unidata.ucar.edu/mailing_lists/
> >
> >
> >
> > _______________________________________________
> > netcdf-java mailing list
> > netcdf-java@xxxxxxxxxxxxxxxx
> > For list information or to unsubscribe, visit:
> > http://www.unidata.ucar.edu/mailing_lists/
>
> _______________________________________________
> netcdf-java mailing list
> netcdf-java@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
--
Ryan May
Software Engineer
UCAR/Unidata
Boulder, CO
