我在使用Java 19的Maven插件时遇到了一个错误。Java 18运行良好。我该如何解决这个问题？
我在Centos的Docker集装箱里跑步。7.9.2009。当在Ubuntu 20.0内核5.15.0-52-generic上的同一个容器中测试时，它可以正常工作。
堆叠通道如下。
Caused by: java.io.IOException: Function not implemented
Oct 28 12:12:49 at sun.nio.ch.FileChannelImpl.transferFrom0 (Native Method)
Oct 28 12:12:49 at sun.nio.ch.FileChannelImpl.transferFromDirectlyInternal (FileChannelImpl.java:804)
Oct 28 12:12:49 at sun.nio.ch.FileChannelImpl.transferFromDirectly (FileChannelImpl.java:833)
Oct 28 12:12:49 at sun.nio.ch.FileChannelImpl.transferFrom (FileChannelImpl.java:935)
Oct 28 12:12:49 at org.codehaus.plexus.util.FileUtils.doCopyFile (FileUtils.java:1077)
Oct 28 12:12:49 at org.codehaus.plexus.util.FileUtils.copyFile (FileUtils.java:1049)
使用的版本
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Java version: 19, vendor: Eclipse Adoptium, runtime: /opt/java/openjdk
OS name: "linux", version: "3.10.0-1160.76.1.el7.x86_64", arch: "amd64", family: "unix"
我很好奇，所以深入调查了此事。看来我最初的评论是正确的：您的内核版本对于这个特定的函数来说还为时过早：
FileChannelImpl.transferFrom0在此处实现- 它首先检查CCD_ 2是否为非空，否则返回CCD_
- CCD_ 4显然是通过查找符号CCD_
- 根据这个手册页，系统调用被添加到Linux内核4.5中，但自2.27以来，glibc在用户空间中进行了模拟
Linux 4.5于2016年3月发布，glibc 2.27于2018年2月发布。
由于libc实际上是由容器提供的，因此在使用它时(注意，像Alpine这样基于musl的容器可能有其他要求(，确保容器包含2.27以上的glibc版本就足够了。
请注意，该函数的用户空间模拟不会提供真正的内核实现所能提供的零复制效率增益(即，它将比在更新的内核上运行更慢(。