On Fri, 10 Dec 2021 19:40:59 GMT, Lance Andersen wrote:
>> Looks like the CSR has been approved. I have a mach5 run that should
>> hopefully finish sooner rather than later and if that remains happy, I will
>> approve the PR
>
>> @LanceAndersen let me know if mach5 looks good please, then I th
On Sat, 11 Dec 2021 11:57:57 GMT, Lance Andersen wrote:
> Hi Andrew,
>
> The latest Mach5 runs remain clean and the updates look good so you are good
> to integrate when you are ready!
Thank you @LanceAndersen
-
PR: https://git.openjdk.java.net/jdk/pull/6481
On Fri, 19 Nov 2021 16:52:36 GMT, Andrew Leonard wrote:
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
On Fri, 10 Dec 2021 17:20:40 GMT, Kevin Rushforth wrote:
>> @LanceAndersen let me know if mach5 looks good please, then I think we're
>> good to go..
>
> @andrew-m-leonard if this enhancement is now intended to go into JDK 19, then
> you can simply integrate it into jdk mainline when it is read
On Fri, 10 Dec 2021 19:16:49 GMT, John Neffenger wrote:
>>> Thanks, CSR now Finalized
>>
>> Just a minor note: the CSR uses the adjective "extended" in three places for
>> the DOS date and time field, but that field is actually a part of the
>> original ZIP specification and not in an extended
On Tue, 7 Dec 2021 19:06:17 GMT, John Neffenger wrote:
>> Thanks, CSR now Finalized
>
>> Thanks, CSR now Finalized
>
> Just a minor note: the CSR uses the adjective "extended" in three places for
> the DOS date and time field, but that field is actually a part of the
> original ZIP specificati
On Fri, 10 Dec 2021 17:20:40 GMT, Kevin Rushforth wrote:
>> @LanceAndersen let me know if mach5 looks good please, then I think we're
>> good to go..
>
> @andrew-m-leonard if this enhancement is now intended to go into JDK 19, then
> you can simply integrate it into jdk mainline when it is read
On Tue, 7 Dec 2021 19:25:05 GMT, Lance Andersen wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>
On Fri, 10 Dec 2021 11:51:53 GMT, Lance Andersen wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
On Tue, 7 Dec 2021 19:25:05 GMT, Lance Andersen wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
On Thu, 9 Dec 2021 18:15:42 GMT, Lance Andersen wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
On Thu, 9 Dec 2021 18:31:57 GMT, Lance Andersen wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>
On Thu, 9 Dec 2021 18:40:01 GMT, Lance Andersen wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>
On Thu, 9 Dec 2021 18:14:39 GMT, Lance Andersen wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>
On Thu, 9 Dec 2021 22:11:57 GMT, Andrew Leonard wrote:
>> test/jdk/tools/jar/ReproducibleJar.java line 87:
>>
>>> 85: "2098-02-18T00:00:00-08:00",
>>> 86: "2099-12-31T23:59:59+00:00&quo
On Thu, 9 Dec 2021 18:14:13 GMT, Lance Andersen wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>
On Tue, 7 Dec 2021 19:25:05 GMT, Lance Andersen wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
On Wed, 8 Dec 2021 16:51:05 GMT, Alan Bateman wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>
On Mon, 6 Dec 2021 19:11:45 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
&g
On Mon, 6 Dec 2021 19:11:45 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
&g
On Tue, 7 Dec 2021 12:03:10 GMT, Lance Andersen wrote:
> The latest CSR update looks good so I think you are in good shape now
@LanceAndersen thank you Lance
-
PR: https://git.openjdk.java.net/jdk/pull/6481
On Tue, 7 Dec 2021 09:24:44 GMT, Alan Bateman wrote:
> I've edited the CSR to make the summary a bit simpler. I've also removed some
> of text from the Solution section as the discussion about SOURCE_DATE_EPOCH
> being an issue due to the security manager was confusing. I also removed the
> se
On Mon, 29 Nov 2021 19:08:43 GMT, Lance Andersen wrote:
>>> @AlanBateman yes, see above comment, thanks
>>
>> This is a significant change to the ZipEntry API that will require
>> discussion and agreement. Can you start a discussion on core-libs-dev about
>> the topic? You could start with a s
On Mon, 6 Dec 2021 19:04:06 GMT, Andrew Leonard wrote:
>> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line
>> 300:
>>
>>> 298: \ --date=TIMESTAMP The timestamp in ISO-8601 extended
>>> offset date-time with\n\
>>>
On Mon, 6 Dec 2021 16:36:37 GMT, Alan Bateman wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
On Mon, 6 Dec 2021 00:15:13 GMT, Lance Andersen wrote:
>> Andrew Leonard has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 25 commits:
>>
>> - Merge jdk:master
>>
>>Signed-off-by: Andrew
On Fri, 3 Dec 2021 10:05:43 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
&g
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
On Fri, 3 Dec 2021 10:05:43 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
&g
On Thu, 2 Dec 2021 01:53:47 GMT, John Neffenger wrote:
>>> I'm testing it now. So far, it's working great!
>>>
>>> I found one boundary problem. The magic instant of `1980-01-01T00:00:00Z`
>>> triggers an extended header with the wrong time:
>>>
>>> ```
>>> file last modified on (DOS date/ti
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated the pu
On Thu, 2 Dec 2021 21:07:30 GMT, Andrew Leonard wrote:
> PR https://github.com/openjdk/jdk/pull/6647 resolved the GENDATA_CACERTS_SRC
> fir --with-cacerts-src after the recipe, which meant the dependencies were
> wrong.
> This PR moves it before the recipe.
>
> Signed-off-
On Thu, 2 Dec 2021 18:46:09 GMT, Erik Joelsson wrote:
>> this was my understanding:
>> https://www.gnu.org/software/make/manual/html_node/Variables-in-Recipes.html
>>
>> This occurs after make has finished reading all the makefiles and the target
>> is determined to be out of date; so, the rec
On Thu, 2 Dec 2021 17:48:04 GMT, Andrew Leonard wrote:
>> you make a valid point, but i've tested this numerous times, but let me
>> check again
>
> my assumption was the recipe gets resolved later
this was my understanding:
https://www.gnu.org/software/make/manual
On Thu, 2 Dec 2021 17:46:35 GMT, Andrew Leonard wrote:
>> I would have expected to see something like:
>>
>> ifneq ($(CACERTS_SRC), )
>> GENDATA_CACERTS_SRC := $(CACERTS_SRC)
>> else
>> GENDATA_CACERTS_SRC := $(TOPDIR)/make/data/cacerts/
>> end
On Thu, 2 Dec 2021 17:35:36 GMT, Magnus Ihse Bursie wrote:
>> make/modules/java.base/Gendata.gmk line 76:
>>
>>> 74: ifneq ($(CACERTS_SRC), )
>>> 75: GENDATA_CACERTS_SRC := $(CACERTS_SRC)
>>> 76: endif
>>
>> Does this even work?! You are reassigning the variable after it has been
>> used. Th
On Wed, 1 Dec 2021 18:30:06 GMT, Andrew Leonard wrote:
> Addition of a configure option --with-cacerts-src='user cacerts folder' to
> allow developers to specify their own cacerts PEM folder for generation of
> the cacerts store using the deterministic openjdk GenerateCacert
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated the pu
On Thu, 2 Dec 2021 14:29:00 GMT, Sean Mullan wrote:
> I don’t have any major concerns with this change, as long as the default
> cacerts are still the ones that are in the JDK. As an aside, using Mozilla's
> root certificates might be fine for TLS certificates, but if you need to
> support cod
> Addition of a configure option --with-cacerts-src='user cacerts folder' to
> allow developers to specify their own cacerts PEM folder for generation of
> the cacerts store using the deterministic openjdk GenerateCacerts tool.
>
> Signed-off-by: Andrew Leonard
Andre
On Wed, 1 Dec 2021 18:47:41 GMT, Erik Joelsson wrote:
>> Andrew Leonard has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contai
On Thu, 2 Dec 2021 00:09:15 GMT, John Neffenger wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>>
&g
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated the pu
On Thu, 2 Dec 2021 00:09:31 GMT, Sergey Bylokhov wrote:
> I have a question related to the custom cacerts which can be added to the
> OpenJDK bundle. How do you pass the tests like
> test/jdk/sun/security/lib/cacerts/VerifyCACerts.java using that custom jdk
> bundle? Probably we can add an add
On Thu, 2 Dec 2021 01:53:47 GMT, John Neffenger wrote:
>>> I'm testing it now. So far, it's working great!
>>>
>>> I found one boundary problem. The magic instant of `1980-01-01T00:00:00Z`
>>> triggers an extended header with the wrong time:
>>>
>>> ```
>>> file last modified on (DOS date/ti
On Wed, 1 Dec 2021 18:20:11 GMT, John Neffenger wrote:
> I'm testing it now. So far, it's working great!
>
> I found one boundary problem. The magic instant of `1980-01-01T00:00:00Z`
> triggers an extended header with the wrong time:
>
> ```
> file last modified on (DOS date/time):
Addition of a configure option --with-cacerts-src='user cacerts folder' to
allow developers to specify their own cacerts PEM folder for generation of the
cacerts store using the deterministic openjdk GenerateCacerts tool.
Signed-off-by: Andrew Leonard
-
Commi
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
On Mon, 29 Nov 2021 17:07:52 GMT, Alan Bateman wrote:
>> @andrew-m-leonard I see you've add several APIs to ZipEntry in this PR. I
>> think this part will require discussion as it's not immediately clear that
>> we should over burden the ZipEntry API as proposed.
>
>> @AlanBateman yes, see abov
On Wed, 1 Dec 2021 01:37:55 GMT, John Neffenger wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated the pu
On Tue, 30 Nov 2021 20:00:19 GMT, John Neffenger wrote:
> > Whichever we use, we have to use e.setTimeLocal(), so can't see what the
> > difference is?
>
> Okay, here's a brief command-line example before posting the code example. In
> my experience, most people trying to set up a common, proj
On Tue, 30 Nov 2021 19:31:37 GMT, John Neffenger wrote:
> > Both basically truncate the timezone.
>
> There's a difference. The first option saves a DOS date and time that depends
> on the time zone of the build machine due to the ISO 8601 string returned by
> default from the `git` and `date`
On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
&g
On Tue, 30 Nov 2021 16:26:28 GMT, John Neffenger wrote:
> > So what you suggest sounds reasonable, although it would be a "behaviour
> > change" in that whereas now if the date is between 1980->2106 only a
> > xdostime is stored, we would now always be storing the additional "mtime"
> > field
On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
&g
On Tue, 30 Nov 2021 08:53:03 GMT, John Neffenger wrote:
>> @andrew-m-leonard Thank you, Andrew, for your bold solution to Mark's
>> request -- one that even solves the problem with the current `ZipEntry` API!
>>
>> Would you be willing to consider a minor change to your implementation?
>>
>> A
Ah, I suspect the getTime() for xdostime performance issue relates to this:
https://bugs.openjdk.java.net/browse/JDK-4981560
which is not relevant any more since dosToJavaTime() is now implemented
differently
On Tue, Nov 30, 2021 at 2:44 PM Andrew Leonard wrote:
> Thanks Alan,
>
on of restricting the --date option to 1980->2099
regards
Andrew
On Tue, Nov 30, 2021 at 1:13 PM Alan Bateman
wrote:
> On 29/11/2021 19:25, Andrew Leonard wrote:
>
> *Problem:*
> PR https://github.com/openjdk/jdk/pull/6481
> addresses the main problems with deterministic time
On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
&g
On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
&g
On Tue, 30 Nov 2021 08:53:03 GMT, John Neffenger wrote:
>> @andrew-m-leonard Thank you, Andrew, for your bold solution to Mark's
>> request -- one that even solves the problem with the current `ZipEntry` API!
>>
>> Would you be willing to consider a minor change to your implementation?
>>
>> A
Given an API-change is not realistic at this point in jdk-18, would it
make more sense to implement solution (1), and consider (2) for jdk-19+.. ?
On Mon, 29 Nov 2021 17:07:52 GMT, Alan Bateman wrote:
>> @andrew-m-leonard I see you've add several APIs to ZipEntry in this PR. I
>> think this part will require discussion as it's not immediately clear that
>> we should over burden the ZipEntry API as proposed.
>
>> @AlanBateman yes, see abov
*Problem:*
PR https://github.com/openjdk/jdk/pull/6481
addresses the main problems with deterministic timestamping of Zip entries,
with
the introduction of a new --date option for jar & jmod.
However, the ZipEntry timestamp is constructed from a combination of an
MS-DOS timestamp
and a FileTime(se
On Mon, 29 Nov 2021 16:18:44 GMT, Alan Bateman wrote:
>> Andrew Leonard has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
On Thu, 25 Nov 2021 19:21:36 GMT, John Neffenger wrote:
>>> A user who’s not familiar with the lingo of [reproducible
>>> builds](https://reproducible-builds.org/docs/source-date-epoch/) will be
>>> mystified by an option named `--source-date`. A user who just wants to set
>>> the timestamp of
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
On Fri, 26 Nov 2021 16:24:31 GMT, Lance Andersen wrote:
>> @LanceAndersen java File times can't be before the epoch, but having a test
>> before dostime 1980 would be useful
>
>>
>
> The change to sun/tools/jar/GNUStyleOptions.java does not prevent a negative
> value which can be set via ZipE
On Fri, 26 Nov 2021 16:25:43 GMT, Lance Andersen wrote:
>> For files with large number of entries, alot of LocalDateTime Objects are
>> being created here. Would there be an efficiency gain by converting
>> sourceDate variable to be of type LocalDateTime and simply pass it to the
>> s.setTimeL
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated the pu
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
On Wed, 24 Nov 2021 16:43:10 GMT, Lance Andersen wrote:
>> Andrew Leonard has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains five commits:
>>
>> - 8276766: Enable jar and jmod to produce determini
On Wed, 24 Nov 2021 19:40:38 GMT, Mark Reinhold wrote:
> A user who’s not familiar with the lingo of [reproducible
> builds](https://reproducible-builds.org/docs/source-date-epoch/) will be
> mystified by an option named `--source-date`. A user who just wants to set
> the timestamp of new entr
On Wed, 24 Nov 2021 16:48:42 GMT, Lance Andersen wrote:
>> Andrew Leonard has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains five commits:
>>
>> - 8276766: Enable jar and jmod to produce determini
On Thu, 25 Nov 2021 09:37:59 GMT, Andrew Leonard wrote:
>> test/jdk/tools/jar/JarEntryTime.java line 129:
>>
>>> 127: // Make a jar file from that directory structure with
>>> 128: // --source-date set to epoch seconds 1647302400 (15/03/2022)
&g
On Wed, 24 Nov 2021 16:43:10 GMT, Lance Andersen wrote:
>> Andrew Leonard has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains five commits:
>>
>> - 8276766: Enable jar and jmod to produce determini
On Tue, 23 Nov 2021 20:29:15 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
&g
> Add a new --source-date (epoch milliseconds) option to jar and
> jmod to allow specification of time to use for created/updated jar/jmod
> entries. This then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
On Mon, 15 Nov 2021 18:47:34 GMT, Andrew Leonard wrote:
> Both jar and jmod utilise java.io file operations whose methods define no
> ordering of the return file lists, and in fact rely on OS query file
> ordering, which can differ by underlying OS architecture.
> This PR adds sor
> Add a new --source-date (epoch milliseconds) option to jar and
> jmod to allow specification of time to use for created/updated jar/jmod
> entries. This then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
> Add a new --source-date (epoch milliseconds) option to jar and
> jmod to allow specification of time to use for created/updated jar/jmod
> entries. This then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated t
On Tue, 23 Nov 2021 14:34:23 GMT, Andrew Leonard wrote:
>>> I've added updates to the jar and jmod man pages, as "Notes" about
>>> ordering, does that sound reasonable?
>>
>> The true source of the man pages are still kept in our closed repositor
On Fri, 19 Nov 2021 21:33:43 GMT, Mandy Chung wrote:
>> @magicus I've added updates to the jar and jmod man pages, as "Notes" about
>> ordering, does that sound reasonable?
>
>> I've added updates to the jar and jmod man pages, as "Notes" about
>> ordering, does that sound reasonable?
>
> The
t;>
>> Signed-off-by: Andrew Leonard
>
> Thank you for this timely pull request, Andrew! I need this pull request and
> also #6395 to [enable reproducible builds in
> JavaFX](https://github.com/openjdk/jfx/pull/446). I drove myself crazy this
> weekend with time zon
's to
> enable a deterministic content ordering.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated the pull request incrementally with one additional
commit since the last revision:
8276764: Enable deterministic file content ordering for Jar and Jmod
On Mon, 22 Nov 2021 14:57:01 GMT, Daniel Fuchs wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8276764: Enable deterministic file content ordering for Jar and Jmod
>>
>
's to
> enable a deterministic content ordering.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated the pull request incrementally with one additional
commit since the last revision:
8276764: Enable deterministic file content ordering for Jar and Jmod
1 - 100 of 211 matches
Mail list logo
