Thanks for the detailed info! Given that I have control over all options, I've opted to separate Java sources out into a separate zip file.
-Doug > On 9 Mar 2017, at 19:46, Jonathan Gibbons <jonathan.gibb...@oracle.com> wrote: > > -implicit:none is also a good solution, but which solution is best depends on > your specific situation (i.e. there is no one "best" for everyone.) > > With -implicit:none, you are allowing javac to determine which kind of file > to read (source or class) when more than one kind is available for any given > class, as determined by -Xprefer. In this case, it would seem like javac is > choosing to read source files, which may require more analysis (i.e. > performance cost) than a previously compiled class file. > > By setting sourcepath, you are more directly informing javac of where to read > source files (if any, and if you want that) as compared to class files. > > Whether you prefer to have javac read source files or class files depends on > whether you just want the signatures defined in the class file, or whether > you want all the info available in the source file, and/or whether > performance is an issue. > > -- Jon > > On 03/09/2017 01:13 AM, Doug Simon wrote: >> 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 >>>>> >
