On Sat, 28 May 2022 12:00:00 GMT, Andrey Turbanov wrote:
> Hashtable doesn't allow `null` values. So, instead of pair
> `containsKey`/`remove` calls, we can directly call `remove` and then compare
> result with `null`.
>
On Tue, 24 May 2022 09:52:29 GMT, Alexey Ivanov wrote:
>> Replaces usages of articles that follow each other in all combinations:
>> a/the, an?/an?, the/the…
>>
>> It's the last issue in the series, and it still touches different areas of
>> the code.
>
> Alexey Ivanov has updated the pull
On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote:
> Replaces usages of articles that follow each other in all combinations:
> a/the, an?/an?, the/the…
>
> It's the last issue in the series, and it still touches different areas of
> the code.
Marked as reviewed by lancea (Reviewer).
On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote:
> Replaces usages of articles that follow each other in all combinations:
> a/the, an?/an?, the/the…
>
> Also, I fixed a couple of spelling mistakes.
Marked as reviewed by lancea (Reviewer).
-
PR:
On Thu, 12 May 2022 16:47:43 GMT, Roger Riggs wrote:
> Updates to modules java.rmi and java.smartcardio to remove warnings about
> lossy-conversions introduced by PR#8599.
>
> Explicit casts are inserted where implicit casts occur.
>
> 8286393: Address possibly lossy conversions in java.rmi
>
On Tue, 19 Apr 2022 16:50:12 GMT, Magnus Ihse Bursie wrote:
>> I ran `codespell` on the `src/java.base` directory, and accepted those
>> changes where it indeed discovered real typos.
>>
>> (Due to false positives this can unfortunately not be run automatically)
>>
>> The majority of fixes
On Wed, 13 Apr 2022 16:29:11 GMT, XenoAmess wrote:
>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> revert changes in:
> src/java.desktop
> src/java.management
>
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
What problem are you having editing the PR header? You should be able to do
so as the author of the PR
-
PR:
On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy wrote:
> Please review this small API enhancement to add the usual constructors taking
> a cause to SocketException and then update uses of initiCause on creating
> SocketException to instead pass the cause via the constructor.
>
> Please also review
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
The changes look OK. The copyright year probably should be updated as part of
this PR
-
Marked as reviewed by
On Fri, 4 Feb 2022 12:42:39 GMT, Lance Andersen 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 ZipE
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:
Modified and clarified test comments
-
Changes:
On Sat, 19 Feb 2022 10:59:56 GMT, Alan Bateman wrote:
> > Ok, thank you for the feedback. I just pushed a change with additional
> > comments on the jar creation which hopefully will address your input above.
>
> It's a bit better but I think it needs a clear step-by-step instructions in a
>
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 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 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 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 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 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: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 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 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 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 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 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 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 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 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 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 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 Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov
wrote:
> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check
> if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to
On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov
wrote:
> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't
> touch primitive types casts.
Marked as reviewed by lancea (Reviewer).
On Wed, 22 Sep 2021 15:35:54 GMT, Pavel Rappo wrote:
>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add missing "the"
>
> (Spotted by Brian Burkhalter.)
Marked as
On Wed, 22 Sep 2021 13:01:34 GMT, Pavel Rappo wrote:
>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - Fix "non-white space"
>
>JDK predominantly uses
On Tue, 21 Sep 2021 16:48:53 GMT, Brian Burkhalter wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Tweak wording for Throwable constructor parameters
>
> src/java.base/share/classes/java/lang/Throwable.java line
On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo wrote:
>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Tweak wording for Throwable constructor parameters
Overall looks like a
On Tue, 7 Sep 2021 07:03:20 GMT, Alan Bateman wrote:
>> There is a bug for URLClassPath.findResources with JarIndex.
>> With some discussions about the bug, the current priority is to remove the
>> JAR index support in URLClassPath,
>> and don’t need to do anything to the jar tool in the short
On Tue, 31 Aug 2021 02:08:48 GMT, Weijun Wang wrote:
>> This change modifies the default value of the `java.security.manager` system
>> property from "allow" to "disallow". This means unless it's explicitly set
>> to "allow", any call to `System.setSecurityManager()` would throw an UOE.
>>
>>
On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote:
> This change modifies the default value of the `java.security.manager` system
> property from "allow" to "disallow". This means unless it's explicitly set to
> "allow", any call to `System.setSecurityManager()` would throw an UOE.
>
> The
On Wed, 30 Jun 2021 15:45:25 GMT, Weijun Wang wrote:
>> Add a cache to record which sources have called `System::setSecurityManager`
>> and only print out warning lines once for each.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last
On Mon, 28 Jun 2021 18:03:56 GMT, Weijun Wang wrote:
> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>
> Sometimes I introduce new methods. Please feel free to suggest method names
> you like to use.
>
> Note: this is copied from
On Fri, 25 Jun 2021 23:40:27 GMT, Weijun Wang wrote:
>> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>>
>> Sometimes I introduce new methods. Please feel free to suggest method names
>> you like to use.
>
> Weijun Wang has updated the pull request incrementally with
On Fri, 25 Jun 2021 20:04:37 GMT, Weijun Wang wrote:
> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>
> Sometimes I introduce new methods. Please feel free to suggest method names
> you like to use.
Changes look good Max
-
Marked as reviewed by lancea
On Mon, 14 Jun 2021 22:34:03 GMT, Weijun Wang wrote:
>> More loudly and precise warning messages when a security manager is either
>> enabled at startup or installed at runtime.
>>
>> This is new PR for the `openjdk/jdk17` repo copied from
>> https://github.com/openjdk/jdk/pull/4400. A new
On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon
wrote:
> Hi,
>
> Could someone please review my code for updating the code in the `java.util`
> package to make use of the `instanceof` pattern variable?
>
> Kind regards,
> Patrick
Changes look good.
-
Marked as reviewed by
On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon
wrote:
> Hi,
>
> Could someone please review my code for updating the code in the `java.io`,
> `java.math`, and `java.text` packages to make use of the `instanceof` pattern
> variable?
>
> Kind regards,
> Patrick
Looks good
-
On Fri, 5 Mar 2021 19:36:13 GMT, Jonathan Gibbons wrote:
> Please review some simple cleanup for empty `` tags.
>
> Two of the tags are completely redundant, and simply deleted.
>
> The other three, in _package.html_ files are generally undesirable. Although
> the presumed intent of the `id`
On Tue, 2 Mar 2021 19:35:47 GMT, Jonathan Gibbons wrote:
> Please review some minor doc fixes, for issues found by _doccheck_.There
> are two kinds of errors that are addressed.
>
> 1. Incorrect use of ``. In HTML, `` marks the *beginning* of a
> paragraph. It is not a terminator, to mark
On Thu, 19 Nov 2020 17:08:21 GMT, Alan Bateman wrote:
>> Small change to retrieve the raw bytes of manifest during verifying signed
>> JAR.
>
> Marked as reviewed by alanb (Reviewer).
I can sponsor once you integrate
-
PR: https://git.openjdk.java.net/jdk/pull/1299
On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao wrote:
> Small change to retrieve the raw bytes of manifest during verifying signed
> JAR.
Marked as reviewed by lancea (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/1299
On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao wrote:
> Small change to retrieve the raw bytes of manifest during verifying signed
> JAR.
The changes looks good. I am assuming that we do not need an additional test
for this and if so, please add a noreg label such as noreg-trivial to the bug
On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote:
> The change is (just) to remove legacy usages of a JDK-private custom tag.
looks fine
-
Marked as reviewed by lancea (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/814
On Wed, 14 Oct 2020 14:52:29 GMT, Lance Andersen wrote:
>> Volker Simonis has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental
>> views will show differences compared to the previous content of the PR.
>
> The chang
On Mon, 12 Oct 2020 11:46:31 GMT, Volker Simonis wrote:
>> I don't believe we discuss/reference the data descriptor for a Zip entry
>> (outside of the PKWare Zip specification) so I
>> am not sure we should reference it in the javadoc.
>> Placing the sentence after "The default compression
On Wed, 14 Oct 2020 10:54:30 GMT, Volker Simonis wrote:
>> ### Summary
>>
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code
>> which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>>
>> In general it is not safe to directly write
On Tue, 13 Oct 2020 19:07:33 GMT, Volker Simonis wrote:
>> ### Summary
>>
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code
>> which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>>
>> In general it is not safe to directly write
On Tue, 13 Oct 2020 19:07:33 GMT, Volker Simonis wrote:
>> ### Summary
>>
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code
>> which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>>
>> In general it is not safe to directly write
On Tue, 13 Oct 2020 19:07:33 GMT, Volker Simonis wrote:
>> ### Summary
>>
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code
>> which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>>
>> In general it is not safe to directly write
On Tue, 13 Oct 2020 18:46:59 GMT, Alan Bateman wrote:
>> Volker Simonis has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now
>> contains one commit:
>> 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's
>> compressed
On Tue, 13 Oct 2020 11:40:36 GMT, Volker Simonis wrote:
>> ### Summary
>>
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code
>> which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>>
>> In general it is not safe to directly write
On Wed, 7 Oct 2020 17:04:02 GMT, Lance Andersen wrote:
>> I totally agree. What about using just the last sentence (as you've
>> proposed) in the spec section and add the other to
>> as @implNote? O you think the last sentence will be enough?
>
> I think we can just g
On Mon, 12 Oct 2020 15:49:29 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/util/jar/JarOutputStream.java line 81:
>>
>>> 79: * any previous entry. The default compression method will be
>>> 80: * used if no compression method was specified for the entry.
>>> 81: *
On Mon, 12 Oct 2020 11:44:28 GMT, Volker Simonis wrote:
>> ### Summary
>>
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code
>> which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>>
>> In general it is not safe to directly write
On Mon, 12 Oct 2020 11:44:28 GMT, Volker Simonis wrote:
>> ### Summary
>>
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code
>> which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>>
>> In general it is not safe to directly write
On Mon, 12 Oct 2020 12:48:36 GMT, Alan Bateman wrote:
>> Volker Simonis has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental
>> views will show differences compared to the previous content of the PR. The
>> pull request contains one new
On Sun, 11 Oct 2020 17:22:58 GMT, Alan Bateman wrote:
>> Volker Simonis has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental
>> views will show differences compared to the previous content of the PR.
>
>
On Fri, 9 Oct 2020 10:28:34 GMT, Volker Simonis wrote:
>> ### Summary
>>
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code
>> which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>>
>> In general it is not safe to directly write
On Thu, 1 Oct 2020 14:42:21 GMT, Jaikiran Pai wrote:
>> Can I please get a review and a sponsor for a fix for
>> https://bugs.openjdk.java.net/browse/JDK-8242882?
>>
>> As noted in that JBS issue, if the size of the Manifest entry in the jar
>> happens to be very large (such that it exceeds
On Wed, 7 Oct 2020 16:43:53 GMT, Volker Simonis wrote:
>> Alan makes a good point. Perhaps we keep things simple and focus solely on
>> tweaking the description of the change in
>> behavior which is described in your last paragraph
>
> I totally agree. What about using just the last sentence
On Tue, 6 Oct 2020 10:02:09 GMT, Volker Simonis wrote:
> ### Summary
>
> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code
> which can lead to the `ZipException "invalid
> entry compressed size"`.
> ### Motivation
>
> In general it is not safe to directly write a
On Wed, 7 Oct 2020 15:10:06 GMT, Alan Bateman wrote:
>> ### Summary
>>
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code
>> which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>>
>> In general it is not safe to directly write a
On Tue, 6 Oct 2020 10:02:09 GMT, Volker Simonis wrote:
> ### Summary
>
> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code
> which can lead to the `ZipException "invalid
> entry compressed size"`.
> ### Motivation
>
> In general it is not safe to directly write a
On Tue, 6 Oct 2020 10:02:09 GMT, Volker Simonis wrote:
> ### Summary
>
> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code
> which can lead to the `ZipException "invalid
> entry compressed size"`.
> ### Motivation
>
> In general it is not safe to directly write a
On Wed, 30 Sep 2020 17:26:18 GMT, Brent Christian wrote:
>> test/jdk/java/util/jar/JarFile/LargeManifestOOMTest.java line 60:
>>
>>> 58: final OutOfMemoryError oome =
>>> Assert.expectThrows(OutOfMemoryError.class, () -> jar.getManifest());
>>> 59: // additionally verify that
On Tue, 15 Sep 2020 16:59:59 GMT, Lance Andersen wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove "final"
>
> I am fine with this as well. I will pull over the chan
On Mon, 7 Sep 2020 18:57:11 GMT, Sean Coffey wrote:
>> Continuation of RFR thread from
>> http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html
>>
>> CSR has been approved.
>
> Sean Coffey has updated the pull request incrementally with one additional
> commit since the
On Mon, 7 Sep 2020 13:48:57 GMT, Sean Coffey wrote:
> Continuation of RFR thread from
> http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html
>
> CSR has been approved.
I think this looks good over all Sean. In your SymLinkTest, I probably would
have the test delete
rds,
>>>>> Sean.
>>>>>
>>>>> On 26/08/2020 23:15, Weijun Wang wrote:
>>>>>> Are you going to update the warning text or create a new one?
>>>>>>
>>>>>> Thanks,
>>>>>> Max
>>>&g
me other means, or even
>> that the warning is because they are using unsigned values.
>>
>> It might be better to tweak the second part to make it a bit clearer, up to
>> you but something like "These attributes are ignored when signing and are
>> not protected by the signature".
>>
>> -Alan
Best
Lance
--
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
v/>
> regards,
> Sean.
>
> On 12/06/2020 17:05, Lance Andersen wrote:
>> Hi Sean,
>>
>> I think your changes look fine so all good FMPOV.
>>
>> Best
>> Lance
>>
>>> On Jun 12, 2020, at 6:21 AM, Seán Coffey >> <mailto:sean.
1 - 100 of 169 matches
Mail list logo
