FULL PRODUCT VERSION :
$ /usr/lib/jvm/java-8-openjdk-amd64/bin/java -version
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-8u121-b13-3-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)

$ /usr/lib/jvm/java-9-openjdk-amd64/bin/java -version
openjdk version "9-Debian"
OpenJDK Runtime Environment (build 9-Debian+0-9b155-1)
OpenJDK 64-Bit Server VM (build 9-Debian+0-9b155-1, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Debian testing
Linux thinkpad 4.10.0-rc7-00127-g3d88460dbd28 #208 SMP Fri Feb 10 12:30:45 GMT 2017 x86_64 GNU/Linux


EXTRA RELEVANT SYSTEM CONFIGURATION :
Product Version: NetBeans IDE Dev (Build 201702090002)
Java: 1.8.0_121; OpenJDK 64-Bit Server VM 25.121-b13
Runtime: OpenJDK Runtime Environment 1.8.0_121-8u121-b13-3-b13
System: Linux version 4.10.0-rc7-00127-g3d88460dbd28 running on amd64; UTF-8; en_IE (nb)
User directory: /home/bob/.netbeans/dev
Cache directory: /home/bob/.cache/netbeans/dev

A DESCRIPTION OF THE PROBLEM :
I wanted to try out the JDK9 EA support in a nightly build of NetBeans (201702090002).

NetBeans works OK with a JDK8 runtime. After adding a JDK9 Java platform, with JDK8 runtime, most UI interactions would result in the following or similar:

java.lang.NoSuchMethodError: java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer;
at jdk.internal.jimage.BasicImageReader.slice(BasicImageReader.java:203)
at jdk.internal.jimage.BasicImageReader.intBuffer(BasicImageReader.java:210)
at jdk.internal.jimage.BasicImageReader.<init>(BasicImageReader.java:147)
at jdk.internal.jimage.ImageReader$SharedImageReader.<init>(ImageReader.java:218)
at jdk.internal.jimage.ImageReader$SharedImageReader.open(ImageReader.java:232)
at jdk.internal.jimage.ImageReader.open(ImageReader.java:65)
at jdk.internal.jimage.ImageReader.open(ImageReader.java:69)
at jdk.internal.jrtfs.SystemImage.open(SystemImage.java:59)
at jdk.internal.jrtfs.JrtFileSystem.<init>(JrtFileSystem.java:90)
at jdk.internal.jrtfs.JrtFileSystemProvider.newFileSystem(JrtFileSystemProvider.java:110)
at jdk.internal.jrtfs.JrtFileSystemProvider.newFileSystem(JrtFileSystemProvider.java:129)
at jdk.internal.jrtfs.JrtFileSystemProvider.newFileSystem(JrtFileSystemProvider.java:108)
at java.nio.file.FileSystems.newFileSystem(FileSystems.java:336)
at org.netbeans.modules.java.j2seplatform.platformdefinition.jrtfs.NBJRTFileSystem.create(NBJRTFileSystem.java:95)
at org.netbeans.modules.java.j2seplatform.platformdefinition.jrtfs.NBJRTFileSystemProvider.getFileSystem(NBJRTFileSystemProvider.java:87)
at org.netbeans.modules.java.j2seplatform.platformdefinition.jrtfs.NBJRTFileSystemProvider.getFileSystem(NBJRTFileSystemProvider.java:72)
at org.netbeans.modules.java.j2seplatform.platformdefinition.jrtfs.NBJRTURLMapper.getFileObjects(NBJRTURLMapper.java:97)
at org.openide.filesystems.URLMapper.findFileObject(URLMapper.java:213)
at org.netbeans.modules.java.j2seplatform.platformdefinition.Util.createModulePath(Util.java:122)
at org.netbeans.modules.java.j2seplatform.platformdefinition.J2SEPlatformImpl.getBootstrapLibraries(J2SEPlatformImpl.java:271)
at org.netbeans.modules.java.platform.classpath.PlatformClassPathProvider.findClassPath(PlatformClassPathProvider.java:102)
at org.netbeans.api.java.classpath.ClassPath.getClassPath(ClassPath.java:676)
at org.netbeans.api.java.source.ClasspathInfo.create(ClasspathInfo.java:424)
at org.netbeans.api.java.source.ClasspathInfo.create(ClasspathInfo.java:301)
at org.netbeans.api.java.source.JavaSource.getClasspathInfo(JavaSource.java:702)
at org.netbeans.modules.java.source.JavaSourceAccessor$CancelableTaskWrapper.getClasspathInfo(JavaSourceAccessor.java:305)
at org.netbeans.modules.java.source.parsing.JavacParser.init(JavacParser.java:265)
at org.netbeans.modules.java.source.parsing.JavacParser.parseImpl(JavacParser.java:417)
at org.netbeans.modules.java.source.parsing.JavacParser.parse(JavacParser.java:360)
at org.netbeans.modules.parsing.impl.TaskProcessor.callParse(TaskProcessor.java:621)
at org.netbeans.modules.parsing.impl.SourceCache.getResult(SourceCache.java:251)
at org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.run(TaskProcessor.java:798)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:304)
at org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.execute(TaskProcessor.java:725)
[catch] at org.netbeans.modules.parsing.impl.TaskProcessor$CompilationJob.run(TaskProcessor.java:686)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443)
at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:68)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2058)

