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.
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: