Re: [netcdf-java] NoSuchMethodError

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.


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