August 2014 - core-libs-dev

Re: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net
by Mike Duigou 10 Sep '14

10 Sep '14

On Aug 14 2014, at 06:39 , Alan Bateman <Alan.Bateman(a)oracle.com> wrote: > On 14/08/2014 14:23, Claes Redestad wrote: >> How about methods only taking beginIndex? Integer.parseInt("x: 10000000", 3, 10)? I guess these could to be dropped >> to avoid ambiguity and instead allow for variations where radix can be left out. >> >> I think there are two alternatives to the current implementation: >> - only keep parseInt(CharSequence s, int beginIndex, int endIndex, int radix) > That's my preference Looking at the examples I agree that providing only this one method is probably the least error prone option. Mike > and core-libs-dev would be the place to move the discussion. > > -Alan. > > >> - optional radix: parseInt(CharSequence s, int beginIndex, int endIndex), parseInt(CharSequence s, int beginIndex, int endIndex, int radix) >> >> (Should this discussion be moved to core-libs-dev?) >> >> /Claes >

3 2

Replace concat String to append in StringBuilder parameters
by Otávio Gonçalves de Santana 09 Sep '14

09 Sep '14

*Motivation:* Make another append instead of concat String inside of append parameter in StringBuilder class. To avoid an extra StringBuilder created for the purpose of concatenating. So it will save memory and will faster than concat String. Doing a code to benchMark[1], the result is: Benchmark Mode Samples Mean Mean error Units m.StringBuilderConcatBenchMark.stringBuilder thrpt 10 6317444.705 108673.584 ops/s m.StringBuilderConcatBenchMark.stringBuilderWithConcat thrpt 10 3354554.435 68353.924 ops/s The webrev of all code is: https://dl.dropboxusercontent.com/u/16109193/open_jdk/string_builder_concat… <https://dl.dropboxusercontent.com/u/16109193/open_jdk/string_builder_concat…> [1] @State(Scope.Thread) @OutputTimeUnit(TimeUnit.SECONDS) public class StringBuilderConcatBenchMark { private static final String F = "!!!!"; private static final String E = " running in Java "; private static final String D = " in the code "; private static final String C = " to try impact "; private static final String B = " with some text "; private static final String A = "Doing a test"; @GenerateMicroBenchmark public void stringBuilder(BlackHole bh) { bh.consume(createBuilder(A, B, C, D, E, F)); } @GenerateMicroBenchmark public void stringBuilderWithConcat(BlackHole bh) { bh.consume(createBuilderWithConcat(A, B, C, D, E, F)); } private StringBuilder createBuilder(String... values) { StringBuilder text = new StringBuilder(); text.append(values[0]).append(values[1]) .append(values[2]).append(values[3]) .append(values[4]).append(values[5]); return text; } private StringBuilder createBuilderWithConcat(String... values) { StringBuilder text = new StringBuilder(); text.append(values[0] + values[1]) .append(values[2] + values[3]) .append(values[4]+ values[5]); return text; } } -- Otávio Gonçalves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: *http://about.me/otaviojava <http://about.me/otaviojava>* 55 (11) 98255-3513

17 69

Impact of code difference in Collection#contains() worth improving?
by Fabian Lange 08 Sep '14

08 Sep '14

Hi all, I have been involved recently in some theoretical or nonsensical discussions about microbenchmarking, jit compiling assemblies and so fort. One example was LinkedList vs ArrayList. What I noticed is that those two have a different implementation for contains(): ArrayList: public boolean contains(Object o) { return indexOf(o) >= 0; } LinkedList: public boolean contains(Object o) { return indexOf(o) != -1; } Logically this is of course identical due to the contract of contains which returns either -1 or the >=0 index of the element. This code has been like this almost forever, and I was wondering if this actually makes a difference in CPU cycles. And in fact this code compiles into different assembler instructions. The array list does a test against 0 and conditional move, while the linked list does a jump equals on -1. Again that is not surprising, because the actual java source is different. But I wonder if both options are equally good in cold performance and when jitted based on parameter values. Wouldn't one implementation be better than the other? And why is not the "better" implementation taken in both classes (and maybe other Collections which use indexOf) ? Is the answer that this has always been like this and the benefit is not worth the risk of touching ancient code? And if not for performance, would code clarify and similarity be an argument? (this message was posted to jdk8-dev initially, thanks to Dalibor Topic for the pointer to this list) Fabian

10 29

RFR: JDK-8054987: (reflect) Add sharing of annotations between instances of Executable
by Joel Borggren-Franck 08 Sep '14

08 Sep '14

