javac unzips class files from jars on class path into output directory
Jonathan Gibbons
jonathan.gibbons at oracle.com
Thu Mar 9 01:17:43 UTC 2017
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.gibbons at 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 at 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 at kurz-3 ~/h/graal-core> jar tf jdk.internal.vm.ci.jar | wc -l
>>> 444
>>> dsimon at 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
More information about the jigsaw-dev
mailing list