December 2012 - core-libs-dev

Request for Review: Java SE 8 Compact Profiles
by David Holmes 14 Jan '13

14 Jan '13

The Java SE 8 Compact Profiles: http://openjdk.java.net/jeps/161 provides for subsetting of the Java SE 8 platform. While the specification covers the platform, we are only providing a reference implementation on Linux x86 at this time. This work is covered by a number of CRs due to there being a need for a number of CC requests to modifying existing specifications 8004265: Add build support for Compact Profiles 8004502: Compact Profiles contents 8003255: (profiles) Update JAR file specification to support profiles 8003256: (profiles) Add support for profile identification 8004931: add/removePropertyChangeListener should not exist in subset Profiles of Java SE The changes primarily involve the build, as you would imagine, the compact profiles define: - which files (binaries, jars, native libs) are in a JRE (profile-includes.txt) - which packages/classes are in rt.jar/resources.jar (profile-rtjar-includes.txt) But there are additional source changes: - to support reporting the profile name as part of version information - to test the versioning and tool changes and also changes to java, javac and jar so that you can indicate which profile you are targeting, and have javac make sure you don't use an API that won't be present; and which profile you need to run (listed in your executable jar) so the launcher can reject it if it isn't the right profile. The launcher and jar changes are included in this webrev, while the javac changes are being integrated separately (plus some related javadoc changes). Only the new build system is supported for building profiles. webrevs: top-level repo: http://cr.openjdk.java.net/~dholmes/8004265/webrev.top/ The main change is to simply add profiles and profiles-only as top level make targets (similar to images). There is also a change to remove the hardcoded version information (though this may be handled by a separate CR). jdk repo: http://cr.openjdk.java.net/~dholmes/8004265/webrev.jdk/ The overall build changes expand on the pre-existing definitions whereby a JRE is a JDK with things take out. So a compact JRE is then a JRE with additional things taken out. There are three compact profiles (compact1 being the smallest) and a full JRE. For internal build purposes these are referred to as PROFILE_1 etc, with a full JRE being represented by PROFILE_4 when needed. The specification for profiles indicates what is included in each profile, but the build rules then invert this to obtain a set of exclusions for each profile: the exclusions of a given profile is the set of inclusions of all larger profiles and the JRE (and of course the JDK). Please note I only expect build folks to look at build changes and core-libs to look at src/test changes (all of which have been developed by Alan Bateman) and there is no need to cross-post your responses. Like many I am about to head for Xmas break but I will continue to monitor email and deal with changes as needed. This is needed for M6 and we need to be ready to push in early January. Thanks, David Holmes

6 16

RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader)
by Daniel Fuchs 11 Jan '13

11 Jan '13

Hi, Here is a new webrev in the series that addresses using ServiceLoader in JAXP for JDK 8. 7169894: JAXP Plugability Layer: using service loader This changeset addresses modification in the javax.xml.stream package. It is similar to changes proposed for the javax.xml.parsers package [1], with a few differences due to the specificity of javax.xml.stream. Namely: 1. The XMLXxxxFactory.newInstance methods that takes parameter takes a property name, rather than a class name, and thus calls FactoryFinder.find. 2. One of the deprecated XMLOutputFactory.newInstance method had a bug - it used to return an XMLInputFactory - and was deprecated because of that - so I did preserve the bug. 3. The noarg newFactory() methods were leaking instances of the private FactoryFinder$ConfigurationError - my patch corrects that since it removes FactoryFinder$ConfigurationError. 4. In FactoryFinder.find() the ClassLoader parameter is often ignored, which makes the factories in the stream package behave differently from theirs cousins in the other packages. I believe this was an oversight due to (1). My patch will not fix that - I will instead log this as a separate issue. <http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.stream/webrev.00> best regards, -- daniel previous webrevs in the series: [1] javax.xml.parsers: <http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.parser/webrev.06> [2] javax.xml.datatype: <http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.datatype/webrev.02>

5 26

PPC Linux 64 needs -fsigned-char option for gcc
by Sean Chou 11 Jan '13

11 Jan '13

