Should we build jrt-fs.jar again with the "Build JDK" ?
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Thu Sep 21 09:48:51 UTC 2023
On 2023-09-21 10:59, Andrew Leonard wrote:
> My only concern might be the fact the MANIFEST would say "Created by:
> jdk-N-1", which is still accurate according to the spec:
> "Created-By: Defines the version and the vendor of the java
> implementation on top of which this manifest file is generated. This
> attribute is generated by the jar tool."
> However, people would probably jump to the conclusion that the classes
> there in are jdk-N-1 compiled, when they are actually compiled by
> jdk-N....
> Thoughts?
If the definition of the `Created by` field says it is set by the jar
tool that generated the jar file, then this is as it should be, and we
should not try to change it.
It is not in our powers to stop people from jumping to (incorrect)
conclusions, based on their misunderstanding of the specifications (even
though I often wished that it were...).
/Magnus
>
> On Wed, Sep 20, 2023 at 10:50 PM <erik.joelsson at oracle.com> wrote:
>
> Hello Andrew,
>
> The bootcycle-images target is AFAIK just a test. It's certainly
> not meant to be the authoritative way of building the JDK. Using
> JDK N-1 as bootjdk is the official way of producing a JDK of
> version JDK N. For convenience, and because it should work, we
> also allow JDK N. Vendors should definitely not be encouraged to
> use bootcycle builds to produce their JDK binaries.
>
> Switching the compiler to interim would help with the
> reproducibility issue. I would support that change. I don't think
> we can reasonably do something about the jar tool.
>
> /Erik
>
> On 9/20/23 08:12, Andrew Leonard wrote:
>> Hi Magnus,
>>
>> So yes, jrt-fs.jar can be different between a normal build and a
>> bootcycle build, which is where I sort of came in here... For
>> example, building say jdk-21 using a jdk-20 bootjdk, you will
>> find that there is an extra inner class in the standard build of
>> jrt-fs.jar, due to the fact that the jdk-21 compiler optimized
>> the inner class generation for enum's somewhere, such that
>> jdk/internal/jrtfs/JrtFileAttributeView$1.class only exists in a
>> jdk-20 compiled jrt-fs.jar!
>>
>> I did experiment, and you can simply switch jrt-fs.jar to be
>> COMPILER="interim", however when it comes to the jar's
>> construction via "jar", it obviously uses the bootjdk "jar"
>> command since the "interim-compiler" is just a compiler....
>>
>> In summary, I suspect this is just eluding to what the real
>> purpose of "bootcycle-images" is, which I think is essentially a
>> "test", and I suspect most vendors will either just do a standard
>> "product-images" build, or perform their own bootcycle by doing
>> two builds...
>>
>> Cheers
>> Andrew
>>
>>
>>
>> On Wed, Sep 20, 2023 at 2:44 PM Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com> wrote:
>>
>> On 2023-09-20 09:38, Andrew Leonard wrote:
>>
>>> Thanks Alan,
>>>
>>> So different gcc, glibc, Xcode,.. agree, they need to be the
>>> same for identical bits.
>>> However, at the moment using the same toolchains, if you do
>>> a standard product build,
>>> and then a bootcycle build, of the same source, jrt-fs.jar
>>> will differ.
>>> I'll do some investigation of the make files to see if a
>>> "Build JDK" rebuild of jrt-fs.jar is
>>> feasible.
>>
>> I would not in general assume that a normal build and a
>> bootcycle build produce identical results. A bootcycle build
>> will build the product using a newer version of the JDK (viz.
>> the one you just build from the sources), and as such,
>> changes to javac can result in different class file outputs,
>> etc. That being said, for large time periods of the JDK
>> source code, a normal build and a bootcycle build can
>> certainly result in the same output, since no changes have
>> been made in the product that affects how .class files are
>> generated. But that is not guaranteed, nor is a difference
>> between normal and bootcycle build a sign of trouble or a defect.
>>
>> If jrt-fs.jar is consistently different between a bootcycle
>> build and a normal build, that sounds a bit odd, though.
>> Especially since it should be built with `--release 8` (or
>> something like that) to ensure it is usable on older Java;
>> and that output ought not to really change as the JDK develops.
>>
>> (Also, questions about the build process is preferably
>> handled on the build-dev list)
>>
>> /Magnus
>>
>>
>>>
>>> Cheers
>>> Andrew
>>>
>>>
>>> On Tue, Sep 19, 2023 at 5:42 PM Alan Bateman
>>> <Alan.Bateman at oracle.com> wrote:
>>>
>>> On 18/09/2023 14:51, Andrew Leonard wrote:
>>> > Thanks for the clarification Alan.
>>> >
>>> > To ensure the reproducibility of the whole JDK image
>>> regardless of the
>>> > specific bootjdk used, would it make sense once the
>>> "Build JDK" has
>>> > been built, we re-build jrt-fs.jar again using the
>>> "Build JDK" ? Thus
>>> > jrt-fs.jar will be consistent with the rest of the
>>> image in terms of
>>> > what it is compiled with.
>>> >
>>>
>>> The boot JDK will be JDK N-1, or the newly built JDK in
>>> the case of boot
>>> cycle builds. It seems a bit of a stretch to have builds
>>> using different
>>> tool chains to produce identical bits but maybe you mean
>>> something else.
>>>
>>> In any case, for jrt-fs.jar the important thing is that
>>> they are
>>> compiled to --release 8 (that might rev at some points)
>>> so that
>>> IDEs/tools can open a target run-time image as a file
>>> system and access
>>> the classes/resources.
>>>
>>> -Alan.
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230921/01e53975/attachment.htm>
More information about the build-dev
mailing list