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/
>>
>
