July 2011 - core-libs-dev

Bound MethodHandle at runtime
by Sebastian Sickelmann 20 Jul '11

20 Jul '11

Hi, first of all. Your Job at invokedynamic is really awesome. I have started a project called "mockinject" at java.net a few year ago that need to hook inside method calls and invokedynamic will make it really easy to do it in jdk7. I got some problem with the actual implementation some time ago, but i want to restart the project with invokedymic. mockinject does a lot of byte-code-fiddeling and this is really bug intensive. So i decided to start another project "jvmdebug" that emulates the real byte-code-instruction-execution with simulation-code which has debug-information-pointers to asm-dumps of the real-class. My favorite IDE detects the debug-information show the asm-dump and so it looks like you are debugging the byte-code. And here is my question: Is there a way to identify the actually bound method-handle that will be used by an invokedynimic call? It would be really usefull for the user to get this information before executing the invokedynamic instruction. Kind regards Sebastian -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

2 1

hg: jdk8/tl/jdk: 7068617: Core libraries don't build with javac -Xlint:all -Werror
by jonathan.gibbons＠oracle.com 20 Jul '11

20 Jul '11

Changeset: 9505edecc8b5 Author: jjg Date: 2011-07-20 12:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9505edecc8b5 7068617: Core libraries don't build with javac -Xlint:all -Werror Reviewed-by: darcy Contributed-by: alexandre.boulgakov(a)oracle.com ! make/java/java/Makefile ! src/share/classes/sun/reflect/generics/reflectiveObjects/NotImplementedException.java ! src/share/classes/sun/reflect/misc/ConstructorUtil.java ! src/share/classes/sun/reflect/misc/FieldUtil.java ! src/share/classes/sun/reflect/misc/MethodUtil.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java

1 0

hg: jdk8/tl/jdk: 7065972: Some race condition may happen in SSLSocketImpl class
by xuelei.fan＠oracle.com 20 Jul '11

20 Jul '11

Changeset: 99dc852080e1 Author: xuelei Date: 2011-07-19 21:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99dc852080e1 7065972: Some race condition may happen in SSLSocketImpl class Reviewed-by: wetmore, weijun, dgu ! src/share/classes/sun/security/ssl/SSLSocketImpl.java

1 0

hg: jdk8/tl/jdk: 7007535: (reflect) Please generalize Constructor and Method
by joe.darcy＠oracle.com 20 Jul '11

20 Jul '11

Changeset: d083644bc615 Author: darcy Date: 2011-07-19 17:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d083644bc615 7007535: (reflect) Please generalize Constructor and Method Reviewed-by: mduigou, peterjones, dholmes, andrew ! src/share/classes/java/lang/reflect/Constructor.java + src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Method.java

1 0

hg: jdk8/tl/jdk: 7067922: (launcher) java -jar throws NPE if JAR file does not contain Main-Class attribute
by kumar.x.srinivasan＠oracle.com 19 Jul '11

19 Jul '11

Changeset: d17eb3380a49 Author: ksrini Date: 2011-07-19 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d17eb3380a49 7067922: (launcher) java -jar throws NPE if JAR file does not contain Main-Class attribute Reviewed-by: darcy, ohair, alanb, mduigou ! src/share/classes/sun/launcher/LauncherHelper.java ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java

1 0

Launcher fix: 7067922, please review
by Kumar Srinivasan 19 Jul '11

19 Jul '11

Hi, Please review.... http://cr.openjdk.java.net/~ksrini/7067922 Thanks Kumar

5 5

hg: jdk8/tl/jdk: 7059709: close the IO in a final block
by xuelei.fan＠oracle.com 19 Jul '11

19 Jul '11

Changeset: 5355b9ccd19d Author: xuelei Date: 2011-07-19 08:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5355b9ccd19d 7059709: close the IO in a final block Reviewed-by: smarks, mullan, wetmore ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java

1 0

FontConfig fails when optional system library is missing
by Steve Poole 18 Jul '11

18 Jul '11

