July 2015 - core-libs-dev

RFR 9: JDK-8130877 : (process) java/lang/ProcessHandle/TreeTest test3 failure - Destroyed process.isAlive
by Roger Riggs 14 Jul '15

14 Jul '15

Please review a testbug to correctly look for destroyed processes. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-isalive-8130877/ Issue: https://bugs.openjdk.java.net/browse/JDK-8130877 Thanks, Roger

2 2

Fwd: Re: [PATCH] javax,script.ScriptEngineFactory Typos
by A. Sundararajan 14 Jul '15

14 Jul '15

Forwarding this contribution from Ahmed to core-libs-dev alias as the change is going to be in "jdk/java.scripting/javax.script" code. PS. I'll send out webrev after build, test. Thanks Ahmed, -Sundar -------- Forwarded Message -------- Subject: Re: [PATCH] javax,script.ScriptEngineFactory Typos Date: Fri, 10 Jul 2015 07:46:40 +0200 From: Ahmed Ashour <asashour(a)yahoo.com> To: nashorn-dev(a)openjdk.java.net Dear all, Please find below a proposed patch based on jdk9/dev. Thanks, Ahmed diff -r b526c2584b4b src/java.scripting/share/classes/javax/script/ScriptEngineFactory.java --- a/src/java.scripting/share/classes/javax/script/ScriptEngineFactory.java Wed Jul 08 21:54:32 2015 -0400 +++ b/src/java.scripting/share/classes/javax/script/ScriptEngineFactory.java Thu Jul 09 08:10:26 2015 +0200 @@ -160,7 +160,6 @@ * } * ret += ")"; * return ret; - * } * } </pre> * * @param obj The name representing the object whose method is to be invoked. The @@ -190,8 +189,6 @@ * * @param toDisplay The String to be displayed by the returned statement. * @return The string used to display the String in the syntax of the scripting language. - * - * */ public String getOutputStatement(String toDisplay); @@ -208,14 +205,12 @@ * retval += statements[i] + ";\n"; * } * return retval += "?>"; - * } * }</pre> * * @param statements The statements to be executed. May be return values of * calls to the <code>getMethodCallSyntax</code> and <code>getOutputStatement</code> methods. * @return The Program */ - public String getProgram(String... statements); /** @@ -225,5 +220,5 @@ * * @return A new <code>ScriptEngine</code> instance. */ - public ScriptEngine getScriptEngine(); + public ScriptEngine getScriptEngine(); }

2 2

RFE: Intristics for asin, acos
by Nelson Dcosta 14 Jul '15

14 Jul '15

Hi Martin, Thank you reaching out to us regarding this report. This report is under evaluation and we have included this in our bug reporting system as https://bugs.openjdk.java.net/browse/JDK-8131132 . Feel free to drop me a mail at any time if you would like an update on the report. Regards, Nelson > > -------- Forwarded Message -------- > Subject: What happend to: '(Review ID: 9055455) - RFE: Intristics for > asin, acos' > Date: Mon, 13 Jul 2015 14:20:50 +0200 (CEST) > From: Janda Martin <jandam(a)crcdata.cz> > To: core-libs-dev <core-libs-dev(a)openjdk.java.net> > > > > Hi all, > > I would like to know what happened to '(Review ID: 9055455) - RFE: Intristics for asin, acos'. I made report onhttp://bugreport.java.com/. Is it under evaluation or bugreport.java.com is only black hole as somebody complained? > > Thank you for info > > Martin >

1 0

RFR [S] 8131034: Cleanup in j.u.regex.Pattern.quote()
by Ivan Gerasimov 13 Jul '15

13 Jul '15

Hello! There's a minor issue in the current implementation of Pattern.quote() with possible numeric overflow when calculating initial capacity of StringBuilder. With the fix, some slight optimizations were done and a few typos were fixed. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8131034 WEBREV: http://cr.openjdk.java.net/~igerasim/8131034/00/webrev/ Sincerely yours, Ivan

4 6

RFR [S] 6854417: TESTBUG: java/util/regex/RegExTest.java fails intermittently
by Ivan Gerasimov 13 Jul '15

13 Jul '15

Hello! RegExTest fails sometimes in checking Boyer-Moore search. This is because it was assumed that after insertion a pattern into a string at some position, we'll find it at the same position. That's not true if we insert 'aa' into 'xxaxx' at index 3, cause then we'll find 'aa' at index 2. The proposed fix is to exclude patterns that start and end with the same substring, because only those can cause this kind of problem. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-6854417 WEBREV: http://cr.openjdk.java.net/~igerasim/6854417/00/webrev/ Sincerely yours, Ivan

2 1

What happend to: '(Review ID: 9055455) - RFE: Intristics for asin, acos'
by Janda Martin 13 Jul '15

13 Jul '15

Hi all, I would like to know what happened to '(Review ID: 9055455) - RFE: Intristics for asin, acos'. I made report on http://bugreport.java.com/. Is it under evaluation or bugreport.java.com is only black hole as somebody complained? Thank you for info Martin

1 0

[9] RFR: 8130753: Sync-up javadoc changes in jax-ws area - includes JAX-B API, JAX-WS API, SAAJ-API
by Miroslav Kos 10 Jul '15

10 Jul '15

