Stuart, Thanks for all the details.
All you have said makes sense to me, I have no contention for closing this
issue as Won't Fix (am not related to originator, picked this issue up as
starters to understand the contribution process)
Regards!
Jay
-Stuart Marks wrote: -
To:
Thanks for the review comment Stuart. Yes, I will need a sponsor, this is my
first time here in OpenJDK.
Regards!
Jay
-Stuart Marks wrote: -
To: Jayashree Sk1
From: Stuart Marks
Date: 04/30/2020 09:22AM
Cc: core-libs-dev@openjdk.java.net
Subject: [EXTERNAL] Re: RFR: 6415694
The bug report states that this method specification describes implementation
details, with the implication that implementation details should be avoided and
that abstract specifications (contracts or invariants) should be provided
instead. The alternative wording from the bug report removes
The change looks fine. Although this is in a normative portion of the
specification, the nature of the change is purely editorial, so I don't think it
needs a CSR.
Do you need a sponsor?
s'marks
On 4/29/20 2:57 AM, Jayashree Sk1 wrote:
Hi All,
Please find the below changes for the
Hi Dmytro,
Callers of an API performing explicit synchronization, along with the
synchronized collections wrappers, have mostly fallen into disuse since the
introduction of the java.util.concurrent collections.
Multiple threads can either interact directly on a concurrent collection, or the
LGTM
Vyom
On Thu, Apr 30, 2020 at 3:50 AM wrote:
> Hello,
>
> Please review this small fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8244152
>
> The proposed changeset is located at:
>
> https://cr.openjdk.java.net/~naoto/8244152/webrev.00/
>
> The hash map used there
On 4/29/20 10:23 PM, Maurizio Cimadamore wrote:
Many thanks Peter,
my preference would be for adding the benchmark now, and come back to
fix this post integration. The MemoryScope code is finicky and getting
confidence that the code is race-free takes time and I'd prefer not to
change that
+1
-Joe
On 4/29/2020 3:18 PM, naoto.s...@oracle.com wrote:
Hello,
Please review this small fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8244152
The proposed changeset is located at:
https://cr.openjdk.java.net/~naoto/8244152/webrev.00/
The hash map used there
On 4/29/20 11:16 PM, Maurizio Cimadamore wrote:
On 29/04/2020 21:40, Maurizio Cimadamore wrote:
On 29/04/2020 08:10, Peter Levart wrote:
Right, as you saw in a private Email, I did exactly that in a
revised version (posted below). The spurious ISE may happen but only
when close is called
On 4/29/20 2:30 PM, fo...@univ-mlv.fr wrote:
I think the problem with perf might be caused by the fact that while the
array is now a constant, the elements are not (the array is mutable
after all). For fields you can fix this by using @Stable, but not for CP
entries :)
I think you're right,
On 4/29/20 2:07 AM, Simone Bordet wrote:
Did you get any exception in 14? Is it from findVirtual or from in?
From findVirtual():
Exception in thread "main" java.lang.IllegalAccessException: no such
method: org.module1.MyEndPoint.onMessage(MyString)void/invokeVirtual
at
Hello,
Please review this small fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8244152
The proposed changeset is located at:
https://cr.openjdk.java.net/~naoto/8244152/webrev.00/
The hash map used there didn't have initial capacity, even though the
exact numbers are
Background on this can be found here:
https://bugs.openjdk.java.net/browse/JDK-4335520
Jason
From: core-libs-dev on behalf of
dmytro sheyko
Sent: Wednesday, April 29, 2020 2:58 AM
To: core-libs-dev
Subject: Collections.synchronizedXXX() and internal
- Mail original -
> De: "Jorn Vernee"
> À: "Maurizio Cimadamore" , "mandy chung"
> , "Remi Forax"
>
> Cc: "core-libs-dev"
> Envoyé: Mercredi 29 Avril 2020 22:09:47
> Objet: Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second
> Incubator)
> Hi,
Hi Jorn,
>
> I think
- Mail original -
> De: "Maurizio Cimadamore"
> À: "mandy chung" , "Remi Forax"
> Cc: "core-libs-dev"
> Envoyé: Mercredi 29 Avril 2020 03:13:35
> Objet: Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second
> Incubator)
> On 28/04/2020 21:44, Maurizio Cimadamore
On 29/04/2020 21:40, Maurizio Cimadamore wrote:
On 29/04/2020 08:10, Peter Levart wrote:
Right, as you saw in a private Email, I did exactly that in a revised
version (posted below). The spurious ISE may happen but only when
close is called prematurely relative to all child scope close(s)
Looks good.
- Alexey
On 4/29/2020 2:36 PM, Andy Herrick wrote:
I don't think I sent out webrev.5 [6] fixing Alexander's points below.
Please Review:
[6] http://cr.openjdk.java.net/~herrick/8219536/webrev.05/index.html
/Andy
On 4/23/2020 7:59 PM, Alexander Matveev wrote:
Hi Andy,
Hi Andy,
Looks fine.
Thanks,
Alexander
On 4/29/20 11:36 AM, Andy Herrick wrote:
I don't think I sent out webrev.5 [6] fixing Alexander's points below.
Please Review:
[6] http://cr.openjdk.java.net/~herrick/8219536/webrev.05/index.html
/Andy
On 4/23/2020 7:59 PM, Alexander Matveev wrote:
Hi Andy,
http://cr.openjdk.java.net/~herrick/8244018/webrev.01/src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/internal/resources/MainResources_ja.properties.frames.html
On 29/04/2020 08:10, Peter Levart wrote:
Right, as you saw in a private Email, I did exactly that in a revised
version (posted below). The spurious ISE may happen but only when
close is called prematurely relative to all child scope close(s) that
were or are still active. So we could say the
Many thanks Peter,
my preference would be for adding the benchmark now, and come back to
fix this post integration. The MemoryScope code is finicky and getting
confidence that the code is race-free takes time and I'd prefer not to
change that during the course of this RFR.
Your approach
Hi,
I think the problem with perf might be caused by the fact that while the
array is now a constant, the elements are not (the array is mutable
after all). For fields you can fix this by using @Stable, but not for CP
entries :)
I think what could work is; rather than ldc'ing the array, and
Hi Maurizio,
On 4/29/20 2:41 AM, Maurizio Cimadamore wrote:
The current implementation has performances that are on par with the
previous acquire-based implementation, and also on par with what can
be achieved with Unsafe. We do have a micro benchmark in the patch
(see ParallelSum (**)) which
On 4/28/20 9:48 PM, Jason Mehrens wrote:
Looks like It is intentional that unmodifiable queues are not present. See:
https://bugs.openjdk.java.net/browse/JDK-5030930. The same logic would have
been used for when Deque was added in the following release.
Good find.
Looking at the Queue
I don't think I sent out webrev.5 [6] fixing Alexander's points below.
Please Review:
[6] http://cr.openjdk.java.net/~herrick/8219536/webrev.05/index.html
/Andy
On 4/23/2020 7:59 PM, Alexander Matveev wrote:
Hi Andy,
Hi Fernando,
Thanks for adding coverage to this API. The change looks good overall. A
couple of comments to the test:
Line 39 instead of LocalPart, it may be better to verify the QName
themselves, I mean, assert the QNames are equal.
Line 19-21: the comment block can be moved to a @summary
On 27/04/2020 19:19, Kiran Ravikumar wrote:
> Hi Martin and Andrew,
>
>
> Thanks for the review and providing a direction towards updating the
> translations.
>
>
> Here is an updated webrev with the changes:
>
> http://cr.openjdk.java.net/~kravikumar/8243541/webrev/
>
>
> All associated
Please review fix at [1] for issue [2]
The change just adds error when specified icon is not found, and a test
for that.
/Andy
[1] - http://cr.openjdk.java.net/~herrick/8244018/webrev.01/
[2] - https://bugs.openjdk.java.net/browse/JDK-8244018
Serguei, David,
thanks for your reviews. pushed.
-- Igor
> On Apr 28, 2020, at 11:39 PM, serguei.spit...@oracle.com wrote:
>
> LGTM++
>
> Thanks,
> Serguei
>
>
> On 4/28/20 23:28, David Holmes wrote:
>> Looks good!
>>
>> Thanks,
>> David
>>
>> On 29/04/2020 1:20 pm, Igor Ignatyev wrote:
Hi Stefan,
I've already pushed it (right after Ioi reviewed it), nevertheless I appreciate
you reviewing it.
-- Igor
> On Apr 28, 2020, at 11:11 PM, Stefan Karlsson
> wrote:
>
> Looks good.
>
> StefanK
>
> On 2020-04-29 06:41, Igor Ignatyev wrote:
>>
Hi all,
Please, review the following change:
webrev: http://cr.openjdk.java.net/~joehw/jdk15/8183266/webrev/
bug: https://bugs.openjdk.java.net/browse/JDK-8183266
Change details:
- Added test coverage for XPathEvaluationResult.XPathResultType.getQNameType
method
- Added type check for the
Hi All,
Please find the below changes for the issues
https://bugs.openjdk.java.net/browse/JDK-6415694.
It is a description change, which was already approved by the reviewer.
Thanks!
diff -r 59b5bd9a7168
src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java
---
Hi All,
Please find the below changes for the issues
https://bugs.openjdk.java.net/browse/JDK-7147994
It is a description change, which was already approved by the reviewer.
Thanks!
diff -r 59b5bd9a7168 src/java.base/share/classes/java/util/Hashtable.java
---
Hi,
On Tue, Apr 28, 2020 at 7:34 PM Mandy Chung wrote:
> endPointClass is in unnamed module and so it's unconditionally exported. The
> public lookup should be able to find public members from it.One thing to
> double check if endPointClass is publicly accessible?
It is.
> Did you get
Hello,
Have you ever discussed to make field mutex in synchronized collections
accessible?
Javadoc for Collections#synchronizedSortedSet suggest to iterate collection
this way:
SortedSet s = Collections.synchronizedSortedSet(new TreeSet());
SortedSet s2 = s.headSet(foo);
...
> De: "mandy chung"
> À: "Remi Forax"
> Cc: "Maurizio Cimadamore" , "core-libs-dev"
>
> Envoyé: Mardi 28 Avril 2020 20:09:07
> Objet: Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second
> Incubator)
> On 4/28/20 12:58 AM, [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.fr ] wrote:
On 4/29/20 2:41 AM, Maurizio Cimadamore wrote:
On 28/04/2020 21:27, Peter Levart wrote:
Hi,
The problem with current implementation of MemoryScope is that if a
child scope is frequently acquired and closed (which increments and
then decrements the parent scope counter atomically using
LGTM++
Thanks,
Serguei
On 4/28/20 23:28, David Holmes wrote:
Looks good!
Thanks,
David
On 29/04/2020 1:20 pm, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8244052/webrev.00/
34 lines changed: 0 ins; 11 del; 23 mod;
Hi all,
could you please review this trivial patch?
from
Looks good!
Thanks,
David
On 29/04/2020 1:20 pm, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8244052/webrev.00/
34 lines changed: 0 ins; 11 del; 23 mod;
Hi all,
could you please review this trivial patch?
from JBS:
JDK-8199290 made it unnecessary to explicitly pass
Looks good.
StefanK
On 2020-04-29 06:41, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8244066/webrev.00
16 lines changed: 0 ins; 0 del; 16 mod;
Hi all,
could you please review this trivial cleanup in tests?
from JBS:
ClassFileInstaller is a test utility class which copies
40 matches
Mail list logo
