RFR: 8059169 [Findbugs]Classes under package com.sun.tools.internal.xjc may expose internal representation by storing an externally mutable object

Hi all, Could you please help me to review my code change about issue https://bugs.openjdk.java.net/browse/JDK-8059169 ? webrev: http://cr.openjdk.java.net/~fyuan/eguo/8059169/webrev.00/ . These change are only for JDK 9. Best regards, Eric

Re: JDK 9 RFR of JDK-8038330: tools/jar/JarEntryTime.java fails intermittently on checking extracted file last modified values are the current times

On 3/3/16 3:42 AM, Xueming Shen wrote: +1 though it might be better (?) to check as 184 if (now< start || now> end)) { Updated :-) http://cr.openjdk.java.net/~amlu/8038330/webrev.02/ Thanks, Amy thanks, sherman On 03/02/2016 06:23 AM, Amy Lu wrote: Please help to review the

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

Mandy, thank you for reviewing this. On 3/2/16 9:18 PM, Mandy Chung wrote: On Mar 2, 2016, at 4:03 PM, Coleen Phillimore wrote: Freshly tested changes with jck tests, with missing checks and other changes to use the depth field, as pointed out by Aleksey. I've kept the StackTraceElement[]

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

> On Mar 2, 2016, at 4:03 PM, Coleen Phillimore > wrote: > > Freshly tested changes with jck tests, with missing checks and other changes > to use the depth field, as pointed out by Aleksey. I've kept the > StackTraceElement[] allocation in Java to match the new API that was approved. > > o

Re: Custom security policy without replacing files in the OpenJDK?

On 27/02/2016 2:56 AM, Marcus Lagergren wrote: Hi! Is it possible to override lib/security/local_policy on app level without patching jdk distro? i.e. -Duse.this.policy.jar= … or something? Can’t find a way to do it http://docs.oracle.com/javase/8/docs/technotes/guides/security/PolicyFiles.h

RFR: 8151098: Introduce multi-slot per-thread cache for StringDecoders/Encoders

Hi all, We discussed this change in a previous e-mail thread. Here’s a patch for your consideration: http://cr.openjdk.java.net/~tonyp/8151098/webrev.1/ I cloned the Cache class from ThreadLocalCoders and reworked it a bit. The StringDecoder and StringEncoder classes had some common fields (th

Re: RFR: jsr166 jdk9 integration wave 5

Webrevs updated, incorporating changes to tests in my previous message.

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

On 3/2/16 3:21 PM, Aleksey Shipilev wrote: On 03/02/2016 10:57 PM, Coleen Phillimore wrote: On 3/2/16 1:58 PM, Aleksey Shipilev wrote: Is there an underlying reason why we can't return the pre-filled StackTraceElements[] array from the JVM_GetStackTraceElements to begin with? This will avoid

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

On 03/02/2016 10:57 PM, Coleen Phillimore wrote: > On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >> Is there an underlying reason why we can't return the pre-filled >> StackTraceElements[] array from the JVM_GetStackTraceElements to begin >> with? This will avoid leaking StackTraceElement constructor

Re: [8u-dev] Request for REVIEW and APPROVAL to backport: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

Reviewed! On Wed, Mar 2, 2016 at 9:29 AM, Ivan Gerasimov wrote: > Hello! > > I'm seeking for approval to backport this fix into jdk8u-dev. > Comparing to Jdk9, the patch had to be changed mainly due to compact string > support introduced in jdk9. > However, the fix is essentially the same: we jus

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

On 3/2/16 1:58 PM, Aleksey Shipilev wrote: Hi Coleen, On 03/02/2016 09:44 PM, Coleen Phillimore wrote: Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, with JVM_GetStackTraceElements that gets all the elements in the StackTraceElement[] These improvements were found duri

RFR(S): 8150957: j.l.i.MethodHandles.whileLoop(...) fails with IOOBE in the case 'init' is null, 'step' and 'pred' have parameters

Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8150957 Webrev: http://cr.openjdk.java.net/~mhaupt/8150957/webrev.00/ The bug was actually fixed with the push for JDK-8150635. This change adds a test for the issue. Thanks, Michael --

Re: JDK 9 RFR of JDK-8038330: tools/jar/JarEntryTime.java fails intermittently on checking extracted file last modified values are the current times

