Re: [9] 8149571: [launcher] create a regression test to test symlinks on Windows

Hi, Please review the simple test of launcher started using a symlink. issue: https://bugs.openjdk.java.net/browse/JDK-8149571 webrev: http://cr.openjdk.java.net/~ogb/8149571/ Thanks, Oleg

Re: RFR(s): 8153330: deprecate Runtime.traceInstructions & traceMethodCalls for removal

> On Apr 19, 2016, at 3:11 PM, Stuart Marks wrote: > > Hi all, > > I missed a couple bits of cruft in the previous round of java.lang > deprecations: the Runtime.traceInstructions() and traceMethodCalls() methods. > > Their implementations are empty. That is, they do

Re: RFR(s): 8153330: deprecate Runtime.traceInstructions & traceMethodCalls for removal

On 19/04/2016 23:11, Stuart Marks wrote: Hi all, I missed a couple bits of cruft in the previous round of java.lang deprecations: the Runtime.traceInstructions() and traceMethodCalls() methods. This looks fine. -Alan

Re: RFR: 8154231: Simplify access to System properties from JDK code

On 2016-04-20 20:51, Chris Hegarty wrote: On 20 Apr 2016, at 15:44, Claes Redestad wrote: Hello, now that the sun.security.action package is encapsulated we can simplify internal code to get System properties. Bug:

Re: RFR: 8154231: Simplify access to System properties from JDK code

On 20 Apr 2016, at 15:44, Claes Redestad wrote: > Hello, > > now that the sun.security.action package is encapsulated we can simplify > internal code to get System properties. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154231 > Webrev:

Re: RFR: 8154231: Simplify access to System properties from JDK code

Hi Claes, thanks. Am 20.04.2016 um 18:12 schrieb Claes Redestad: Thanks for looking at this, Ulf! - Isn't the "theProp" naming style something from an old usage where all members have been named myXyz? I more would like "propName" or just "property". I chose to go with keeping names in line

Re: RFR: 8154231: Simplify access to System properties from JDK code

Thanks for looking at this, Ulf! On 2016-04-20 17:57, Ulf Zibis wrote: Hi, here my comments: Am 20.04.2016 um 16:44 schrieb Claes Redestad: Hello, now that the sun.security.action package is encapsulated we can simplify internal code to get System properties. Bug:

Re: Locks implementing Closable

Here's a bit of background for you to explore: http://stackoverflow.com/questions/16574353/any-risk-in-a-autocloseable-wrapper-for-java-util-concurrent-locks-lock http://cs.oswego.edu/pipermail/lambda-lib/2012-June/000447.html https://bugs.openjdk.java.net/browse/JDK-7084550 I'm sure if

Re: Locks implementing Closable

Thank you very much for the background. -- View this message in context: http://openjdk.5641.n7.nabble.com/Locks-implementing-Closable-tp267580p267599.html Sent from the OpenJDK Core Libraries mailing list archive at Nabble.com.

Re: RFR: 8154231: Simplify access to System properties from JDK code

Hi, here my comments: Am 20.04.2016 um 16:44 schrieb Claes Redestad: Hello, now that the sun.security.action package is encapsulated we can simplify internal code to get System properties. Bug: https://bugs.openjdk.java.net/browse/JDK-8154231 Webrev:

Re: RFR: JDK-8152690: main thread does not have native thread name

Hi Kumar, Isn't there a management API or something to enumerate the threads ? On Linux, user apps can get native thread name through pthread_getname_np(3). However, this function is not called in hotspot and jdk. So I think it is difficult to get native thread name in all platforms. Well

Re: RFR: 8154231: Simplify access to System properties from JDK code

This is quite convenient. We not cover the other modules? exports sun.security.action to java.desktop, java.security.jgss, jdk.crypto.pkcs11; Thanks Max > On Apr 20, 2016, at 10:44 PM, Claes Redestad > wrote: > > Hello, > > now that the

Locks implementing Closable

