Thank you for fixing JDK-8023541. Then I leave ActivationLibrary.java
for now.
I still did some clean up following your suggestion.
1. I changed waitFor(long timeout) method, this method is going to use
code like Process.waitFor(timeout, unit). This can be backported to
JDK7. Also exitValue is
On Jan 31, 2014, at 1:58 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8033278/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8033278
The fix for 8032585 [1] introduced a regression: in some cases access check
on a reference class is
Changeset: 9f098aed44c0
Author:anazarov
Date: 2014-01-31 12:01 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f098aed44c0
8032025: Update repeating annotations demo
Reviewed-by: jfranck
+
src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Device.java
Hi Philip,
Am 27.01.2014 02:12, schrieb Philip Hodges:
Please please please drop StringJoiner from Java 1.8 before it is too late.
I have not seen any technical justifications whatsoever so far, just
inexplicable enthusiasm.
It is like giving young drivers a faster car with no seat belts.
On Jan 30, 2014, at 11:02 PM, Stuart Marks stuart.ma...@oracle.com wrote:
Maybe. I'd guess that the new JMM will stick to covering well-behaved
programs (e.g. ones that adhere to safe publication). The difficulty with
issues like this one is that once publication has occurred unsafely, we
On 01/31/2014 08:32 AM, Paul Sandoz wrote:
On Jan 30, 2014, at 11:02 PM, Stuart Marks stuart.ma...@oracle.com wrote:
Maybe. I'd guess that the new JMM will stick to covering well-behaved programs
(e.g. ones that adhere to safe publication). The difficulty with issues like
this one is that
Paul,
The transformation you suggest is equivalent, but I reluctant to apply
it. IMO, it doesn't add much value and current version is easier to
read. Considering the current level of complexity in
VA.isMemberAccessible I don't want to increase it even further :-)
Best regards,
Vladimir
On Jan 31, 2014, at 3:21 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Paul,
The transformation you suggest is equivalent, but I reluctant to apply it.
IMO, it doesn't add much value and current version is easier to read.
OK, i guess we will just have to agree to disagree on
Trivial change to CopyOnWriteArrayList.COWSubList.subList to catch the
case where the fromIndex is greater that the toIndex.
http://cr.openjdk.java.net/~chegar/8011645/webrev.00/webrev/
-Chris.
On Jan 31, 2014, at 5:23 PM, Chris Hegarty chris.hega...@oracle.com wrote:
Trivial change to CopyOnWriteArrayList.COWSubList.subList to catch the case
where the fromIndex is greater that the toIndex.
http://cr.openjdk.java.net/~chegar/8011645/webrev.00/webrev/
Looks ok to me.
--
Shame
Changeset: f684c9773858
Author:vlivanov
Date: 2014-01-31 21:07 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f684c9773858
8033278: Missed access checks for Lookup.unreflect* after 8032585
Reviewed-by: jrose, twisti
! src/share/classes/sun/invoke/util/VerifyAccess.java
!
Thanks Martin and Chris!
-Doug
On 01/31/2014 01:01 PM, Martin Buchholz wrote:
jsr166 CVS is now updated with this fix, and also adds some missing tck tests.
Index: src/jdk7/java/util/concurrent/CopyOnWriteArrayList.java
===
RCS
Thanks I’ll update the test before pushing.
I know you have tests in the TCK for this now, but I’ll add the trivial jtreg
test to OpenJDK to ensure this doesn’t creep back.
-Chris.
On 31 Jan 2014, at 18:07, Martin Buchholz marti...@google.com wrote:
The jtreg test is fine, but:
Please review a typo and javadoc cleanup for java.util.Date
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-date-typo-8032221/
Thanks, Roger
On 01/31/2014 10:33 AM, roger riggs wrote:
Please review a typo and javadoc cleanup for java.util.Date
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-date-typo-8032221/
Thanks, Roger
Looks good Roger.
Cheers,
-Joe
trancate - truncate . Other cleanups look good too.
-Chris.
On 31 Jan 2014, at 18:33, roger riggs roger.ri...@oracle.com wrote:
Please review a typo and javadoc cleanup for java.util.Date
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-date-typo-8032221/
Thanks, Roger
looks fine. getting rid of tt and code, is something I guess we should
look to do throughout all of our code?
On Jan 31, 2014, at 1:33 PM, roger riggs wrote:
Please review a typo and javadoc cleanup for java.util.Date
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-date-typo-8032221/
Forwarding to correct core-libs-dev list.
-Chris.
On 31 Jan 2014, at 14:22, Chris Hegarty chris.hega...@oracle.com wrote:
Hi Robert,
I think your patch can be split into two logical, independent, parts. The
first is the use of unsafe to access the String UTF length. The seconds is to
Forwarding for correct core-libs-dev list.
-Chris.
On 31 Jan 2014, at 15:26, Robert Stupp sn...@gmx.de wrote:
Hi Chris,
fine. I'm a bit proud that my 5ct help to improve JDK9 :)
The primitive buffer array size rounding was there to reduce the number of
re-allocations when a class
On 1/31/14 10:46 AM, Chris Hegarty wrote:
I think your patch can be split into two logical, independent, parts. The
first is the use of unsafe to access the String UTF length. The seconds is
to reuse, where possible, the existing StringBuilder instances, skipping of
primitive/object
Looks good.
On Jan 30, 2014, at 4:58 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8033278/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8033278
The fix for 8032585 [1] introduced a regression: in some cases access
check on a reference
Chris, thank you.
Best regards,
Vladimir Ivanov
On 1/31/14 11:22 PM, Christian Thalinger wrote:
Looks good.
On Jan 30, 2014, at 4:58 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8033278/webrev.00/
On 31 Jan 2014, at 19:07, Stuart Marks stuart.ma...@oracle.com wrote:
On 1/31/14 10:46 AM, Chris Hegarty wrote:
I think your patch can be split into two logical, independent, parts. The
first is the use of unsafe to access the String UTF length. The seconds is
to reuse, where possible, the
Martin,
Unifying the List testing code might be kind of tricky with
https://bugs.openjdk.java.net/browse/JDK-4506427 as unresolved.
http://docs.oracle.com/javase/7/docs/api/java/util/List.html
http://docs.oracle.com/javase/7/docs/api/java/util/AbstractList.html The patch
looks good though.
On Jan 31 2014, at 11:50 , Martin Buchholz marti...@google.com wrote:
Jason,
Thanks for pointing that out. I'm sure I have seen those bugs before (when
I owned them!) but had suppressed the memory.
I'm currently the assignee for this bug.
I probably didn't try fixing them because there is
Seems like good changes.
ObjectStreamClass.java::
- Why not have getClassSignature() return an interned string? (that's if
interning is actually essential. Are we sure it's not just overhead?)
On Jan 31 2014, at 10:46 , Chris Hegarty chris.hega...@oracle.com wrote:
Forwarding to correct
On 01/31/2014 10:44 AM, Lance Andersen - Oracle wrote:
looks fine. getting rid of tt and code, is something I guess we should
look to do throughout all of our code?
Yes :-)
In the core libraries, Jason did some bulk conversions along those lines
in JDK 8:
JDK-8017324 Cleanup of the
On Jan 31 2014, at 15:09 , Jason Mehrens jason_mehr...@hotmail.com wrote:
Martin, Mike,
Totally agree with everything that has been said on this. Leaving it
'unresolved' or 'closed as will not fix' won't bother me.
Mike has it listed as a 'doc clarification only' so my suggestion
One would have to measure of course, but intuitively, it seems like a good
change to reuse the stringbuilder. There's also the issue that the local
stringbuilder before was default-sized, and for large content, it would
generate even more garbage as the underlying array is expanded.
The
29 matches
Mail list logo
