Summary
javac JAR files on the class-path no longer have updated class files written back to them.
Problem
Note: This issue only occurs when javac
is run without either the -sourcepath
or -d
(output directory) options.
If there is no -sourcepath
specified, javac will also search the classpath for source files, and may use the source file instead of a corresponding classfile, depending on the timestamps and entry ordering. By default these source files are compiled all the way into the corresponding classfiles. When there is no -d
specified, javac generally places the output classfiles next to the sourcesfile. As a consequence, javac may modify the JAR file on the classpath, writing a new classfile into it.
This is problematic, because the JAR files on the classpath may be from authoritative sources.
Solution
When determining output class-file paths, in the absence of the -d
option, check for whether a source file object comes from a JAR file, and (if so) avoid specifying the output class file as its sibling. The classfile will be written into the current working directory instead.
This solution reverts behavior to that found in JDK 8 and earlier, including writing any affected class files into the current working directory. This behavior results in a loss of package/directory consistency and is unlikely to be useful, but it is the historical behavior.
Specification
No formal specification change, and behavior is being reverted to that of JDK 8.
- csr of
-
JDK-8338675 javac shouldn't silently change .jar files on the classpath
-
- Open
-
- relates to
-
JDK-8350880 (zipfs) Add support for read-only zip file systems
-
- Open
-