8008290: (profiles) Startup regression due to additional checking of JAR file manifests
This one is a startup-time regression caused by the compact profiles work. As background, there was a lot of work done in the distant past on startup performance. Amongst the startup improvements was to the code that checks for the Class-Path attribute when opening JAR files so that it skips checking of known JAR files (in the JDK) and in addition do a quick search of the manifest to avoid parsing it when not present. These optimizations were disrupted by the profiles work so the change here is to fix this regression to get startup performance back to where it was previously. The changes are very simple, it just extends the implementation to check for the Profile attribute in the same way that we've always checked the Class-Path attribute. I've also refreshed the list of known JAR files as that has been stale for some time. The changes do mean the manifest bytes are searched twice and it might benefit from using a multi-pattern search and that it something for another day. So far, at least in the startup tests that I've run, it doesn't make any observable difference and startup performance is back to where it was. The webrev with the changes is here. I should point out that this is against jdk8/build as the changes aren't in jdk8/tl at this time. http://cr.openjdk.java.net/~alanb/8008290/webrev/ Finally, I should explain that the goal here is simply to get startup back to where it was. There is clearly other clean-up that should be done on this code at some point. Thanks, Alan.
hg: jdk8/tl/langtools: 6 new changesets
Changeset: d686d8a7eb78 Author:mcimadamore Date: 2013-02-21 15:19 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d686d8a7eb78 8008227: Mixing lambdas with anonymous classes leads to NPE thrown by compiler Summary: Disentangle cyclic dependency between static-ness of synthetic lambda method and static-ness of classes nested within lambdas Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/LambdaConv27.java Changeset: 3a39d123d33a Author:mcimadamore Date: 2013-02-21 15:21 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3a39d123d33a 8008276: assertion error in com.sun.tools.javac.comp.TransTypes.visitApply Summary: DiagnosticFilter used during speculative attribution is too broad Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java + test/tools/javac/lambda/speculative/MissingError.java + test/tools/javac/lambda/speculative/MissingError.out Changeset: f4fdd53f8b3e Author:mcimadamore Date: 2013-02-21 15:23 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f4fdd53f8b3e 8005183: Missing accessor for constructor reference pointing to private inner class ctor Summary: Compiler should add bridges when translating private constructor reference Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/MethodReference63.java Changeset: 7ac9242d2ca6 Author:mcimadamore Date: 2013-02-21 15:25 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7ac9242d2ca6 8008293: Declared bounds not considered when functional interface containing unbound wildcards is instantiated Summary: Wildcards inference should re-use some of the bounds info generated during capture conversion Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/TargetType64.java Changeset: 9f0ec00514b6 Author:mcimadamore Date: 2013-02-21 15:26 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9f0ec00514b6 8007461: Regression: bad overload resolution when inner class and outer class have method with same name Summary: Fix regression in varargs method resolution introduced by bad refactoring Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/resolve/Pos.java + test/tools/javac/resolve/tests/InnerOverOuter.java Changeset: 3fef0cae83b3 Author:mcimadamore Date: 2013-02-21 15:27 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3fef0cae83b3 8008444: Inherited generic functional descriptors are merged incorrectly Summary: Missing call to Types.createMethodWithThrownTypes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/LambdaConv25.java + test/tools/javac/lambda/LambdaConv25.out
Re: 8008290: (profiles) Startup regression due to additional checking of JAR file manifests
Alan, the changes look good and glad you added the extra comments for clarity. Best Lance On Feb 21, 2013, at 9:33 AM, Alan Bateman wrote: This one is a startup-time regression caused by the compact profiles work. As background, there was a lot of work done in the distant past on startup performance. Amongst the startup improvements was to the code that checks for the Class-Path attribute when opening JAR files so that it skips checking of known JAR files (in the JDK) and in addition do a quick search of the manifest to avoid parsing it when not present. These optimizations were disrupted by the profiles work so the change here is to fix this regression to get startup performance back to where it was previously. The changes are very simple, it just extends the implementation to check for the Profile attribute in the same way that we've always checked the Class-Path attribute. I've also refreshed the list of known JAR files as that has been stale for some time. The changes do mean the manifest bytes are searched twice and it might benefit from using a multi-pattern search and that it something for another day. So far, at least in the startup tests that I've run, it doesn't make any observable difference and startup performance is back to where it was. The webrev with the changes is here. I should point out that this is against jdk8/build as the changes aren't in jdk8/tl at this time. http://cr.openjdk.java.net/~alanb/8008290/webrev/ Finally, I should explain that the goal here is simply to get startup back to where it was. There is clearly other clean-up that should be done on this code at some point. Thanks, Alan. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: 8008290: (profiles) Startup regression due to additional checking of JAR file manifests
On 21/02/2013 16:11, Lance Andersen - Oracle wrote: Alan, the changes look good and glad you added the extra comments for clarity. +1 Trivially, I think you can remove the comment: * ## Add a fast path like Class-Path to avoid reading the manifest when the attribute *is not present. -Chris. Best Lance On Feb 21, 2013, at 9:33 AM, Alan Bateman wrote: This one is a startup-time regression caused by the compact profiles work. As background, there was a lot of work done in the distant past on startup performance. Amongst the startup improvements was to the code that checks for the Class-Path attribute when opening JAR files so that it skips checking of known JAR files (in the JDK) and in addition do a quick search of the manifest to avoid parsing it when not present. These optimizations were disrupted by the profiles work so the change here is to fix this regression to get startup performance back to where it was previously. The changes are very simple, it just extends the implementation to check for the Profile attribute in the same way that we've always checked the Class-Path attribute. I've also refreshed the list of known JAR files as that has been stale for some time. The changes do mean the manifest bytes are searched twice and it might benefit from using a multi-pattern search and that it something for another day. So far, at least in the startup tests that I've run, it doesn't make any observable difference and startup performance is back to where it was. The webrev with the changes is here. I should point out that this is against jdk8/build as the changes aren't in jdk8/tl at this time. http://cr.openjdk.java.net/~alanb/8008290/webrev/ Finally, I should explain that the goal here is simply to get startup back to where it was. There is clearly other clean-up that should be done on this code at some point. Thanks, Alan. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
RE: 8008290: (profiles) Startup regression due to additional checking of JAR file manifests
Hi, Alan. Very nice. Just curious. How are you testing startup? Custom micro benchmark or are you using something else? iris -Original Message- From: Alan Bateman Sent: Thursday, February 21, 2013 6:33 AM To: core-libs-dev Subject: 8008290: (profiles) Startup regression due to additional checking of JAR file manifests This one is a startup-time regression caused by the compact profiles work. As background, there was a lot of work done in the distant past on startup performance. Amongst the startup improvements was to the code that checks for the Class-Path attribute when opening JAR files so that it skips checking of known JAR files (in the JDK) and in addition do a quick search of the manifest to avoid parsing it when not present. These optimizations were disrupted by the profiles work so the change here is to fix this regression to get startup performance back to where it was previously. The changes are very simple, it just extends the implementation to check for the Profile attribute in the same way that we've always checked the Class-Path attribute. I've also refreshed the list of known JAR files as that has been stale for some time. The changes do mean the manifest bytes are searched twice and it might benefit from using a multi-pattern search and that it something for another day. So far, at least in the startup tests that I've run, it doesn't make any observable difference and startup performance is back to where it was. The webrev with the changes is here. I should point out that this is against jdk8/build as the changes aren't in jdk8/tl at this time. http://cr.openjdk.java.net/~alanb/8008290/webrev/ Finally, I should explain that the goal here is simply to get startup back to where it was. There is clearly other clean-up that should be done on this code at some point. Thanks, Alan.
Re: 8008290: (profiles) Startup regression due to additional checking of JAR file manifests
On 21/02/2013 16:42, Iris Clark wrote: Hi, Alan. Very nice. Just curious. How are you testing startup? Custom micro benchmark or are you using something else? A calendar :-) I'm using a performance test suite from the Oracle performance team. It's called refworkload and includes startup and footprint tests. Sorry, it's not in OpenJDK, we don't have anything in OpenJDK. -Alan
8008662: Add @jdk.Supported to JDK-specific/supported API
Joe Darcy recently added @jdk.Supported [1] to make it possible to identify JDK-specific APIs. I'd like to add this to a number of APIs in the com.sun namespace to make it obvious these are supported. Specifically I'm proposing to add it to: - Java Debug Interface (com.sun.jdi) - Attach API (com.sun.tools.attach) - SCTP API (com.sun.nio.sctp) - HTTP server API (com.sun.net.httpserver) - Management extensions (com.sun.management) - JDK-specific API to JAAS (com.sun.security.auth) - JDK-specific JGSS API (com.sun.security.jgss) The javadoc for all of these is generated as part of the regular JDK docs build and so shouldn't be controversial. There are a number of other candidates in com.sun with murkier status that I've stayed clear of for now. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/8008662/webrev/ In a couple of cases the package description is legacy package.html so I've had to move/convert them to package-info.java. In all but one case I've added the annotation to the package-info, the one exception is com.sun.management where there is at least one type that is documented as not supported. Joe Darcy might have suggestions on that. Otherwise this is mostly mechanical and the patch file is easier to review that the webrev. -Alan [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/55cca2f38ee6
Code review request: JDK-8008670 (partial java.util.stream implementation)
At: http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/ there is a webrev of a subset of the implementation of java.util.stream, for review. These are all new files. None of these are public classes; they are internal interfaces for the Stream library, as well as some implementation classes. This is about half the classes in the Streams package. (The webrev includes changes to Map, but those are being reviewed separately, so just ignore those.) We're asking people to focus their review on both the quality of API specification for these internal APIs, and the quality of implementation of the specified classes. It may not be obvious how some of these work until you've seen the rest of it, but do what you can.
Re: 8008662: Add @jdk.Supported to JDK-specific/supported API
Well, that was quite a few files to have to go through :-) Looks fine On Feb 21, 2013, at 1:46 PM, Alan Bateman wrote: Joe Darcy recently added @jdk.Supported [1] to make it possible to identify JDK-specific APIs. I'd like to add this to a number of APIs in the com.sun namespace to make it obvious these are supported. Specifically I'm proposing to add it to: - Java Debug Interface (com.sun.jdi) - Attach API (com.sun.tools.attach) - SCTP API (com.sun.nio.sctp) - HTTP server API (com.sun.net.httpserver) - Management extensions (com.sun.management) - JDK-specific API to JAAS (com.sun.security.auth) - JDK-specific JGSS API (com.sun.security.jgss) The javadoc for all of these is generated as part of the regular JDK docs build and so shouldn't be controversial. There are a number of other candidates in com.sun with murkier status that I've stayed clear of for now. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/8008662/webrev/ In a couple of cases the package description is legacy package.html so I've had to move/convert them to package-info.java. In all but one case I've added the annotation to the package-info, the one exception is com.sun.management where there is at least one type that is documented as not supported. Joe Darcy might have suggestions on that. Otherwise this is mostly mechanical and the patch file is easier to review that the webrev. -Alan [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/55cca2f38ee6 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: 8008290: (profiles) Startup regression due to additional checking of JAR file manifests
Alan, This fix looks good and the ## fast path ... comment can be taken out as Chris pointed out. A minor note - the list of known jar files seems to be incomplete (e.g. tzdb.jar and some windows-specific ones). I think it may be better to file a bug to follow up this and maybe even better to replace the hardcoded list with other mechanism (if appropriate). Mandy On 2/21/2013 6:33 AM, Alan Bateman wrote: This one is a startup-time regression caused by the compact profiles work. As background, there was a lot of work done in the distant past on startup performance. Amongst the startup improvements was to the code that checks for the Class-Path attribute when opening JAR files so that it skips checking of known JAR files (in the JDK) and in addition do a quick search of the manifest to avoid parsing it when not present. These optimizations were disrupted by the profiles work so the change here is to fix this regression to get startup performance back to where it was previously. The changes are very simple, it just extends the implementation to check for the Profile attribute in the same way that we've always checked the Class-Path attribute. I've also refreshed the list of known JAR files as that has been stale for some time. The changes do mean the manifest bytes are searched twice and it might benefit from using a multi-pattern search and that it something for another day. So far, at least in the startup tests that I've run, it doesn't make any observable difference and startup performance is back to where it was. The webrev with the changes is here. I should point out that this is against jdk8/build as the changes aren't in jdk8/tl at this time. http://cr.openjdk.java.net/~alanb/8008290/webrev/ Finally, I should explain that the goal here is simply to get startup back to where it was. There is clearly other clean-up that should be done on this code at some point. Thanks, Alan.
Re: 8008290: (profiles) Startup regression due to additional checking of JAR file manifests
On 21/02/2013 19:45, Mandy Chung wrote: Alan, This fix looks good and the ## fast path ... comment can be taken out as Chris pointed out. Yes, I put that comment in there as a reminder and should have removed it - thanks (and Chris). A minor note - the list of known jar files seems to be incomplete (e.g. tzdb.jar and some windows-specific ones). I think it may be better to file a bug to follow up this and maybe even better to replace the hardcoded list with other mechanism (if appropriate). The list doesn't have to be complete, this is just the JAR files that will be skipped. I completed list that hardcoded list needs clean-up (even the construction of) and that's the clean-up I hinted at in the first mail. I decided not to change in this round as I just wanted to restore the startup. Also it takes time to verify startup across a number of platforms so changing code in this area takes a bit longer to verify. -Alan
Re: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue()
My initial testing with another micro-benchmarking framework (other than Caliper) shows a performance increase of 900X for doubleValue() and 1500X for floatValue() on a MacBookPro5,3. There is some more evaluation yet to be done but we should be able to move this patch along pretty soon. Brian On Feb 15, 2013, at 4:41 PM, Brian Burkhalter wrote: Hi Louis, After the two issues for which I've posted review requests (6480539 - stripTrailingZeros(), 4396272 - Parsing doubles fails to follow IEEE) are resolved, issue 7131192 is currently very near the head of my queue. Given that I still have a ways to go to get up to speed on this entire topic area and code base, I would hesitate to give a date estimate just yet. Brian Any update on when this could get reviewed? On Thu, Dec 13, 2012 at 3:36 PM, Louis Wasserman lowas...@google.com wrote: Hi, I'm working at Google now, but I'd like to revive this patch as a contribution from Google. At the moment, what's mainly needed is review for http://bugs.sun.com/view_bug.do?bug_id=7192954, the fix to Float.parseFloat's rounding behavior, before we can go anywhere with the patch to optimize BigInteger.floatValue() and doubleValue(). Would anyone be able to review that patch so these can start moving forward? Thanks, Louis Wasserman Java Core Libraries Team @ Google guava-libraries.googlecode.com
Re: RFR: 8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries
Looks good to me other than the variable name. I'd prefer JDK_ARCH_ABI_NAME or JDK_ARCH_ABI_PROP_NAME over ARCHABIPROPNAME. Bob. On Feb 21, 2013, at 5:02 PM, Vladimir Danushevsky wrote: Please review changes for https://jbs.oracle.com/bugs/browse/JDK-8005545 Add System property to identify ARCH specific details such as ARM hard-float binaries which adds an optional sun.os.abi Java system property indicating an ABI type being used by the JVM: CCC Reguest: http://ccc.us.oracle.com/8005545 Webrev: http://cr.openjdk.java.net/~vladidan/8005545/webrev.00/ Separate change to the build script (e.g. in ARM Hard-Float ABI case): setenv ARCHABIPROPNAME gnueabihf -DARCHABIPROPNAME=\$(ARCHABIPROPNAME)\ is passed to the CFLAGS Thanks, Vlad
Withdraw: Review: 4396272 - Parsing doubles fails to follow IEEE for largest decimal that should yield 0
I am withdrawing this patch for the time being as properly the changes should also go into the fork sun.misc.FormattedFloatingDecimal. I'll post an updated patch once it is available. Thanks, Brian On Feb 14, 2013, at 5:23 PM, Brian Burkhalter wrote: The patch below is as submitted to OpenJDK bugzilla but with enhanced comments. It pertains to the correction loop in the doubleValue() method of FloatingDecimal. The situation appears to arise when the candidate value is less than 2*Double.MIN_NORMAL as for such values the ULP is less than 2*Double.MIN_VALUE so that the intermediate result 0.5*ULP is less than Double.MIN_VALUE which rounds to zero per FP-strict and the correction is therefore zero. Thus the candidate value is unchanged. The fix is to add the ULP to twice the candidate value, obtain the intermediate result, and then halve it to obtain the adjusted candidate. I am relatively new to IEEE-754 and this area of the code so any comments would be appreciated. Thanks, Brian diff -r 1405ad6afb1e -r 36482ed9bb7e src/share/classes/sun/misc/FloatingDecimal.java --- a/src/share/classes/sun/misc/FloatingDecimal.java Thu Feb 14 11:09:07 2013 -0800 +++ b/src/share/classes/sun/misc/FloatingDecimal.java Thu Feb 14 16:47:53 2013 -0800
hg: jdk8/tl/langtools: 8008405: Now that metafactory is in place, add javac lambda serialization tests
Changeset: cd7340a84bb8 Author:rfield Date: 2013-02-21 14:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cd7340a84bb8 8008405: Now that metafactory is in place, add javac lambda serialization tests Summary: Tests part of original langtools serialization review. Reviewed-by: mcimadamore + test/tools/javac/T8004969.java + test/tools/javac/lambda/LambdaInnerTypeVarArgsSerialize.java + test/tools/javac/lambda/LambdaInnerTypeVarSerialize.java
hg: jdk8/tl/langtools: 8008658: Four new method param jtreg tests fail in nightly tests
Changeset: dabb36173c63 Author:ksrini Date: 2013-02-21 12:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dabb36173c63 8008658: Four new method param jtreg tests fail in nightly tests Reviewed-by: jjg, ksrini, mcimadamore Contributed-by: eric.mccor...@oracle.com ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! test/tools/javac/MethodParameters/EnumTest.java ! test/tools/javac/MethodParameters/LocalClassTest.java ! test/tools/javac/MethodParameters/MemberClassTest.java
hg: jdk8/tl/jdk: 8008356: Test LambdaSerialization.java failing
Changeset: 1da987f0311a Author:rfield Date: 2013-02-21 15:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1da987f0311a 8008356: Test LambdaSerialization.java failing Summary: run in /othervm mode Reviewed-by: ksrini ! test/java/lang/invoke/lambda/LambdaSerialization.java
RFR: 8006039 : test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C
Hi, This test started failing after 8003228 [1] was putback (setting sun.jnu.encoding to UTF-8 on Mac). It tests if java is able to launch a .jar stored in a directory named with two-byte characters. The code comments in the test case state that (on Unix) it expects LC_ALL to be set (to ja_JP.UTF-8/ja_JP.utf8/ja_JP.ujis), though it also seems to work with en_US.UTF-8). Our automated build+test Macs have LANG=C, so the test has been passing without actually testing the functionality. The test case determines if the environment is suitable for testing by checking if sun.jnu.encoding is either MS932 or UTF-8 (on Mac, this is now always UTF-8). The test doesn't actually check LC_ALL. I think the test should also check the LANG LC_ALL env vars, and go back to fake passing the test if either is set to 'C'. This would allow the test to continue to run for real in the default Mac environment (LANG=en_US.UTF-8), and stop the test from failing on the build+test Macs. Of course it would be even better to update the test so the automated test machines actually test the intended functionality. On UNIX at least, perhaps it could find something suitable to set LC_ALL to before attempting to launch the .jar. I can file a separate bug for this. Webrev is here: http://cr.openjdk.java.net/~bchristi/8006039/webrev.00/ Thanks, -Brent [1] http://bugs.sun.com/view_bug.do?bug_id=8003228
Re: 8008662: Add @jdk.Supported to JDK-specific/supported API
On 2/21/2013 10:46 AM, Alan Bateman wrote: Joe Darcy recently added @jdk.Supported [1] to make it possible to identify JDK-specific APIs. I'd like to add this to a number of APIs in the com.sun namespace to make it obvious these are supported. It's nice to be able to mark what is supported vs unsupported in the com.sun namespace since there are a mix of supported and unsupported APIs. [...] The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/8008662/webrev/ Looks good to me. In a couple of cases the package description is legacy package.html so I've had to move/convert them to package-info.java. In all but one case I've added the annotation to the package-info, the one exception is com.sun.management where there is at least one type that is documented as not supported. Joe Darcy might have suggestions on that. I wasn't aware of the unsupported com.sun.management.OSMBeanFactory class being included in the javadoc. I think that can be fixed and I'll file a bug and hopefully we can clean that up. Mandy Otherwise this is mostly mechanical and the patch file is easier to review that the webrev. -Alan [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/55cca2f38ee6
JDK RFR of 6556996: (ann spec) SuppressWarnings strings should be documented
Hello,
Please review the simple fix below for
6556996: (ann spec) SuppressWarnings strings should be documented
http://bugs.sun.com/view_bug.do?bug_id=6556996
the webrev is at
http://cr.openjdk.java.net/~darcy/6556996.0/
and the patch is below. In brief, the only required string to be
recognized in the SuppressWarnings annotation is unchecked, which has
been required by the JLS since Java SE 5. I made that adjustment to the
documentation of the SuppressWarnings type. In addition, I added more
@jls links relating the documentation of various annotation type to the
JLS sections which discuss them.
Thanks,
-Joe
--- old/src/share/classes/java/lang/Deprecated.java2013-02-21
17:37:08.0 -0800
+++ new/src/share/classes/java/lang/Deprecated.java2013-02-21
17:37:08.0 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2003, 2010, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -36,6 +36,7 @@
*
* @author Neal Gafter
* @since 1.5
+ * @jls 9.6.3.6 @Deprecated
*/
@Documented
@Retention(RetentionPolicy.RUNTIME)
--- old/src/share/classes/java/lang/Override.java2013-02-21
17:37:09.0 -0800
+++ new/src/share/classes/java/lang/Override.java2013-02-21
17:37:09.0 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -43,7 +43,7 @@
*
* @author Peter von der Aheacute;
* @author Joshua Bloch
- * @jls 9.6.1.4 Override
+ * @jls 9.6.1.4 @Override
* @since 1.5
*/
@Target(ElementType.METHOD)
--- old/src/share/classes/java/lang/SafeVarargs.java2013-02-21
17:37:09.0 -0800
+++ new/src/share/classes/java/lang/SafeVarargs.java2013-02-21
17:37:09.0 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2010, 2011, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -85,6 +85,7 @@
* @since 1.7
* @jls 4.7 Reifiable Types
* @jls 8.4.1 Formal Parameters
+ * @jls 9.6.3.7 @SafeVarargs
*/
@Documented
@Retention(RetentionPolicy.RUNTIME)
--- old/src/share/classes/java/lang/SuppressWarnings.java 2013-02-21
17:37:10.0 -0800
+++ new/src/share/classes/java/lang/SuppressWarnings.java 2013-02-21
17:37:09.0 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -41,8 +41,11 @@
* suppress a warning in a particular method, you should annotate that
* method rather than its class.
*
- * @since 1.5
* @author Josh Bloch
+ * @since 1.5
+ * @jls 5.1.9. Unchecked Conversion
+ * @jls 5.5.2. Checked Casts and Unchecked Casts
+ * @jls 9.6.3.5 @SuppressWarnings
*/
@Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE})
@Retention(RetentionPolicy.SOURCE)
@@ -56,9 +59,11 @@
* free to emit a warning if an annotation contains an unrecognized
* warning name.
*
- * pCompiler vendors should document the warning names they
support in
- * conjunction with this annotation type. They are encouraged to
cooperate
- * to ensure that the same names work across multiple compilers.
+ * p The string {@code unchecked} is used to suppress
+ * unchecked warnings. Compiler vendors should document the
+ * additional warning names they support in conjunction with this
+ * annotation type. They are encouraged to cooperate to ensure
+ * that the same names work across multiple compilers.
*/
String[] value();
}
--- old/src/share/classes/java/lang/annotation/Inherited.java 2013-02-21
17:37:10.0 -0800
+++ new/src/share/classes/java/lang/annotation/Inherited.java 2013-02-21
17:37:10.0 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2003, 2004, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -44,6 +44,7 @@
*
* @author Joshua Bloch
* @since 1.5
+ * @jls 9.6.3.3 @Inherited
*/
@Documented
Re: 8008662: Add @jdk.Supported to JDK-specific/supported API
On 02/21/2013 10:46 AM, Alan Bateman wrote: Joe Darcy recently added @jdk.Supported [1] to make it possible to identify JDK-specific APIs. I'd like to add this to a number of APIs in the com.sun namespace to make it obvious these are supported. Specifically I'm proposing to add it to: To add some more context here, there are various APIs outside of the Java SE namespaces (java.* and javax.*) that are shipped with the JDK. Some of these APIs and meant to be called by normal users of the JDK and evolve under essentially the same general evolution policy [1] as the SE API. Call such non-SE APIs in the JDK supported. One example of such a supported API is the javac Tree API in com.sun.source.* JDK 7: http://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/index.html JDK 8: http://download.java.net/jdk8/docs/jdk/api/javac/tree/index.html However, the com.sun.* subpackages are a mix of APIs that are supported as described above as well as APIs that are not supported. APIs that are not supported are *not* meant to be called by normal users of the JDK and can have a very different evolution policy, up to and including deletion from the JDK in a update release. The goal of adding the @Supported annotations is to allow these API categories to be more easily distinguished from each other, including enabling tools to check that @Supported(value=false) APIs are not referenced. The jdk.Supported annotation can be applied to both types and packages; it is *not* intended to allow modeling of supported-ness down to only a subset of methods of a type. In other words, if @jdk.Supported is applied to something, it is meant to refer to the whole entity, either all the parts of a type or all the types in a package. To make the information more prominent and easier to find, I recommend applying the annotation to both all the types in a package and the package itself, which is what I've done in the tree API. [2] In Alan's case below, I would not apply the annotation to a package if the package had a mix of supported and unsupported types. Cheers, -Joe [1] http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy [2] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/011cf7e0a148 - Java Debug Interface (com.sun.jdi) - Attach API (com.sun.tools.attach) - SCTP API (com.sun.nio.sctp) - HTTP server API (com.sun.net.httpserver) - Management extensions (com.sun.management) - JDK-specific API to JAAS (com.sun.security.auth) - JDK-specific JGSS API (com.sun.security.jgss) The javadoc for all of these is generated as part of the regular JDK docs build and so shouldn't be controversial. There are a number of other candidates in com.sun with murkier status that I've stayed clear of for now. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/8008662/webrev/ In a couple of cases the package description is legacy package.html so I've had to move/convert them to package-info.java. In all but one case I've added the annotation to the package-info, the one exception is com.sun.management where there is at least one type that is documented as not supported. Joe Darcy might have suggestions on that. Otherwise this is mostly mechanical and the patch file is easier to review that the webrev. -Alan [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/55cca2f38ee6
Re: Withdraw: Review: 4396272 - Parsing doubles fails to follow IEEE for largest decimal that should yield 0
Do you want that I prepare this FloatingDecimal/FormattedFloatingDecimal patch ? -Dima On Fri, Feb 22, 2013 at 2:32 AM, Brian Burkhalter brian.burkhal...@oracle.com wrote: I am withdrawing this patch for the time being as properly the changes should also go into the fork sun.misc.FormattedFloatingDecimal. I'll post an updated patch once it is available. Thanks, Brian On Feb 14, 2013, at 5:23 PM, Brian Burkhalter wrote: The patch below is as submitted to OpenJDK bugzilla but with enhanced comments. It pertains to the correction loop in the doubleValue() method of FloatingDecimal. The situation appears to arise when the candidate value is less than 2*Double.MIN_NORMAL as for such values the ULP is less than 2*Double.MIN_VALUE so that the intermediate result 0.5*ULP is less than Double.MIN_VALUE which rounds to zero per FP-strict and the correction is therefore zero. Thus the candidate value is unchanged. The fix is to add the ULP to twice the candidate value, obtain the intermediate result, and then halve it to obtain the adjusted candidate. I am relatively new to IEEE-754 and this area of the code so any comments would be appreciated. Thanks, Brian diff -r 1405ad6afb1e -r 36482ed9bb7e src/share/classes/sun/misc/FloatingDecimal.java --- a/src/share/classes/sun/misc/FloatingDecimal.java Thu Feb 14 11:09:07 2013 -0800 +++ b/src/share/classes/sun/misc/FloatingDecimal.java Thu Feb 14 16:47:53 2013 -0800
Re: RFR: 8006039 : test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C
Hi Brent,
I am not an expert here, and I am hoping someone from I18N
also reviews this.
A nit
- LC_ALL + LC_ALL + \n +
+ LC_ALL= + LC_ALL + \n +
If Mac is the only system affected by this, should we make the checks for
LC* and LANG specific to Macs since other platforms don't have this issue ?
I am concerned this might pass vacuously on systems configured correctly.
Since the test extends TestHelper all you have to do is:
-if(C.equals(LANG) || C.equals(LC_ALL)) {
+if (isMacOSX (C.equals(LANG) || C.equals(LC_ALL))) {
Kumar
Hi,
This test started failing after 8003228 [1] was putback (setting
sun.jnu.encoding to UTF-8 on Mac). It tests if java is able to launch
a .jar stored in a directory named with two-byte characters.
The code comments in the test case state that (on Unix) it expects
LC_ALL to be set (to ja_JP.UTF-8/ja_JP.utf8/ja_JP.ujis), though it
also seems to work with en_US.UTF-8).
Our automated build+test Macs have LANG=C, so the test has been
passing without actually testing the functionality.
The test case determines if the environment is suitable for testing by
checking if sun.jnu.encoding is either MS932 or UTF-8 (on Mac,
this is now always UTF-8). The test doesn't actually check LC_ALL.
I think the test should also check the LANG LC_ALL env vars, and go
back to fake passing the test if either is set to 'C'. This would
allow the test to continue to run for real in the default Mac
environment (LANG=en_US.UTF-8), and stop the test from failing on the
build+test Macs.
Of course it would be even better to update the test so the automated
test machines actually test the intended functionality. On UNIX at
least, perhaps it could find something suitable to set LC_ALL to
before attempting to launch the .jar. I can file a separate bug for
this.
Webrev is here:
http://cr.openjdk.java.net/~bchristi/8006039/webrev.00/
Thanks,
-Brent
[1]
http://bugs.sun.com/view_bug.do?bug_id=8003228
hg: jdk8/tl: 9 new changesets
Changeset: ffb4d2e95140 Author:erikj Date: 2013-02-15 10:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ffb4d2e95140 8005879: Add -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 to builds on Mac Reviewed-by: ohair ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: b0642df54d63 Author:erikj Date: 2013-02-18 10:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b0642df54d63 Merge Changeset: b80abec66e70 Author:bpatel Date: 2013-01-21 00:29 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b80abec66e70 8006124: javadoc/doclet should be updated to support profiles Reviewed-by: jjg, dholmes ! common/makefiles/javadoc/Javadoc.gmk Changeset: 7ed0c9db6943 Author:dholmes Date: 2013-01-21 01:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7ed0c9db6943 8004265: Add build support for Compact Profiles Reviewed-by: erikj, ohair ! NewMakefile.gmk ! common/autoconf/generated-configure.sh ! common/makefiles/Main.gmk Changeset: 2f8fd30f02e6 Author:dholmes Date: 2013-01-22 19:30 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2f8fd30f02e6 Merge ! common/autoconf/generated-configure.sh Changeset: bebeaa04ab8e Author:dholmes Date: 2013-02-04 18:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/bebeaa04ab8e Merge ! common/autoconf/generated-configure.sh ! common/makefiles/javadoc/Javadoc.gmk Changeset: 28071e4ca1de Author:dholmes Date: 2013-02-17 16:44 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/28071e4ca1de Merge ! common/autoconf/generated-configure.sh ! common/makefiles/Main.gmk Changeset: fd1a5574cf68 Author:dholmes Date: 2013-02-18 15:35 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/fd1a5574cf68 Merge ! common/autoconf/generated-configure.sh Changeset: b70196e01c53 Author:lana Date: 2013-02-21 17:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b70196e01c53 Merge
Re: RFR: 8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries
Hi Vlad, On 22/02/2013 8:02 AM, Vladimir Danushevsky wrote: Please review changes for https://jbs.oracle.com/bugs/browse/JDK-8005545 Add System property to identify ARCH specific details such as ARM hard-float binaries which adds an optional sun.os.abi Java system property indicating an ABI type being used by the JVM: CCC Reguest: http://ccc.us.oracle.com/8005545 Neither of the above URLs are accessible outside Oracle. Webrev: http://cr.openjdk.java.net/~vladidan/8005545/webrev.00/ Looks okay (names not withstanding :)) At some point this will need to sync with profiles changes in Images.gmk that also updates the release file. I did it a slightly different way when the obvious way (using ifneq inside 'define create-info-file') didn't work - I added to the actual recipe: $(JRE_INFO_FILE): $(OUTPUT_ROOT)/spec.gmk $(OUTPUT_ROOT)/source_tips $(ECHO) $(LOG_INFO) Generating $(patsubst $(OUTPUT_ROOT)/%,%,$@) $(call create-info-file) ifneq ($(PROFILE),) $(call info-file-item, JAVA_PROFILE, $(call profile_name, $(call profile_number, $(PROFILE endif (that was only needed for a JRE not the JDK). Doing it via the shell is cleaner I think. David - Separate change to the build script (e.g. in ARM Hard-Float ABI case): setenv ARCHABIPROPNAME gnueabihf -DARCHABIPROPNAME=\$(ARCHABIPROPNAME)\ is passed to the CFLAGS Thanks, Vlad
