December 2012 - core-libs-dev

RFR: CR#8004561 : Additional Functional Interfaces and Updates
by Mike Duigou 26 Dec '12

26 Dec '12

Hello all; Here are some additional functional interfaces for review. The additions fill in holes for primitive types and for two operand "Bi" operations. http://cr.openjdk.java.net/~mduigou/8004561/0/webrev/ http://cr.openjdk.java.net/~mduigou/8004561/0/specdiff/java/util/function/p… Additionally, this patch contains naming updates on the existing functional interfaces following 335 EG review. It does not include the interface specializations and default methods previously proposed in CR#8004015. That proposal has been withdrawn. It turned out that user errors involving unexpected boxing were just too common for the value provided. Mike

3 2

hg: jdk8/tl/langtools: 8004893: the javadoc/doclet needs to be updated to accommodate lambda changes
by bhavesh.x.patel＠oracle.com 26 Dec '12

26 Dec '12

Changeset: 690c41cdab55 Author: bpatel Date: 2012-12-25 17:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/690c41cdab55 8004893: the javadoc/doclet needs to be updated to accommodate lambda changes Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MethodTypes.java ! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java + test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java + test/com/sun/javadoc/testLambdaFeature/pkg/A.java + test/com/sun/javadoc/testLambdaFeature/pkg/B.java ! test/com/sun/javadoc/testMethodTypes/TestMethodTypes.java

1 0

Re: RFR: CR#8004561 : Additional Functional Interfaces and Updates
by Brian Goetz 25 Dec '12

25 Dec '12

Yes, this is a deliberate u-turn that comes as a result of the unexpected interactions with the overloading resolution rules. By having DoubleBlock extending Block<Double>, we created problems for overloading. For example, consider this expected-to-be-common overloading in Bunch<T>: <U> Bunch<U> transform(Function<T,U> transformer) IntBunch transform(IntFunction<T> transformer) There are some conflicting rules in overload selection: - prefer more-specific SAMs to less specific (favors IntFunction) - prefer less boxing/unboxing What we'd like is to choose the former when the "natural" type of transformer is T -> Integer and the latter when the "natural" type is T -> int. But, because the more specific rule has higher priority, we would coerce a T -> Integer into a T -> int (with unboxing) all the time. On 12/20/2012 9:07 PM, Howard Lovatt wrote: > 1. DoubleBlock doesn't extend Block<Double> and doesn't have a default > method, similarly int and long > 2. Similarly all the rest like Function aren't extended > > Is this the correct link - it seems to have gone backwards? > > -- Howard. > > > On 21 December 2012 12:41, Mike Duigou <mike.duigou(a)oracle.com> wrote: > >> Hello all; >> >> Here are some additional functional interfaces for review. The additions >> fill in holes for primitive types and for two operand "Bi" operations. >> >> http://cr.openjdk.java.net/~mduigou/8004561/0/webrev/ >> >> http://cr.openjdk.java.net/~mduigou/8004561/0/specdiff/java/util/function/p… >> >> Additionally, this patch contains naming updates on the existing >> functional interfaces following 335 EG review. It does not include the >> interface specializations and default methods previously proposed in >> CR#8004015. That proposal has been withdrawn. It turned out that user >> errors involving unexpected boxing were just too common for the value >> provided. >> >> Mike >> >> > >

3 3

Updated unit test for BigInteger patch (#4837946)
by Tim Buktu 25 Dec '12

25 Dec '12

/On 01/30/2012 09:06 AM, Joe Darcy wrote:/ > On 01/27/2012 02:41 PM, Tim Buktu wrote: > >/ On 01/11/2012 11:59 AM, Joe Darcy wrote: > />>/ Thanks Tim. I'll add this to my review queue after Alan Eliasen's work > />>/ (finally) gets in. > />/ Is there a timeframe for this yet? > / > The timeframe is on the order of weeks to months. > > Cheers, > > -Joe Seeing as it's been a while, I was wondering if this is still being considered for JDK 8. Would it help if I made an updated patch against the current BigInteger.java? Thanks, Tim

1 0

RFR: JDK-8005263: Logging APIs takes Supplier<String> for message
by Henry Jen 24 Dec '12

24 Dec '12

Hi, This patch adds a couple APIs to java.util.logging.Logger so that construction of log messages only occurs when it is actually to be logged by using Supplier<String> instead of String. Since the idea is to avoid unnecessary construction of log messages, thus APIs imply formatting are not provided. Thus all forms of logrb and log with Parameters are not included. log with Throwable are named to be logEx or logpEx to avoid null ambiguous as it seems like it's quite common usage with logger.log(level, null, thrown) Specdiff and webrev can be found at following, http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/specdiff/diff.html http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/webrev/ Cheers, Henry

6 9

Review request:Updated JDK-8004728 Implement core reflection API for parameter reflection
by Eric McCorkle 22 Dec '12

22 Dec '12

Hello, Please review the implementation of the core reflection API for method parameter reflection. This changeset introduces a new class, Parameter, which represents information about method parameters. It introduces a new method into Executable which returns an array of the parameters for the method or constructor represented by the Executable. This is part of a larger set of changes which implement portions of the method parameter reflection functionality in hotspot and javac. The open webrev is here: http://cr.openjdk.java.net/~jgish/~emccorkl/webrev/JDK-8004729/ The feature request is here: http://bugs.sun.com/view_bug.do?bug_id=8004729 The latest version of the spec can be found here: http://cr.openjdk.java.net/~abuckley/8misc.pdf Thanks, Eric

7 10

RFR 8004547: Extend JavaFX launcher support...
by David DeHaven 22 Dec '12

22 Dec '12

Request for review for extending the launcher support to allow the JavaFX runtime to fully support all of it's launch features, including preloaders, classpath, etc.. Webrev: http://cr.openjdk.java.net/~ddehaven/8004547/webrev.1/ Corresponding JavaFX JIRA issue that these changes depend on: http://javafx-jira.kenai.com/browse/RT-26751 This should be the final step in adding launcher support for JavaFX applications. These changes should allow any future changes to be done entirely in the JavaFX runtime. The changes for RT-26751 are in this weeks promotion of JavaFX, so should be available in next weeks JRE build (I think.. I'm never sure about promotion timing..). -DrD-