Hi all, Cleaning out the patch queue, I found this small patch that adds sharing of conceptually immutable annotation maps between instances of Executable representing the same executable. In short, Method/Constructor contain one bit of mutable state, if they have been set accessible or not. Core Reflection keeps a 'root' instance of an executable and copies it whenever you call get(Declared){Method|Constructor}. When using an Executable to look at annotations each copy you query for annotations, for exampel m1.getAnnotations(), gets its own LinkedHashMap containing the annotations. The map is then flattned and handed out to the client as a newly allocated array. This patch queries the root method for its map thus sharing annotation instances. It still hands out a unique array for each invocation but the Map and the instances are shared. Webrev: http://cr.openjdk.java.net/~jfranck/8054987/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8054987 cheers /Joel

3 8

About JDK-8042694
by Harshad RJ 06 Sep '14

06 Sep '14

Hi, I hit this bug in my own application today: https://bugs.openjdk.java.net/browse/JDK-8042694 My app uses the h2 database which installs a shutdown hook. Works fine, but while running with JNLP, the shutdown hook thrown an exception, probably because the JAR gets closed too early. I can't find a way to register on the JIRA site, hence posting here. I would like to know why was the bug closed as "won't fix"? thanks, -- *Harshad RJ <http://lavadip.com>*

2 2

RFR (JAXP) 8056202: Xerces Update: Catalog Resolver
by huizhe wang 05 Sep '14

05 Sep '14

Hi, This is an update to Xerces' Catalog Resolver implementation. The changes were mostly performance related, for example the changes to the normalizeURI method in Catalog.java to avoid creating new Strings if the input is already in normalized form. Bug: https://bugs.openjdk.java.net/browse/JDK-8056202 Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8056202/webrev/ Thanks, Joe

2 2

[9] RFR (S) 8050173: Generalize BMH.copyWith API to all method handles
by Vladimir Ivanov 05 Sep '14

05 Sep '14

http://cr.openjdk.java.net/~vlivanov/8050173/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8050173 Added j.l.i.MethodHandle.copyWith(MethodType, LambdaForm) and provided implementation for all subclasses. Also, some cleanups: * rewrote MH.viewAsType on top of MH.copyWith; * extended MH.viewAsType to do strict checks w/ assertions turned on (new parameter: boolean strict); * extended MT.isViewableAs to accept both interface preserving and interface erasing conversions (new parameter: boolean keepInterfaces). Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. Reviewed-by: vlivanov, ? Contributed-by: john.r.rose(a)oracle.com Thanks! Best regards, Vladimir Ivanov

3 4

RFR: 8049343: (tz) Support tzdata2014f
by Aleksej Efimov 04 Sep '14

04 Sep '14

Hi, Please, review the tzdata2014f integration (with tzdata2014e related changes included too) [1] fix to JDK9: http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/ The tzdata2014f changes are extensive and relates mostly to timezone short names changes + "Asia/Srednekolymsk" time zone were added. Almost complete list of changes can be found in the JBS bug description [1], plus some changes wasn't documented in tzdata release notes - for such cases raw tzdata diff was used for the names modifications. Two issues with JSR310 implementation were discovered during integration process: First issue is related to the internal representation of the '24:00' value. The JSR310 implementation treats this value as a next day 00:00 time. The workaround already exists in JSR310 code for similar entries and this failure is resolved in similar way [2] as part of this update. For the second issue JDK-8051641 [3] was filled and 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only one that fails with this tzdata. Other time zone related tests [4] passes without failures. Thank you, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8049343 [2] http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share… [3] https://bugs.openjdk.java.net/browse/JDK-8051641 [4] TZ related test sets: test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/java/util/TimeZone test/java/time\ test/java/util/Formatter test/closed/java/util/Calendar test/closed/java/util/TimeZone

3 12

RFR: 8055776, Add tests to exercise SQLPermissions for DriverManager & SyncFactory
by Lance Andersen 03 Sep '14

03 Sep '14

Hi all, This is a request for review for This adds tests which exercise SQLPermissions for DriverManager and SyncFactory. The webrev can be found at http://cr.openjdk.java.net/~lancea/8055776/webrev.00/ Best, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen(a)oracle.com

2 3

ReferenceQueue.remove to allow GC of the queue itself
by Jaroslav Tulach 03 Sep '14

03 Sep '14

Hi. I'd like to add one new method into java.lang.ref.ReferenceQueue. Can anyone help me go through the review process? I've reported https://bugs.openjdk.java.net/browse/JDK-8051843 but that probably is not enough, right? Thanks in advance for your help. -jt

12 54