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