Hi Michael,
On 17/04/2021 10:57 am, Michael Hall wrote:
Is there anyway to get a simple/test reference type application available that
could be used in reproducing bugs?
I had two I think potentially serious bugs that were basically not addressed
for problems in reproducing.
JDK-8263156 : [m
On 17/04/2021 4:54 am, Raffaello Giulietti wrote:
I guess the reporter meant to limit the cache range similarly to the one
used for valueOf().
I have no clue about the benefit/cost ratio for the proposed String
cache. It really depends on usage, workload, etc. One can easily imagine
both extr
> Please review the changes for the subject issue. This has been suggested in
> a recent discussion thread for the JEP 400
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
> A CSR has also been drafted, and comments are welcome
> [[2](https://bugs.openjdk.
> With the introduction of `toList()`, preserving the SIZED characteristics in
> more cases becomes more important. This patch preserves SIZED on `skip()` and
> `limit()` operations, so now every combination of
> `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and
> `toList()`,
> With the introduction of `toList()`, preserving the SIZED characteristics in
> more cases becomes more important. This patch preserves SIZED on `skip()` and
> `limit()` operations, so now every combination of
> `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and
> `toList()`,
On Sat, 17 Apr 2021 01:55:26 GMT, Tagir F. Valeev wrote:
>> With the introduction of `toList()`, preserving the SIZED characteristics in
>> more cases becomes more important. This patch preserves SIZED on `skip()`
>> and `limit()` operations, so now every combination of
>> `map/mapToX/boxed/as
> With the introduction of `toList()`, preserving the SIZED characteristics in
> more cases becomes more important. This patch preserves SIZED on `skip()` and
> `limit()` operations, so now every combination of
> `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and
> `toList()`,
Is there anyway to get a simple/test reference type application available that
could be used in reproducing bugs?
I had two I think potentially serious bugs that were basically not addressed
for problems in reproducing.
JDK-8263156 : [macos]: OS X application signing concerns - a sealed resourc
On Fri, 16 Apr 2021 19:05:25 GMT, Roger Riggs wrote:
>> Peter Levart has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add String.join benchmark method to StringJoinerBenchmark and adjust some
>> parameters to cover bigger range
>
> src/j
On Thu, 15 Apr 2021 01:24:04 GMT, Alexander Matveev
wrote:
> - Issue was reproducible when install-dir points to some invalid location.
> - Fixed by defaulting DMG drag and drop location to /Applications folder and
> --install-dir will be ignored with warning for DMG.
> - I do not see any way
On Fri, 16 Apr 2021 21:10:42 GMT, Naoto Sato wrote:
> Please review the fix to the tier4 build failure. The piece of code that made
> into `CLDRLocaleProviderAdapter.java` was also needed in the build tool
> counterpart (`CLDRConverter`).
This pull request has now been integrated.
Changeset:
> Please review the fix to the tier4 build failure. The piece of code that made
> into `CLDRLocaleProviderAdapter.java` was also needed in the build tool
> counterpart (`CLDRConverter`).
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Hi Stuart,
We should be cautious when adding new APIs to existing interfaces. There may be
libraries which extend JDK types and already have reversed(), toReversed() or
asReversed() APIs and corresponding interfaces.
There are OrderedIterable and ReversibleIterable interfaces and asReversed()
Hi Roger,
> Are you taking into account that for many reads the data is not copied
> into the local buffer.
> See the comments in BufferedInputStream.read1: 277:280?
sure, I'm aware of this optimization. The buffer however is always allocated as
BufferedInputStream instantiated,
waisting by defa
On Fri, 16 Apr 2021 21:10:42 GMT, Naoto Sato wrote:
> Please review the fix to the tier4 build failure. The piece of code that made
> into `CLDRLocaleProviderAdapter.java` was also needed in the build tool
> counterpart (`CLDRConverter`).
Marked as reviewed by joehw (Reviewer).
-
Please review the fix to the tier4 build failure. The piece of code that made
into `CLDRLocaleProviderAdapter.java` was also needed in the build tool
counterpart (`CLDRConverter`).
-
Commit messages:
- 8265375: Bootcycle builds fail with StackOverflowError in cldrconverter
Changes
> To allow agents the definition of auxiliary classes, an API is needed to
> allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or
> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed
> from `sun.misc.Unsafe`.
Rafael Winterhalter has refreshed the c
On Fri, 16 Apr 2021 18:07:01 GMT, Daniel D. Daugherty
wrote:
> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:
>
> - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
> - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
> - JDK-8
I have never seen a need for a non-agent to define a class in a
non-existing package. Injection is typically required if you want to work
with package-private types or methods which is really only relevant for the
Spring framework, but even there I do not think it's such a big area that
it cannot b
I am trying to revive issue 8200559 (
https://bugs.openjdk.java.net/browse/JDK-8200559) which was briefly
discussed on this mailing list over three years ago (
http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000405.html). I
am hopeful that a solution could be reached prior to releasing
On Fri, 16 Apr 2021 19:42:06 GMT, Brian Burkhalter wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove changes for JDK-8265366 at @fguallini's request.
>
> Marked as reviewed by bpb (Reviewer).
@bplb and
On Fri, 16 Apr 2021 20:12:45 GMT, Daniel D. Daugherty
wrote:
>> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:
>>
>> - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
>> - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
>> -
> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:
>
> - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
> - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
> - JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch
On Fri, 16 Apr 2021 13:44:16 GMT, Rafael Winterhalter
wrote:
> To allow agents the definition of auxiliary classes, an API is needed to
> allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or
> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed
>
On Tue, 6 Apr 2021 20:34:52 GMT, Ian Graves wrote:
> This fixes a bug where the formatting code for `%g` flags incorrectly tries
> to round `BigDecimal` after determining whether it should be a decimal
> numeric format or a scientific numeric format. The solution rounds before
> determining th
On Fri, 16 Apr 2021 16:08:53 GMT, Ian Graves wrote:
>> This fixes a bug where the formatting code for `%g` flags incorrectly tries
>> to round `BigDecimal` after determining whether it should be a decimal
>> numeric format or a scientific numeric format. The solution rounds before
>> determini
On Fri, 16 Apr 2021 18:07:01 GMT, Daniel D. Daugherty
wrote:
> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:
>
> - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
> - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
> - JDK-8
On Fri, 16 Apr 2021 18:07:01 GMT, Daniel D. Daugherty
wrote:
> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:
>
> - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
> - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
> - JDK-8
A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:
- JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
- JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
- JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64
- JDK-8
On Thu, 15 Apr 2021 19:26:48 GMT, Peter Levart wrote:
>> While JDK-8148937 improved StringJoiner class by replacing internal use of
>> getChars that copies out characters from String elements into a char[] array
>> with StringBuilder which is somehow more optimal, the improvement was
>> margin
On Fri, 16 Apr 2021 18:15:41 GMT, Roger Riggs wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Modified javadocs per suggestions.
>
> src/java.base/share/classes/java/io/InputStreamReader.java line 48:
>
>> 46: * F
I guess the reporter meant to limit the cache range similarly to the one
used for valueOf().
I have no clue about the benefit/cost ratio for the proposed String
cache. It really depends on usage, workload, etc. One can easily imagine
both extreme scenarios but it's hard to tell how the average
On Sat, 13 Mar 2021 14:28:25 GMT, Philippe Marschall
wrote:
>> Implement three optimiztations for Reader.read(CharBuffer)
>>
>> * Add a code path for heap buffers in Reader#read to use the backing array
>> instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#
On Sat, 13 Mar 2021 14:28:25 GMT, Philippe Marschall
wrote:
>> Implement three optimiztations for Reader.read(CharBuffer)
>>
>> * Add a code path for heap buffers in Reader#read to use the backing array
>> instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#
Hi,
Is there any way to quantify the savings?
And what technique can be applied to limit the size of the cache.
The size of the small integer cache is somewhat arbitrary.
Regards, Roger
On 4/16/21 12:48 PM, Raffaello Giulietti wrote:
Hello,
does the enhancement proposed in [1] make sense, bot
On Thu, 15 Apr 2021 18:29:17 GMT, Naoto Sato wrote:
>> Please review the changes for the subject issue. This has been suggested in
>> a recent discussion thread for the JEP 400
>> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>> A CSR has also been draft
> De: "Rafael Winterhalter"
> À: "Remi Forax"
> Cc: "Rafael Winterhalter" , "core-libs-dev"
> , "serviceability-dev"
>
> Envoyé: Vendredi 16 Avril 2021 18:41:26
> Objet: Re: RFR: 8200559: Java agents doing instrumentation need a means to
> define auxilary classes
> This would be a problem, howe
This is a proposal to add a ReversibleCollection interface to the Collections
Framework. I'm looking for comments on overall design before I work on detailed
specifications and tests. Please send such comments as replies on this email thread.
Here's a link to a draft PR that contains the code d
On Fri, 16 Apr 2021 16:08:53 GMT, Ian Graves wrote:
>> This fixes a bug where the formatting code for `%g` flags incorrectly tries
>> to round `BigDecimal` after determining whether it should be a decimal
>> numeric format or a scientific numeric format. The solution rounds before
>> determini
On 16/04/2021 17:40, Rafael Winterhalter wrote:
:
I will try to make my case on the mailing list. I hoped this could get resolved
within the release of Java 17 as this would make it possible to write agents
without use of Unsafe API to support Java 17 and later. Since agents often are
suppleme
On Sat, 13 Mar 2021 14:28:25 GMT, Philippe Marschall
wrote:
>> Implement three optimiztations for Reader.read(CharBuffer)
>>
>> * Add a code path for heap buffers in Reader#read to use the backing array
>> instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#
Hello Philippe,
> On Apr 16, 2021, at 8:43 AM, Philippe Marschall wrote:
>
> Hello
>
> I am looking for reviewers and a sponsor for JDK-4926314: Optimize
> Reader.read(CharBuffer) [1]. The PR [2] went through quite some changes
> and is now back to few changes to reduce the impact and the risk.
On Sat, 13 Mar 2021 14:28:25 GMT, Philippe Marschall
wrote:
>> Implement three optimiztations for Reader.read(CharBuffer)
>>
>> * Add a code path for heap buffers in Reader#read to use the backing array
>> instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#
On Thu, 15 Apr 2021 01:24:04 GMT, Alexander Matveev
wrote:
> - Issue was reproducible when install-dir points to some invalid location.
> - Fixed by defaulting DMG drag and drop location to /Applications folder and
> --install-dir will be ignored with warning for DMG.
> - I do not see any way
Hello,
does the enhancement proposed in [1] make sense, both today and when
wrappers will be migrated to primitive classes?
If so, it should be rather simple to add it and I could prepare a PR.
If not, the issue might perhaps be closed.
Greetings
Raffaello
[1] https://bugs.openjdk.java
This would be a problem, however. Since there is currently no official way
of defining a class, and since Java agents do not control the class loading
order, if a class was loaded for the first time, you could for example not
add a field with a type of an auxiliary class that you had planned to
inj
On Fri, 16 Apr 2021 13:44:16 GMT, Rafael Winterhalter
wrote:
> To allow agents the definition of auxiliary classes, an API is needed to
> allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or
> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed
>
> De: "Rafael Winterhalter"
> À: "Remi Forax"
> Cc: "Rafael Winterhalter" , "core-libs-dev"
> , "serviceability-dev"
>
> Envoyé: Vendredi 16 Avril 2021 18:27:46
> Objet: Re: RFR: 8200559: Java agents doing instrumentation need a means to
> define auxilary classes
> Not by my understanding. A su
Not by my understanding. A suitable lookup requires a loaded class for the
package. A Java agent might however not provide a handle for a class that
is not yet loaded. Or how would you suggest to approach this?
Am Fr., 16. Apr. 2021 um 16:21 Uhr schrieb Remi Forax :
> - Mail original -
>
On Fri, 16 Apr 2021 14:26:58 GMT, Roger Riggs wrote:
>> Ian Graves has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Adding BigDecimal equivalents to tests
>
> src/java.base/share/classes/java/util/Formatter.java line 3826:
>
>> 3824:
> This fixes a bug where the formatting code for `%g` flags incorrectly tries
> to round `BigDecimal` after determining whether it should be a decimal
> numeric format or a scientific numeric format. The solution rounds before
> determining the correct format.
Ian Graves has updated the pull re
Hello
I am looking for reviewers and a sponsor for JDK-4926314: Optimize
Reader.read(CharBuffer) [1]. The PR [2] went through quite some changes
and is now back to few changes to reduce the impact and the risk.
[1] https://bugs.openjdk.java.net/browse/JDK-4926314
[2] https://github.com/openjdk
Hello,
the reporter of [1] seems to understand that the current behavior is
well specified (since ever) and correctly implemented. Also, it's
unclear how s/he would like to enhance it.
Shouldn't [1] be closed?
Greetings
Raffaello
[1] https://bugs.openjdk.java.net/browse/JDK-8246334
On Fri, 16 Apr 2021 13:44:16 GMT, Rafael Winterhalter
wrote:
> To allow agents the definition of auxiliary classes, an API is needed to
> allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or
> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed
>
On Fri, 2 Apr 2021 19:15:39 GMT, Ian Graves wrote:
>> Bug fix with the intersection `&&` operator in regex patterns. In
>> JDK-8037397, some character classes on the right hand side of the operator
>> are dropped in cases where nested `[..]` classes are used with non "nested"
>> ones.
>
> Ian
On Wed, 7 Apr 2021 02:48:00 GMT, Ian Graves wrote:
>> This fixes a bug where the formatting code for `%g` flags incorrectly tries
>> to round `BigDecimal` after determining whether it should be a decimal
>> numeric format or a scientific numeric format. The solution rounds before
>> determinin
- Mail original -
> De: "Rafael Winterhalter"
> À: "core-libs-dev" , "serviceability-dev"
>
> Envoyé: Vendredi 16 Avril 2021 15:52:07
> Objet: RFR: 8200559: Java agents doing instrumentation need a means to define
> auxilary classes
> To allow agents the definition of auxiliary classes
To allow agents the definition of auxiliary classes, an API is needed to allow
this. Currently, this is often achieved by using `sun.misc.Unsafe` or
`jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from
`sun.misc.Unsafe`.
-
Commit messages:
- 8200559: Jav
> Hello,
>
> here's a PR for a patch submitted on March 2020
> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a
> thing.
>
> The patch has been edited to adhere to OpenJDK code conventions about
> multi-line (block) comments. Nothing in the code proper has changed,
On Thu, 8 Apr 2021 21:12:21 GMT, Raffaello Giulietti
wrote:
> Hello,
>
> here's a PR for a patch submitted on March 2020
> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a
> thing.
>
> The patch has been edited to adhere to OpenJDK code conventions about
> multi
On Thu, 15 Apr 2021 12:37:52 GMT, Jim Laskey wrote:
>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> Jim Laskey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Remove extraneous references to makeXXXSpliterator
On Thu, 15 Apr 2021 12:37:52 GMT, Jim Laskey wrote:
>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> Jim Laskey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Remove extraneous references to makeXXXSpliterator
On Fri, 16 Apr 2021 08:22:41 GMT, Jan Lahoda wrote:
>> Hello,
>>
>> here's a PR for a patch submitted on March 2020
>> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was
>> a thing.
>>
>> The patch has been edited to adhere to OpenJDK code conventions about
>> multi-
On Thu, 8 Apr 2021 21:12:21 GMT, Raffaello Giulietti
wrote:
> Hello,
>
> here's a PR for a patch submitted on March 2020
> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a
> thing.
>
> The patch has been edited to adhere to OpenJDK code conventions about
> multi
On Thu, 8 Apr 2021 21:12:21 GMT, Raffaello Giulietti
wrote:
> Hello,
>
> here's a PR for a patch submitted on March 2020
> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a
> thing.
>
> The patch has been edited to adhere to OpenJDK code conventions about
> multi
On Thu, 8 Apr 2021 21:12:21 GMT, Raffaello Giulietti
wrote:
> Hello,
>
> here's a PR for a patch submitted on March 2020
> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a
> thing.
>
> The patch has been edited to adhere to OpenJDK code conventions about
> multi
On Thu, 8 Apr 2021 21:12:21 GMT, Raffaello Giulietti
wrote:
> Hello,
>
> here's a PR for a patch submitted on March 2020
> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a
> thing.
>
> The patch has been edited to adhere to OpenJDK code conventions about
> multi
67 matches
Mail list logo