Hi all, a problem was discovered on JDK7 when using the Nimbus L&F on a system where libfontconfig.so was not installed (On AIX actually but in theory on any unix system) Under the covers Nimbus uses the sun.font.FontConfigManager to retrieve fonts. sun.font.FontConfigManager in turn is intended to use (for a unix system) the libfontconfig.so system library if present. The code is intended to cope with the library being missing but it unfortunately doesn't. A array is referenced without checking if it is null. On systems where the system library is present this array is never null but in this specific case the array is null and the reference fails as follows. — Exception in thread "main" java.lang.NullPointerException at sun.font.FontConfigManager.getFontConfigFont(FontConfigManager.java:352) at sun.awt.X11FontManager.getFontConfigFUIR(X11FontManager.java:817) at sun.font.FontUtilities.getFontConfigFUIR(FontUtilities.java:472) at javax.swing.plaf.nimbus.NimbusDefaults.<init>(NimbusDefaults.java:138) at javax.swing.plaf.nimbus.NimbusLookAndFeel.<init>(NimbusLookAndFeel.java:100) at Nimbus.main(Nimbus.java:6) – The fix is trivial (see attached) and probably just tactical. Cheers, Steve

2 3

hg: jdk8/tl/jdk: 7021280: SocketPermission should accept wildcards
by chris.hegarty＠oracle.com 18 Jul '11

18 Jul '11

Changeset: 8bbea505b060 Author: chegar Date: 2011-07-18 22:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8bbea505b060 7021280: SocketPermission should accept wildcards Reviewed-by: michaelm ! src/share/classes/java/net/SocketPermission.java + test/java/net/SocketPermission/Wildcard.java

1 0

JDK 8 code review request for 7062430 "Minor iconsistency in ulp descriptions"
by Joe Darcy 18 Jul '11

18 Jul '11