Hello, We found -fsigned-char is added to ppc platform, but not added to ppc64 platform. As they are different platforms, I think it is needed for ppc64 as well. Currently I just added one line modification as follow, but there may be more places to modify. If some one can give some comments, I can make a complete webrev. The buggy scenario we found needs closed code to reproduce, so it is not reproduced with current openjdk build on ppc linux from AIX porting project. I tested with ibmjdk, the patch works. I found CFLAGS_REQUIRED_ppc is from changeset http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/54d8193f177b . Is it enough to add ppc64 option for places ppc appears in that patch? ///////////////////////// the patch //////////////////////// diff --git a/make/common/Defs-linux.gmk b/make/common/Defs-linux.gmk --- a/make/common/Defs-linux.gmk +++ b/make/common/Defs-linux.gmk @@ -196,6 +196,7 @@ LDFLAGS_COMMON_sparc += -m32 -mcpu=v9 CFLAGS_REQUIRED_arm += -fsigned-char -D_LITTLE_ENDIAN CFLAGS_REQUIRED_ppc += -fsigned-char -D_BIG_ENDIAN +CFLAGS_REQUIRED_ppc64 += -fsigned-char -D_BIG_ENDIAN ifeq ($(ZERO_BUILD), true) CFLAGS_REQUIRED = $(ZERO_ARCHFLAG) ifeq ($(ZERO_ENDIANNESS), little) -- Best Regards, Sean Chou

4 4

RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family
by Aleksey Shipilev 10 Jan '13

10 Jan '13

Hi, Sorry for cross-list posting, but this change affects both HS and JDK. This simple change is missing from recently committed CR 7023898. While the VM support is there in Hotspot, no methods are exposed in Unsafe to actually make use of those intrinsics. This is the webrev fixing that: http://cr.openjdk.java.net/~shade/8004330/webrev.00/ It turns out the getAndSet intrinsics HotSpot are overloaded, which had deluged both Doug and me in the previous patch. These namings are inconsistent with other Unsafe intrinsic naming convention, so this change fixes that as well. Testing: - Built and tested in Linux x86_64 - java-concurrency-torture [1] atomicity tests are passed for AtomicIntegerV8 [2] and AtomicLongV8 [3] making use of those intrinsics on Linux x86_64 - running the java-concurrency-torture tests "-XX:+PrintInlining | grep Unsafe" tells all intrinsics have been successfully inlined - no other testing is expected for this trivial change. I would need a sponsor to push this. Thanks for your patience and reviews! Contributors: - dl: original patch, testing - shade: due diligence, messing with reviews, tests, and rebuilds -Aleksey. [1] https://github.com/shipilev/java-concurrency-torture/ [2] https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/j… [3] https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/j…

5 15

javax.sql.rowset.serial.SerialBlob doesn't support free and getBinaryStream
by Deven You 10 Jan '13

10 Jan '13

Hi All, First of all, if the jdbc problem has a better mailing list to post please tell me. I find that javax.sql.rowset.serial.SerialBlob is not fully implemented in OpenJDK 8. Methods public InputStream getBinaryStream(long pos,long length) throws SQLException public void free() throws SQLException only throw UnsupportedOperationException. I have made a patch[1] to implement these 2 methods. Could anyone take a look to review it. BTW: I think the spec for SerialBlob is not very clear like it doesn't mention if all method rather than free() need throw any exception after free() is invoked. However that behavior seems reasonable. [1] http://cr.openjdk.java.net/~littlee/OJDK-576/webrev Thanks a lot. -- Best Regards, Deven

3 14

Scaling problem of HashMap (introduced with alternative hashing)
by Zhong Yu 07 Jan '13

07 Jan '13

Reported by the SO question http://stackoverflow.com/questions/14010906 the HashMap constructor contains a CAS, which is kind of surprising. Could it be removed? transient final int hashSeed = sun.misc.Hashing.randomHashSeed(this); // CAS Zhong Yu

10 16

RFR : 8003228 : (props) sun.jnu.encoding should be set to UTF-8 [macosx]
by Brent Christian 03 Jan '13

03 Jan '13

Hi, I've prepared a JDK 8 fix for 8003228 [1]. The webrev is here: http://cr.openjdk.java.net/~bchristi/8003228/webrev.00/ JPRT passes on all platforms (with the exception of two known bugs[2]). There was some recent discussion related to this - see [3]. Thanks, -Brent [1] http://bugs.sun.com/view_bug.do?bug_id=8003228 [2] 8005195 (Doclint tests on Windows), 8004544 (FDSeparateCompilationTest timeout) [3] http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-November/005124…

3 5

RFR: (jaxp) 8005473 : Warnings compiling jaxp
by Joe Wang 03 Jan '13

03 Jan '13

Hi, This is a patch to clean up compiling warnings in jaxp. Bug: http://bugs.sun.com/view_bug.do?bug_id=8005473 Webrev: http://cr.openjdk.java.net/~joehw/jdk8/8005473/webrev/ Thanks, Joe

5 9