Similar stacktraces have been reported in November 2016 (http://statistics.netbeans.org/analytics/detail.do?id=227049).

Investigating further the error seems to be caused by attempting to use the jrt:/ filesystem with a JDK8 runtime.

As per JEP 220, jrt-fs.jar should be useable from a JDK8 runtime. Which seems to be what NetBeans is trying to do.

This bug is not NetBeans specific as the the steps to reproduce below only require the command line.

NetBeans with a JDK9 runtime does not result in this error.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create Test.java from source code below.

Compile Test.java with JDK8.
$ /usr/lib/jvm/java-8-openjdk-amd64/bin/javac Test.java

Run Test.class with JDK8 but load jrt-fs.jar from the JDK9 environment.
$ /usr/lib/jvm/java-8-openjdk-amd64/bin/java -cp .:/usr/lib/jvm/java-9-openjdk-amd64/lib/jrt-fs.jar Test


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No output is expected.
ACTUAL -
$ /usr/lib/jvm/java-8-openjdk-amd64/bin/java -cp .:/usr/lib/jvm/java-9-openjdk-amd64/lib/jrt-fs.jar Test
Exception in thread "main" java.lang.NoSuchMethodError: java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer;
        at jdk.internal.jimage.BasicImageReader.slice(BasicImageReader.java:203)
        at jdk.internal.jimage.BasicImageReader.intBuffer(BasicImageReader.java:210)
        at jdk.internal.jimage.BasicImageReader.<init>(BasicImageReader.java:147)
        at jdk.internal.jimage.ImageReader$SharedImageReader.<init>(ImageReader.java:218)
        at jdk.internal.jimage.ImageReader$SharedImageReader.open(ImageReader.java:232)
        at jdk.internal.jimage.ImageReader.open(ImageReader.java:65)
        at jdk.internal.jimage.ImageReader.open(ImageReader.java:69)
        at jdk.internal.jrtfs.SystemImage.open(SystemImage.java:59)
        at jdk.internal.jrtfs.JrtFileSystem.<init>(JrtFileSystem.java:90)
        at jdk.internal.jrtfs.JrtFileSystemProvider.getTheFileSystem(JrtFileSystemProvider.java:209)
        at jdk.internal.jrtfs.JrtFileSystemProvider.getFileSystem(JrtFileSystemProvider.java:223)
        at java.nio.file.FileSystems.getFileSystem(FileSystems.java:221)
        at Test.main(Test.java:6)


REPRODUCIBILITY :
This bug can be reproduced often.

---------- BEGIN SOURCE ----------
import java.net.*;
import java.nio.file.*;

public class Test {
    public static void main(String[] args) {
        FileSystem fs = FileSystems.getFileSystem(URI.create("jrt:/"));
    }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Using a JDK9 runtime works around the problem.

Some extra comments:

The ByteBuffer incompatibly between JDK8 and JDK9 seems to relate to (http://hg.openjdk.java.net/jdk9/jdk9/jdk/annotate/173916b1007e/src/java.base/share/classes/java/nio/Buffer.java#l273) 4774077: Use covariant return types in the NIO buffer hierarchy.

Maybe jrt-fs.jar should be build with the javac -release 8 feature (JEP 247), to catch some of these incompatibilities at compile time?