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: > EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBS

Re: Multi-Release JAR runtime support

Yes. > On Apr 19, 2016, at 5:11 PM, mark.reinh...@oracle.com wrote: > > 2016/4/19 12:37:41 -0700, Hervé BOUTEMY : >> that's it: I added this Multi-Release: true attribute configuration in the >> demo and now it works like a charm, thank you >> >> Perhaps this requirement should be described in

Re: Multi-Release JAR runtime support

2016/4/19 12:37:41 -0700, Hervé BOUTEMY : > that's it: I added this Multi-Release: true attribute configuration in the > demo and now it works like a charm, thank you > > Perhaps this requirement should be described in > http://openjdk.java.net/jeps/238 Yes -- that was certainly non-obvious! S

Re: PING: RFR: JDK-4347142: Need method to set Password protection to Zip entries

2016/4/8 9:52:56 -0700, anthony.vanelverdin...@gmail.com: > I don't mind if decryption support is added for the "Traditional > Encryption". However, I believe it would be wrong to introduce > encryption support for a known-to-be-broken encryption method in the > JDK. Using the argument of "it's

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

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 absolutely nothing. They're only mentioned a couple times in the JDK, in CORBA (!) and 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

On 4/19/2016 1:45 PM, Langer, Christoph wrote: Hi Joe, I've updated the testcase to increase the probability of it really hitting the issue. The old version was prone to miss the issue in case something changed in the parser. http://cr.openjdk.java.net/~clanger/webrevs/8153781.2/ Looks good

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

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 main method. */ 497 (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainA

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

Hi Joe, > > I've updated the testcase to increase the probability of it really hitting > > the > issue. The old version was prone to miss the issue in case something changed > in > the parser. > > > > http://cr.openjdk.java.net/~clanger/webrevs/8153781.2/ > > Looks good overall. OK, thanks. >

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

On 20/04/2016 3:00 AM, Kumar Srinivasan wrote: Hi David, 493 /* Set native thread name. */ 494 SetNativeThreadName(env, "main"); 495 496 /* Invoke main method. */ 497 (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); Supposing an exception is thrown in 49

Re: Multi-Release JAR runtime support

that's it: I added this Multi-Release: true attribute configuration in the demo and now it works like a charm, thank you Perhaps this requirement should be described in http://openjdk.java.net/jeps/238 Is it expected to be supported with JDK 8 also? Is there any magic trick to add this feature

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

On 4/19/2016 6:54 AM, Langer, Christoph wrote: Hi again, I've updated the testcase to increase the probability of it really hitting the issue. The old version was prone to miss the issue in case something changed in the parser. http://cr.openjdk.java.net/~clanger/webrevs/8153781.2/ Looks g

Re: RFR:JDK-8031085:DateTimeFormatter won't parse dates with custom format "yyyyMMddHHmmssSSS"

Hi Roger, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8031085/webrev.02/ Regards, Nadeesh TV On 4/19/2016 10:51 PM, Roger Riggs wrote: Hi Nadeesh, java/time/format/DateTimeFormatterBuilder.java: - line 671, the @code should be @link, especially since it says "see", to

RFR: 8152084: Introduction of ssliop protocol to corbaloc

Hello All, I would like to propose an extension to corbaloc resolution - the ssliop protocol. IORs created from corbaloc url with ssliop protocol will contain SSL tagged component with indication that secured invocation is required. As a result, connection to the resolved object will have to be

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

Hi David, 493 /* Set native thread name. */ 494 SetNativeThreadName(env, "main"); 495 496 /* Invoke main method. */ 497 (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); Supposing an exception is thrown in 494 (a very remote case), will we not re-enter the VM i

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

> On 19 Apr 2016, at 18:28, Tagir F. Valeev wrote: > > Hello! > > webrev is updated in-place (just added parentheses): > http://cr.openjdk.java.net/~tvaleev/webrev/8154387/r1/ > > Updated benchmark source and results are available here: > http://cr.openjdk.java.net/~tvaleev/webrev/8154387/jmh/

Re: RFR:JDK-8031085:DateTimeFormatter won't parse dates with custom format "yyyyMMddHHmmssSSS"

Hi Nadeesh, java/time/format/DateTimeFormatterBuilder.java: - line 671, the @code should be @link, especially since it says "see", to make navigation easier - line 2998: Missing first sentence of the method description. otherwise looks ok. Roger On 4/19/2016 10:16 AM, Stephen Colebour

Re: JDK 9 pre-review of JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract

I wanted to reply that if you have a perf sensitive code that uses newInstance you should use a MethodHandle instead to avoid to do the security checks multiple times but i remember that they was an issue with MethodHandle attached to a constructor and i don't know if it was resolved. Rémi Le

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

Hello! webrev is updated in-place (just added parentheses): http://cr.openjdk.java.net/~tvaleev/webrev/8154387/r1/ Updated benchmark source and results are available here: http://cr.openjdk.java.net/~tvaleev/webrev/8154387/jmh/ In general I observe that for low-Q filter (x -> true) the results a

Re: Multi-Release JAR runtime support

Hi Herve, I checked the jar file created from your code and, as others have suspected, the manifest does not contain the “Multi-Release” attribute. I added the attribute with emacs and tried it out: $ java -classpath multirelease/target/multirelease-0.8-SNAPSHOT.jar base.Base 9-ea+113 FROM BAS

Re: Project Jigsaw, Apache Tomcat and RMI related memory leaks

Hi Mark, It may take a bit of time to unwind and find a good solution. On 4/18/16 11:58 AM, Mark Thomas wrote: Hi, The Apache Tomcat community was asked by Rory O'Donnell for feedback on JDK 9 + Project Jigsaw. Having provided that feedback we were directed here so I have reproduced that feedb

Re: RFR:JDK-8148947:DateTimeFormatter pattern letter 'g'

Hi Nadeesh, Looks good to me also. Thanks, Roger On 4/17/2016 5:58 PM, Stephen Colebourne wrote: Looks fine to me Stephen On 30 March 2016 at 19:11, nadeesh tv wrote: Hi all, BUG ID : https://bugs.openjdk.java.net/browse/JDK-8148947 Webrev : http://cr.openjdk.java.net/~ntv/8148947/webre

Re: RFR:JDK-8031085:DateTimeFormatter won't parse dates with custom format "yyyyMMddHHmmssSSS"

Looks good. Stephen On 19 April 2016 at 09:42, nadeesh tv wrote: > Hi Stephen, > > Thanks for the comments. > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8031085/webrev.01/ > > -- > Thanks and Regards, > Nadeesh TV > > > > > On 4/18/2016 3:03 AM, Stephen Colebourne wrote: >> >

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

Hi again, I've updated the testcase to increase the probability of it really hitting the issue. The old version was prone to miss the issue in case something changed in the parser. http://cr.openjdk.java.net/~clanger/webrevs/8153781.2/ Best regards Christoph > -Original Message- > F

RE: [JNDI/LDAP] Intercepting LDAP URLs with initial and referral directory contexts

Hi Pavel, > Any chance these relates to what you are looking for? > > "Automatic Discovery of LDAP Servers" [1] and "Manually Following > Referrals" [2]? I know both but cannot/refuse to use them. As for [1]: It suffers from https://bugs.openjdk.java.net/browse/JDK-8149521 plus I can neither lo

Re: RFR [9] 8148863: Remove sun.misc.ManagedLocalsThread from corba

On 19 Apr 2016, at 13:18, Mark Sheppard wrote: > > the moniker PEPT-Transport-Thread for the SelectorImpl is a bit like the name > Sue in the Johnny Cash song ... > > perhaps ORB-Selector-Thread would be more favourable Ok, that’s better. > also maybe go the "whole hog" with Async-Request-I

Re: [JNDI/LDAP] Intercepting LDAP URLs with initial and referral directory contexts

Any chance these relates to what you are looking for? "Automatic Discovery of LDAP Servers" [1] and "Manually Following Referrals" [2]? [1] http://docs.oracle.com/javase/jndi/tutorial/ldap/connect/create.html [2] ht

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

On 19/04/2016 10:54 PM, Gerard Ziemski wrote: On Apr 19, 2016, at 12:04 AM, David Holmes wrote: On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: Hi Gerard, 2016/04/19 3:14 "Gerard Ziemski" mailto:gerard.ziem...@oracle.com>>: hi Yasumasa, Nice work. I have 2 questions: File: java.

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

> On Apr 19, 2016, at 12:04 AM, David Holmes wrote: > > On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >> Hi Gerard, >> >> 2016/04/19 3:14 "Gerard Ziemski" > >: >> > >> > hi Yasumasa, >> > >> > Nice work. I have 2 questions: >> > >> > >> > File: java.c

Re: RFR [9] 8148863: Remove sun.misc.ManagedLocalsThread from corba

the moniker PEPT-Transport-Thread for the SelectorImpl is a bit like the name Sue in the Johnny Cash song ... perhaps ORB-Selector-Thread would be more favourable also maybe go the "whole hog" with Async-Request-Invoker-Thread, please just like naming children very emotive :-) regards Mark