+1 though it might be better (?) to check as 184 if (now< start || now> end)) { thanks, sherman On 03/02/2016 06:23 AM, Amy Lu wrote: Please help to review the updated version: http://cr.openjdk.java.net/~amlu/8038330/webrev.01/ Thanks, Amy On 3/1/16 7:41 PM, Peter Levart wrote:

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

Hi Daniel, Thank you for looking at this so quickly. On 3/2/16 1:57 PM, Daniel Fuchs wrote: Hi Coleen, Nice improvement! Two remarks on http://cr.openjdk.java.net/~coleenp/8150778_jdk/ 1. StackTraceElement.java Does the new constructor in StackTraceElement really need to be public? Can't we

RFR 8150679: closed/javax/crypto/CryptoPermission/CallerIdentification.sh fails after fix for JDK-8132734

Please review the following fix for JDK-8150679 webrev: http://cr.openjdk.java.net/~sdrach/8150679/webrev/ issue: https://bugs.openjdk.java.net/browse/JDK-8150679 The test was modified to dem

Re: Replacement of Quicksort in java.util.Arrays with new Dual-Pivot Quicksort

Hi Stuart, I hate replying to an ancient threat, but I figured it was the best method. Thanks for the tips. The original paper was almost as hard to find as he is proving to be. :) All the best, -Jason C. McDonald On 02/26/2016 06:05 PM, Stuart Marks wrote: Wow, is this a reply to a nearly

Custom security policy without replacing files in the OpenJDK?

Hi! Is it possible to override lib/security/local_policy on app level without patching jdk distro? i.e. -Duse.this.policy.jar= … or something? Can’t find a way to do it Regards Marcus

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

Hi Coleen, On 03/02/2016 09:44 PM, Coleen Phillimore wrote: > Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, > with JVM_GetStackTraceElements that gets all the elements in the > StackTraceElement[] > > These improvements were found during the investigation for replacing > T

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

Hi Coleen, Nice improvement! Two remarks on http://cr.openjdk.java.net/~coleenp/8150778_jdk/ 1. StackTraceElement.java Does the new constructor in StackTraceElement really need to be public? Can't we keep that package protected? 2. Throwable.java:902 902 * package-protection for use by

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

Hi , Please see the updated webrev http://cr.openjdk.java.net/~ntv/8030864/webrev.03/ Thanks and Regards, Nadeesh On 3/3/2016 12:01 AM, Roger Riggs wrote: Hi Nadeesh, Editorial comments: Chronology.java: 716+ "Java epoch" -> "epoch" "minute, second and zoneOffset" -> "minute, second

RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, with JVM_GetStackTraceElements that gets all the elements in the StackTraceElement[] These improvements were found during the investigation for replacing Throwable with the StackWalkAPI. This change also adds iterator for

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

Hi Nadeesh, Editorial comments: Chronology.java: 716+ "Java epoch" -> "epoch" "minute, second and zoneOffset" -> "minute, second*,* and zoneOffset" (add a comma; two places) "caluculated using given era, prolepticYear," -> "calculated using the era, year-of-era," "to represent" ->

[8u-dev] Request for REVIEW and APPROVAL to backport: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

Hello! I'm seeking for approval to backport this fix into jdk8u-dev. Comparing to Jdk9, the patch had to be changed mainly due to compact string support introduced in jdk9. However, the fix is essentially the same: we just avoid getting too close to Integer.MAX_VALUE when doing reallocations un

Re: RFR [9] 8150976: JarFile and MRJAR tests should use the JDK specific Version API

> On Mar 1, 2016, at 8:38 AM, Chris Hegarty wrote: > > Currently JarFile and MRJAR tests use sun.misc.Version to retrieve the major > runtime version. They should be updated to use the new JDK specific Version > API. > > Note: There is an issue, 8144062 [1], to revisit the JDK specific Version

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

I think that this is fine now, but Roger/others should also chime in. thanks Stephen On 2 March 2016 at 15:17, nadeesh tv wrote: > Hi, > Stephen, Thanks for the comments. > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8030864/webrev.02/ > > Regards, > Nadeesh TV > > > On 3/2/20

RFR: 8147755: ASM should create correct constant tag for invokestatic on handle point to interface static method

Hello Remi, et. al., Webrev: http://cr.openjdk.java.net/~ksrini/8147755/webrev.00/ Can you please approve this patch, it is taken out of ASM's svn repo. change id 1795, which addresses the problem described in [1]. Note 1: A couple of @Deprecated annotations and doc comments have been disabled

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

Hi, Stephen, Thanks for the comments. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8030864/webrev.02/ Regards, Nadeesh TV On 3/2/2016 5:41 PM, Stephen Colebourne wrote: Remove "Subclass can override the default implementation for a more efficient implementation." as it adds no

