On Wed, 14 Sep 2022 01:42:20 GMT, Lance Andersen wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this
> Please review this PR which updates the JarInputStream class description to
> clarify when the Manifest is accessible via JarInputStream::getManifest and
> JarInputStream::get[Jar]Entry.
>
> It is worth noting that with this update, we are finally documenting
> behavior that dates back to
On Wed, 14 Sep 2022 00:39:37 GMT, Weijun Wang wrote:
> On lines 36 and 37, there are two "Manifest". The first uses `linkplain` so
> it's using normal font style, the 2nd uses `code` so it's fixed-width. I
> would like them to be the same. In fact, I would not use `linkplain` at all.
> I only
On Tue, 13 Sep 2022 17:41:04 GMT, Aleksey Shipilev wrote:
>> I have been looking into `make clean-images images` performance, and
>> realized jmod keeps compressing files with default compression level. Tuning
>> that toward lighter compression levels improves build performance
>>
On Tue, 13 Sep 2022 20:58:04 GMT, Lance Andersen wrote:
>> src/java.base/share/classes/java/util/jar/JarInputStream.java line 36:
>>
>>> 34: * The {@code JarInputStream} class, which extends {@linkplain
>>> ZipInputStream},
>>> 35: * is used to read the contents of a JAR file from an input
On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote:
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
> removal, and remove the remaining special handling of ThreadDeath from the
> JDK.
>
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2
> Hi,
>
> Please review this update to the ZipInputStream class description to clarify
> that ZipInputStream walks sequentially through each Zip Entry contained
> within the Zip File. As a result, the CEN header for the Zip file entries
> are not read resulting in ZipInputStream not having
On Tue, 13 Sep 2022 20:39:31 GMT, Weijun Wang wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this update,
On Fri, 26 Aug 2022 15:48:55 GMT, Lance Andersen wrote:
> Please review this PR which updates the JarInputStream class description to
> clarify when the Manifest is accessible via JarInputStream::getManifest and
> JarInputStream::get[Jar]Entry.
>
> It is worth noting that with this update,
On Fri, 26 Aug 2022 15:48:55 GMT, Lance Andersen wrote:
> Please review this PR which updates the JarInputStream class description to
> clarify when the Manifest is accessible via JarInputStream::getManifest and
> JarInputStream::get[Jar]Entry.
>
> It is worth noting that with this update,
> Hi,
>
> Please review this update to the ZipInputStream class description to clarify
> that ZipInputStream walks sequentially through each Zip Entry contained
> within the Zip File. As a result, the CEN header for the Zip file entries
> are not read resulting in ZipInputStream not having
On Tue, 13 Sep 2022 19:30:01 GMT, Alan Bateman wrote:
>> Lance Andersen has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address sample indentation and typo
>
> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 65:
>
>>
On Thu, 25 Aug 2022 09:25:55 GMT, Alan Bateman wrote:
> > What is wrong with the change?
>
> You'll need parentheses to make that work, changing it to use '|' would work
> too.
Does that mean there is no explicit test for DataInputStream endianess (if only
accidential tests checking for
On Tue, 13 Sep 2022 18:12:44 GMT, Lance Andersen wrote:
>> Hi,
>>
>> Please review this update to the ZipInputStream class description to clarify
>> that ZipInputStream walks sequentially through each Zip Entry contained
>> within the Zip File. As a result, the CEN header for the Zip file
On Tue, 13 Sep 2022 18:57:34 GMT, Sean Mullan wrote:
> What about also removing and undocumenting `RuntimePermission("stopThread")`
> as part of this change?
Ah yes, the table RuntimePermission can be updated as part of this (and the
corresponding constant in
On Tue, 13 Sep 2022 19:12:26 GMT, Alan Bateman wrote:
> > There is a bunch of VM code for this too. Should we clean that up
> > separately?
>
>
>
> Yes chatted with @dholmes-ora about this recently and he suggested separating
> out so there is a follow-on JBS issue created for that. Aside
On Tue, 13 Sep 2022 19:06:14 GMT, Erik Österlund wrote:
> There is a bunch of VM code for this too. Should we clean that up separately?
Yes chatted with @dholmes-ora about this recently and he suggested separating
out so there is a follow-on JBS issue created for that. Aside from
On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote:
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
> removal, and remove the remaining special handling of ThreadDeath from the
> JDK.
>
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2
On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote:
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
> removal, and remove the remaining special handling of ThreadDeath from the
> JDK.
>
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2
On Tue, 13 Sep 2022 18:12:44 GMT, Lance Andersen wrote:
>> Hi,
>>
>> Please review this update to the ZipInputStream class description to clarify
>> that ZipInputStream walks sequentially through each Zip Entry contained
>> within the Zip File. As a result, the CEN header for the Zip file
On Tue, 13 Sep 2022 17:38:29 GMT, Brian Burkhalter wrote:
>> Lance Andersen has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address sample indentation and typo
>
> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 49:
>
> Hi,
>
> Please review this update to the ZipInputStream class description to clarify
> that ZipInputStream walks sequentially through each Zip Entry contained
> within the Zip File. As a result, the CEN header for the Zip file entries
> are not read resulting in ZipInputStream not having
On Tue, 13 Sep 2022 17:35:45 GMT, Aleksey Shipilev wrote:
>> Here is where we get into a minor pickle. We currently default to
>> `Deflater.DEFAULT_COMPRESSION`, which is `-1`, and which is handled inside
>> `zlib` as `6`. We can say `zip-6` here is the default, but that would be
>> stale if
On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote:
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
> removal, and remove the remaining special handling of ThreadDeath from the
> JDK.
>
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2
On Wed, 31 Aug 2022 16:06:57 GMT, Lance Andersen wrote:
> Hi,
>
> Please review this update to the ZipInputStream class description to clarify
> that ZipInputStream walks sequentially through each Zip Entry contained
> within the Zip File. As a result, the CEN header for the Zip file entries
> I have been looking into `make clean-images images` performance, and realized
> jmod keeps compressing files with default compression level. Tuning that
> toward lighter compression levels improves build performance considerably,
> without a heavy loss in *.jmod sizes.
>
> This PR allows
On Tue, 13 Sep 2022 17:21:52 GMT, Aleksey Shipilev wrote:
>> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties line 87:
>>
>>> 85: main.opt.compress=Compression to use when creating the JMOD archive.\
>>> 86: \ Accepted values are: zip-[0-9], where zip-0 provides no
Hi,
Please review this update to the ZipInputStream class description to clarify
that ZipInputStream walks sequentially through each Zip Entry contained within
the Zip File. As a result, the CEN header for the Zip file entries are not
read resulting in ZipInputStream not having access to
On Thu, 1 Sep 2022 11:06:41 GMT, Lance Andersen wrote:
>> That's right. But I think we care about the MANIFEST more. It's not that
>> important whether META-INF is there.
>
> True we do care more about the manifest, but was also trying to address the
> difference between ZipInputStream which
On Tue, 13 Sep 2022 16:51:52 GMT, Mandy Chung wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> More review comments
>
> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties line 87:
>
>> 85:
On Fri, 2 Sep 2022 14:50:32 GMT, Alan Bateman wrote:
>> I could do tweak further to say:
>>
>> _`getManifest()` will return the Manifest if it is the first entry or
>> META-INF/ is the first entry and the Manifest is the second entry within the
>> Jar file. When the Manifest is returned by
On Thu, 1 Sep 2022 17:56:03 GMT, Lance Andersen wrote:
>>> It's better. Do you need to explicitly say "For all other cases"?
>>
>> I thought it is worth being specific, but happy to leave it out if you and
>> others prefer
>>>
>>> My original comment was more about explaining `getManifest()`
On Thu, 1 Sep 2022 13:53:05 GMT, Weijun Wang wrote:
> It's better. Do you need to explicitly say "For all other cases"?
I thought it is worth being specific, but happy to leave it out if you and
others prefer
>
> My original comment was more about explaining `getManifest()` and
>
On Thu, 1 Sep 2022 17:27:23 GMT, Lance Andersen wrote:
>> It's better. Do you need to explicitly say "For all other cases"?
>>
>> My original comment was more about explaining `getManifest()` and
>> `getNextEntry()` in the same if. It's still doable.
>
>> It's better. Do you need to explicitly
On Wed, 31 Aug 2022 19:13:05 GMT, Weijun Wang wrote:
>> The challenge I had with the wording is due to the fact that if "META-INF/"
>> is the first entry in the Zip file, it will not be returned regardless of
>> whether there is a manifest. So open to suggestions.
>
> That's right. But I
On Wed, 31 Aug 2022 18:31:13 GMT, Lance Andersen wrote:
>> src/java.base/share/classes/java/util/jar/JarInputStream.java line 62:
>>
>>> 60: * is the second jar entry
>>> 61: *
>>> 62: *
>>
>> I wonder if it's necessary to duplicate these lines. How about something
>> like
On Tue, 30 Aug 2022 21:47:03 GMT, Weijun Wang wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this update,
On Fri, 26 Aug 2022 15:48:55 GMT, Lance Andersen wrote:
> Please review this PR which updates the JarInputStream class description to
> clarify when the Manifest is accessible via JarInputStream::getManifest and
> JarInputStream::get[Jar]Entry.
>
> It is worth noting that with this update,
Please review this PR which updates the JarInputStream class description to
clarify when the Manifest is accessible via JarInputStream::getManifest and
JarInputStream::get[Jar]Entry.
It is worth noting that with this update, we are finally documenting behavior
that dates back to when this
On Tue, 13 Sep 2022 09:31:49 GMT, Aleksey Shipilev wrote:
>> I have been looking into `make clean-images images` performance, and
>> realized jmod keeps compressing files with default compression level. Tuning
>> that toward lighter compression levels improves build performance
>>
On Mon, 12 Sep 2022 18:14:26 GMT, Joe Darcy wrote:
> Small fixes to AccessFlag implementation.
This pull request has now been integrated.
Changeset: 1dc5039f
Author:Joe Darcy
URL:
https://git.openjdk.org/jdk/commit/1dc5039fed9494f4d9b6c7002d28da9bc466fb10
Stats: 33 lines in 3
On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote:
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
> removal, and remove the remaining special handling of ThreadDeath from the
> JDK.
>
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2
On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote:
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
> removal, and remove the remaining special handling of ThreadDeath from the
> JDK.
>
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2
Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
removal, and remove the remaining special handling of ThreadDeath from the JDK.
Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998)
with a link to a supplementary page that explains the
On Thu, 25 Aug 2022 09:25:55 GMT, Alan Bateman wrote:
>> Btw, I've tried to reimplement `readInt()` in a way similar to `readLong()`:
>>
>> public final int readInt() throws IOException {
>> readFully(readBuffer, 0, 4);
>> return (readBuffer[0] & 0xff) << 24
>> + (readBuffer[1]
On Thu, 25 Aug 2022 09:25:55 GMT, Alan Bateman wrote:
>> Btw, I've tried to reimplement `readInt()` in a way similar to `readLong()`:
>>
>> public final int readInt() throws IOException {
>> readFully(readBuffer, 0, 4);
>> return (readBuffer[0] & 0xff) << 24
>> + (readBuffer[1]
On Tue, 13 Sep 2022 09:28:07 GMT, Aleksey Shipilev wrote:
>> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 1196:
>>
>>> 1194: }
>>> 1195: try {
>>> 1196: int level = Integer.parseInt(value.substring(idx +
>>> 1));
>>
>> If I'm reading
On Tue, 13 Sep 2022 09:31:49 GMT, Aleksey Shipilev wrote:
>> I have been looking into `make clean-images images` performance, and
>> realized jmod keeps compressing files with default compression level. Tuning
>> that toward lighter compression levels improves build performance
>>
On Tue, 13 Sep 2022 08:10:28 GMT, Jaikiran Pai wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> More review comments
>
> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java line 66:
>
>> 64:
> I have been looking into `make clean-images images` performance, and realized
> jmod keeps compressing files with default compression level. Tuning that
> toward lighter compression levels improves build performance considerably,
> without a heavy loss in *.jmod sizes.
>
> This PR allows
On Tue, 13 Sep 2022 07:42:33 GMT, Aleksey Shipilev wrote:
>> I have been looking into `make clean-images images` performance, and
>> realized jmod keeps compressing files with default compression level. Tuning
>> that toward lighter compression levels improves build performance
>>
On Mon, 12 Sep 2022 14:29:56 GMT, Aleksei Efimov wrote:
>> ### Summary of the change
>>
>> The LDAP Naming Service Provider implementation's default settings are
>> changed to disallow deserialization and reconstruction of Java objects from
>> different LDAP attributes (RFC 2713). Currently,
On Mon, 12 Sep 2022 18:51:28 GMT, Mandy Chung wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Adopt "--compress zip-[0-9]" as option format
>
> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
> I have been looking into `make clean-images images` performance, and realized
> jmod keeps compressing files with default compression level. Tuning that
> toward lighter compression levels improves build performance considerably,
> without a heavy loss in *.jmod sizes.
>
> This PR allows
54 matches
Mail list logo
