On Mon, 7 Oct 2024 06:26:09 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which proposes to deprecate for
>> removal the `jrunscript` tool?
>>
>> The `jrunscript` tool as documented in its specification
>> https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunsc
> Can I please get a review for this change which proposes to deprecate for
> removal the `jrunscript` tool?
>
> The `jrunscript` tool as documented in its specification
> https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was
> an experimental and unsupported tool. Ever
On Mon, 7 Oct 2024 04:49:45 GMT, Athijegannathan Sundararajan
wrote:
> That documentation comment in module-info.java of java.scripting has to be
> updated for deprecation info of the tool (as you noted)
I've now updated the PR to make a mention of the `jrunscript` tool being
deprecated, in t
> Can I please get a review for this patch which proposes to implement the
> enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>
> Edit: This PR description has now been updated to match the changes that were
> done over the course of review inputs that were received
On Thu, 3 Oct 2024 16:54:40 GMT, Aleksey Shipilev wrote:
>> test/micro/org/openjdk/bench/java/lang/ref/ReferenceClear.java line 2:
>>
>>> 1: //
>>> 2: // * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
>>
>> Drive-by comment: The `// *` format looks weird.
>
> Actually, this
On Tue, 10 Sep 2024 05:36:17 GMT, Christian Stein wrote:
>> Jaikiran Pai has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 20 commits:
>>
>> - merge latest from master branch
>> - merge latest from master branch
>> - merge latest
> Can I please get a review for this patch which proposes to implement the
> enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>
> Edit: This PR description has now been updated to match the changes that were
> done over the course of review inputs that were received
On Mon, 7 Oct 2024 04:23:20 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to deprecate for
> removal the `jrunscript` tool?
>
> The `jrunscript` tool as documented in its specification
> https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.
On Sun, 6 Oct 2024 19:24:07 GMT, Brett Okken wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixup! Reader.of(String)
>>
>> Dropping non-public JavaDocs
>
> src/java.base/share/classes/java/io/Reader.java line
On Mon, 7 Oct 2024 00:04:40 GMT, ExE Boss wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixup! Reader.of(String)
>>
>> Dropping non-public JavaDocs
>
> src/java.base/share/classes/java/io/Reader.java line 172
On Wed, 7 Aug 2024 00:02:46 GMT, Joe Darcy wrote:
>> First pass at adding some quality of implementation discussions around the
>> overridable methods of Object.
>
> Joe Darcy has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the u
On Mon, 7 Oct 2024 04:23:20 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to deprecate for
> removal the `jrunscript` tool?
>
> The `jrunscript` tool as documented in its specification
> https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.
Can I please get a review for this change which proposes to deprecate for
removal the `jrunscript` tool?
The `jrunscript` tool as documented in its specification
https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was an
experimental and unsupported tool. Ever since the sc
On Sun, 6 Oct 2024 19:17:24 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which proposes to change the input buffer size of
>> `ZipFileInflaterInputStream` to be based on the _compressed_ size of a ZIP
>> entry instead of the _uncompressed_ size. This saves allocation since
>> buffers wi
> java.base should provide best practices for Class File API
>
> 1. Use fluent coding style
> 2. Use aconst_null instead of oadConstant(null)
> 3. use astore intead of 'storeLocal(REFERENCE'
> 4. use aload instead of 'loadLocal(REFERENCE'
> 5. 'lload/lstore' instead of 'loadLocal(LONG)/storeLocal(
On Tue, 10 Sep 2024 13:13:22 GMT, Shaojin Wen wrote:
>> The string concatenation of the java.base module is implemented using
>> StringBuilder. By providing a series of concat methods in
>> StringConcatHelper, it is used in the java.lang package to replace string
>> concatenation.
>>
>> These
On Sun, 6 Oct 2024 17:44:53 GMT, Markus KARG wrote:
>> This Pull Requests proposes an implementation for
>> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
>> method `public static Reader Reader.of(CharSequence)` will return an
>> anonymous, non-synchronized implemen
On Wed, 7 Aug 2024 00:02:46 GMT, Joe Darcy wrote:
>> First pass at adding some quality of implementation discussions around the
>> overridable methods of Object.
>
> Joe Darcy has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the u
On Sun, 6 Oct 2024 19:33:49 GMT, Eirik Bjørsnøs wrote:
>> As it's a pre-existing issue I'd prefer to keep this one focused on the
>> switch-over. How would you model unsigned long values here, though? Sure we
>> could read into a `BigInteger` or accept negative values, but to really
>> support
> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
> improve performance in zip-related microbenchmarks, but doing so would
> increase startup overheads. Progress was stalled as we backed out some
> related early use of `ByteArray(LittleEndian)` and started exploring m
On Sun, 6 Oct 2024 19:19:15 GMT, Claes Redestad wrote:
> How would you model unsigned long values here, though?
I don't think we should. `9223372036854775807 ` should be enough for everyone
:-)
It may be worth renaming the method to `get64S` and add a `get64` variant which
either clamps at `L
On Sun, 6 Oct 2024 15:48:57 GMT, Eirik Bjørsnøs wrote:
>> Sure, I think the JIT is pretty good at eliminating the (intrinsic)
>> `checkIndex` calls when they are redundant though. Performance with and
>> without these `checkIndex`es are the same in my testing, so we can eat and
>> have the cak
On Sun, 6 Oct 2024 17:44:53 GMT, Markus KARG wrote:
>> This Pull Requests proposes an implementation for
>> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
>> method `public static Reader Reader.of(CharSequence)` will return an
>> anonymous, non-synchronized implemen
On Sun, 6 Oct 2024 15:53:55 GMT, Eirik Bjørsnøs wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> copyright
>
> src/java.base/share/classes/java/util/zip/ZipUtils.java line 195:
>
>> 193: * The bytes are assu
On Sun, 6 Oct 2024 16:27:52 GMT, Chen Liang wrote:
>> test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java line 110:
>>
>>> 108: zf2.close();
>>> 109: }
>>> 110:
>>
>> A short comment stating the purpose of the main method would not hurt.
>
> https://github.com/openjdk/jdk/p
> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
> improve performance in zip-related microbenchmarks, but doing so would
> increase startup overheads. Progress was stalled as we backed out some
> related early use of `ByteArray(LittleEndian)` and started exploring m
On Sun, 6 Oct 2024 18:02:58 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which proposes to change the input buffer size of
> `ZipFileInflaterInputStream` to be based on the _compressed_ size of a ZIP
> entry instead of the _uncompressed_ size. This saves allocation since buffers
> will n
On Sun, 6 Oct 2024 18:05:28 GMT, Bernd wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixup! Reader.of(String)
>>
>> Dropping non-public JavaDocs
>
> src/java.base/share/classes/java/io/Reader.java line 231:
>
On Sun, 6 Oct 2024 17:44:53 GMT, Markus KARG wrote:
>> This Pull Requests proposes an implementation for
>> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
>> method `public static Reader Reader.of(CharSequence)` will return an
>> anonymous, non-synchronized implemen
On Sun, 6 Oct 2024 17:44:53 GMT, Markus KARG wrote:
>> This Pull Requests proposes an implementation for
>> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
>> method `public static Reader Reader.of(CharSequence)` will return an
>> anonymous, non-synchronized implemen
Please review this PR which proposes to change the input buffer size of
`ZipFileInflaterInputStream` to be based on the _compressed_ size of a ZIP
entry instead of the _uncompressed_ size. This saves allocation since buffers
will no longer be oversized:
* The `size` parameter passed to the `Zip
On Sun, 6 Oct 2024 17:44:53 GMT, Markus KARG wrote:
>> This Pull Requests proposes an implementation for
>> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
>> method `public static Reader Reader.of(CharSequence)` will return an
>> anonymous, non-synchronized implemen
On Sun, 6 Oct 2024 17:31:42 GMT, Markus KARG wrote:
>> I recommend adding another test case against an ad-hoc `CharSequence`
>> implementation wrapping a `char[]` in a record, to ensure the generic paths
>> in `read(char[], int, int)` works as intended.
>
> Good idea. But instead, we could also
On Sun, 6 Oct 2024 17:44:53 GMT, Markus KARG wrote:
>> This Pull Requests proposes an implementation for
>> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
>> method `public static Reader Reader.of(CharSequence)` will return an
>> anonymous, non-synchronized implemen
On Sun, 6 Oct 2024 14:54:22 GMT, Markus KARG wrote:
>> src/java.base/share/classes/java/io/Reader.java line 163:
>>
>>> 161: * {@code transferTo()} methods all throw {@code IOException}.
>>> 162: *
>>> 163: * The {@code markSupported()} method returns {@code true}.
>>
>> Suggest
This would likely work for those cases. The Byte Buddy plugins for Gradle
and Maven discover today what release version is configured in the compile
step, and uses that version for configuring the class file locators that it
can configure. If a release version is for example set to Java 17, the
cla
On Sun, 6 Oct 2024 15:23:15 GMT, Markus KARG wrote:
>> This Pull Requests proposes an implementation for
>> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
>> method `public static Reader Reader.of(CharSequence)` will return an
>> anonymous, non-synchronized implemen
On Sun, 6 Oct 2024 17:25:55 GMT, Markus KARG wrote:
>> src/java.base/share/classes/java/io/Reader.java line 187:
>>
>>> 185: * Reads a single character.
>>> 186: *
>>> 187: * @return The character read, or -1 if the end of the
>>> stream has been
>>
>
> This Pull Requests proposes an implementation for
> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
> method `public static Reader Reader.of(CharSequence)` will return an
> anonymous, non-synchronized implementation of a `Reader` for each kind of
> `CharSequence` im
On Sun, 6 Oct 2024 16:41:13 GMT, Chen Liang wrote:
>> test/jdk/java/io/Reader/Of.java line 51:
>>
>>> 49: public static Reader[] readers() {
>>> 50: return new Reader[] {
>>> 51: new StringReader(CONTENT),
>>
>> Explicitly including that original class here (even if it h
On Sun, 6 Oct 2024 16:32:51 GMT, Chen Liang wrote:
>> This text already exists in this very file, it is a 1:1 copy from
>> `nullReader()`. It cannot be wrong for `of()` if it was correct for
>> `nullReader()`. To stay consistent with existing JavaDocs in this very same
>> file, we should not h
On Sun, 6 Oct 2024 16:39:02 GMT, Chen Liang wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixup! Reader.of(String)
>>
>> Updated JavaDocs according to Alan Bateman's review comments:
>> * Dropped "API compa
On Sat, 5 Oct 2024 16:45:01 GMT, Markus KARG wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixup! Reader.of(String)
>>
>> Updated JavaDocs according to Alan Bateman's review comments:
>> * Dropped "API comp
On Sun, 6 Oct 2024 15:23:15 GMT, Markus KARG wrote:
>> This Pull Requests proposes an implementation for
>> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
>> method `public static Reader Reader.of(CharSequence)` will return an
>> anonymous, non-synchronized implemen
On Sun, 6 Oct 2024 14:58:23 GMT, Markus KARG wrote:
>> src/java.base/share/classes/java/io/Reader.java line 161:
>>
>>> 159: * {@code read(char[])}, {@code read(char[], int, int)},
>>> 160: * {@code read(CharBuffer)}, {@code ready()}, {@code skip(long)},
>>> and
>>> 161: * {@code
On Sun, 6 Oct 2024 15:27:07 GMT, Eirik Bjørsnøs wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> copyright
>
> test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java line 110:
>
>> 108: zf2.close();
On Fri, 30 Aug 2024 15:08:20 GMT, David M. Lloyd wrote:
> Please review this small documentation change to ConstantPoolBuilder to fix a
> typo and clarify the usage of the `constantValueEntry` method.
This pull request has now been integrated.
Changeset: 20f36c66
Author:David M. Lloyd
Com
On Mon, 30 Sep 2024 14:59:12 GMT, David M. Lloyd wrote:
>> Please review this small documentation change to ConstantPoolBuilder to fix
>> a typo and clarify the usage of the `constantValueEntry` method.
>
> David M. Lloyd has updated the pull request incrementally with one additional
> commit s
On Sun, 6 Oct 2024 14:56:27 GMT, Eirik Bjørsnøs wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> copyright
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 1644:
>
>> 1642: // Now s
On Sun, 6 Oct 2024 15:48:57 GMT, Eirik Bjørsnøs wrote:
>> Sure, I think the JIT is pretty good at eliminating the (intrinsic)
>> `checkIndex` calls when they are redundant though. Performance with and
>> without these `checkIndex`es are the same in my testing, so we can eat and
>> have the cak
On Sun, 6 Oct 2024 15:14:05 GMT, Claes Redestad wrote:
>> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
>> improve performance in zip-related microbenchmarks, but doing so would
>> increase startup overheads. Progress was stalled as we backed out some
>> related e
On Sun, 6 Oct 2024 15:35:44 GMT, Claes Redestad wrote:
>> Actually if we trust the input index to be nonnegative, we can just check
>> our end index for out of bounds too.
>
> Sure, I think the JIT is pretty good at eliminating the (intrinsic)
> `checkIndex` calls when they are redundant though
On Sun, 6 Oct 2024 15:29:13 GMT, Eirik Bjørsnøs wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> copyright
>
> src/java.base/share/classes/java/util/zip/ZipUtils.java line 258:
>
>> 256: static final long CEN
On Sun, 6 Oct 2024 15:14:05 GMT, Claes Redestad wrote:
>> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
>> improve performance in zip-related microbenchmarks, but doing so would
>> increase startup overheads. Progress was stalled as we backed out some
>> related e
On Sun, 6 Oct 2024 15:14:05 GMT, Claes Redestad wrote:
>> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
>> improve performance in zip-related microbenchmarks, but doing so would
>> increase startup overheads. Progress was stalled as we backed out some
>> related e
On Sun, 6 Oct 2024 15:11:19 GMT, Chen Liang wrote:
>> It's actually not less overhead in my tests, since `checkIndex` is intrinsic
>> and mostly disappears, while with `checkFromIndexSize` performance gets
>> significantly worse (on par with baseline). It's on my todo to investigate
>> this in
On Sun, 6 Oct 2024 15:23:15 GMT, Markus KARG wrote:
>> This Pull Requests proposes an implementation for
>> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
>> method `public static Reader Reader.of(CharSequence)` will return an
>> anonymous, non-synchronized implemen
> This Pull Requests proposes an implementation for
> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
> method `public static Reader Reader.of(CharSequence)` will return an
> anonymous, non-synchronized implementation of a `Reader` for each kind of
> `CharSequence` im
On Sun, 6 Oct 2024 15:07:02 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/util/zip/ZipUtils.java line 175:
>>
>>> 173: public static final int get16(byte[] b, int off) {
>>> 174: Preconditions.checkIndex(off, b.length,
>>> Preconditions.AIOOBE_FORMATTER);
>>> 175:
> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
> improve performance in zip-related microbenchmarks, but doing so would
> increase startup overheads. Progress was stalled as we backed out some
> related early use of `ByteArray(LittleEndian)` and started exploring m
On Sun, 6 Oct 2024 14:40:37 GMT, Chen Liang wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> copyright
>
> src/java.base/share/classes/java/util/zip/ZipUtils.java line 175:
>
>> 173: public static final int g
On Sun, 6 Oct 2024 14:35:35 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/io/Reader.java line 341:
>>
>>> 339: public void close() {
>>> 340: cs = null;
>>> 341: }
>>
>> @AlanBateman I need to confess that I did not understand what you had in
On Sun, 6 Oct 2024 14:29:09 GMT, Chen Liang wrote:
>> This Pull Requests proposes an implementation for
>> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
>> method `public static Reader Reader.of(CharSequence)` will return an
>> anonymous, non-synchronized implement
On Sun, 6 Oct 2024 14:21:30 GMT, Chen Liang wrote:
>> This Pull Requests proposes an implementation for
>> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
>> method `public static Reader Reader.of(CharSequence)` will return an
>> anonymous, non-synchronized implement
On Sun, 6 Oct 2024 14:20:12 GMT, Chen Liang wrote:
>> This Pull Requests proposes an implementation for
>> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
>> method `public static Reader Reader.of(CharSequence)` will return an
>> anonymous, non-synchronized implement
On Sun, 6 Oct 2024 14:16:44 GMT, Claes Redestad wrote:
> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
> improve performance in zip-related microbenchmarks, but doing so would
> increase startup overheads. Progress was stalled as we backed out some
> related early
On Sun, 6 Oct 2024 14:16:44 GMT, Claes Redestad wrote:
> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
> improve performance in zip-related microbenchmarks, but doing so would
> increase startup overheads. Progress was stalled as we backed out some
> related early
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a performance
> sensitive path. However, it shows up prominently on simple be
On Sat, 5 Oct 2024 16:48:56 GMT, Markus KARG wrote:
>> This Pull Requests proposes an implementation for
>> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
>> method `public static Reader Reader.of(CharSequence)` will return an
>> anonymous, non-synchronized implemen
On Sat, 5 Oct 2024 16:32:39 GMT, Markus KARG wrote:
> This Pull Requests proposes an implementation for
> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
> method `public static Reader Reader.of(CharSequence)` will return an
> anonymous, non-synchronized implementati
#14632 showed that coalescing loads in the `ZipUtils` utility methods could
improve performance in zip-related microbenchmarks, but doing so would increase
startup overheads. Progress was stalled as we backed out some related early use
of `ByteArray(LittleEndian)` and started exploring merge sto
On Sat, 5 Oct 2024 16:32:39 GMT, Markus KARG wrote:
> This Pull Requests proposes an implementation for
> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
> method `public static Reader Reader.of(CharSequence)` will return an
> anonymous, non-synchronized implementati
On Sun, 6 Oct 2024 08:32:20 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly
>> just the revert of the backout.
>>
>> Regarding the related issues:
>>
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and
>> [JDK-830
A trivial fix to ProblemList `java/foreign/TestUpcallStress.java` in Xcomp mode.
-
Commit messages:
- 8341593: Problemlist java/foreign/TestUpcallStress.java in Xcomp mode
Changes: https://git.openjdk.org/jdk/pull/21375/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21375&
> Hi,
>
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just
> the revert of the backout.
>
> Regarding the related issues:
>
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and
> [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fix
75 matches
Mail list logo