Re: JDK 9 RFR of JDK-8038330: tools/jar/JarEntryTime.java fails intermittently on checking extracted file last modified values are the current times

Please help to review the updated version: http://cr.openjdk.java.net/~amlu/8038330/webrev.01/ Thanks, Amy On 3/1/16 7:41 PM, Peter Levart wrote: Hi Amy, I think that the following test: 178 if (!(Math.abs(now - start) >= 0L && Math.abs(end - now) >= 0L)) { ...will always be false

Re: RFR(XS): 8150953: j.l.i.MethodHandles: example section in whileLoop(...) provides example for doWhileLoop

> On 1 Mar 2016, at 14:46, Michael Haupt wrote: > > Dear all, > > please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8150953 > Webrev: http://cr.openjdk.java.net/~mhaupt/8150953/webrev.00/ > +1 Paul. > The API docs and corresponding JavaDocExampleTest test case for > M

Re: RFR(M): 8150832: split T8139885 into several tests by functionality

Hi Claes, thanks a lot, and I agree with the renaming. Best, Michael > Am 02.03.2016 um 13:59 schrieb Claes Redestad : > > Hi, > > this looks good to me. > > Maybe rename LoopTest to LoopCombinatorTest to add a bit of specificity? > > /Claes > > On 2016-03-02 13:46, Michael Haupt wrote: >>

Re: RFR(M): 8150832: split T8139885 into several tests by functionality

Hi, this looks good to me. Maybe rename LoopTest to LoopCombinatorTest to add a bit of specificity? /Claes On 2016-03-02 13:46, Michael Haupt wrote: Dear all, please review this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8150832 Webrev: http://cr.openjdk.java.net/~mhaupt/8150832/w

RFR(M): 8150832: split T8139885 into several tests by functionality

Dear all, please review this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8150832 Webrev: http://cr.openjdk.java.net/~mhaupt/8150832/webrev.00 This is a refactoring; the monolithic test for JEP 274 was split into several tests along functionality covered. Also, data providers and other

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

Remove "Subclass can override the default implementation for a more efficient implementation." as it adds no value. In the default implementation of epochSecond(Era era, int yearofEra, int month, int dayOfMonth, int hour, int minute, int second, ZoneOffset zoneOffset) use prolepticYear(era, yea

Re: RFR [9] 8150976: JarFile and MRJAR tests should use the JDK specific Version API

On 01/03/2016 16:38, Chris Hegarty wrote: Currently JarFile and MRJAR tests use sun.misc.Version to retrieve the major runtime version. They should be updated to use the new JDK specific Version API. Note: There is an issue, 8144062 [1], to revisit the JDK specific Version API to determine if it

Re: RFR (XS): 8149596: Remove java.nio.Bits copy wrapper methods

> On 1 Mar 2016, at 19:29, Mikael Vidstedt wrote: > > > As part of JDK-8141491[1] the native methods in java.nio.Bits were removed, > and the functionality is instead provided by the VM through j.i.m.Unsafe. The > Bits wrapper methods are therefore redundant and can be removed. > > Bug: http

RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

Hi all, Please review an enhancement for a garbage free epochSecond method. Bug ID: https://bugs.openjdk.java.net/browse/JDK-8030864 webrev: http://cr.openjdk.java.net/~ntv/8030864/webrev.01

Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Hi Andrew, On Wed, Mar 2, 2016 at 9:28 AM, Andrew Haley wrote: > On 01/03/16 10:20, Dmitry Samersoff wrote: > > The bug: https://bugs.openjdk.java.net/browse/JDK-8150460 > >> The Webrev: > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.00/webrev/ > > Why use c

Re: RFR 8148187 : Remove OS X-specific com.apple.concurrent package

On 01/03/2016 21:16, Brent Christian wrote: For your review is a webrev of this change: http://cr.openjdk.java.net/~bchristi/8148187/webrev.01/ This looks good to me, in particular the move of FileManager.m into the right source tree as it was just wrong for that to be in jdk.deploy.osx when

Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

On 01/03/16 10:20, Dmitry Samersoff wrote: > The bug: https://bugs.openjdk.java.net/browse/JDK-8150460 >> The Webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.00/webrev/ Why use calloc here? Surely it makes more sense to use mmap(MAP_NORESERVE), at least on

Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Hi Hans, thanks for the hint! But how would I do this for my problem: Allocate memory, zero it out and then store the pointer into a variable seen by other threads, while preventing the other threads from seeing . I do not understand how atomics would help: I can make the pointer itself an atomi