June 2014 - core-libs-dev

[PATCH] LambdaTranslationTest[1|2] may fail when executed with other locale than US
by Andrej Golovnin 21 Jun '14

21 Jun '14

Hi Joel, as I already wrote [1] the tests jdk/lambda/LambdaTranslationTest1.java jdk/lambda/LambdaTranslationTest2.java fails when they are executed with other locale than US. The tests make use of Locale sensitive APIs and assume that the current Locale has the same formatting rules as Locale.US. The test LambdaTranslationTest1 fails with the message: test LambdaTranslationTest1.testMethodRefs(): failure java.lang.AssertionError: expected [d:1234.000000] but found [d:1234,000000] The test LambdaTranslationTest2 fails with the message: test LambdaTranslationTest2.testBoxing(): failure java.lang.AssertionError: expected [b1 s2 cA i4 j5 ztrue f6,000000 d7,000000] but found [b1 s2 cA i4 j5 ztrue f6.000000 d7.000000] To reproduce the failure you should execute following commands in the shell (tested only on Linux): export LANG=de_DE.utf8 export LC_PAPER=de_DE.utf8 export LC_MONETARY=de_DE.utf8 export LC_NUMERIC=de_DE.utf8 export LC_MEASUREMENT=de_DE.utf8 export LC_TIME=de_DE.utf8 make test TEST=jdk_lang I have created patch to fix this problem. The patch is attached to this mail. Best regards, Andrej Golovnin [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027194.html

1 0

Review request: 8044063: Remove com.sun.java.browser.* from jdk repo
by Mandy Chung 20 Jun '14

20 Jun '14

com.sun.java.browser.dom and com.sun.java.browser.net classes are legacy and only used by old plugin. Time to remove them. Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8044063/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8044063 Jon - having a second thought and decide to clean up the CreateSymbols of the removal of these packages just for completeness. Can you review the langtools change? Thanks Mandy

3 3

RFR: 8047721: @since should have JDK version
by Paul Benedict 20 Jun '14

20 Jun '14

Henry, I think "JCE1.2" should get the space to be "JCE 1.2" so it matches other secondary versions like "JNDI 1.1" (last part of your patch). Or, you could make that another cleanup in itself. Cheers, Paul

3 3

Please review: (JDK-8044866) Fix raw and unchecked lint warnings in asm
by Kumar Srinivasan 20 Jun '14

20 Jun '14

Hi Joe, all, Please approve fix for removings warnings in asm, this is merely a mini refresh from upstream sources, I have verified there are no more warnings in asm sources. http://cr.openjdk.java.net/~ksrini/8044866/webrev/ Thanks Kumar PS: many thanks to Remi Forax for pushing these fixes into the upstream source base.

2 1

Optimizations to create instances in Number classes and Character
by Otávio Gonçalves de Santana 20 Jun '14

20 Jun '14

The Number classes (Integer, Short, Byte, Long) and Character have cache and it is used when is called the valueOf method, this way it creates new instances when is necessary. Using the valueOf, when the value is in the cache, beyond save memory will faster than always create new instances. [1] WebDrev: https://dl.dropboxusercontent.com/u/16109193/open_jdk/number_character.zip Benchmark (size) Mode Samples Mean Mean error Units m.InstancesBenchmark.newInstanceByte 1000000 thrpt 10 295.250 3.964 ops/s m.InstancesBenchmark.newInstanceChar 1000000 thrpt 10 290.962 6.096 ops/s m.InstancesBenchmark.newInstanceInteger 1000000 thrpt 10 280.035 5.997 ops/s m.InstancesBenchmark.newInstanceLong 1000000 thrpt 10 195.535 5.326 ops/s m.InstancesBenchmark.newInstanceShort 1000000 thrpt 10 289.213 6.920 ops/s m.InstancesBenchmark.valueOfByte 1000000 thrpt 10 457.773 0.788 ops/s m.InstancesBenchmark.valueOfChar 1000000 thrpt 10 343.380 1.364 ops/s m.InstancesBenchmark.valueOfInteger 1000000 thrpt 10 332.707 1.771 ops/s m.InstancesBenchmark.valueOfLong 1000000 thrpt 10 336.833 3.318 ops/s m.InstancesBenchmark.valueOfShort 1000000 thrpt 10 333.420 0.651 ops/s [1] import java.util.ArrayList; import java.util.List; import java.util.Random; import java.util.concurrent.TimeUnit; import org.openjdk.jmh.annotations.GenerateMicroBenchmark; import org.openjdk.jmh.annotations.OutputTimeUnit; import org.openjdk.jmh.annotations.Scope; import org.openjdk.jmh.annotations.State; import org.openjdk.jmh.annotations.Param; import org.openjdk.jmh.annotations.Setup; import org.openjdk.jmh.logic.BlackHole; @State(Scope.Thread) @OutputTimeUnit(TimeUnit.SECONDS) public class InstancesBenchmark { @Param("1000000") private int size; private Random random; private short[] shorts; private byte[] bytes; private int[] interges; private long[] longs; private char[] chars; @Setup public void s() { random = new Random(); shorts = new short[size]; bytes = new byte[size]; interges = new int[size]; longs = new long[size]; chars = new char[size]; for (int i = 0; i < size; i++) { int value = random.nextInt(); longs[i] = (long) value; interges[i] = value; shorts[i] = (short) value; bytes[i] = (byte) value; chars[i] = (char) value; } } @GenerateMicroBenchmark public void valueOfInteger(BlackHole bh) { for (int value : interges) { Integer number = value; bh.consume(number); } } @GenerateMicroBenchmark public void newInstanceInteger(BlackHole bh) { for (int value : interges) { Integer number = new Integer(value); bh.consume(number); } } @GenerateMicroBenchmark public void valueOfLong(BlackHole bh) { for (long value : longs) { Long number = value; bh.consume(number); } } @GenerateMicroBenchmark public void newInstanceLong(BlackHole bh) { for (long value : longs) { Long number = new Long(value); bh.consume(number); } } @GenerateMicroBenchmark public void valueOfByte(BlackHole bh) { for (byte value : bytes) { Byte number = value; bh.consume(number); } } @GenerateMicroBenchmark public void newInstanceByte(BlackHole bh) { for (byte value : bytes) { Byte number = new Byte(value); bh.consume(number); } } @GenerateMicroBenchmark public void valueOfShort(BlackHole bh) { for (short value : shorts) { Short number = value; bh.consume(number); } } @GenerateMicroBenchmark public void newInstanceShort(BlackHole bh) { for (short value : shorts) { Short number = new Short(value); bh.consume(number); } } @GenerateMicroBenchmark public void valueOfChar(BlackHole bh) { for (char value : chars) { Character number = value; bh.consume(number); } } @GenerateMicroBenchmark public void newInstanceChar(BlackHole bh) { for (char value : chars) { Character number = new Character(value); bh.consume(number); } } } -- Atenciosamente. Otávio Gonçalves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513

1 0

[9] request for review 8047353: Improve error message when a JAR with invalid signatures is loaded
by Vincent Ryan 20 Jun '14

20 Jun '14

Please review the following simple changeset to identify the offending JAR file following a signature verification error. Previously, only the offending entry in the JAR was identified. This helps during troubleshooting when several JAR files being processed. The request was originally submitted by Aaron Digulla. Bug: https://bugs.openjdk.java.net/browse/JDK-8047353 Webrev: http://cr.openjdk.java.net/~vinnie/8047353/webrev.00/

3 5

RFR: JDK-8042369 Remove duplicated java.time classes in build.tools.tzdb
by Xueming Shen 19 Jun '14

19 Jun '14

Hi Please help review the change for #8042369 Issue: https://bugs.openjdk.java.net/browse/JDK-8042369 Webrev: http://cr.openjdk.java.net/~sherman/8042369/webrev In jdk8 we had to duplicate dozen java.time classes in build.tools to build the timezone data for the new JSR310 timezone data compiler, which uses the new jdk8 java.time classes (these classes don't exit in the < 8 boot jdk). JDK9 has switched to use the jdk8 as the boot jdk, so most of these duplicated classes are no longer needed, with ZoneRules as the only exception. The ZoneRules is still needed to help the tzdb compiler to output the tzdb data in the serialization forms of those transitions and rules. The proposed change here is to remove those unneeded duplicated classes. I also took the opportunity to re-organize/re-wrote the "builder" classes to have a faster, simpler and and straightforward implementation, with the goal of migrating it into a second default ZoneRulesProvider later to plug it into jdk, so jdk/jre can uses the tzdb source data from the IANA directly. One of the benefits of such a provider is that the end user may just drop the latest timezone data file into the jdk/jre and go, without waiting for the latest timezone binary bits from Oracle. Here is the webrev for the idea http://cr.openjdk.java.net/~sherman/tzdbProvider/webrev/ The only disadvantage appears to be the possible "slowdown" of startup time because of the reading and compiling of the 200k tzdb source data...(we need another new "bridge" for j.u.TimeZone, if we go with this direction) Thanks! -Sherman

2 5

lambda reference to inner class in base class causes LambdaConversionException
by Remi Forax 19 Jun '14

19 Jun '14

I've just take a look to bug 8047341 [1] and I think it's a javac bug and not a bug in the lambda meta-factory, moreover, Eclipse generates a code which doesn't throw an exception at runtime. In list.stream().forEach(TestString::new), TestString::new reference the constructor of TestString which is an inner class (non static) of FooBase, so the constructor takes a hidden FooBase parameter so the method reference should refer to TestString(FooBase, String). The code generated by javac is: 14: aload_0 15: invokedynamic #5, 0 // InvokeDynamic #0:accept:(LFoo;)Ljava/util/function/Consumer; 20: invokeinterface #6, 2 // InterfaceMethod java/util/stream/Stream.forEach:(Ljava/util/function/Consumer;)V while Eclipse ecj generates: 14: aload_0 15: invokedynamic #27, 0 // InvokeDynamic #0:accept:(LFooBase;)Ljava/util/function/Consumer; 20: invokeinterface #28, 2 // InterfaceMethod java/util/stream/Stream.forEach:(Ljava/util/function/Consumer;)V as you can see, javac generate an invokedynamic call with a Foo instead of a FooBase which I think is the correct behavior. So for me, it's a bug in javac, not in the meta-factory. cheers, Rémi [1] https://bugs.openjdk.java.net/browse/JDK-8047341

2 2

RFR: 8046485: Add missing @since tag under javax.swing.*
by Henry Jen 19 Jun '14

19 Jun '14

Hi, Please review a trivial webrev that provides missing @since tag for elements under javax.swing, Essentially it's simply add @since 1.2 for all classes/interfaces/exception that are missing @since tag, as JDK 1.2 package.html has @since tag but was removed in 1.3. The @since tag is added to *.java instead of package.html so that we can have javac report javadoc via javax.lang.model.util.Elements.getDocComment(Element c). http://cr.openjdk.java.net/~henryjen/jdk9/8046485/0/webrev/ Cheers, Henry

4 8

RFR: 8046443 : A few typos in JAXP JavaDoc
by huizhe wang 18 Jun '14

18 Jun '14

Fix some typos in the JAXP documentation. Please review. http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/ Thanks, Joe

7 14