4 11

EnumData space optimization in j.l.Class (JEP-146)
by Peter Levart 22 Dec '12

22 Dec '12

Hi David and others, Here's a patch that eliminates one of two fields in java.lang.Class, related to caching enum constants: http://dl.dropbox.com/u/101777488/jdk8-tl/JEP-149.enum/webrev.01/index.html It does it by moving one field to a subclass of HashMap, which is referenced by a remaining field that serves two different purposes/stages of caching. These are the results of a micro-benchmark that exercises public API that uses the internal j.l.Class API regarding enum constants: enum MyEnum { ONE, TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN } EnumSet.noneOf(MyEnum.class): 300_000_000 loops MyEnum.valueOf(String): 30_000_000 loops * 10 calls for different names ** Original JDK8 code Executing: /home/peter/Apps64/jdk1.8.0-jdk8-tl/bin/java -Xmx4G -cp ../out/production/test test.EnumTest reference EnumSet.noneOf(Class): 351610312 340302968 339893333 339774384 339750612 339558414 339547022 339621595 MyEnum.valueOf(String): 935153830 897188742 887541353 960839820 886119463 885818334 885827093 885752461 EnumSet.noneOf(Class): 339552678 339469528 339513757 339451341 339512154 339511634 339664326 339793144 ** patched java.lang.Class Executing: /home/peter/Apps64/jdk1.8.0-jdk8-tl/bin/java -Xmx4G -cp ../out/production/test -Xbootclasspath/p:../out/production/jdk test.EnumTest EnumSet.noneOf(Class): 351724931 339286591 305082929 305042885 305058303 305044144 305073463 305049604 MyEnum.valueOf(String): 955032718 908534137 891406394 891506147 891414312 893652469 891412757 891409294 EnumSet.noneOf(Class): 414044087 406904161 406788898 406839824 406765274 406815728 407002576 406779162 The slow-down of about 20% (last line) is presumably a consequence of another in-direction to obtain shared enum constants array when there is already a Map in place. It is still fast though (300M EnumSet instances / 0.4 s). Here's the source of the micro-benchmark: https://raw.github.com/plevart/jdk8-tl/JEP-149.enum/test/src/test/EnumTest.… I don't know what's more important in this occasion. A small space gain (8 or 4 bytes per j.l.Class instance) or a small performance gain (20%). Regards, Peter

4 10

hg: jdk8/tl/jdk: 8005280: (props) Improve test coverage for small XML parser
by huizhe.wang＠oracle.com 22 Dec '12

22 Dec '12

Changeset: c1227b872a12 Author: joehw Date: 2012-12-21 17:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1227b872a12 8005280: (props) Improve test coverage for small XML parser Summary: added a few more invalid XML files, international characters to LoadAndStore test, and a behavior compatibility test. Reviewed-by: alanb, lancea + test/java/util/Properties/Compatibility.xml + test/java/util/Properties/CompatibilityTest.java ! test/java/util/Properties/LoadAndStoreXML.java + test/java/util/Properties/invalidxml/BadDocType.xml - test/java/util/Properties/invalidxml/BadDocType.xml.excluded + test/java/util/Properties/invalidxml/DTDRootNotMatch.xml + test/java/util/Properties/invalidxml/IllegalComment.xml + test/java/util/Properties/invalidxml/IllegalEntry.xml + test/java/util/Properties/invalidxml/IllegalEntry1.xml + test/java/util/Properties/invalidxml/IllegalKeyAttribute.xml + test/java/util/Properties/invalidxml/NoDocType.xml - test/java/util/Properties/invalidxml/NoDocType.xml.excluded + test/java/util/Properties/invalidxml/NoNamespaceSupport.xml

1 0

RFR 8005281: (props) loadFromXML with small XML parser provider does not detect bad DOCTYPE
by Joe Wang 21 Dec '12

21 Dec '12

The cause of the LoadAndStoreXML test failure appeared to be that of 8005281 that Alan just fixed. Before the 8005281 patch, I was able to get the tests to pass when I isolated the relevant tests (that is, copy LoadAndStoreXML and remove other test cases). After the 8005281 patch, LoadAndStoreXML passed in its original form. I've also added a few more invalid xml files, plus international characters to testLoadAndStore. Webrev: http://cr.openjdk.java.net/~joehw/jdk8/8005280/webrev/ Thanks, Joe

3 7