On Mon, 21 Feb 2022 12:42:37 GMT, Jaikiran Pai wrote:
> Can I please get a review of this trivial change to the javadoc of
> `DateTimeFormatter.getDecimalStyle()` method which fixes the typo noted in
> https://bugs.openjdk.java.net/browse/JDK-8282190?
Marked as reviewed by lancea (Reviewer).
Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar
> test runs
>
> Best
> Lance
Lance Andersen has updated the pull request incrementally with one additional
commit since the last revision:
remove extra '}'
-
Changes:
- all: https:
Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar
> test runs
>
> Best
> Lance
Lance Andersen has updated the pull request incrementally with one additional
commit since the last revision:
remove trailing space
-
Changes:
- all: https:
On Fri, 18 Feb 2022 17:20:26 GMT, Alan Bateman wrote:
> > If you feel there is still something lacking for documentation, I can
> > certainly make another pass clarify/add it, but I tried to cover the steps
> > (but I also understand what might be obvious to me might not be as obvious
> > as
Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar
> test runs
>
> Best
> Lance
Lance Andersen has updated the pull request incrementally with one additional
commit since the last revision:
Add additional comments describing how the jars are creat
On Fri, 18 Feb 2022 17:05:53 GMT, Alan Bateman wrote:
> > > The updates changes to ZipFile/JarFile look okay. I don't have time to
> > > study the test too closely right now but it will need to include
> > > instructions on how to re-create the signed JAR that is stored in the
> > > byte
On Fri, 18 Feb 2022 12:09:53 GMT, Alan Bateman wrote:
> The updates changes to ZipFile/JarFile look okay. I don't have time to study
> the test too closely right now but it will need to include instructions on
> how to re-create the signed JAR that is stored in the byte array.
Those
On Thu, 17 Feb 2022 16:02:42 GMT, Volker Simonis wrote:
>> Currently, `InflaterInputStream::read()` first does a native call to the
>> underlying zlib `inflate()` function and only afterwards checks if the
>> inflater requires input (i.e. `Inflater::needsInput()`) or has finished
>> inflating
On Fri, 11 Feb 2022 17:43:47 GMT, Lance Andersen wrote:
>> src/java.base/share/classes/java/util/jar/JarFile.java line 881:
>>
>>> 879: ze = getJarEntry(entryName);
>>> 880: } else {
>>> 881: throw new ZipExc
Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar
> test runs
>
> Best
> Lance
Lance Andersen has updated the pull request incrementally with one additional
commit since the last revision:
Return null when ZipEntry::getName is null
-
Chan
On Thu, 17 Feb 2022 18:02:20 GMT, Ian Graves wrote:
> Adding a missing period per this doc bug.
Marked as reviewed by lancea (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/7521
On Tue, 15 Feb 2022 06:40:57 GMT, Christian Stein wrote:
>> A number of modules declare that the "provide" ToolProvider.
>>
>> These modules now specify the "name" of the argument used by
>> `ToolProvider.findFirst` to access an instance of the tool provider within
>> the description part of
On Mon, 14 Feb 2022 18:20:19 GMT, Christian Stein wrote:
> I think Jon's latest proposal combines all requirements with using better
> wording than my initial text.
>
> Do you agree, @AlanBateman and @LanceAndersen?
Yes, I think that sounds good
-
PR:
On Fri, 11 Feb 2022 13:45:47 GMT, Alan Bateman wrote:
>> Lance Andersen has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Return a null InputStream when the ZipEntry is not found in the Jar
>> - Address f
On Thu, 10 Feb 2022 20:37:50 GMT, Sean Mullan wrote:
>> Agree on returning null to maintain current behavior. I would also lean
>> towards amending the specification to specify what has been long-standing
>> behavior.
>
> If we had to do it over again, I do think throwing IAE is more
Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar
> test runs
>
> Best
> Lance
Lance Andersen has updated the pull request incrementally with two additional
commits since the last revision:
- Return a null InputStream when the ZipEntry is not found in
On Thu, 10 Feb 2022 03:04:43 GMT, Christian Stein wrote:
>> What is "it" in "it provides..." ?
>
> Perhaps like this?
>
>
> /**
> * ...
> * @provides java.util.spi.ToolProvider
> * Module {@code jdk.jartool} provides a tool named {@code "jar"}.
> * Invoke {@link
On Tue, 8 Feb 2022 18:06:04 GMT, Lance Andersen wrote:
>>> ze can't be null here.
>>
>> Actually it can be: Consider the following:
>>
>>
>> try (JarFile jf = new JarFile(SIGNED_VALID_ENTRY_NAME_JAR.toFile(),
>> true)) {
>>
On Wed, 9 Feb 2022 16:37:00 GMT, Christian Stein wrote:
> A number of modules declare that the "provide" ToolProvider.
>
> These modules now specify the "name" of the argument used by
> `ToolProvider.findFirst` to access an instance of the tool provider within
> the description part of a
On Wed, 9 Feb 2022 06:42:51 GMT, Christian Stein wrote:
> This PR removes the redundant and failing test-case.
> It also removes the test class from the problem list.
>
> Adds additional test-cases using long form option names of `jar`.
Looks good. Thank you for addressing this hiccup!
On Tue, 8 Feb 2022 20:09:30 GMT, Daniel D. Daugherty wrote:
> A trivial fix to ProblemList tools/jar/CreateMissingParentDirectories.java.
Marked as reviewed by lancea (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/7390
On Tue, 8 Feb 2022 18:56:02 GMT, Alan Bateman wrote:
>>> I'm almost tempted to have getInputStream(ZipEntry) be re-specified to
>>> throw IAE if the zip entry name is null.
>>
>> I personally think it is best to continue throw the NPE as that provides
>> symmetry with ZipFile::getInputStream,
On Tue, 8 Feb 2022 15:55:50 GMT, Alan Bateman wrote:
> ze can't be null here.
Actually it can be: Consider the following:
try (JarFile jf = new JarFile(SIGNED_VALID_ENTRY_NAME_JAR.toFile(),
true)) {
var ze = new ZipEntry("org/gotham/Batcave.class");
var ex=
On Tue, 8 Feb 2022 18:05:25 GMT, Lance Andersen wrote:
>> ze can't be null here.
>
>> ze can't be null here.
>
> Actually it can be: Consider the following:
>
>
> try (JarFile jf = new JarFile(SIGNED_VALID_ENTRY_NAME_JAR.toFile(),
> true)) {
>
On Tue, 8 Feb 2022 15:31:51 GMT, Sean Mullan wrote:
>> Lance Andersen has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Reduce Exception checking to JarFile::verifiableEntry
>
> src/java.base/share/classes/j
On Tue, 8 Feb 2022 18:06:52 GMT, Lance Andersen wrote:
>> Ah, yes - good catch!
>
> Will do.
> I'm almost tempted to have getInputStream(ZipEntry) be re-specified to throw
> IAE if the zip entry name is null.
I personally think it is best to continue throw the NPE as that
On Tue, 8 Feb 2022 16:15:20 GMT, Sean Mullan wrote:
>> if ZipEntry is extended and getName() overridden then you can't trust the
>> name. So I think you'll have extract the name rather than calling
>> ZipEntry::getName twice. I'm almost tempted to have getInputStream(ZipEntry)
>> be
On Fri, 4 Feb 2022 22:29:45 GMT, Christian Stein wrote:
>> Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing
>> parent directories (here `a/b`) on the default file system before storing
>> the JAR file (here `foo.jar`) in the destination directory.
>
> Christian Stein
On Mon, 7 Feb 2022 20:16:43 GMT, Lance Andersen wrote:
>> If you are pretty sure the only other case are as above, I wonder if a
>> simpler fix would be to change `verifiableEntry()` to check for these null
>> cases and throw a `ZipException` which will get d
Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar
> test runs
>
> Best
> Lance
Lance Andersen has updated the pull request incrementally with one additional
commit since the last revision:
Reduce Exception checking to JarFile::verifiableEnt
On Mon, 7 Feb 2022 18:44:10 GMT, Sean Mullan wrote:
>> Looking at this a bit more, it looks like `JariFile::initializeVerifier` is
>> the only place currently in `JarFile` that could throw a `JarException` and
>> that method could be called from `JarFile::getInputStream`
>>
>> As
On Mon, 7 Feb 2022 15:16:43 GMT, Sean Mullan wrote:
>> JarFile::getInputStream. mentions ZipException but not JarException which is
>> why I chose this. If we change this to JarException, I would need to update
>> the javadoc and create a CSR.
>>
>> Please let me know your preference
>
>
On Fri, 4 Feb 2022 21:47:16 GMT, Christian Stein wrote:
> Should I also extend this "usage.compat" help message block? When and where
> is it displayed? 樂
>
>
On Fri, 4 Feb 2022 21:55:28 GMT, Christian Stein wrote:
>> Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing
>> parent directories (here `a/b`) on the default file system before storing
>> the JAR file (here `foo.jar`) in the destination directory.
>
> Christian Stein
On Wed, 2 Feb 2022 20:21:54 GMT, Christian Stein wrote:
> Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing
> parent directories (here `a/b`) on the default file system before storing the
> JAR file (here `foo.jar`) in the destination directory.
> > I think this
On Fri, 4 Feb 2022 16:06:34 GMT, Lance Andersen wrote:
> > Could these unexpected exceptions also occur when using the
> > `JarInputStream` API?
>
> It's a different code path as Zip/JarFile leverage the CEN where
> Zip/JarInputStream leverage the LO
On Fri, 4 Feb 2022 15:55:33 GMT, Sean Mullan wrote:
> Could these unexpected exceptions also occur when using the `JarInputStream`
> API?
It's a different code path as Zip/JarFile leverage the CEN where
Zip/JarInputStream leverage the LOC. I can give it a go and if there is an
issue will
On Fri, 4 Feb 2022 15:06:59 GMT, Alan Bateman wrote:
>> Hi all,
>>
>> Please review the attached patch to address
>>
>> - That JarFile::getInputStream did not check for a null ZipEntry passed as a
>> parameter
>> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an
>>
Hi all,
Please review the attached patch to address
- That JarFile::getInputStream did not check for a null ZipEntry passed as a
parameter
- Have Zip/JarFile::getInputStream throw a ZipException in the event that an
unexpected exception occurs
Mach5 tiers1-3 runs are clean as are the TCK
On Thu, 3 Feb 2022 19:42:25 GMT, Christian Stein wrote:
> Thanks for the review, Lance.
>
> I didn't change order of creation, validation, and movement of the temporary
> JAR file in order to keep existing behaviour consistent.
I do think we are better served with the validation check earlier
On Wed, 2 Feb 2022 20:21:54 GMT, Christian Stein wrote:
> Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing
> parent directories (here `a/b`) on the default file system before storing the
> JAR file (here `foo.jar`) in the destination directory.
Thank you for taking
On Tue, 1 Feb 2022 21:11:39 GMT, Joe Darcy wrote:
> The references to JOSS, the Java Object Serialization Specification, are not
> done consistently in the API javadoc. This should be improved.
>
> I'll update copyright years before pushing.
Marked as reviewed by lancea (Reviewer).
On Fri, 28 Jan 2022 02:15:59 GMT, Joe Darcy wrote:
>> The changes in this PR on top of the out-for-review changes in
>> https://git.openjdk.java.net/jdk/pull/7222 allow compile-time doclint
>> checking to be enabled in all JDK modules.
>>
>> Typically, a @SuppressWarnings("doclint:refernce")
On Tue, 25 Jan 2022 10:47:41 GMT, Masanori Yano wrote:
> I have removed the duplicate property keys.
> Could you please review the fix?
Marked as reviewed by lancea (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/7212
On Mon, 24 Jan 2022 17:21:57 GMT, Ian Graves wrote:
> Replacing a buggy NullPointerException in `Pattern.compile()` with the proper
> PatternSyntaxException
Marked as reviewed by lancea (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/7201
On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote:
> Use presumed syntax that will be introduced by JDK-8280488.
Marked as reviewed by lancea (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/7189
On Mon, 17 Jan 2022 09:56:13 GMT, Masanori Yano wrote:
>> Could you please review the JDK-8272746 bug fixes?
>> Since the array index is of type int, the overflow occurs when the value of
>> end.cenlen is too large because of too many entries.
>> It is necessary to read a part of the CEN from
On Fri, 14 Jan 2022 11:05:06 GMT, Masanori Yano wrote:
>> Could you please review the JDK-8272746 bug fixes?
>> Since the array index is of type int, the overflow occurs when the value of
>> end.cenlen is too large because of too many entries.
>> It is necessary to read a part of the CEN from
On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote:
>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead,
>> please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in
On Thu, 13 Jan 2022 13:48:02 GMT, Pavel Rappo wrote:
> > Yes an "or" is probably worthwhile to add.
>
> I would prefer to leave it for the follow-up cleanup if only because adding
> "or" here would make it inconsistent with other `@throws SQLException`
> descriptions in that file and perhaps
On Thu, 13 Jan 2022 12:37:46 GMT, Pavel Rappo wrote:
> > The above is a bit confusing as it reads(same in ImageInputStream.java). I
> > think that that can be looked at later.
>
> Just to clarify: you are okay with removing the ` ` entity, right? As for
> ImageInputStream, some doc comments
On Thu, 13 Jan 2022 11:29:35 GMT, Pavel Rappo wrote:
>> src/java.sql/share/classes/java/sql/Statement.java line 784:
>>
>>> 782: * statement returns a {@code ResultSet} object, the second
>>> argument
>>> 783: * supplied to this method is not an
>>> 784: * {@code int} array
On Thu, 13 Jan 2022 11:28:34 GMT, Kevin Walls wrote:
>> I thought about it too, but then noticed how the position of `[]` mimics
>> that of the respective method signatures in code.
>
> OK, so lines 264, 295, 329, 364, 431 are arguably wrong as well? Separating
> the [] completely looks
On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote:
> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead,
> please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in
On Fri, 24 Dec 2021 11:07:04 GMT, Masanori Yano wrote:
>> Could you please review the JDK-8272746 bug fixes?
>> Since the array index is of type int, the overflow occurs when the value of
>> end.cenlen is too large because of too many entries.
>> It is necessary to read a part of the CEN from
On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato wrote:
> Please review the changes for upgrading the Unicode support in the JDK, from
> version 13 to version 14. Corresponding CSR has also been drafted.
Marked as reviewed by lancea (Reviewer).
-
PR:
On Thu, 6 Jan 2022 09:34:24 GMT, Alan Bateman wrote:
> > @AlanBateman Could you please review the above comments.
>
> Thanks for changing the message, the update to ZipFile looks good to me
> although I'm still surprised that the native tools support a CEN larger than
> 2Gb.
>
> I'm slow to
On Sat, 11 Sep 2021 12:11:50 GMT, Andrey Turbanov wrote:
> Usages of primitive types should be preferred and makes code easier to read.
> Similar cleanups:
> 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168)
> java.desktop
> 2.
On Mon, 6 Dec 2021 16:59:41 GMT, Roger Riggs wrote:
>> The effects of invalid values of `jdk.serialFilter` and
>> `jdk.serialFilterFactory` properties are
>> incompletely specified. The behavior for invalid values of the properties is
>> different and
>> use an unconventional exception type,
On Mon, 6 Dec 2021 16:01:43 GMT, Roger Riggs wrote:
>> The specification of ObjectInputStream constructors that invoke
>> `ObjectInputFilter.Config.getSerialFilterFactory()` do not mention
>> exceptions that may be thrown by the apply() method.
>>
>> In both constructors, add the following to
On Thu, 16 Dec 2021 06:33:24 GMT, Stuart Marks wrote:
> A small modification to the Launcher's help text.
Marked as reviewed by lancea (Reviewer).
-
PR: https://git.openjdk.java.net/jdk18/pull/34
On Tue, 14 Dec 2021 18:25:45 GMT, Naoto Sato wrote:
> This is a doc fix to `StringTokenizer`, where the original spec does not
> account for the delimiter's length in the case of a supplementary character.
> Corresponding CSR has been drafted:
>
On Wed, 1 Dec 2021 14:47:54 GMT, Roger Riggs wrote:
> Compilation warnings of the test library introduce noise in test output and
> should be addressed or suppressed.
> Changes include:
> - SuppressWarnings("deprecation") and SuppressWarnings("removal")
> - Adding type parameters to Raw
On Fri, 10 Dec 2021 14:09:00 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-off-by:
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 08:16:46 GMT, Christian Stein wrote:
>> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and
>> class `PathFileObject` in module `jdk.compiler` were always composed by base
>> path names. Even for versioned entries of a multi-release JAR file.
>>
>>
On Fri, 10 Dec 2021 10:54:06 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-off-by:
On Thu, 9 Dec 2021 18:07:58 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-off-by:
On Tue, 7 Dec 2021 09:32:47 GMT, Andrew Leonard 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
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.
>>
>> Signed-off-by:
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.
>>
>> Signed-off-by:
On Sat, 20 Nov 2021 04:09:51 GMT, Tim Prinzing wrote:
> JDK-8276681: Malformed Javadoc inline tags in JDK source
> jdk/internal/net/http/ResponseSubscribers.java
Marked as reviewed by lancea (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6486
On Wed, 1 Dec 2021 18:33:44 GMT, Lance Andersen wrote:
> Hi all,
>
> Please review this patch to address a failure at DST->STD offset transition.
> The fix mirrors what was done for JDK-8190748
>
>
> Best,
> Lance
This pull request has now been integrated.
Hi all,
Please review this patch to address a failure at DST->STD offset transition.
The fix mirrors what was done for JDK-8190748
Best,
Lance
-
Commit messages:
- Patch for JDK-8277422
Changes: https://git.openjdk.java.net/jdk/pull/6648/files
Webrev:
On Mon, 29 Nov 2021 21:59:31 GMT, Naoto Sato wrote:
>> Fixing tests that fail at DST->STD offset transition. Simply skipping the
>> tests on that occasion.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Changed to not
On Tue, 30 Nov 2021 14:28:05 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which fixes a typo in the javadoc
> of `java.util.zip.ZipEntry.setTime()` method?
Marked as reviewed by lancea (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6615
On Mon, 29 Nov 2021 18:48:45 GMT, Naoto Sato wrote:
> Fixing tests that fail at DST->STD offset transition. Simply skipping the
> tests on that occasion.
test/jdk/java/text/Format/DateFormat/DateFormatTest.java line 349:
> 347: var defZone = ZoneId.systemDefault();
> 348: if
On Mon, 29 Nov 2021 17:07:52 GMT, Alan Bateman 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
On Thu, 25 Nov 2021 17:57:20 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)
>>> 129: long sourceDate =
On Fri, 26 Nov 2021 12:23:41 GMT, Sean Coffey wrote:
>> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 2290:
>>
>>> 2288: private void setSourceDate(ZipEntry e, long origTime) {
>>> 2289: if (sourceDate != -1) {
>>> 2290:
On Wed, 24 Nov 2021 20:08:50 GMT, Lance Andersen wrote:
> HI all,
>
> Attached is a patch for 4 failing MR tests due the issue that was resolved
> via JDK-8272728
>
> Best
> Lance
This pull request has now been integrated.
Changeset: b5841ba3
Author:Lance Anders
HI all,
Attached is a patch for 4 failing MR tests due the issue that was resolved via
JDK-8272728
Best
Lance
-
Commit messages:
- Fix for JDK-8272728
Changes: https://git.openjdk.java.net/jdk/pull/6546/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6546=00
Issue:
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.
>>
>> Signed-off-by:
On Wed, 24 Nov 2021 15:04:35 GMT, Jaikiran Pai wrote:
>> The commit here is a potential fix for the issue noted in
>> https://bugs.openjdk.java.net/browse/JDK-8258117.
>>
>> The change here repurposes an existing internal interface `ModuleInfoEntry`
>> to keep track of the last modified
On Mon, 22 Nov 2021 14:37:47 GMT, Jaikiran Pai wrote:
>> The commit here is a potential fix for the issue noted in
>> https://bugs.openjdk.java.net/browse/JDK-8258117.
>>
>> The change here repurposes an existing internal interface `ModuleInfoEntry`
>> to keep track of the last modified
On Fri, 19 Nov 2021 22:04:47 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 sort
On Fri, 19 Nov 2021 20:15:54 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 sort
On Fri, 19 Nov 2021 18:55:40 GMT, Mandy Chung wrote:
>> The benchmark should use JMH. @cl4es, what are your thoughts here?
>
>> My thought is to remove it from this PR, since we've already determined the
>> change has little impact.
> We can raise a new issue if we feel it's needed.
>
> This
On Fri, 19 Nov 2021 10:10:33 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 sort
On Mon, 8 Nov 2021 18:59:06 GMT, Сергей Цыпанов wrote:
>> This is a follow-up for https://github.com/openjdk/jdk/pull/4507, looks like
>> there are some cases that were not covered.
>>
>> Also this is related to https://github.com/openjdk/jdk/pull/3615
>
> Сергей Цыпанов has updated the pull
On Fri, 19 Nov 2021 10:10:33 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 sort
On Fri, 19 Nov 2021 18:30:37 GMT, Andrew Leonard wrote:
>> @LanceAndersen what's your opinion? I'm not totally sure of it's usefulness?
>
> My thought is to remove it from this PR, since we've already determined the
> change has little impact.
> We can raise a new issue if we feel it's needed.
On Fri, 19 Nov 2021 18:30:17 GMT, Lance Andersen wrote:
> The changes look OK.
>
> Have you run the JCK tests in addition to the Mach5 tests for the areas being
> changed to make sure we did not trip over a conformance test?
Sorry wrong PR window please ignore this comment
-
On Fri, 19 Nov 2021 10:10:33 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 sort
On Fri, 5 Nov 2021 13:52:49 GMT, Jaikiran Pai wrote:
>> The commit here is a potential fix for the issue noted in
>> https://bugs.openjdk.java.net/browse/JDK-8258117.
>>
>> The change here repurposes an existing internal interface `ModuleInfoEntry`
>> to keep track of the last modified
On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote:
> Here are the code changes for the "Deprecate finalizers in the standard Java
> API" portion of JEP 421 ("Deprecate Finalization for Removal") for code
> review.
>
> This change makes the indicated deprecations, and updates the API
On Thu, 18 Nov 2021 23:43:20 GMT, Joe Wang wrote:
>> Add setProperty/getProperty methods to the XPath API so that properties can
>> be supported in the future.
>
> Joe Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> update as
On Thu, 18 Nov 2021 15:33:26 GMT, Roger Riggs wrote:
>> The ObjectInputStream.GetField.get(String name, Object val) method is
>> returning null instead of throwing an exception when the class of the object
>> is not found. The caller is not able to correctly handle the case where the
>> class
On Wed, 17 Nov 2021 21:24:40 GMT, Andrew Leonard wrote:
>> I agree, we should change this to include braces with the if statement.
>
> I agree, I always use {}, I was being consistent with the rest of the
> expand() method, but I will add {} as I prefer that too, better to set a good
>
On Wed, 17 Nov 2021 21:04:20 GMT, Ravi Reddy wrote:
>> Hi all,
>>
>> Please review this fix for Infinite loop in ZipOutputStream.close().
>> The main issue here is when ever there is an exception during close
>> operations on GZip we are not setting the deflator to a finished state which
>>
101 - 200 of 1866 matches
Mail list logo