RMI java processes left running on JPRT systems
by Kelly O'Hair 03 Jan '13

03 Jan '13

FYI... After shutting down JPRT I found two systems with ActivationGroupInit java processes running. I am assuming that a test case has fired them up and forgotten about them??? Not sure why JPRT did not kill them automatically... -kto jprtadm@sc11136053:~> jps -l -m 11651 sun.tools.jps.Jps -l -m 16530 sun.rmi.server.ActivationGroupInit jprtadm@sc11136053:~> ps -fel | fgrep java 0 S jprtadm 11669 11603 0 80 0 - 511 pipe_w 12:35 pts/0 00:00:00 fgrep java 0 S jprtadm 16530 1 0 80 0 - 239212 futex_ Dec27 ? 00:01:02 /opt/jprt/T/P1/211212.chhegar/testproduct/linux_i586_2.6-product/jre/bin/java -Djava.security.manager=default -Djava.security.policy=/opt/jprt/T/P1/211212.chhegar/s/jdk/test/java/rmi/activation/ActivationSystem/unregisterGroup/group.security.policy -DunregisterGroup.port=53315 -Dtest.src=/opt/jprt/T/P1/211212.chhegar/s/jdk/test/java/rmi/activation/ActivationSystem/unregisterGroup -Dtest.classes=/opt/jprt/T/P1/211212.chhegar/s/jdk/build/linux-i586/testoutput/jdk_rmi/JTwork/classes/java/rmi/activation/ActivationSystem/unregisterGroup sun.rmi.server.ActivationGroupInit jprtadm@sc11136053:~> uname -a Linux sc11136053 2.6.27.25-78.2.56.fc9.i686 #1 SMP Thu Jun 18 12:47:50 EDT 2009 i686 i686 i386 GNU/Linux jprtadm@sc11136053:~> jprtadm@sc11136024:~> jps -l -m 17187 sun.rmi.server.ActivationGroupInit 5809 sun.tools.jps.Jps -l -m 12314 sun.rmi.server.ActivationGroupInit jprtadm@sc11136024:~> ps -fel | fgrep java 0 S jprtadm 12314 1 0 80 0 - 239252 futex_ Dec26 ? 00:01:26 /opt/jprt/T/P1/172428.jzavgren/testproduct/linux_i586_2.6-product/jre/bin/java -Djava.security.manager=default -DunregisterGroup.port=42896 -Djava.security.policy=/opt/jprt/T/P1/172428.jzavgren/s/jdk/test/java/rmi/activation/ActivationSystem/unregisterGroup/group.security.policy -Dtest.src=/opt/jprt/T/P1/172428.jzavgren/s/jdk/test/java/rmi/activation/ActivationSystem/unregisterGroup -Dtest.classes=/opt/jprt/T/P1/172428.jzavgren/s/jdk/build/linux-i586/testoutput/jdk_rmi/JTwork/classes/java/rmi/activation/ActivationSystem/unregisterGroup sun.rmi.server.ActivationGroupInit 0 S jprtadm 17187 1 0 80 0 - 239231 futex_ Dec27 ? 00:00:52 /opt/jprt/T/P1/020528.jcg-int/testproduct/linux_i586_2.6-product/jre/bin/java -Djava.security.policy=/opt/jprt/T/P1/020528.jcg-int/s/jdk/test/java/rmi/activation/ActivationSystem/unregisterGroup/group.security.policy -Djava.security.manager=default -DunregisterGroup.port=43443 -Dtest.src=/opt/jprt/T/P1/020528.jcg-int/s/jdk/test/java/rmi/activation/ActivationSystem/unregisterGroup -Dtest.classes=/opt/jprt/T/P1/020528.jcg-int/s/jdk/build/linux-i586/testoutput/jdk_rmi/JTwork/classes/java/rmi/activation/ActivationSystem/unregisterGroup sun.rmi.server.ActivationGroupInit

2 1

RFR 2: JDK-8005263: Logging APIs takes Supplier<String> for message
by Henry Jen 02 Jan '13

02 Jan '13

Hi, Update patch with review feedback, - JavaDoc update for benefit and gotcha. - logEx/logpEx is not log/logp with Supplier<String> as last argument. As a matter of fact, all API with Supplier<String> takes it as last argument. - No more doLog(Level, Supplier<String>, Block<LogRecord>) helper for performance concerns. Specdiff and webrev can be found at following, http://cr.openjdk.java.net/~henryjen/ccc/8005263.1/specdiff/diff.html http://cr.openjdk.java.net/~henryjen/ccc/8005263.1/webrev/ Cheers, Henry

6 15