Re: Multi-Release JAR runtime support

> On 19 Apr 2016, at 14:11, Paul Sandoz wrote: > > >> On 19 Apr 2016, at 09:46, Alan Bateman > > wrote: >> >> >> >> On 19/04/2016 02:49, Hervé BOUTEMY wrote: >>> : >>> >>> But the unexpected part is that JRE 9, either classical or jigsaw, don't >>> take >>>

Re: Multi-Release JAR runtime support

> On 19 Apr 2016, at 09:46, Alan Bateman wrote: > > > > On 19/04/2016 02:49, Hervé BOUTEMY wrote: >> : >> >> But the unexpected part is that JRE 9, either classical or jigsaw, don't take >> advantage of the MR JAR: is this really expected, or did I do something >> wrong? > Hervé - can you du

[JNDI/LDAP] Intercepting LDAP URLs with initial and referral directory contexts

Hi folks, I am looking for a clean way to intercept/alter LDAP URLs for both cases: initial and referrals (follow) before the directory context is created actually. In detail, I need to perform some AD related SRV lookups and replace the provided hostname which is actually a naming context with

Re: RFR [9] 8148863: Remove sun.misc.ManagedLocalsThread from corba

On 19/04/2016 11:17, Chris Hegarty wrote: : I took another pass over the names. Updated in-place http://cr.openjdk.java.net/~chegar/8148863/ Looks okay although there still some inconsistencies - for example "POA-Destroy-Thread" vs. other POA threads that are named "Etherealizer-Thread" a

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

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 bulk periodically, often closer to the end a

