Hi All
Could you please help to review code fix for JDK-8035388.
http://cr.openjdk.java.net/~tyan/JDK-8035388/webrev.00/
Description:
method inactiveObject in ActivationGroupImpl.java, release lock happen
before checkInactiveGroup. This makes groupInactive reset even before
next
Hi Everyone,
I'm working on the test bug
https://bugs.openjdk.java.net/browse/JDK-8035633, There are 4 tests (one
is in a closed test) failed due to NullPointerException.
All tests failed at similar places if (isWindows
ni.getDisplayName().contains(Teredo)), the root cause is the
On 25/02/2014 08:49, Eric Wang wrote:
Hi Everyone,
I'm working on the test bug
https://bugs.openjdk.java.net/browse/JDK-8035633, There are 4 tests
(one is in a closed test) failed due to NullPointerException.
All tests failed at similar places if (isWindows
*Pretext*
The reference implementation has strange behavior when there are nested
character classes involved.
This is described briefly in the bug report:
https://bugs.openjdk.java.net/browse/JDK-6609854
And also brought up again with more details on stackoverflow.com
John,
Thanks for review!
Updated webrev:
http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.02/
See my comments inline.
Also, integrated some pending cleanups (e.g. improved selectAlternative
detection).
Best regards,
Vladimir Ivanov
On 2/24/14 9:46 PM, John Rose wrote:
On Feb 20,
Hello, Core and AWT teams.
In AWT we have a lot of pending exception warnings which are now being fixed. A
big fraction of this warnings is about a pending JNI exception at a call to
JNU_Throw*.
Why don’t we add an env-ExceptionClear() call in the beginning of each
JNU_Throw function? It is
On 25/02/2014 10:31, Petr Pchelko wrote:
Hello, Core and AWT teams.
In AWT we have a lot of pending exception warnings which are now being fixed. A
big fraction of this warnings is about a pending JNI exception at a call to
JNU_Throw*.
Why don’t we add an env-ExceptionClear() call in the
Hi,
I know, this is too late, but I want to share my suggestion:
public T extends AccessibleObjectAnnotatedElement T reflectAs(Class?
super T expected, MethodHandles.Lookup lookup)
Member mr = reflectAs(Member.class, MethodHandles.lookup());
AnnotatedElement ae =
Hello, Alan.
I can see how this might be attractive but doesn't it mean you are
suppressing an important exception?
In case we’ve already got into the JNU_Throw we will throw a new exception and
override the original one anyway. However I agree that this might suppress the
warning for the
On 25/02/14 11:26, Petr Pchelko wrote:
Hello, Alan.
I can see how this might be attractive but doesn't it mean you are suppressing
an important exception?
In case we’ve already got into the JNU_Throw we will throw a new exception and
override the original one anyway. However I agree that
On Feb 25, 2014, at 1:32 AM, Brian Burkhalter brian.burkhal...@oracle.com
wrote:
On Feb 20, 2014, at 6:39 PM, David Holmes wrote:
Not clear what you mean by this.
This is more or less my reaction to this entire thread, so to speak. ;-)
Anyway, thanks for all the comments.
:-)
On Feb 25, 2014, at 12:52 AM, Brent Christian brent.christ...@oracle.com
wrote:
Please review my changes for:
https://bugs.openjdk.java.net/browse/JDK-8027640
The webrev is here:
http://cr.openjdk.java.net/~bchristi/8027640/webrev.00/
In AbstractStringBuilder there is a small typo, k:
In some cases, I would expect that the exception being overridden
would/should become the 'cause' of the new exception so it is not cleared
but chained. Does JNI support that?
On the original issue, discarding of exceptions should be explicit not
implicit.
Keep (or insert) the
Thank you Mike!
On 24.02.2014 22:26, Mike Duigou wrote:
On Feb 24 2014, at 06:37 , roger riggs roger.ri...@oracle.com wrote:
Hi Ivan,
The code is correct as written but there might be some creep in the end time
due to the sampling of System.nanoTime.
I would be inclined to calculate the
Thank you Mandy!
On 25.02.2014 2:11, Mandy Chung wrote:
On 2/23/14 9:59 PM, Ivan Gerasimov wrote:
Hello!
ReferenceQueue.remove(timeout) may return too early, i.e. before the
specified timeout has elapsed.
Would you please review the fix?
The change also includes a regression test, which
Couple rounds of emails had been exchanged internally regarding this
issue years
ago and a proposal had been briefly discussed at this list back to 2011 [1].
The only reason that hold us to just fix it is the compatibility
concern, since the
described behavior has been there for decade.
It
On 2/25/14 6:32 AM, Ivan Gerasimov wrote:
line 76: why do you want to catch InterruptedException? If
interrupted, should the test fail?
ReferenceQueue#remove() can throw InterruptedException, so I had to
handle it.
In the new webrev I set the initial value of actual to TIMEOUT, so if
the
Looks OK. Some minor comments:
- Some of the static fields in the test could be final (queue, weakReference,
startedSignal).
- After the join() loop in the test you could check that the weakReference is
cleared and enqueued.
- Why is the check thread.actual TIMEOUT only done if
On Feb 25, 2014, at 4:26 AM, Paul Sandoz wrote:
Might as well just remove the @Deprecated stuff. I think it is fine under the
circumstances to have offsets and getter methods that return the correct
values.
I have posted a new webrev taking this approach:
On Feb 20, 2014, at 1:42 AM, Paul Sandoz wrote:
Not sure the static powerCache field, in the original code, needs to be
volatile either:
1137 private static volatile BigInteger[][] powerCache;
Is there consensus on whether volatile is necessary here?
Thanks,
Brian
Hi Martin,
Yes, um, I agree. :-) Perhaps theere is some hope here:
http://openjdk.java.net/jeps/187
Which of course will avoid all the mistakes in the first version of
serialization. That will create room for bigger and better mistakes. :-)
And then of course there is this:
On 2/25/14 12:34 AM, Tristan Yan wrote:
Could you please help to review code fix for JDK-8035388.
http://cr.openjdk.java.net/~tyan/JDK-8035388/webrev.00/
Description:
method inactiveObject in ActivationGroupImpl.java, release lock happen before
checkInactiveGroup. This makes groupInactive
Thanks you Mike!
On 25.02.2014 22:47, Mike Duigou wrote:
Looks OK. Some minor comments:
- Some of the static fields in the test could be final (queue, weakReference,
startedSignal).
Done.
- After the join() loop in the test you could check that the weakReference is
cleared and enqueued.
I
Thank you Mandy!
On 25.02.2014 21:53, Mandy Chung wrote:
On 2/25/14 6:32 AM, Ivan Gerasimov wrote:
line 76: why do you want to catch InterruptedException? If
interrupted, should the test fail?
ReferenceQueue#remove() can throw InterruptedException, so I had to
handle it.
In the new webrev I
On 2/25/14 4:41 AM, Paul Sandoz wrote:
On Feb 25, 2014, at 12:52 AM, Brent Christian brent.christ...@oracle.com
wrote:
Please review my changes for:
https://bugs.openjdk.java.net/browse/JDK-8027640
The webrev is here:
http://cr.openjdk.java.net/~bchristi/8027640/webrev.00/
In
http://cr.openjdk.java.net/~vlivanov/8033666/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8033666
ValueConversions::castReference was introduced to workaround a problem
with unreliable inlining of Class::cast method. Unfortunately, since
ValueConversions class is located in
Looks good.
While touching the code some time ago John and I were playing around with the
idea to call Class.cast in the failing case:
+ static T,U T castReference(Class? extends T t, U x) {
+ // inlined Class.cast because we can't ForceInline it
+ if (x != null
On Feb 25, 2014, at 5:17 PM, Christian Thalinger
christian.thalin...@oracle.com wrote:
While touching the code some time ago John and I were playing around with the
idea to call Class.cast in the failing case:
+ static T,U T castReference(Class? extends T t, U x) {
+ //
On Feb 25, 2014, at 4:16 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
As an interim fix, I moved castReference method into
java.lang.invoke.MethodHandleImpl class and added new entry point
ValueConversions::cast which accepts a method handle to a method which
should be used for
Hi Ivan,
143 long start = (timeout == 0) ? 0 : System.nanoTime();
This can simply be:
143 long start = System.nanoTime();
If timeout==0 then you will never execute the code that even looks at start.
Cheers,
David
On 26/02/2014 7:46 AM, Ivan Gerasimov wrote:
Thank
Thanks David!
On 26.02.2014 8:44, David Holmes wrote:
Hi Ivan,
143 long start = (timeout == 0) ? 0 : System.nanoTime();
This can simply be:
143 long start = System.nanoTime();
If timeout==0 then you will never execute the code that even looks at
start.
That's
On 2/25/2014 1:46 PM, Ivan Gerasimov wrote:
line 61: I think the test should be:
if (thread.reference != null || thread.actual TIMEOUT)
Sorry, I'm not clear why.
We have two threads:
1) The lucky one gets non-null reference when it calls remove(). For
this thread the actual time it
On 26.02.2014 10:19, Mandy Chung wrote:
On 2/25/2014 1:46 PM, Ivan Gerasimov wrote:
line 61: I think the test should be:
if (thread.reference != null || thread.actual TIMEOUT)
Sorry, I'm not clear why.
We have two threads:
1) The lucky one gets non-null reference when it calls
33 matches
Mail list logo
