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.
Martin: Thank you very much for that excellent explanation. John: Well, I could upgrade to Java 11 or 17, however: * One reason to use netcdf-java 5.5.1 is to quickly get access to security changes. But the changes to Java after Java 8 make the upgrade to Java 11 or 17 potentially a big deal. I wouldn't feel comfortable switching and then doing a release quickly (assuming I could do it quickly) and certainly not on Dec 22 when I was winding things up to take some vacation time. * The netcdf-java release notes specifically say you support and test with Java 8. https://github.com/Unidata/netcdf-java/releases/tag/v5.5.1 "This release has been built and test [sic] using Temurin 8 from the (Eclipse Adoptium project) 8, 11, and Zulu 8 and 11." * You say I should upgrade to Java 11 or 17 for "security reasons" but Java 8 offers the same "Long Term Support" (LTS) designation as Java 11 (and not 17). So Java 8 and 11 both get all the security fixes and should be as secure as Java 17. * There are advantages to using the LTS versions over the "latest" Java version (e.g., 17): notably, ERDDAP administrators can reliably upgrade to the latest version of Java 8 or 11 in order to get Java security fixes and know that ERDDAP will still function. If I use/recommend the "latest" Java version (e.g., 17), there is the danger that a change to the Java libraries will be incompatible with ERDDAP and users will be stranded until I release a new version of ERDDAP specifically compiled for the "latest" version of Java. I am still hoping that you will release a newer version of netcdf-java which is fully compatible with Java 8. I will eventually switch to Java 11 (LTS) or some other newer LTS version of Java. On Fri, Dec 24, 2021 at 4:39 PM John Caron <jcaron1129@xxxxxxxxx> wrote: > Thanks Bob for that report, and Martin for that explanation, I hadnt yet > heard of that issue. > > Hailey, can you verify that we are using Java 11? or 17? for compiling > version 5 now? Do we test on a Java 8 JVM? Are there any failures? > > Bob, can you consider upgrading to Java 11 or Java 17? Seems like a good > idea for security reasons. > > thanks, > John > > On Wed, Dec 22, 2021 at 8:54 AM Martin Desruisseaux < > martin.desruisseaux@xxxxxxxxxxxx> wrote: > >> Hello Bob >> >> I have already meet the exact same error with other software. It seems to >> be caused by a hole in a compatibility later of Java compiler. More >> specifically, it is possible to compile a library for Java 8 using a more >> recent Java version, for example 17, by specifying the following option to >> the Java compiler: >> >> --release 8 >> >> Maybe this is what the netCDF project does. When this option is given to >> javac, the compiler uses some list of what methods were available in >> Java 8, and generate a compiler error if we try to use a Java 17 method >> which was not available in Java 8. >> >> Unfortunately there is apparently a grey area not well covered by above >> mechanism: covariant return type. The following method existed (indirectly) >> in Java 8. I said "indirectly" because it was actually inherited from the >> Buffer parent class: >> >> public class ByteBuffer extends Buffer { >> public *Buffer* flip(); >> } >> >> However in Java 9, above method has been overridden has below: the return >> type has been specialized from Buffer to ByteBuffer (this is "return >> type covariance"). >> >> public class ByteBuffer extends Buffer { >> public *ByteBuffer* flip(); >> } >> >> From Java language point of view, methods with the same signature but >> covariant return type are the same method. But from the JVM point of view, >> if the return type is not exactly the same, this is considered as two >> completely different methods. Normally the Java compiler handles those >> difference by generating synthetic methods (invisible to Java developers, >> except in stack trace when an exception is thrown). >> >> So I believe that this is a hole in the compatibility later of javac, >> where it did not recognize that the call to "ByteBuffer flip()" needs to >> be replaced by "Buffer flip()". There is two ways to fix this problem: >> >> - Compile with Java 8. >> - Or modify the source code with the following change in every place >> where a flip() or similar method is invoked on a Buffer subclass: >> >> Replace: >> >> buffer.flip(); >> >> By: >> >> ((Buffer) buffer).flip(); >> >> Martin >> >> >> _______________________________________________ >> NOTE: All exchanges posted to Unidata maintained email lists are >> recorded in the Unidata inquiry tracking system and made publicly >> available through the web. Users who post to any of the lists we >> maintain are reminded to remove any personal information that they >> do not want to be made public. >> >> >> netcdf-java mailing list >> netcdf-java@xxxxxxxxxxxxxxxx >> For list information or to unsubscribe, visit: >> https://www.unidata.ucar.edu/mailing_lists/ >> >
netcdf-java archives: