August 2014 - core-libs-dev

JDK 9 RFR of 8054720: Modifications of I/O methods for instrumentation purposes
by Brian Burkhalter 25 Aug '14

25 Aug '14

JDK 9 reviewers: I would like to reprise this thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-August/028181.html with an updated patch Issue: https://bugs.openjdk.java.net/browse/JDK-8054720 Patch: http://cr.openjdk.java.net/~bpb/8054720/webrev.01/ This changes builds on all platforms and passes the jdk_io and jdk_net tests on all platforms. Note that the patch posted in the original discussion thread has been moved to http://cr.openjdk.java.net/~bpb/8054720/webrev.00/ Thanks, Brian

3 2

RFR 8042003: java/lang/Math tests have external dependency on sun.misc.DoubleConsts and sun.misc.FloatConsts
by Amy Lu 22 Aug '14

22 Aug '14

There are jdk tests that have dependency on sun.misc.DoubleConsts and sun.misc.FloatConsts. This fix is to remove above internal API dependency from the tests. bug: https://bugs.openjdk.java.net/browse/JDK-8042003 webrev: http://cr.openjdk.java.net/~ewang/amylu/JDK-8042003/webrev.00/ The fix: 1. Updated test withconstants that defined in java.lang.Double/Float if the definition exist 2. Introduced jdk.testlibrary.DoubleUtils/FloatUtils to contain additional constants Thanks, Amy

3 11

8055393: Some tests added to the TEST.group to exclude execution on inappropriate compact profiles
by Evgeniya Stepanova 21 Aug '14

21 Aug '14

Hi all, Could you please review fix for 8055393 Problem:Some tests are being executed and fail under profiles Solution: -test java/lang/ProcessBuilder/InheritIO/InheritIO.sh changed to use COMPILEJAVA (set by jtreg harness) javac instead of TESTJAVA (which is absent in profiles) -java/lang/annotation/AnnotationType/AnnotationTypeDeadlockTest.java and some of the java/util/logging/ tests use java.lang.management.ManagementFactory class to get deadlocked threads. Such tests are added to the needs_compact3 testgroup -test java/lang/invoke/lambda/LambdaAsm.java check bytecode generation and use javac classes. Added to needs_jdk testgroup -test java/net/Authenticator/B4769350.java uses com.sun.net.httpserver.HttpHandler class as base class for all testcases. Added to the needs_compact2 testgroup -Some of the javax/management/mxbean tests uses java.beans.ConstructorProperties annotation. Such tests are added to the needs_jre test group -test sun/misc/URLClassPath/ClassnameCharTest.java included in both needs_compact2 and needs_jre testgroups. Removed from needs_compact2 testgroup since it fails on compacts2-3 Testing: locally. Tests excluded as expected In attachement diff against jdk8u-dev repo

3 6

RFR 8055262: Update jdk/test/java/util/Base64 tests to use java.util.Base64 instead of sun.misc.BASE64Encoder/Decoder
by Amy Lu 19 Aug '14

19 Aug '14

There are two tests under jdk/test/java/util/Base64 that have dependency on internal API sun.misc.BASE64Encoder sun.misc.BASE64Decoder java/util/Base64/TestBase64Golden.java java/util/Base64/TestBase64.java This fix is to remove the internal API dependency from the tests. bug: https://bugs.openjdk.java.net/browse/JDK-8055262 webrev: http://cr.openjdk.java.net/~ewang/amylu/JDK-8055262/webrev.00/ As mentioned tests are testing java.util.Base64, in this case, the unnecessary sun.misc.BASE64* verifying can be removed. Thanks, Amy

3 4

RFR: 8052403 java/util/logging/CheckZombieLockTest.java fails with NoSuchFileException
by Daniel Fuchs 19 Aug '14

19 Aug '14

Please find below a fix for 8052403: java/util/logging/CheckZombieLockTest.java fails with NoSuchFileException https://bugs.openjdk.java.net/browse/JDK-8052403 The issue here is that CheckZombieLockTest and CheckLockLocationTest use (create and delete) the same writable-dir under /tmp. When jtreg is run with a high concurrency factor this sometimes results in one of the tests deleting the directory that the other is running. I could verify this by triggering the same failure with: jtreg -verbose:all -jdk $MYJDK -conc:12 \ jdk/test/java/util/logging/Check* The fix simply arranges for CheckZombieLockTest to use a different directory than that used by CheckLockLocationTest (and also improves the diagnostic by arranging for setUp() to fail fast if the test lock file cannot be created). Webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8052403/webrev.00/ best regards, -- daniel

2 2

new StringBuilder(char)
by Eddie Aftandilian 19 Aug '14

19 Aug '14

Hi all, We recently realized that calling new StringBuilder(char) does not do what you would think it does. Since there is no char constructor defined, the char is widened to an int and the StringBuffer is presized to the character's encoded value. Thus code like this prints an empty string rather than the expected "a": System.out.println(new StringBuilder('a')); Would it be possible to add a char constructor to StringBuilder to prevent this problem? I understand this would change the behavior of any code that is currently doing this, but it's hard to imagine anyone doing this intentionally. Of the ~20 instances we found in Google's codebase, all were bugs. What is your policy on making changes like this where (a) it will cause a change in behavior, but (b) the currently behavior is clearly wrong? If you're willing to take the change, I'd be happy to send a patch. Thanks, Eddie

9 12