Re: JDK 9 pre-review of JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract

Hi, On 04/19/2016 01:05 AM, Stuart Marks wrote: On 4/17/16 10:31 AM, joe darcy wrote: With talk of deprecation in the air [1], I thought it would be a fine time to "In the Spring a young man's fancy lightly turns to thoughts of deprecation." -- apologies to Tennyson examine one of t

Re: RFR [9] 8148863: Remove sun.misc.ManagedLocalsThread from corba

On 19 Apr 2016, at 09:55, Alan Bateman wrote: > > On 18/04/2016 21:50, Chris Hegarty wrote: >> This change updates the code in the cobra module to use the new >> Thread constructor that suppresses inheritable-thread-local initial >> values. >> >> http://cr.openjdk.java.net/~chegar/8148863/ >>

RFR: 8072921: -Xincgc should be removed from output

Hi all, I hope this is the right list for this RFR. Please review this patch to remove the -Xincgc output from the java launcher. http://cr.openjdk.java.net/~stefank/8072921/webrev.01 https://bugs.openjdk.java.net/browse/JDK-8072921 The output can be seen by running 'java -X': $ ../build/lin

Re: RFR [9] 8148863: Remove sun.misc.ManagedLocalsThread from corba

On 18/04/2016 21:50, Chris Hegarty wrote: This change updates the code in the cobra module to use the new Thread constructor that suppresses inheritable-thread-local initial values. http://cr.openjdk.java.net/~chegar/8148863/ https://bugs.openjdk.java.net/browse/JDK-8148863 I’m open to sugges

Re: RFR:JDK-8031085:DateTimeFormatter won't parse dates with custom format "yyyyMMddHHmmssSSS"

Hi Stephen, Thanks for the comments. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8031085/webrev.01/ -- Thanks and Regards, Nadeesh TV On 4/18/2016 3:03 AM, Stephen Colebourne wrote: The updated spec at line 670 is not clear - the adjacent parsing mode only applies when i

Re: RFR [9] 8148863: Remove sun.misc.ManagedLocalsThread from corba

Looks good Chris. Regards, Sean. On 18/04/2016 21:50, Chris Hegarty wrote: This change updates the code in the cobra module to use the new Thread constructor that suppresses inheritable-thread-local initial values. http://cr.openjdk.java.net/~chegar/8148863/ https://bugs.openjdk.java.net/brows

Re: RFR: 8154470: defines.h confused about PROGNAME and JAVA_ARGS

On 19/04/2016 00:53, Kumar Srinivasan wrote: Hi Martin, Tested with jprt, seems to be ok, the changes are ok with me. Unless Alan has some reservations. No reservations, looks okay to me too. -Alan

Re: Multi-Release JAR runtime support

On 19/04/2016 02:49, Hervé BOUTEMY wrote: : But the unexpected part is that JRE 9, either classical or jigsaw, don't take advantage of the MR JAR: is this really expected, or did I do something wrong? Hervé - can you dump the manifest? It's not clear from your mail that it has the Multi-Relea