Has it been considered to have the Lock interface use AutoCloseable? That way users can lock in a try and not have to worry about a finally? -- View this message in context: http://openjdk.5641.n7.nabble.com/Locks-implementing-Closable-tp267580.html Sent from the OpenJDK Core Libraries

RFR: 8154231: Simplify access to System properties from JDK code

Hello, now that the sun.security.action package is encapsulated we can simplify internal code to get System properties. Bug: https://bugs.openjdk.java.net/browse/JDK-8154231 Webrev: http://cr.openjdk.java.net/~redestad/8154231/webrev.01/ This adds a few convenience methods to

Re: RFR: JDK-8152690: main thread does not have native thread name

On 4/20/2016 6:06 AM, David Holmes wrote: On 20/04/2016 10:58 PM, Kumar Srinivasan wrote: Hello, One more thing, what about a launcher regression test ? What kind of regression test? I've manually visually inspected the desired behaviour but a test for it is very problematic. AFAIK there

RFR(S): 8154754: MethodHandles.countedLoop errors in deriving loop arguments, result type, and local state

Dear all, please review this change. It depends on the one about 8154751 posted earlier [1]. Bug: https://bugs.openjdk.java.net/browse/JDK-8154754 Webrev: http://cr.openjdk.java.net/~mhaupt/8154754/webrev.00/ Thanks, Michael [1]

RFR(S): 8154751: MethodHandles.countedLoop does not accept empty bodies

Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8154751 Webrev: http://cr.openjdk.java.net/~mhaupt/8154751/webrev.00/ Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331

Re: RFR: JDK-8152690: main thread does not have native thread name

On 20/04/2016 10:58 PM, Kumar Srinivasan wrote: Hello, One more thing, what about a launcher regression test ? What kind of regression test? I've manually visually inspected the desired behaviour but a test for it is very problematic. AFAIK there are no tests for setting the native thread

Re: RFR: JDK-8152690: main thread does not have native thread name

Hello, One more thing, what about a launcher regression test ? Thanks Kumar On 4/19/2016 1:32 PM, David Holmes wrote: On 20/04/2016 3:00 AM, Kumar Srinivasan wrote: Hi David, 493 /* Set native thread name. */ 494 SetNativeThreadName(env, "main"); 495 496 /* Invoke

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

> On 20 Apr 2016, at 13:50, Tagir F. Valeev wrote: > > Hello! > > PS> Thinking some more about this, i think it would be preferable. It > PS> reduces the explicit referral to > PS> ForkJoinPool.getCommonPoolParallelism(). > > No problems, here's updated webrev: >

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

Hello! PS> Thinking some more about this, i think it would be preferable. It PS> reduces the explicit referral to PS> ForkJoinPool.getCommonPoolParallelism(). No problems, here's updated webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8154387/r2/ All tests pass. With best regards, Tagir

RFR(S): 8152667: MHs.iteratedLoop(...) throws unexpected WMTE, disallows Iterator subclasses, generates inconsistent loop result type

Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8152667 Webrev: http://cr.openjdk.java.net/~mhaupt/8152667/webrev.00/ Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

> On 19 Apr 2016, at 18:57, Paul Sandoz wrote: >> The LEAF_TARGET version does not change the results significantly. If >> you feel that using LEAF_TARGET is more suitable I can update webrev >> correspondingly. >> > > It has some appeal, since there is a symmetry to

Re: RFR: 8072921: -Xincgc should be removed from output

On 2016-04-19 12:45, Alan Bateman wrote: On 19/04/2016 10:58, Stefan Karlsson wrote: I've left the locale specific launcher files untouched. Should I update them as well? Dropping -Xincgc rom the -X output looks okay to me. We usually don't touch the translations as they are updated in

RE: RFR: JDK-8153781 Issue in XMLScanner: EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large DOCTYPE section with CRLF at wrong place

Thanks Joe :-) > -Original Message- > From: huizhe wang [mailto:huizhe.w...@oracle.com] > Sent: Dienstag, 19. April 2016 23:44 > To: Langer, Christoph > Cc: core-libs-dev@openjdk.java.net > Subject: Re: RFR: JDK-8153781 Issue in XMLScanner: >