Re: Review request 8072656: test/java/lang/reflect/Proxy/ClassRestrictions.java assumes app class loader be URLClassLoader

On 05/02/2015 21:42, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8072656/webrev.00/ This updates the test to get the classpath from "test.classes" system property and pass it to the custom class loader (instead of calling the getURLs() method of the app class loader). T

Optimize `AbstractStringBuilder.replace`

Hello, I'm looking into AbstractStringBuilder java.lang.AbstractStringBuilder.replace(int start, int end, String str) There is a array copy after `ensureCapacityInternal`, it's mi

Re: FilePermission Canonical path optimization

Hi All, I have updated the patch[1] according to above discussion. Please review it. Thanks a lot [1] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.03/ 2015-02-03 16:04 GMT+08:00 Peter Levart : > Hi Deven, > > > On 02/03/2015 08:42 AM, deven you wrote: > >> Hi Sean, >> >> The performanc

Re: [9] RFR of 8066842: java.math.BigDecimal.divide(BigDecimal, RoundingMode) produces incorrect result

Hi Paul, On Feb 5, 2015, at 6:06 AM, Paul Sandoz wrote: > I don't claim to understand the fine details of these methods but i can see > how the new method avoid loosing bits. > > 4947 private static long[] divRemNegativeLong(long n, long d) { > 4948 if (n >= 0) { > 4949

Re: Review request 8072656: test/java/lang/reflect/Proxy/ClassRestrictions.java assumes app class loader be URLClassLoader

looks fine mandy On Feb 5, 2015, at 4:42 PM, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8072656/webrev.00/ > > This updates the test to get the classpath from "test.classes" system > property and pass it to the custom class loader (instead of calling the > getURLs()

Review request 8072656: test/java/lang/reflect/Proxy/ClassRestrictions.java assumes app class loader be URLClassLoader

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8072656/webrev.00/ This updates the test to get the classpath from "test.classes" system property and pass it to the custom class loader (instead of calling the getURLs() method of the app class loader). Mandy

Re: RFR: JDK-8030179: java/nio/Buffer/Chars.java, testcases seems all pass but jtreg/testng failed with java.lang.AssertionError

On 05/02/2015 19:00, Xueming Shen wrote: Hi, Please help review the fix for #8030179 issue: https://bugs.openjdk.java.net/browse/JDK-8030179 webrev: http://cr.openjdk.java.net/~sherman/8030179/webrev This is the regression bug introduced in jdk7 when trying to optimize the single byte encodin

Re: RFR: JDK-8030179: java/nio/Buffer/Chars.java, testcases seems all pass but jtreg/testng failed with java.lang.AssertionError

On 02/05/2015 12:47 PM, Paul Sandoz wrote: On Feb 5, 2015, at 8:00 PM, Xueming Shen wrote: Hi, Please help review the fix for #8030179 issue: https://bugs.openjdk.java.net/browse/JDK-8030179 webrev: http://cr.openjdk.java.net/~sherman/8030179/webrev This is the regression bug introduced in

Re: RFR: JDK-8030179: java/nio/Buffer/Chars.java, testcases seems all pass but jtreg/testng failed with java.lang.AssertionError

On Feb 5, 2015, at 8:00 PM, Xueming Shen wrote: > Hi, > > Please help review the fix for #8030179 > > issue: https://bugs.openjdk.java.net/browse/JDK-8030179 > webrev: http://cr.openjdk.java.net/~sherman/8030179/webrev > > This is the regression bug introduced in jdk7 when trying to optimize

RFR: JDK-8030179: java/nio/Buffer/Chars.java, testcases seems all pass but jtreg/testng failed with java.lang.AssertionError

Hi, Please help review the fix for #8030179 issue: https://bugs.openjdk.java.net/browse/JDK-8030179 webrev: http://cr.openjdk.java.net/~sherman/8030179/webrev This is the regression bug introduced in jdk7 when trying to optimize the single byte encoding loop, in which the "optimization" code in

Re: [9] RFR of 8066842: java.math.BigDecimal.divide(BigDecimal, RoundingMode) produces incorrect result

Hi Brian. I don't claim to understand the fine details of these methods but i can see how the new method avoid loosing bits. 4947 private static long[] divRemNegativeLong(long n, long d) { 4948 if (n >= 0) { 4949 throw new IllegalArgumentException("Non-negative numerator"

Re: Using StringBuilder instead StringBuffer[JAXP]

On Tue, Dec 23, 2014 at 7:46 AM, Otávio Gonçalves de Santana < otavioj...@java.net> wrote: > > *Motivation:* StringBuffer is synchronized while StringBuilder is not > which makes StringBuilder faster than StringBuffer[1]. The strategy was > removed the StringBuffer when it is not necessary. > > >

RFR 8071479: Stream and lamdification improvements to j.u.regex.Matcher

Hi. Please review these stream/lambda enhancements on Matcher: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/ Two new methods are added to Matcher: 1) replaceAll(Function ) that is more flexible than the existing replaceAll that accepts a single value.

Re: RFC: Adding ConcurrentModificationException for HashMap.computeIfAbsent(), and JDK-8071667

On Feb 5, 2015, at 1:36 AM, Brent Christian wrote: > I prefer this approach of discouraging/preventing side-effects via CME, > rather than allowing them. Keep the functions "functional", as it were. > > If there are situations where determining the mapping for one key > necessitates making add

Re: RFC: Adding ConcurrentModificationException for HashMap.computeIfAbsent(), and JDK-8071667

On Feb 5, 2015, at 1:45 AM, Doug Lea wrote: > On 02/04/2015 05:01 AM, Paul Sandoz wrote: > >> So i propose: >> >> - the functions should be side-effect free. >> >> ... >> - concurrent map implementations should, on a best-effort basis, detect >> non-termination situations and fail with ISE.