[10] RFR: 8177631: Outdated performance advice in StringCoding

Hi, Class.getClassLoader0 was once an expensive native operation, but since JDK-6642881 was fixed it is now a simple getter, retrieving a final field injected during class load. Thus the advice in StringCoding that getClass().getClassLoader0 is expensive should be removed. Webrev: http://cr.

Re: RFR 9: 8165641 : Deprecate Object.finalize

The api note for Object.finalize is not an optimal location for this more general advice, but is good as far as it can go in relation to the current changes to deprecate Object.finalize(). The webrev[1] is updated to add a paragraph to the apiNote[2]: * @apiNote * Classes that embed

Re: [10] RFR: 8177631: Outdated performance advice in StringCoding

+1 On 4/3/17, 7:31 AM, Claes Redestad wrote: Hi, Class.getClassLoader0 was once an expensive native operation, but since JDK-6642881 was fixed it is now a simple getter, retrieving a final field injected during class load. Thus the advice in StringCoding that getClass().getClassLoader0 is ex

[9] RFR 8177969: Faster FilePermission::implies by avoiding the use of Path::relativize

http://cr.openjdk.java.net/~weijun/8177969/webrev.00/ This new implementation of containsPath(Path,Path) uses the logic of Path::relativize without directly calling it, which is much faster now. Thanks Max

Re: [10] RFR: 8177631: Outdated performance advice in StringCoding

On 04/03/2017 05:29 PM, Xueming Shen wrote: +1 Thanks Sherman! /Claes

Re: Bug in File.getLastModified()

Just to add another though... I was just double-reading the documentation and it says: "All platforms support file-modification times to the nearest second, but some provide more precision. The argument will be truncated to fit the supported precision." So, if the platform supports it, the argum

Re: Bug in File.getLastModified()

Hi all, I agree with Sean, as said in the bug. The reason we have in the documentation that it can be possibly truncated is most likely related to older linux's that wouldn't support it... If the data is there and available, why explicitly truncate it? Also note that the workaround also doesn't w

Re: RFR [9] 8177738: Runtime.Version must be a value-based class

Hi, 962 * [1-9][0-9]*((\.0)*\.[1-9][0-9]*)* You removed the initial “^” which is still mentioned in JDK-8148822 < `^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$`. The sequence may be of arbitrary --- > `^[1-9][0-9]*((\.0)*\.[1-9][0-9]*)*$`. The sequence may be of arbitrary JEP 223 is still using the f

Re: RFR: jsr166 jdk10 integration wave 1

Hi, Looks good. It’s trivial but we probably require a CCC for ScheduledThreadPoolExecutor calling out the NPE for null unit argument values, to clarify pool sizes of TPE, and to clarify that AbortPolicy default handler for TPE *and* STPE. We are not quite there yet with the CCC being open (so

Re: RFR [9] 8177738: Runtime.Version must be a value-based class

> On 3 Apr 2017, at 20:39, Paul Sandoz wrote: > > Hi, > > 962 * [1-9][0-9]*((\.0)*\.[1-9][0-9]*)* > > You removed the initial “^” which is still mentioned in JDK-8148822 > > < `^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$`. The sequence may be of arbitrary > --- >> `^[1-9][0-9]*((\.0)*\.[1-9][0-9]*

Re: RFR [9] 8177738: Runtime.Version must be a value-based class

> On 3 Apr 2017, at 16:40, Pavel Rappo wrote: > > >> On 3 Apr 2017, at 20:39, Paul Sandoz wrote: >> >> Hi, >> >> 962 * [1-9][0-9]*((\.0)*\.[1-9][0-9]*)* >> >> You removed the initial “^” which is still mentioned in JDK-8148822 >> >> < `^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$`. The sequence

Re: RFR: jsr166 jdk10 integration wave 1

Thanks! On Mon, Apr 3, 2017 at 1:05 PM, Paul Sandoz wrote: > Hi, > > Looks good. > > It’s trivial but we probably require a CCC for ScheduledThreadPoolExecutor > calling out the NPE for null unit argument values, to clarify pool sizes of > TPE, and to clarify that AbortPolicy default handler for