Jon, Thanks for the insight. I was not aware (or had forgotten) that the classpath is also searched for source files. Reading the javac man page, it seems like I could also use -implicit:none (I confirmed this works). Is that somehow better/cleaner than an empty source path? Of course, since I control creation of the synthetic jars, I should really just put the sources into a separate zip (a la src.zip in the jdk).
-Doug > On 9 Mar 2017, at 02:17, Jonathan Gibbons <jonathan.gibb...@oracle.com> wrote: > > 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 >>> >
