Looks good.
Thanks Kim!
David
-
On 14/03/2019 9:02 am, Kim Barrett wrote:
On Mar 13, 2019, at 4:29 PM, Kim Barrett wrote:
On Mar 13, 2019, at 4:07 PM, Kim Barrett wrote:
Please review this change to the JNI specification. The specified
behavior of Weak Global References, and in parti
Hi Stuart!
On 3/13/19 5:45 PM, Stuart Marks wrote:
On 3/12/19 4:32 PM, Ivan Gerasimov wrote:
If there were two new subtypes of Iterable introduced: IterableOnce
and IterableMultipleTimes, then all existing Iterables could be
retrofitted to implement one of these.
It wouldn't *automaticall
+1 (on the security class).
Thanks,
Max
> On Mar 14, 2019, at 1:10 AM, Lance Andersen wrote:
>
> +1
>> On Mar 13, 2019, at 1:04 PM, Chris Hegarty wrote:
>>
>> Trivially, there should be a comma after the year. Just add it.
>>
>>
>> $ hg diff src/java.base/share/classes/jdk/ src/java.base/sh
Why not Reference.reachabilityFence ?
On 3/5/19 12:43 PM, Mike Duigou wrote:
I don't believe that I would use the proposed enhancement to the for statement.
For me there is cognitive load reduction in using a symmetrical method for all
iterations even if they end up being a little more complicated for individual
cases. Usually,
On 3/12/19 4:32 PM, Ivan Gerasimov wrote:
If there were two new subtypes of Iterable introduced: IterableOnce and
IterableMultipleTimes, then all existing Iterables could be retrofitted to
implement one of these.
It wouldn't *automatically* solve the problem of 3rd party API, which accepts
Hi Goetz,
Roger, Coleen, Maurizio and I talked about this proposed feature.
We all think that improving NPE message is a useful enhancement for
the platform and helps developers to tell what causes NPE.
This is not a small enhancement. Diving into a large code review
would not be the best way t
> On Mar 13, 2019, at 6:19 PM, Hans Boehm wrote:
>
> Looks great to me!
Thanks.
> Just to be clear, this is intended to guarantee that it's not possible to
> promote a weak global reference that indirectly points to A after a
> PhantomReference or a WeakGlobalReference to A has been cleared?
> On Mar 13, 2019, at 5:32 PM, Per Liden wrote:
>
>
> On 03/13/2019 09:29 PM, Kim Barrett wrote:
>>> On Mar 13, 2019, at 4:07 PM, Kim Barrett wrote:
>>>
>>> Please review this change to the JNI specification. The specified
>>> behavior of Weak Global References, and in particular their
>>> re
> On Mar 13, 2019, at 5:00 PM, Mandy Chung wrote:
>
>
>
> On 3/13/19 1:29 PM, Kim Barrett wrote:
>>> On Mar 13, 2019, at 4:07 PM, Kim Barrett wrote:
>>>
>>> Please review this change to the JNI specification. The specified
>>> behavior of Weak Global References, and in particular their
>>> r
> On Mar 13, 2019, at 4:29 PM, Kim Barrett wrote:
>
>> On Mar 13, 2019, at 4:07 PM, Kim Barrett wrote:
>>
>> Please review this change to the JNI specification. The specified
>> behavior of Weak Global References, and in particular their
>> relationship to Java PhantomReference, is being updat
Hi,
Please review my test-only fix for 8220088[1]. Along with fixing the
issue, I've also converted this .sh test to .java.
Webrev is here:
http://cr.openjdk.java.net/~bchristi/8220088/webrev.00/
The test does the following:
1. sets up a classloader and loads class "C" into a WeakReference
2
Looks great to me!
Just to be clear, this is intended to guarantee that it's not possible to
promote a weak global reference that indirectly points to A after a
PhantomReference or a WeakGlobalReference to A has been cleared? Thus this
reference clearing must happen more or less atomically.
I thi
Donald,
While it was reasonable to raise the spec issues on core-libs-dev,
any/all questions about
javac code should be addressed to compiler-...@openjdk.java.net.
That being said,
* any comment labelled "// TODO" in new code seems questionable
* the copyright date on the test is wrong and
Attached patch with tests so first the bug for java11 can be fixed and
backported.
Would be nice if someone can guide me how to continue with this and/or
can reply on my previous questions.
Op di 5 mrt. 2019 om 07:11 schreef Donald Kwakkel :
>
> > On 02/28/2019 01:06 PM, Alan Bateman wrote:
> > >
On 03/13/2019 09:29 PM, Kim Barrett wrote:
On Mar 13, 2019, at 4:07 PM, Kim Barrett wrote:
Please review this change to the JNI specification. The specified
behavior of Weak Global References, and in particular their
relationship to Java PhantomReference, is being updated to account
for a ch
On 3/13/19 1:29 PM, Kim Barrett wrote:
On Mar 13, 2019, at 4:07 PM, Kim Barrett wrote:
Please review this change to the JNI specification. The specified
behavior of Weak Global References, and in particular their
relationship to Java PhantomReference, is being updated to account
for a chang
> On Mar 13, 2019, at 4:07 PM, Kim Barrett wrote:
>
> Please review this change to the JNI specification. The specified
> behavior of Weak Global References, and in particular their
> relationship to Java PhantomReference, is being updated to account
> for a change to PhantomReference by JDK-807
Please review this change to the JNI specification. The specified
behavior of Weak Global References, and in particular their
relationship to Java PhantomReference, is being updated to account
for a change to PhantomReference by JDK-8071507.
CR:
https://bugs.openjdk.java.net/browse/JDK-8188066
C
Hi Daniel,
> On Mar 13, 2019, at 3:05 PM, Daniel Fuchs wrote:
>
> Hi Lance,
>
> http://cr.openjdk.java.net/~lancea/8220252/webrev.00/src/java.naming/share/classes/javax/naming/ldap/LdapContext.java.frames.html
>
> It looks like
> 78 * Context Request Controls
> 100 * Connection Request Contro
Hi Lance,
http://cr.openjdk.java.net/~lancea/8220252/webrev.00/src/java.naming/share/classes/javax/naming/ldap/LdapContext.java.frames.html
It looks like
78 * Context Request Controls
100 * Connection Request Controls
136 * Service Provider Requirements
should be - it seems they are all
Hi all
Please review the fix for 8220252, to address the javadoc header issues [1] in
java.naming
The webrev can be found at:
http://cr.openjdk.java.net/~lancea/8220252/webrev.00/index.html
Best
Lance
[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html
Hi,
The test runs significantly slower on the fast debug build.
Release images build: 4 seconds
Fastdebug images build: 2.5 minutes
$.02, Roger
On 03/13/2019 10:45 AM, Alan Bateman wrote:
On 12/03/2019 17:30, Lance Andersen wrote:
Hi all,
Please review this addition to the ProblemList.tx
+1
> On Mar 13, 2019, at 1:04 PM, Chris Hegarty wrote:
>
> Trivially, there should be a comma after the year. Just add it.
>
>
> $ hg diff src/java.base/share/classes/jdk/ src/java.base/share/classes/sun
> diff --git a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
> b/src/ja
Hi Chris,
Looks good.
Roger
On 03/13/2019 01:04 PM, Chris Hegarty wrote:
Trivially, there should be a comma after the year. Just add it.
$ hg diff src/java.base/share/classes/jdk/ src/java.base/share/classes/sun
diff --git a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
Looks good to me Chris!
cheers,
-- daniel
On 13/03/2019 17:04, Chris Hegarty wrote:
Trivially, there should be a comma after the year. Just add it.
Trivially, there should be a comma after the year. Just add it.
$ hg diff src/java.base/share/classes/jdk/ src/java.base/share/classes/sun
diff --git a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
--- a/src/ja
Hi Pavel,
On 13/03/2019 16:35, Pavel Rappo wrote:
Using a bunch of Semaphores here seems a bit surprising. One more CountDownLatch
or CyclicBarrier *might* have been better. But I guess it's not of concern.
Agreed, but I won't change it. The reason is that I had a more
extensive version of the
Using a bunch of Semaphores here seems a bit surprising. One more CountDownLatch
or CyclicBarrier *might* have been better. But I guess it's not of concern.
For the diagnostic purposes I would add a newline between
t4.join(); t3.join();
since they throw exceptions. Otherwise looks good. Thanks
Hi Pavel,
On 13/03/2019 14:41, Pavel Rappo wrote:
After all if this group is
being destroyed, and this is the only call, then 0 would be a correct value,
wouldn't it?
It may only be the correct value if the input argument value n == 0.
As the @summary section says: the 3-args enumerate method
On 12/03/2019 17:30, Lance Andersen wrote:
Hi all,
Please review this addition to the ProblemList.txt as this tests times out
from time to time
I can't tell from the bug what analysis has been done but are these
timeouts always debug builds? If so then maybe you could use `@requires
vm.deb
> On 13 Mar 2019, at 14:22, Daniel Fuchs wrote:
>
> I don't think there is another bug in the 3-args enumerate
> methods.
I might not have expressed myself clearly. I'm not saying there is an extra bug
with the fix applied. What I'm saying is that without the fix, not only was the
value wrong bu
Hi Goetz,
For NullPointerException, I don't think you want writeReplace() to call a
public method that can be overridden. You probably should create a private
helper method that both getMessage and writeReplace() call into.
Jason
From: core-libs-dev o
Hi Pavel,
On 13/03/2019 14:02, Pavel Rappo wrote:
Might it be the case that not only the returned value is wrong, but also the
populated list is corrupted? After all the returned value is used as an index
for the next insertion.
I'm not sure what you mean by that.
I don't think there is anoth
Hi Daniel,
First of all, the change looks good to me. The broken
if (destroyed) {
return n;
}
part looks like a "copy and paste" from some other method in the ThreadGroup
class. They use recursion a lot.
Might it be the case that not only the returned value is wrong, but also the
popu
Daniel,
> On 13 Mar 2019, at 12:59, Daniel Fuchs wrote:
>
> Hi Christoph,
>
> On 13/03/2019 12:44, Langer, Christoph wrote:
>> In the test, you could remove the import java.util.Set; in line 36 and
>> List groups of line 74 is not needed as well.
>> BTW, as you are touching it,
>> src/java.ba
Hi Christoph,
On 13/03/2019 12:44, Langer, Christoph wrote:
In the test, you could remove the import java.util.Set; in line 36 and
List groups of line 74 is not needed as well.
BTW, as you are touching it,
src/java.base/share/classes/java/lang/ThreadGroup.java does not need the import
jdk.in
Hi Daniel,
the fix looks good to me.
In the test, you could remove the import java.util.Set; in line 36 and
List groups of line 74 is not needed as well.
BTW, as you are touching it,
src/java.base/share/classes/java/lang/ThreadGroup.java does not need the import
jdk.internal.misc.VM; in line
Hi Joe, Mandy,
Thanks for getting back to me.
Based on these responses, I'm forgoing the backport.
Will put this one on the backburner while we wait for the CSR to be
approved.
Best Regards
Adam Farley
IBM Runtimes
Joe Darcy wrote on 12/03/2019 03:32:43:
> From: Joe Darcy
> To: Mandy Ch
39 matches
Mail list logo
