Description of problem: javac 9 throws NPE when reading log4j-api.jar. The jar is used by other packages in Fedora, so it should be valid and work with java 8. Version-Release number of selected component (if applicable): java-9-openjdk-devel-9.0.4.11-6.fc28.x86_64 How reproducible: always Steps to Reproduce: 1. echo 'class Main{}' > Main.java 2. Install log4j RPM (I used package from rawhide) 3. /usr/lib/jvm/java-9/bin/javac -cp /usr/share/java/log4j/log4j-api.jar Main.java Actual results: java.lang.NullPointerException at jdk.zipfs/jdk.nio.zipfs.JarFileSystem.getVersionMap(JarFileSystem.java:137) at jdk.zipfs/jdk.nio.zipfs.JarFileSystem.createVersionedLinks(JarFileSystem.java:112) at jdk.zipfs/jdk.nio.zipfs.JarFileSystem.<init>(JarFileSystem.java:85) at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.newFileSystem(ZipFileSystemProvider.java:134) at jdk.compiler/com.sun.tools.javac.file.JavacFileManager$ArchiveContainer.<init>(JavacFileManager.java:517) at jdk.compiler/com.sun.tools.javac.file.JavacFileManager.getContainer(JavacFileManager.java:319) at jdk.compiler/com.sun.tools.javac.file.JavacFileManager.list(JavacFileManager.java:715) at jdk.compiler/com.sun.tools.javac.code.ClassFinder.list(ClassFinder.java:722) at jdk.compiler/com.sun.tools.javac.code.ClassFinder.scanUserPaths(ClassFinder.java:648) at jdk.compiler/com.sun.tools.javac.code.ClassFinder.fillIn(ClassFinder.java:529) at jdk.compiler/com.sun.tools.javac.code.ClassFinder.complete(ClassFinder.java:293) at jdk.compiler/com.sun.tools.javac.code.Symtab.lambda$addRootPackageFor$7(Symtab.java:758) at jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:633) at jdk.compiler/com.sun.tools.javac.comp.Enter.visitTopLevel(Enter.java:354) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:529) at jdk.compiler/com.sun.tools.javac.comp.Enter.classEnter(Enter.java:285) at jdk.compiler/com.sun.tools.javac.comp.Enter.classEnter(Enter.java:300) at jdk.compiler/com.sun.tools.javac.comp.Enter.complete(Enter.java:570) at jdk.compiler/com.sun.tools.javac.comp.Enter.main(Enter.java:554) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1052) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:923) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:302) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:162) at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
Still reproducible with Java 10 on rawhide. java-10-openjdk-10.0.0.46-10.fc29.x86_64
I'll take a look.
This is upstream JDK-8193802. For multi-release jar files[1] which specify "Multi-Release: true" in its MANIFEST.MF, yet don't contain any version specific classes in the jar (e.g. META-INF/versions/{n}/SomeClass.class) an NPE is thrown. It's fixed in JDK 11, but in no JDK 9 or JDK 10 release. In the log4j case, I see: $ jar -tf log4j-api.jar | grep 'META-INF/versions' $ dir=$(mktemp -d); j=$(pwd)/log4j-api.jar \ pushd $dir; unzip $j > /dev/null && \ grep Multi-Release META-INF/MANIFEST.MF; popd; rm -rf $dir /tmp/tmp.zTYTOOmAKb ~/Documents/openjdk/rhbz_bugs/rhbz1557375 Multi-Release: true ~/Documents/openjdk/rhbz_bugs/rhbz1557375 [1] http://openjdk.java.net/jeps/238
https://src.fedoraproject.org/rpms/java-openjdk/pull-request/8 Should be fixed once this completes: https://koji.fedoraproject.org/koji/taskinfo?taskID=26677744
Should be fixed in rawhide.