Hello. Please review this small doc change to spell out what "ulp" means in the methods named "ulp" in the Math and StrictMath classes; patch below, webrev at: 7062430 "Minor iconsistency in ulp descriptions" http://cr.openjdk.java.net/~darcy/7062430.0/ Due to paragraph reformatting, the change takes up many more physical lines than logical ones. In each of the four ulp methods (for for float and one for double in each of Math and StrictMath) the phrase "An ulp of a [...] value is the positive distance..." is replaced with "An ulp, unit in the last place, of a [...] value is the positive distance..." Additionally, the reference to ulp in one the opening paragraphs of the Math class description is replaced with a link to one of the ulp methods in Math. Thanks, -Joe --- old/src/share/classes/java/lang/Math.java 2011-07-14 18:07:17.000000000 -0700 +++ new/src/share/classes/java/lang/Math.java 2011-07-14 18:07:17.000000000 -0700 @@ -50,34 +50,34 @@ * * The quality of implementation specifications concern two * properties, accuracy of the returned result and monotonicity of the - * method. Accuracy of the floating-point {@code Math} methods - * is measured in terms of ulps, units in the last place. For - * a given floating-point format, an ulp of a specific real number - * value is the distance between the two floating-point values - * bracketing that numerical value. When discussing the accuracy of a - * method as a whole rather than at a specific argument, the number of - * ulps cited is for the worst-case error at any argument. If a - * method always has an error less than 0.5 ulps, the method always - * returns the floating-point number nearest the exact result; such a - * method is correctly rounded. A correctly rounded method is - * generally the best a floating-point approximation can be; however, - * it is impractical for many floating-point methods to be correctly - * rounded. Instead, for the {@code Math} class, a larger error - * bound of 1 or 2 ulps is allowed for certain methods. Informally, - * with a 1 ulp error bound, when the exact result is a representable - * number, the exact result should be returned as the computed result; - * otherwise, either of the two floating-point values which bracket - * the exact result may be returned. For exact results large in - * magnitude, one of the endpoints of the bracket may be infinite. - * Besides accuracy at individual arguments, maintaining proper - * relations between the method at different arguments is also - * important. Therefore, most methods with more than 0.5 ulp errors - * are required to be semi-monotonic: whenever the mathematical - * function is non-decreasing, so is the floating-point approximation, - * likewise, whenever the mathematical function is non-increasing, so - * is the floating-point approximation. Not all approximations that - * have 1 ulp accuracy will automatically meet the monotonicity - * requirements. + * method. Accuracy of the floating-point {@code Math} methods is + * measured in terms of ulps, units in the last place. For a + * given floating-point format, an {@linkplain #ulp(double) ulp} of a + * specific real number value is the distance between the two + * floating-point values bracketing that numerical value. When + * discussing the accuracy of a method as a whole rather than at a + * specific argument, the number of ulps cited is for the worst-case + * error at any argument. If a method always has an error less than + * 0.5 ulps, the method always returns the floating-point number + * nearest the exact result; such a method is correctly + * rounded. A correctly rounded method is generally the best a + * floating-point approximation can be; however, it is impractical for + * many floating-point methods to be correctly rounded. Instead, for + * the {@code Math} class, a larger error bound of 1 or 2 ulps is + * allowed for certain methods. Informally, with a 1 ulp error bound, + * when the exact result is a representable number, the exact result + * should be returned as the computed result; otherwise, either of the + * two floating-point values which bracket the exact result may be + * returned. For exact results large in magnitude, one of the + * endpoints of the bracket may be infinite. Besides accuracy at + * individual arguments, maintaining proper relations between the + * method at different arguments is also important. Therefore, most + * methods with more than 0.5 ulp errors are required to be + * semi-monotonic: whenever the mathematical function is + * non-decreasing, so is the floating-point approximation, likewise, + * whenever the mathematical function is non-increasing, so is the + * floating-point approximation. Not all approximations that have 1 + * ulp accuracy will automatically meet the monotonicity requirements. * * @author unascribed * @author Joseph D. Darcy @@ -940,11 +940,11 @@ } /** - * Returns the size of an ulp of the argument. An ulp of a - * {@code double} value is the positive distance between this - * floating-point value and the {@code double} value next - * larger in magnitude. Note that for non-NaN x, - * <code>ulp(-x) == ulp(x)</code>. + * Returns the size of an ulp of the argument. An ulp, unit in + * the last place, of a {@code double} value is the positive + * distance between this floating-point value and the {@code + * double} value next larger in magnitude. Note that for non-NaN + * x, <code>ulp(-x) == ulp(x)</code>. * * Special Cases: * <ul> @@ -967,11 +967,11 @@ } /** - * Returns the size of an ulp of the argument. An ulp of a - * {@code float} value is the positive distance between this - * floating-point value and the {@code float} value next - * larger in magnitude. Note that for non-NaN x, - * <code>ulp(-x) == ulp(x)</code>. + * Returns the size of an ulp of the argument. An ulp, unit in + * the last place, of a {@code float} value is the positive + * distance between this floating-point value and the {@code + * float} value next larger in magnitude. Note that for non-NaN + * x, <code>ulp(-x) == ulp(x)</code>. * * Special Cases: * <ul> --- old/src/share/classes/java/lang/StrictMath.java 2011-07-14 18:07:18.000000000 -0700 +++ new/src/share/classes/java/lang/StrictMath.java 2011-07-14 18:07:18.000000000 -0700 @@ -932,11 +932,11 @@ } /** - * Returns the size of an ulp of the argument. An ulp of a - * {@code double} value is the positive distance between this - * floating-point value and the {@code double} value next - * larger in magnitude. Note that for non-NaN x, - * <code>ulp(-x) == ulp(x)</code>. + * Returns the size of an ulp of the argument. An ulp, unit in + * the last place, of a {@code double} value is the positive + * distance between this floating-point value and the {@code + * double} value next larger in magnitude. Note that for non-NaN + * x, <code>ulp(-x) == ulp(x)</code>. * * Special Cases: * <ul> @@ -959,11 +959,11 @@ } /** - * Returns the size of an ulp of the argument. An ulp of a - * {@code float} value is the positive distance between this - * floating-point value and the {@code float} value next - * larger in magnitude. Note that for non-NaN x, - * <code>ulp(-x) == ulp(x)</code>. + * Returns the size of an ulp of the argument. An ulp, unit in + * the last place, of a {@code float} value is the positive + * distance between this floating-point value and the {@code + * float} value next larger in magnitude. Note that for non-NaN + * x, <code>ulp(-x) == ulp(x)</code>. * * Special Cases: * <ul>

4 3