Re: 8008662: Add @jdk.Supported to JDK-specific/supported API
Thank you Alan, this will clear up a lot of issues surrounding these API's. I skimmed over the changes, paying particular attention to the httpserver and sctp packages. -Chris. On 02/21/2013 06: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
hg: jdk8/tl/jdk: 8006182: cleanup to use java.util.Base64 in java security component, providers, and regression tests
Changeset: 9078c34437ab Author:msheppar Date: 2013-02-21 20:01 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9078c34437ab 8006182: cleanup to use java.util.Base64 in java security component, providers, and regression tests Summary: Refactored code to use java.util.Base64 Mime Encoder and Decoder as a replacement for sun.misc.BASE64Encoder and sun.misc.BASE64Decoder Reviewed-by: vinnie, chegar, sherman ! src/share/classes/sun/security/pkcs10/PKCS10.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/util/ManifestEntryVerifier.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java ! src/share/classes/sun/security/x509/X509CertImpl.java ! src/share/classes/sun/tools/jar/Manifest.java ! src/share/classes/sun/tools/jar/SignatureFile.java ! test/javax/security/auth/kerberos/KerberosTixDateTest.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/BasicConstraints.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyTunnelServer.java ! test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ProxyTunnelServer.java
Re: RFR: 8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries
On 21/02/2013 22:02, Vladimir Danushevsky wrote: : Webrev: http://cr.openjdk.java.net/~vladidan/8005545/webrev.00/ http://cr.openjdk.java.net/%7Evladidan/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 I agree with Bob on the naming, otherwise it looks okay to me. On the release file and Images.gmk then jdk/tl was sync'ed up yesterday so you will probably need to re-base the patch. -Alan
Fwd: RFR: 8007806: Need a Throwables performance counter
Does anyone have anything strongly against this? This is a small change just to add a performance counter, the code to increment it and read it will live in other parts of the code and be a part of a larger separate commit. Alan Bateman gave the response that the name was inappropriate, but I don't really have a better alternative, but neither do I have strong opinions, so feedback would be appreciated! How about sun.throwables.thrownThrowables ? Regards, Nils Loodin Original Message Subject: RFR: 8007806: Need a Throwables performance counter Date: Fri, 08 Feb 2013 18:10:02 +0100 From: Nils Loodin nils.loo...@oracle.com To: core-libs-dev@openjdk.java.net,serviceability_dev_ww_grp serviceability_dev_ww_...@oracle.com It would be interesting to know the number of thrown throwables in the JVM, to be able to do some high level application diagnostics / statistics. A good way to put this number would be a performance counter, since it is accessible both from Java and from the VM. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806 http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ Regards, Nils Loodin
hg: jdk8/tl/langtools: 8008337: Write test to check for compiler error when static method in interface is called via super()
Changeset: 8e82e4f225e4 Author:mcimadamore Date: 2013-02-22 13:31 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8e82e4f225e4 8008337: Write test to check for compiler error when static method in interface is called via super() Reviewed-by: mcimadamore Contributed-by: sonali.g...@oracle.com + test/tools/javac/lambda/StaticMethodNegTest.java + test/tools/javac/lambda/StaticMethodNegTest.out
Re: Fwd: RFR: 8007806: Need a Throwables performance counter
On 22/02/2013 13:10, Nils Loodin wrote: Does anyone have anything strongly against this? This is a small change just to add a performance counter, the code to increment it and read it will live in other parts of the code and be a part of a larger separate commit. Alan Bateman gave the response that the name was inappropriate, but I don't really have a better alternative, but neither do I have strong opinions, so feedback would be appreciated! How about sun.throwables.thrownThrowables ? My comment on the counter name was mostly that sun.misc.PerfCounter isn't really the right place to create a hotspot.* counters. Using the eixsting sun.* or start a new jdk.* name space seems more appropriate. I don't have a strong opinion on the name. -Alan.
Review request for 8008716 to address typo in CallableStatement javadocs
H alli,
This is a review request for 8008716 to address a couple of typos in
CallableStatement:
$ hg diff CallableStatement.java
diff -r 7dcb74c3ffba src/share/classes/java/sql/CallableStatement.java
--- a/src/share/classes/java/sql/CallableStatement.java Tue Feb 12 09:25:43
2013 -0800
+++ b/src/share/classes/java/sql/CallableStatement.java Fri Feb 22 09:02:51
2013 -0500
@@ -2621,7 +2621,7 @@
* parameter determines the Java type that must be used
* in the {@code get} method to read the value of that parameter.
* p
- * This version of {@code registrOutParameter} should be
+ * This version of {@code registerOutParameter} should be
* used when the parameter is of JDBC type {@code JDBCType.NUMERIC}
* or {@code JDBCType.DECIMAL}.
*P
@@ -2649,7 +2649,7 @@
/**
* Registers the designated output parameter.
* This version of
- * the method {@code registrOutParameter}
+ * the method {@code registerOutParameter}
* should be used for a user-defined or {@code REF} output parameter.
* Examples
* of user-defined types include: {@code STRUCT}, {@code DISTINCT},
@@ -2717,7 +2717,7 @@
* register the OUT Parameter.
* If the parameter is of JDBC type {@code JDBCType.NUMERIC}
* or {@code JDBCType.DECIMAL}, the version of
- * {@code registrOutParameter} that accepts a scale value
+ * {@code registerOutParameter} that accepts a scale value
* should be used.
* @exception SQLException if parameterName does not correspond to a named
* parameter; if a database access error occurs or
@@ -2745,7 +2745,7 @@
* parameter determines the Java type that must be used
* in the {@code get} method to read the value of that parameter.
* p
- * This version of {@code registrOutParameter} should be
+ * This version of {@code registerOutParameter} should be
* used when the parameter is of JDBC type {@code JDBCType.NUMERIC}
* or {@code JDBCType.DECIMAL}.
*P
@@ -2774,7 +2774,7 @@
/**
* Registers the designated output parameter. This version of
- * the method {@code registrOutParameter}
+ * the method {@code registerOutParameter}
* should be used for a user-named or REF output parameter. Examples
* of user-named types include: STRUCT, DISTINCT, JAVA_OBJECT, and
* named array types.
Best
Lance
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: Review request for 8008716 to address typo in CallableStatement javadocs
Looks fine to me Lance.
-Chris.
On 02/22/2013 02:12 PM, Lance Andersen - Oracle wrote:
H alli,
This is a review request for 8008716 to address a couple of typos in
CallableStatement:
$ hg diff CallableStatement.java
diff -r 7dcb74c3ffba src/share/classes/java/sql/CallableStatement.java
--- a/src/share/classes/java/sql/CallableStatement.java Tue Feb 12 09:25:43
2013 -0800
+++ b/src/share/classes/java/sql/CallableStatement.java Fri Feb 22 09:02:51
2013 -0500
@@ -2621,7 +2621,7 @@
* parameter determines the Java type that must be used
* in the {@code get} method to read the value of that parameter.
* p
- * This version of {@code registrOutParameter} should be
+ * This version of {@code registerOutParameter} should be
* used when the parameter is of JDBC type {@code JDBCType.NUMERIC}
* or {@code JDBCType.DECIMAL}.
*P
@@ -2649,7 +2649,7 @@
/**
* Registers the designated output parameter.
* This version of
- * the method {@code registrOutParameter}
+ * the method {@code registerOutParameter}
* should be used for a user-defined or {@code REF} output parameter.
* Examples
* of user-defined types include: {@code STRUCT}, {@code DISTINCT},
@@ -2717,7 +2717,7 @@
* register the OUT Parameter.
* If the parameter is of JDBC type {@code JDBCType.NUMERIC}
* or {@code JDBCType.DECIMAL}, the version of
- * {@code registrOutParameter} that accepts a scale value
+ * {@code registerOutParameter} that accepts a scale value
* should be used.
* @exception SQLException if parameterName does not correspond to a named
* parameter; if a database access error occurs or
@@ -2745,7 +2745,7 @@
* parameter determines the Java type that must be used
* in the {@code get} method to read the value of that parameter.
* p
- * This version of {@code registrOutParameter} should be
+ * This version of {@code registerOutParameter} should be
* used when the parameter is of JDBC type {@code JDBCType.NUMERIC}
* or {@code JDBCType.DECIMAL}.
*P
@@ -2774,7 +2774,7 @@
/**
* Registers the designated output parameter. This version of
- * the method {@code registrOutParameter}
+ * the method {@code registerOutParameter}
* should be used for a user-named or REF output parameter. Examples
* of user-named types include: STRUCT, DISTINCT, JAVA_OBJECT, and
* named array types.
Best
Lance
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: 8008662: Add @jdk.Supported to JDK-specific/supported API
The security related ones look ok to me. --Sean On 02/21/2013 01: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
Re: 8008662: Add @jdk.Supported to JDK-specific/supported API
On 22/02/2013 14:06, Martin Buchholz wrote: I was under the impression that the general rule was that all of com.sun.* fell under the jdk supported umbrella, and the level of support was the distinction between sun.com.* and sun.* . com.sun is a mixed bag. There are lots of com.sun.*.internal that are clearly JDK internal/implementation/stay-away but several useful and documented APIs are in com.sun too (the JDK build generates the javadoc for these). In addition there are several APIs with murkier pasts, transitional APIs for areas that previous had a life as a standalone technology before coming into the JDK. -Alan.
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 9f9dac5a9e74 Author:lancea Date: 2013-02-22 09:29 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f9dac5a9e74 8008716: address typo in CallableStatement javadocs Reviewed-by: chegar ! src/share/classes/java/sql/CallableStatement.java Changeset: 8d8a35ac7d40 Author:lancea Date: 2013-02-22 09:58 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d8a35ac7d40 Merge
RE: RFR: 8007806: Need a Throwables performance counter
From this webrev http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/ you are counting the number of throwables constructed. You might want to change the name to reflect that. I don't think anyone would want to write a spec for how many throwables are thrown given that a throwable can be wrapped, suppressed, rethrown, etc. Jason Date: Fri, 22 Feb 2013 14:10:02 +0100 From: nils.loo...@oracle.com To: core-libs-dev@openjdk.java.net; serviceability-...@openjdk.java.net Subject: Fwd: RFR: 8007806: Need a Throwables performance counter Does anyone have anything strongly against this? This is a small change just to add a performance counter, the code to increment it and read it will live in other parts of the code and be a part of a larger separate commit. Alan Bateman gave the response that the name was inappropriate, but I don't really have a better alternative, but neither do I have strong opinions, so feedback would be appreciated! How about sun.throwables.thrownThrowables ? Regards, Nils Loodin Original Message Subject: RFR: 8007806: Need a Throwables performance counter Date: Fri, 08 Feb 2013 18:10:02 +0100 From: Nils Loodin nils.loo...@oracle.com To: core-libs-dev@openjdk.java.net,serviceability_dev_ww_grp serviceability_dev_ww_...@oracle.com It would be interesting to know the number of thrown throwables in the JVM, to be able to do some high level application diagnostics / statistics. A good way to put this number would be a performance counter, since it is accessible both from Java and from the VM. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806 http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/ Regards, Nils Loodin
Re: Withdraw: Review: 4396272 - Parsing doubles fails to follow IEEE for largest decimal that should yield 0
Hello Dima, Yes that would be helpful and appreciated. There is another patch to the same files that I will be looking into, but the changes are disjoint so there should not be a significant merge issue. Thanks, Brian On Feb 21, 2013, at 7:27 PM, Dmitry Nadezhin wrote: 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: Withdraw: Review: 4396272 - Parsing doubles fails to follow IEEE for largest decimal that should yield 0
Brian, Class FloatingDecimal contains both conversion from String to float/double and conversion from float/double to String. My change is in conversion from String to float/double. The methods if FloatingDecimal that implement this conversion are: static FloatingDecimal readJavaFormatString( String in ); double doubleValue(); float floatValue(); My change is in method doubleValue(). Class FormattedFloatingDecimal was forked from FloatingDecimal some time ago. This class is used only for conversion from String to float/double. The unused method readJavaFormatString( String in) was deleted from FormattedFloatingDecimal. Methods doubleValue() and floatValued() were not deleted, but they are never used in JDK code. So I think that the required change in FormattedFloatingDecimal is to delete methods doubleValue(), floatValue() and other unused methods and fields. Am I right ? -Dima On Fri, Feb 22, 2013 at 8:46 PM, Brian Burkhalter brian.burkhal...@oracle.com wrote: Hello Dima, Yes that would be helpful and appreciated. There is another patch to the same files that I will be looking into, but the changes are disjoint so there should not be a significant merge issue. Thanks, Brian On Feb 21, 2013, at 7:27 PM, Dmitry Nadezhin wrote: 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: Withdraw: Review: 4396272 - Parsing doubles fails to follow IEEE for largest decimal that should yield 0
Dima, If the methods are definitely unused that would be correct. I suppose if a clean build of the JDK does not complain then it is acceptable and correct. Thanks, Brian On Feb 22, 2013, at 9:41 AM, Dmitry Nadezhin wrote: So I think that the required change in FormattedFloatingDecimal is to delete methods doubleValue(), floatValue() and other unused methods and fields. Am I right ?
Re: RFR: 8006039 : test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C
Hi Brent, I think the condition needs to check if it is on Unix environment, and check not only C but also other locales that do not use UTF-8 encoding. Also, LC_ALL precedes LANG environment variable, so I'd check LC_ALL first, and if it is not exported then check LANG variable. Naoto On 2/21/13 4:34 PM, Brent Christian wrote: 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/langtools: 8008708: Regression: separate compilation causes crash in wildcards inference logic
Changeset: 94e67bed460d Author:mcimadamore Date: 2013-02-22 18:19 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/94e67bed460d 8008708: Regression: separate compilation causes crash in wildcards inference logic Summary: Invalid use of WildcardType.bound in Types.removeWildcards Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/separate/Foo.java + test/tools/javac/lambda/separate/Test.java
Re: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue()
Sweet. Just be aware that the floatValue() optimization requires Float.parseFloat to be fixed to match IEEE 754 behavior, as you're apparently doing with Double.parseDouble, to pass tests. (The separate patch I sent in to fix that is probably invalidated by your changes, but it shouldn't be too difficult to do yourself -- it really is just copy/pasting the Double.parseDouble implementation and using updated constants.) On Thu, Feb 21, 2013 at 1:27 PM, Brian Burkhalter brian.burkhal...@oracle.com wrote: 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 -- Louis Wasserman
Re: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue()
On Feb 22, 2013, at 11:23 AM, Louis Wasserman wrote: Sweet. Just be aware that the floatValue() optimization requires Float.parseFloat to be fixed to match IEEE 754 behavior, as you're apparently doing with Double.parseDouble, to pass tests. Actually I missed that until yesterday but found it out myself. I do not think however that the patch for 7131192 necessarily has to precede the fix for 7192954, as long as the latter gets into the same release. (The separate patch I sent in to fix that is probably invalidated by your changes, but it shouldn't be too difficult to do yourself -- it really is just copy/pasting the Double.parseDouble implementation and using updated constants.) Thanks for the pointer. As previously noted I am still trying to gain some traction in this area. Brian
Re: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue()
It's up to you guys, probably. The issue is that the reference implementation being tested against is wrong, and which order you want to fix things is up to you guys. On Fri, Feb 22, 2013 at 11:48 AM, Brian Burkhalter brian.burkhal...@oracle.com wrote: On Feb 22, 2013, at 11:33 AM, Brian Burkhalter wrote: Sweet. Just be aware that the floatValue() optimization requires Float.parseFloat to be fixed to match IEEE 754 behavior, as you're apparently doing with Double.parseDouble, to pass tests. Actually I missed that until yesterday but found it out myself. I do not think however that the patch for 7131192 necessarily has to precede the fix for 7192954, as long as the latter gets into the same release. Oops, I had that reversed: I don't know that the patch for 7192954 has to precede that for 7131192 if the latter is deemed correct. B. -- Louis Wasserman
Re: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue()
On Feb 22, 2013, at 12:10 PM, Louis Wasserman wrote: It's up to you guys, probably. The issue is that the reference implementation being tested against is wrong, Yes, I understand. and which order you want to fix things is up to you guys. Brian
Re: Withdraw: Review: 4396272 - Parsing doubles fails to follow IEEE for largest decimal that should yield 0
Dima, Great! Thanks. I will take a look later and re-post the review. Brian On Feb 22, 2013, at 12:29 PM, Dmitry Nadezhin wrote: Brian, I removed unused methods and fields from FormattedFloatingDecimal. JDK build passes. The result of hg diff is attached. -Dima On Fri, Feb 22, 2013 at 9:49 PM, Brian Burkhalter brian.burkhal...@oracle.com wrote: Dima, If the methods are definitely unused that would be correct. I suppose if a clean build of the JDK does not complain then it is acceptable and correct. Thanks, Brian On Feb 22, 2013, at 9:41 AM, Dmitry Nadezhin wrote: So I think that the required change in FormattedFloatingDecimal is to delete methods doubleValue(), floatValue() and other unused methods and fields. Am I right ? hgdiff.txt
Re: JDK RFR of 6556996: (ann spec) SuppressWarnings strings should be documented
looks good to me. Nice to see the JLS additions and good catch on the missing
@since.
On Feb 21 2013, at 17:46 , Joe Darcy wrote:
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.
*
Re: RFR: 8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries
Looks good to me. Bob. On Feb 22, 2013, at 4:33 PM, Vladimir Danushevsky wrote: Thanks, webrev updated http://cr.openjdk.java.net/~vladidan/8005545/webrev.01/ On Feb 22, 2013, at 5:57 AM, Alan Bateman wrote: On 21/02/2013 22:02, Vladimir Danushevsky wrote: : Webrev: http://cr.openjdk.java.net/~vladidan/8005545/webrev.00/ http://cr.openjdk.java.net/%7Evladidan/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 I agree with Bob on the naming, otherwise it looks okay to me. On the release file and Images.gmk then jdk/tl was sync'ed up yesterday so you will probably need to re-base the patch. -Alan
Re: 8008662: Add @jdk.Supported to JDK-specific/supported API
Hi Joe, On Fri, Feb 22, 2013 at 11:19 AM, Joe Darcy joe.da...@oracle.com wrote: Should third-party vendor extensions that are supported for public use by the third-party use jdk.Supported? No; as I envision it, the jdk.Supported annotation is only meant to convey supported-ness in the JDK of parts of the JDK. Depends on what you mean by JDK. Suppose the icedtea project added a public supported method usesSystemZlib(). It would be good to provide guidance what package to put this in (org.classpath.* ?) and how to indicate level of support (by the icedtea project). Suppose the IcedTea project decided to officially support sun.misc.Unsafe. Would they do this by adding jdk.Supported annotation to their version of Unsafe.java, even if their upstream chose not to? What about the X's in hotspot flags and the java tools command line interfaces? The policy around command line interfaces is unchanged; the interfaces are mostly stable, but the more X's are in a flags name, the less stable it can be. We all learned this by indoctrination from the local sensei greybeard, but where is it documented for the wider world? Perhaps Supported isn't a binary thing, but needs to capture different levels of support? Solaris has had such support levels. A beta (laba, experimental) support level is very useful for introducing new technology. It's a very hard problem, especially in a 1000 flowers world.
Do not let internal JDK zlib symbols leak out of fastdebug libzip.so
Hi Alan, Xueming, build-ers, I'd like you to do a code review. I've finally figured out why fastdebug jdk occasionally gives InternalError in the zip code. Exception in thread main java.lang.InternalError at java.util.zip.Inflater.init(Native Method) at java.util.zip.Inflater.init(Inflater.java:101) at java.util.zip.ZipFile.getInflater(ZipFile.java:448) It's because: - jdk changed structure size of z_stream struct - making jdk zlib incompatible with stock zlib - as a result of which, it is imperative to keep jdk zlib sequestered from system zlib - so need to not export zlib symbols from libzip.so - so need to tell makefiles to use linker script unconditionally http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/
Re: 8008662: Add @jdk.Supported to JDK-specific/supported API
Hi Martin, On 2/22/2013 1:40 PM, Martin Buchholz wrote: Hi Joe, On Fri, Feb 22, 2013 at 11:19 AM, Joe Darcy joe.da...@oracle.com mailto:joe.da...@oracle.com wrote: Should third-party vendor extensions that are supported for public use by the third-party use jdk.Supported? No; as I envision it, the jdk.Supported annotation is only meant to convey supported-ness in the JDK of parts of the JDK. Depends on what you mean by JDK. Suppose the icedtea project added a public supported method usesSystemZlib(). It would be good to provide guidance what package to put this in (org.classpath.* ?) and how to indicate level of support (by the icedtea project). Suppose the IcedTea project decided to officially support sun.misc.Unsafe. Would they do this by adding jdk.Supported annotation to their version of Unsafe.java, even if their upstream chose not to? For some definition of JDK, IcedTea is JDK too since they provide a JDK distribution, one at least a little distinct from plain OpenJDK and also distinct from OracleJDK. The long-standing problem I wanted to address was clearly indicating whether or not the upstream code in shared JDK 8 sources was regarded as a public API or not. So I don't think it would necessarily be inappropriate for a hypothetical org.classpath type to use jdk.Supported, but I wasn't really thinking about that use case. What about the X's in hotspot flags and the java tools command line interfaces? The policy around command line interfaces is unchanged; the interfaces are mostly stable, but the more X's are in a flags name, the less stable it can be. We all learned this by indoctrination from the local sensei greybeard, but where is it documented for the wider world? There is some approximation to that guidance in the java man page; options without a X prefix are described as standard and ones with at least one X are described as non-standard. Not all XX options are included in the man page. Perhaps Supported isn't a binary thing, but needs to capture different levels of support? Solaris has had such support levels. A beta (laba, experimental) support level is very useful for introducing new technology. It's a very hard problem, especially in a 1000 flowers world. Yes, I'm vaguely aware that Solaris has had a rich taxonomy in this space and there are, IIRC, dtrace tools to audit if you are calling any sufficient unapproved APIs. However, at least as a first cut, I think a binary supported / not-supported distinction captures at least 80% of the distinction that needs to be made for the purposes of the JDK. Anything more involves much less favorable complexity vs benefit trade-offs. -Joe
Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so
Here is the bugid you will need. 8008759: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so On 02/22/2013 02:03 PM, Martin Buchholz wrote: Hi Alan, Xueming, build-ers, I'd like you to do a code review. I've finally figured out why fastdebug jdk occasionally gives InternalError in the zip code. Exception in thread main java.lang.InternalError at java.util.zip.Inflater.init(Native Method) at java.util.zip.Inflater.init(Inflater.java:101) at java.util.zip.ZipFile.getInflater(ZipFile.java:448) It's because: - jdk changed structure size of z_stream struct - making jdk zlib incompatible with stock zlib - as a result of which, it is imperative to keep jdk zlib sequestered from system zlib - so need to not export zlib symbols from libzip.so - so need to tell makefiles to use linker script unconditionally http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/ http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk8/hide-zlib/
Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so
On Fri, Feb 22, 2013 at 2:15 PM, Xueming Shen xueming.s...@oracle.comwrote: ** Here is the bugid you will need. 8008759: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so Thanks! webrev updated.
@Supported design issues
I understand (deeply!) the problem that @Supported is trying to solve. Martin has raised a number of good questions about it already. Here are some additional concerns I'd like to see addressed before we use it any further in our source code. (I've been unable to find any earlier discussion or code review of this new annotation in the archives, but maybe I missed it.) - The annotation isn't a simple marker annotation, which is what I expected at first glance; it takes a boolean parameter. Does this mean that we have to go add @Supported(false) to everything that's not supported? I'd have thought that anything not marked @Supported(true) would by implication, well, not be supported. Does it mean that if I mark a package @Supported(true) I can use @Supported(false) on some of its member types? - Is the supportedness of a package inherited by its sub-packages? - The name Supported is problematic. It begs the question, Supported by whom? Maybe the annotation should take URL and phone-number parameters so that you know where to go when you run into a problem? A name that captures a more inherent property of the API unit being annotated would avoid this. Perhaps @Stable? - I agree with Martin that supportedness, in the abstract, isn't a binary thing. If we're going to define an annotation for broad use then we should at least consider a metric with more than two values. I'm not saying we should replicate all the detail of the Solaris stability taxonomy [1], but we should at least discuss whether it's worth doing something along those lines, if simpler. I think it'd be particularly valuable to be able to distinguish between at least four levels: - Supported and stable (i.e., will only evolve compatibly) until we tell you it's going to go away (or change incompatibly), and we'll give you at least one feature-release cycle's notice. - Supported in this feature release, but it might go away or change incompatibly in the next, with best-effort notice. - Supported in this update release, but evolving rapidly, with changes announced only in release notes. - Internal to the JDK, expect to get burned if you use it. These are, more or less, the Solaris Stable, Evolving, Unstable, and Internal levels, which suggests a single @Stability annotation and an enum parameter with the values STABLE, EVOLVING, UNSTABLE, and INTERNAL. - The retention policy of the annotation is RUNTIME. Is that really what we want? I'd have expected CLASS. - The annotation is in the top-level jdk package. What's the rationale for this? I'd have expected it to be defined in jdk.annotations, so that if and when other JDK-specific annotations arise we have one convenient place to find them, and only them. Finally, this annotation is intended for use throughout our code base, and will be of interest not just to people working on the JDK but also to people using it. Its syntax, semantics, and intended usage should hence be documented in a JEP, which will be much more visible than an obscure Javadoc page. - Mark [1] http://docs.oracle.com/cd/E19082-01/819-3620/chp-stab-1/index.html
Re: @Supported design issues
One more thought. @Supported has RUNTIME retention, and it will be inevitable that some people will check the annotation at runtime. As a practical matter, once the annotation is added, it will never be removed (or removed only if the corresponding API is itself removed), (for fear of breaking someone), including by third parties like IcedTea.
Re: RFR: 8006039 : test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C
On 2/21/13 7:33 PM, Kumar Srinivasan wrote: A nit - LC_ALL + LC_ALL + \n + + LC_ALL= + LC_ALL + \n + Done, thanks. 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. LANG/LC_ALL=C is not a correct configuration for running this test. It ought to pass vacuously in this case (and does, AFAIK, on other platforms). What is Mac-specific is that sun.jnu.encoding is now always set to UTF-8, even under LANG/LC_ALL=C. The test sees this, and tries (and fails) to run the real test instead of passing vacuously. I don't think it does any harm to check for LANG/LC_ALL != 'C' on other platforms. But it's only on Mac that it's required in order to detect a mis-configured test environment. Of course it would be even better to update the test so the automated test machines actually test the intended functionality. ... I can file a separate bug for this. I've filed 8008761 (test/tools/launcher/I18NJarTest.java should automatically setup its environment) to cover this. To be clear, my short-term goal is to take I18NJarTest back off the ProblemList. The test does correctly test the intended functionality under the default Mac environment (LANG=en_US.UTF-8). So I want to get it running again for engineers using the jdk_tools test target on their local Mac (without causing nightly test failure noise). Later, as time permits, I can tackle 8008761, and get the test to configure its own environment. Thanks, -Brent
RE: @Supported design issues
I agree, but at the same time CLASS retention is really the worst of both worlds in my opinion. It doesn't have any (convenient) runtime benefit, but you can be sure that someone will depend on it at runtime by parsing the class files (this happens surprisingly often). I'd really like to see this be SOURCE initially and only after it is well understood, move it to RUNTIME in some future version of the platform (and then make it a public API instead of a jdk specific thing). Regards, Jeroen -Original Message- From: core-libs-dev-boun...@openjdk.java.net [mailto:core-libs-dev- boun...@openjdk.java.net] On Behalf Of Martin Buchholz Sent: Saturday, February 23, 2013 0:42 To: mark.reinh...@oracle.com Cc: core-libs-dev@openjdk.java.net Subject: Re: @Supported design issues One more thought. @Supported has RUNTIME retention, and it will be inevitable that some people will check the annotation at runtime. As a practical matter, once the annotation is added, it will never be removed (or removed only if the corresponding API is itself removed), (for fear of breaking someone), including by third parties like IcedTea.