sun.net.www.protocol.https.HttpsURLConnectionImpl doesn't equal to self
by Stanimir Simeonoff 18 Aug '14

18 Aug '14

Hi, As the title says there is a major bug with HttpsURLConnection as it breaks the contract of equals. So the instance cannot be contained (mostly removed) in any collection reliably. (Concurrent)HashMap has a provision to test equality by reference prior calling equals, though. Finding the bug in production is quite a ride as the http variant doesn't exhibit the problem. Here is a simple test case. public static void main(String[] args) throws Throwable{ URLConnection c = new URL("https://oracle.com").openConnection(); System.out.println(c.getClass().getName()+" equals self: " +c.equals(c)); c.getInputStream().close(); System.out.println(c.getClass().getName()+" equals self: " +c.equals(c)); } The culprit is in HttpsURLConnectionImpl.equals that blindly calls delagate.equals: public boolean equals(Object obj) { return delegate.equals(obj); } It should be changed to: public boolean equals(Object obj) { return this==obj || (obj instanceof HttpsURLConnectionImpl) && delegate.equals( ((HttpsURLConnectionImpl)obj).delegate ); } The class has some other issue that involves declaring "finalize" method to simply call delegate's dispose. The finalize method is unneeded and just creates unnecessary link in the finalization queue + Finalizer object. Thanks Stanimir

2 1

JEP Review Request: Improve Security Manager Performance
by Sean Mullan 14 Aug '14

14 Aug '14

Hello all, I have submitted a JEP for "Improve Security Manager Performance" that I am seeking further review and feedback: https://bugs.openjdk.java.net/browse/JDK-8043631 This is very similar to a draft I posted earlier [1], but has been re-drafted using the JEP 2.0 process. The JEP is intentionally short on details as it is more of an exploratory JEP at this point and will be updated as potential improvements are prototyped and measured. I want to thank everyone that has provided valuable feedback and ideas so far, especially Peter Firmstone and David M. Lloyd. Please continue to send any more data or ideas you have, no matter how small or trivial you think they may be. This is a great opportunity to gather and share knowledge about this area from the community. Thanks, Sean [1] http://mail.openjdk.java.net/pipermail/security-dev/2014-April/010432.html

1 0

RFR: 8054480: Test java/util/logging/TestLoggerBundleSync.java fails: Unexpected bundle name: null
by Daniel Fuchs 14 Aug '14

14 Aug '14

Hi, Please find below a fix for: 8054480: Test java/util/logging/TestLoggerBundleSync.java fails: Unexpected bundle name: null This test has been reported to fail from time to time with the following stack: java.lang.RuntimeException: Unexpected bundle name: null at TestLoggerBundleSync$GetRB.run(TestLoggerBundleSync.java:257) The issue here is due to a race condition in the test code. The comments in the fix explains the fix & the issue. http://cr.openjdk.java.net/~dfuchs/webrev_8054480/webrev.00/ -- The test creates several GetRB threads which 'read' the resource bundle that will be used by loggers. It does that by publishing a dummy message in a child logger, and checking the resource bundle name stored in the associated LogRecord. The test also creates several SetRB/SetRBName threads which attempts to set the resource bundle on loggers, in parallel with the GetRB threads. The race condition occurs because although each GetRB thread has its own Handler that it uses to get at the ResourceBundle in the LogRecord, it can receive LogRecords that were emitted by other GetRB threads - which (because of thread scheduling) might have been prepared at an earlier time and may contain stale information. What it means is that the following logic from GetRB is flawed: a. gets ResourceBundle from parent logger b. register handler with child logger c. emit dummy message through child logger d. remove handler registered in b. f. check resource bundle that was passed in LogRecord, comparing it with the resource bundle obtained in a. The expectation is that if a. is not null, then the resource bundle name obtained by the handler should not be null, and should be equal to the name obtained in a. This logic is flawed and prone to race conditions, because the following may sometime happens: GetRB#1 logs a message, but gets interrupted after LogRecord is created but before publish() is called. At this point the ResourceBundle has not been set yet, so the record has a null ResourceBundle. SetRB#? sets resource bundle on parent logger GetRB#2 sees the new resource bundle, emit a dummy message, but is interrupted before it removes its handler. At this point the handler has the correct resource bundle and resource bundle name that it found in the LogRecord emitted by GetRB#2 in step c. GetRB#1 is resumed. LogRecord gets published - but since the handler from thread #2 is still present, the 'old' LogRecord from GetRB#1 gets forwarded to GetRB#2's handler where it erases the information previously recorded by the message that was emitted by GetRB#2 GetRB#2 is resumed, and sees the rbName/rb that was present in the old LogRecord emitted by GetRB#1 instead of seeing the newer information that was in the LogRecord emitted by GetRB#2. => the exception gets raised. The fix is relatively simple: the Handler registered by each GetRB thread need simply to ignore messages that were not emitted by its own thread - we do this now by passing 'this' as parameter to the dummy logged message - and by comparing GetRB.this with LogRecord.getParameters()[0]; best regards, -- daniel

2 1

How to use jvisualvm to find memory leaks?
by Wang Weijun 14 Aug '14

14 Aug '14

I am looking at "8054896: Loading a KeyStore prevents GC of Classloader" and am now able to reproduce it on my system. I do see the webapp-related classes present in a heapdump created by VisualVM but not sure what the next steps should be to tell why they are not GC'ed. Is there a good tutorial on this? Thanks Max

2 1