Thanks Magnus, yeah it is still doing as it says on the "tin", so I think
i'm just being paranoid! I'll put a PR together for review, cheers

On Thu, Sep 21, 2023 at 10:49 AM Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> 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.joels...@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.bur...@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.bate...@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.
>>>>
>>>>

Reply via email to