On Tue, 8 Sep 2020 19:44:21 GMT, Roger Riggs wrote:
>> 8252830: Correct missing javadoc comments in java.rmi module
>
> Roger Riggs has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Added java.io.Serial to java.rmi.activation.ActivationID
Ma
On Wed, 9 Sep 2020 06:25:40 GMT, Aleksey Shipilev wrote:
>> rgiulietti has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8238669: Long.divideUnsigned is extremely slow for certain values (Needs
>> to be Intrinsic)
>>
>> Added helpful
Hello
I started working on 8138732 [2] as described in the issue [1]. However
the question about the impact and coordination with other projects came
up, eg.:
- projects that implement their own intrinsics
- Graal
- somebody else?
How do we want to address this and coordinate with these proj
[JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the
jdk.internal.lambda.disableEagerInitialization system property to be able to
disable eager initialization of lambda
classes. This was necessary to prevent side effects of class initializers
triggered by such initializa
On 09/09/2020 09:27, Philippe Marschall wrote:
Hello
I started working on 8138732 [2] as described in the issue [1]. However
the question about the impact and coordination with other projects came
up, eg.:
- projects that implement their own intrinsics
- Graal
- somebody else?
How do we wan
> Hello, newbie here
>
> I picked JDK-8138732 to work on because it has a "starter" label and I
> believe I understand what to do.
>
> - I tried to update the copyright year to 2020 in every file.
> - I decided to change `@since` from 9 to 16 since it is a new annotation name
> in a new package
On Wed, 9 Sep 2020 08:18:11 GMT, Gilles Duboscq wrote:
> [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the
> jdk.internal.lambda.disableEagerInitialization system property to be able to
> disable eager initialization of lambda
> classes. This was necessary to prevent
Hi Paul,
Thanks a lot for the feedback. I've waited a bit before tackling your
feedback to see if others would provide further feedback.
Not yet able to create webrevs (not yet author), so I've gone ahead and
created a PR with the updated changes [6].
Basically, I've moved the fence to `initiali
On Wed, 9 Sep 2020 07:24:57 GMT, Chris Hegarty wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added java.io.Serial to java.rmi.activation.ActivationID
>
> Marked as reviewed by chegar (Reviewer).
Hi Stuart,
I'm g
On Tue, 8 Sep 2020 15:59:33 GMT, Ioi Lam wrote:
> This is the same patch as
> [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/)
> published in
> [hotspot-runtime-...@openjdk.java.net](https://mail.openjdk.java.net/pipermail/hot
On Wed, 9 Sep 2020 08:18:11 GMT, Gilles Duboscq wrote:
> [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the
> jdk.internal.lambda.disableEagerInitialization system property to be able to
> disable eager initialization of lambda
> classes. This was necessary to prevent
On Wed, 9 Sep 2020 12:19:04 GMT, Jan Lahoda wrote:
>> [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced
>> the
>> jdk.internal.lambda.disableEagerInitialization system property to be able to
>> disable eager initialization of lambda
>> classes. This was necessary to pre
On Wed, 9 Sep 2020 08:18:11 GMT, Gilles Duboscq wrote:
> [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the
> jdk.internal.lambda.disableEagerInitialization system property to be able to
> disable eager initialization of lambda
> classes. This was necessary to prevent
On Mon, Sep 7, 2020 at 7:54 PM Alan Bateman wrote:
>
> On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall
> wrote:
>
> > Hello, newbie here
> >
> > I picked JDK-8138732 to work on because it has a "starter" label and I
> > believe I understand what to do.
> >
> > - I tried to update the copyri
On Tue, 8 Sep 2020 15:59:33 GMT, Ioi Lam wrote:
> This is the same patch as
> [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/)
> published in
> [hotspot-runtime-...@openjdk.java.net](https://mail.openjdk.java.net/pipermail/hot
On 9/4/20 8:07 AM, Roger Riggs wrote:
Hi Corey,
The idea I had in mind is refactoring the fast path into the method you
call decodeBlock.
Base64: lines 751-768.
It leaves all the unknown/illegal character handling to the Java code.
And yes, it does not need to handle MIME, except to return on
Hi Roger,
Thanks for your question. The code path for UTF16 has hasn't been interacted
with in a meaningful way in this patch so I think this is just noise. To
validate this hypothesis I re-ran the benchmark with 10 forks (default is 5),
the results indicate that the performance of the UTF16 im
Updated @exception with @throws for core-libs, it fixes all open sub-tasks of
JDK-8252536.
Open Subtasks part of this fix are:
1. JDK-8252537
2. JDK-8252539
3. JDK-8252540
4. JDK-8252541
-
Commit messages:
- JDK-8252537 Updated @exception with @throws
Changes: https://git.openjdk.
`jlink --generate-jli-classes` plugin should retain the original holder classes
if the default_jli_trace.txt
file does not exist.
Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes`
methods are invoked
unconditionally and therefore the holder classes are "regenerated" when
Hi Corey,
Right, the continue was so it would go back and check if the conversion was
complete. An alternative would be to repeat the check and return if
there was
no bytes left to process.
Thanks, Roger
On 9/9/20 3:13 PM, Corey Ashford wrote:
On 9/4/20 8:07 AM, Roger Riggs wrote:
Hi Core
Hi Jason,
Thanks for checking, the difference of the utf16 numbers seemed to be
just outside of the error range.
Regards, Roger
On 9/9/20 3:17 PM, Tatton, Jason wrote:
Hi Roger,
Thanks for your question. The code path for UTF16 has hasn't been interacted
with in a meaningful way in this p
> This is the same patch as
> [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/)
> published in
> [hotspot-runtime-...@openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041496.html).
> The r
On Wed, 9 Sep 2020 18:41:25 GMT, Lois Foltan
wrote:
>> Ioi Lam has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes
>> the unrelated changes brought in by the merge/rebase. The pull request
>> contains six additional commits since t
On Wed, 9 Sep 2020 19:38:38 GMT, Mandy Chung wrote:
> `jlink --generate-jli-classes` plugin should retain the original holder
> classes if the default_jli_trace.txt
> file does not exist.
>
> Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes`
> methods are invoked
> unco
> This is the same patch as
> [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/)
> published in
> [hotspot-runtime-...@openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041496.html).
> The r
On Tue, 8 Sep 2020 17:32:44 GMT, Coleen Phillimore wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Feedback from Coleen
>
> src/hotspot/share/classfile/classLoaderDataShared.cpp line 171:
>
>> 169: }
>> 170:
>> 171: vo
On Wed, 9 Sep 2020 19:38:38 GMT, Mandy Chung wrote:
> `jlink --generate-jli-classes` plugin should retain the original holder
> classes if the default_jli_trace.txt
> file does not exist.
>
> Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes`
> methods are invoked
> unco
On Wed, 9 Sep 2020 18:46:33 GMT, Lois Foltan
wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Feedback from Coleen
>
> Thanks Ioi for addressing my review comments. Overall, looks great!
Ok thanks! So many emails ..
Revert changes made by JDK-8249643, removing the implNote.
-
Commit messages:
- 8251495: Clarify DOM documentation
Changes: https://git.openjdk.java.net/jdk/pull/100/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=100&range=00
Issue: https://bugs.openjdk.java.net/brow
On Wed, 9 Sep 2020 22:56:14 GMT, Joe Wang wrote:
> Revert changes made by JDK-8249643, removing the implNote.
Based on the spec review and follow-on discussions, this change makes sense
-
Marked as reviewed by lancea (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/100
Hi Sergey,
Unsafe.allocateUninitializedArray should be used with great care, so as we are
confident that no array, covering uninitialized memory, leaks out. Or later we
unintentionally introduce a problem through refactoring.
The update to AbstractStringBuilder is problematic because the unini
On 9/9/20 2:04 PM, Roger Riggs wrote:
Hi Corey,
Right, the continue was so it would go back and check if the conversion
was
complete. An alternative would be to repeat the check and return if
there was
no bytes left to process.
Another issue I just discovered is that the way the loop is s
On Wed, 9 Sep 2020 23:15:58 GMT, Lance Andersen wrote:
>> Revert changes made by JDK-8249643, removing the implNote.
>
> Based on the spec review and follow-on discussions, this change makes sense
An implNote was added to the DOM's package description in an attempt to
document the JDK implement
On Wed, 9 Sep 2020 22:56:14 GMT, Joe Wang wrote:
> Revert changes made by JDK-8249643, removing the implNote.
Marked as reviewed by smarks (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/100
On Wed, 9 Sep 2020 22:56:14 GMT, Joe Wang wrote:
> Revert changes made by JDK-8249643, removing the implNote.
Looks good.
-
Marked as reviewed by naoto (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/100
Could someone please help review this RFE?
Enhance default JDK providers except SunPKCS11 with signatures using SHA-3
family of digests. SunPKCS11 provider will
be updated separately (JDK-8242332).
This changes covers SUN, SunRsaSign, and SunEC providers. Changes are
straightforward, just add S
On Wed, 9 Sep 2020 19:38:38 GMT, Mandy Chung wrote:
> `jlink --generate-jli-classes` plugin should retain the original holder
> classes if the default_jli_trace.txt
> file does not exist.
>
> Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes`
> methods are invoked
> unco
On Wed, 9 Sep 2020 22:56:14 GMT, Joe Wang wrote:
> Revert changes made by JDK-8249643, removing the implNote.
Marked as reviewed by alanb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/100
38 matches
Mail list logo
