Doug,
The jar files in your example contain source code; therefore javac is
not so much copying the contents of the classpath to the output
directory as it is compiling the source it is finding.
Two experiments for you.
1.
$ unzip -l jdk.internal.vm.ci.jar | sort -k 4 | head -n 20
--------- -------
1710248 444 files
Archive: jdk.internal.vm.ci.jar
--------- ---------- ----- ----
990 2017-03-07 15:27 jdk/vm/ci/aarch64/AArch64$1.class
7936 2017-03-07 15:27 jdk/vm/ci/aarch64/AArch64.class
1607 2017-03-07 15:27 jdk/vm/ci/aarch64/AArch64$CPUFeature.class
1212 2017-03-07 15:27 jdk/vm/ci/aarch64/AArch64$Flag.class
10478 2017-03-07 15:27 jdk/vm/ci/aarch64/AArch64.java
1414 2017-03-07 15:27 jdk/vm/ci/aarch64/AArch64Kind$1.class
4121 2017-03-07 15:27 jdk/vm/ci/aarch64/AArch64Kind.class
3833 2017-03-07 15:27 jdk/vm/ci/aarch64/AArch64Kind.java
980 2017-03-07 15:27 jdk/vm/ci/amd64/AMD64$1.class
9034 2017-03-07 15:27 jdk/vm/ci/amd64/AMD64.class
2931 2017-03-07 15:27 jdk/vm/ci/amd64/AMD64$CPUFeature.class
1161 2017-03-07 15:27 jdk/vm/ci/amd64/AMD64$Flag.class
11763 2017-03-07 15:27 jdk/vm/ci/amd64/AMD64.java
2207 2017-03-07 15:27 jdk/vm/ci/amd64/AMD64Kind$1.class
5333 2017-03-07 15:27 jdk/vm/ci/amd64/AMD64Kind.class
5384 2017-03-07 15:27 jdk/vm/ci/amd64/AMD64Kind.java
2. In your example, set the sourcepath to be empty. That will force
javac to look for source files on the sourcepath (where it won't find
any), and only look for class files on the classpath.
$ rm -rf bin
$ sh run.sh
$ find bin
bin
bin/org
bin/org/graalvm
bin/org/graalvm/compiler
bin/org/graalvm/compiler/api
bin/org/graalvm/compiler/api/runtime
bin/org/graalvm/compiler/api/runtime/GraalRuntime.class
bin/org/graalvm/compiler/api/runtime/GraalJVMCICompiler.class
$
-- Jon
On 03/07/2017 10:11 AM, Doug Simon wrote:
Hi Jon,
I've attached bug.zip which should reproduce the issue (assuming jdk 9 javac is
on your path):
unzip bug.zip
cd bug
./run.sh
find bin
The last command above should show the extra class files from
jdk.internal.vm.ci.jar in bin.
-Doug
On 7 Mar 2017, at 18:55, Jonathan Gibbons <jonathan.gibb...@oracle.com> wrote:
On 03/07/2017 08:06 AM, Doug Simon wrote:
To be able to develop Graal on JDK 9, we're using the `--release 8` javac
option and providing jar files for API that is either not in 9 or is not
exported in 9. Here is a simplified form of a javac command:
javac -cp jdk.internal.vm.ci.jar:jdk.unsupported_sun.misc.Unsafe.jar -d bin/
--release 8
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/*.java
where:
dsimon@kurz-3 ~/h/graal-core> ls
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/*.java
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/GraalJVMCICompiler.java
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/GraalRuntime.java
I expect 2 class files to be written to bin/. However, I see a number of files
from jdk.internal.vm.ci.jar in bin:
dsimon@kurz-3 ~/h/graal-core> jar tf jdk.internal.vm.ci.jar | wc -l
444
dsimon@kurz-3 ~/h/graal-core> find bin/jdk/vm/ci | wc -l
55
I'm guessing that these are the classes in jdk.internal.vm.ci.jar referenced
(transitively?) from the Graal sources.
Why is this happening? That is, why is javac extracting classes from a jar on
the classpath and putting them in the output directory?
-Doug
Doug,
Can you provide a more complete test case?
-- Jon
