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 "temporar
On Jan 31 2014, at 15:09 , Jason Mehrens 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 toward a
> resolution wo
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 toward a
resolution would be to modify AbstractList.subList documentation with a spec
On 01/31/2014 10:44 AM, Lance Andersen - Oracle wrote:
looks fine. getting rid of and , 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 javado
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 wrote:
> Forwarding to correct core-libs-dev list.
>
> -C
On Jan 31 2014, at 11:50 , Martin Buchholz 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 no clean way ou
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 31 Jan 2014, at 19:07, Stuart Marks 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 existing StringBui
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
wrote:
http://cr.openjdk.java.net/~vlivanov/8033278/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8033278
The fix for 8032585 [1]
Looks good.
On Jan 30, 2014, at 4:58 PM, Vladimir Ivanov
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 omitted.
>
>
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 reading/writi
Forwarding for correct core-libs-dev list.
-Chris.
On 31 Jan 2014, at 15:26, Robert Stupp 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 requires a
Forwarding to correct core-libs-dev list.
-Chris.
On 31 Jan 2014, at 14:22, Chris Hegarty 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
> reuse, where possible,
looks fine. getting rid of and , 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/
>
trancate -> truncate . Other cleanups look good too.
-Chris.
On 31 Jan 2014, at 18:33, 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
>
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
Please review a typo and javadoc cleanup for java.util.Date
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-date-typo-8032221/
Thanks, Roger
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 wrote:
> The jtreg test is fine, but:
>
> s/IOBE/IOOBE/
>
> When I c
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
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
! tes
On Jan 31, 2014, at 5:23 PM, Chris Hegarty 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 it's awkward to share
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 3:21 PM, Vladimir Ivanov
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 that small point as i
thin
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 Ivan
On 01/31/2014 08:32 AM, Paul Sandoz wrote:
On Jan 30, 2014, at 11:02 PM, Stuart Marks 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 occurr
On Jan 30, 2014, at 11:02 PM, Stuart Marks 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 have
> to figure out ho
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.
++
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
On Jan 31, 2014, at 1:58 AM, Vladimir Ivanov
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 omitted.
>
> The fix is t
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
30 matches
Mail list logo