Hi everybody, I'd like to ask for review for following issue: JBS: 8130753: Sync-up javadoc changes in jax-ws area - includes JAX-B API, JAX-WS API, SAAJ-API webrev: http://cr.openjdk.java.net/~mkos/8130753/jaxws.01/ It addresses all the javadoc errors in all 3 JSRs: SAAJ, JAX-B and JAX-WS and it is also syncup with standalone repos. This clean-up had to be done in order to proceed with changes necessary for Jigsaw (specifically SAAJ API and possibly JAX-WS). Thanks Miran

4 5

Re: JDK9 changes to Date?
by Jochen Theodorou 09 Jul '15

09 Jul '15

That means the US locale cannot understand CET as timezone then? And... it assuming that TimeZone.getTimeZone('Etc/GMT') returns the GMT timezone, it means the short format for a date changed from using 70 for the year to 1970? Or is that CLDR related as well? bye blackdrag Am 09.07.2015 21:27, schrieb Naoto Sato: > I meant the root cause seems to be the same between your first issue and > 8130845, where parsing short time zone names has some problem regardless > of it's the ROOT locale or not. > > Naoto > > On 7/9/15 12:23 PM, Jochen Theodorou wrote: >> but both examples set a locale I thought >> >> Am 09.07.2015 21:06, schrieb Naoto Sato: >>> Hi Jochen, >>> >>> It is likely that these are caused by the default locale data change to >>> CLDR with 8008577. >>> >>> On 7/9/15 10:12 AM, Jochen Theodorou wrote: >>>> Hi, >>>> >>>> after fixing some JDK9 related bugs in our build for Groovy we stumbled >>>> over >>>> >>>> new SimpleDateFormat("EEE MMM dd HH:mm:ss zzz yyyy", >>>> Locale.US).parse("Thu Jan 01 01:00:00 CET 1970") >>>> >>>> failing to parse with >>>> >>>>> java.text.ParseException: Unparseable date: "Thu Jan 01 01:00:00 CET >>>>> 1970" >>>>> at java.text.DateFormat.parse(DateFormat.java:366) >>>> >>>> This happens not with my local machine using jdk1.9.0-ea-b68, but it >>>> does fail on our CI server used revision 0906b79c9df4 for this. >>> >>> This seems to be the same issue which has already been reported in >>> 8130845. >>> >>>> >>>> A second case is this one: >>>> >>>>> Locale locale = Locale.UK >>>>> Locale.setDefault locale >>>>> TimeZone.setDefault TimeZone.getTimeZone('Etc/GMT') >>>>> Date d = new Date(0) >>>>> assertEquals '01/01/70', >>>>> DateFormat.getDateInstance(DateFormat.SHORT).format(d); >>>> >>>> the assert used to work, but now the format changed to print 01/01/1970 >>>> instead of 01/01/70. With the same constellation regarding jdk >>>> versions. >>> >>> This is expected, as the short date format for UK in CLDR is "dd/MM/y". >>> >>> Naoto >> >> -- Jochen "blackdrag" Theodorou blog: http://blackdragsview.blogspot.com/

1 1

JDK9 changes to Date?
by Jochen Theodorou 09 Jul '15

09 Jul '15

Hi, after fixing some JDK9 related bugs in our build for Groovy we stumbled over new SimpleDateFormat("EEE MMM dd HH:mm:ss zzz yyyy", Locale.US).parse("Thu Jan 01 01:00:00 CET 1970") failing to parse with > java.text.ParseException: Unparseable date: "Thu Jan 01 01:00:00 CET 1970" > at java.text.DateFormat.parse(DateFormat.java:366) This happens not with my local machine using jdk1.9.0-ea-b68, but it does fail on our CI server used revision 0906b79c9df4 for this. A second case is this one: > Locale locale = Locale.UK > Locale.setDefault locale > TimeZone.setDefault TimeZone.getTimeZone('Etc/GMT') > Date d = new Date(0) > assertEquals '01/01/70', DateFormat.getDateInstance(DateFormat.SHORT).format(d); the assert used to work, but now the format changed to print 01/01/1970 instead of 01/01/70. With the same constellation regarding jdk versions. Are those expected to fail? Can someone verify this? bye Jochen Theodorou -- Jochen "blackdrag" Theodorou blog: http://blackdragsview.blogspot.com/

2 2

RFR [XXS] 8130646: JCK test api/java_io/StringWriter/index_SWWrite5Test start failing after JDK-8077242
by Ivan Gerasimov 09 Jul '15

09 Jul '15

Hi! With the fix for JDK-8077242 ((str) Optimize AbstractStringBuilder.append(CharSequence, int, int) for String argument) a change in behavior was introduced. In the places, where sb.append(str.substring(from, to)) used to be called, in the case of wrong indices StringIndexOutOfBoundsException was thrown. Now, after I replaced the code to sb.append(str, from, to), in such cases IndexOutOfBoundsException is thrown. The proposal is to make AbstractStringBuilder.append(CharSequence, int, int) throw more specific StringIndexOutOfBoundsException, which 1) will eliminate the regression, 2) will be more consistent with most other methods of AbstractStringBuilder, which throw StringIndexOutOfBoundsException. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8130646 WEBREV: http://cr.openjdk.java.net/~igerasim/8130646/00/webrev/ Sincerely yours, Ivan

2 4