Re: [netcdf-java] NoSuchMethodError

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/
>>
>
  • 2022 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: