December 2017 - core-libs-dev

Re: RFR 4358774: Add null InputStream and OutputStream
by Brian Burkhalter 08 Dec '17

08 Dec '17

On Dec 8, 2017, at 10:52 AM, David Lloyd <david.lloyd(a)redhat.com> wrote: > On Fri, Dec 8, 2017 at 12:38 PM, Brian Burkhalter > <brian.burkhalter(a)oracle.com> wrote: >> Patrick’s comment made us think again about the naming here as “nullStream()” would not fit for eventual equivalent methods on Reader and Writer. It might be better to go with something like >> >> InputStream InputStream.nullSource(); >> OutputStream.nullSink(); >> >> and later >> >> Reader.nullSource(); >> Writer.nullSink(); >> >> Another alternative would be simply to reflect the class names in the methods: >> >> InputStream InputStream.nullInputStream(); >> OutputStream.nullOutputStream(); >> >> and later >> >> Reader.nullReader(); >> Writer.nullWriter(); > > I for one prefer this alternative; it's very clear and unambiguous. The second one? Thanks, Brian

3 2

RFR: 8191033: Regression in logging.properties: specifying .handlers= for root logger (instead of handlers=) no longer works
by Daniel Fuchs 08 Dec '17

08 Dec '17

Hi, Please find below a patch for: 8191033 Regression in logging.properties: specifying .handlers= for root logger (instead of handlers=) no longer works https://bugs.openjdk.java.net/browse/JDK-8191033 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8191033/webrev.00/ The patch restores the behavior that was observed for JDK 8. The test fails with jdk 9.0.1, but passes with jdk1.8.0_131 and with this patch applied to a clone of http://hg.openjdk.java.net/jdk/jdk best regards, -- daniel

4 8

RFR: 8187073: The java.util.logging.Level.findLevel() will not correctly find a Level by it's int value
by Daniel Fuchs 08 Dec '17

08 Dec '17

Hi, Please find below a straightforward fix for: 8187073: The java.util.logging.Level.findLevel() will not correctly find a Level by it's int value https://bugs.openjdk.java.net/browse/JDK-8187073 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8187073/webrev.00/ As expected, the test fails without the fix and passes with it. best regards, -- daniel

2 1

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment
by Daniel D. Daugherty 08 Dec '17

08 Dec '17

Adding core-libs-dev@... since this is RMI code. Thanks Alan! Folks, this review spans three OpenJDK aliases so Thunderbird's reply-to-list feature won't get it right. This is one of the few times that reply-to-all is the right thing to do... Dan On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: > Greetings, > > I have a small fix for a very intermittent ServerSocket related test > failure: > > JDK-8182307: Error during JRMP connection establishment > https://bugs.openjdk.java.net/browse/JDK-8182307 > > The fix is copied from Jerry's work on the following bugs: > > JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris > https://bugs.openjdk.java.net/browse/JDK-8182757 > > JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception > https://bugs.openjdk.java.net/browse/JDK-8178676 > > For the gory details of the reasons for this fix please see > Jerry's bugs. > > Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ > > > I observed this test failure one time in my Thread-SMR work and have > been including this fix in months of Thread-SMR stress testing. It was > also included in both JPRT and Mach5 tier[1-5] testing of the Thread-SMR > changes. > > Thanks, in advance, for any comments, suggestions or questions. > > Dan >

5 9

Finalization and dead references: another proposal
by Hans Boehm 08 Dec '17

08 Dec '17

We're still trying to deal with a fair amount of code that implicitly assumes that finalization or similar clean-up will not occur while a pointer to the affected object is in scope. Which is of course not true. As a reminder, the canonical offending usage (anti-)pattern with (deprecated, but easier to write) finalizers is class Foo { private long mPtrToNativeFoo; private static native void nativeDeallocate(long nativePtr); private static native void nativeDoSomething(long nativePtr, long anotherNativePtr); protected void finalize() { ... nativeDeallocate(mPtrToNativeFoo); ... } public void doSomething(Foo another) { ... nativeDoSomething(mPtrToNativeFoo, another.mPtrToNativeFoo) ... } ... } This is subtly incorrect in that, while executing the final call to doSomething() on a particular object, just after retrieving mPtrToNativeFoo and another.mPtrToNativeFoo, but before invoking nativeDoSomething(), the garbage collector may run, and "this" and "another" may be finalized, deallocating the native objects their mPtrToNativeFoos refer to. When nativeDoSomething() finally does run, it may see dangling pointers. Examples using java.lang.ref or Cleaners (or even WeakHashMap, if you must) instead of finalize() are as easy to construct, but a bit longer. (The finalizer version is also arguably incorrect in other ways that are not relevant here. Pretend this were written in terms of PhantomReferences.) It is easily possible to construct 100% Java code with the same problem. Instead of mPtrToNativeFoo, each object stores an integer handle that is used to access additional Java state logically associated with the object. But the native pointer case seems to dominate in practice. Various solutions to this have been proposed, but none seem quite attractive enough that I actually feel comfortable asking people to update their code to use them. Noteworthy proposals include: 0) Explicitly call close() on such objects. Great idea when it works. In general it doesn't, since the code needs to know when the enclosing Java object is no longer needed. If we always knew that we wouldn't need a GC. 1) Various hacks to keep variables live, e.g. the one based on synchronized blocks I advocated in my 2004 JavaOne talk. These are slow and ugly, as we've always admitted. Nobody used them. Incorrect won over slow, ugly, and complicated ~100% of the time. 2) Java 9's reachabilityFence(). This is better. It can be implemented so that it's no longer slow. But in many common cases, it's still quite ugly. For example, the call to nativeDoSomething() above must be followed by two reachabilityFences, one on this and one on another. And to do this really correctly, the whole thing would often need to be in a try...finally block. And in reality code following this pattern usually doesn't have just a single doSomething method that needs this treatment, but may easily have dozens. And the rules for placing reachabilityFences can become quite subtle if there are e.g. locally allocated objects involved. My assessment is that this isn't good enough. People may no longer write incorrect code 100% of the time, but I'd bet on 70%+. 3) JNI functions can be rewritten, so that the containing Java object is passed in addition to the native pointers. Somewhat accidentally, this happens to be roughly free for single argument functions. (Delete "static".) It adds overhead in other cases, like the one above, and the rewriting can get somewhat convoluted. In some cases, it doesn't work at all. AFAIK, it's never actually guaranteed to be correct; it works because standard implementations don't optimize across the language boundary. That's not too likely to change. Maybe. 4) We could change the language spec to always prohibit premature finalization/cleaning in cases like the above. I could personally live with that solution, and proposed it internally here in the past. But it doesn't seem to go over well among implementers. And AFAICT, doing it well requires significant tooling changes, in that we do want to reliably treat local variables as dead once they go out of scope, a piece of information that doesn't seem to be reliably preserved in class files. One could argue that the current class file design implicitly assumes that we can do dead variable elimination. After going back and forth on this, my conclusion is that we need a linguistic mechanism for identifying the case in which the garbage collector is being used to managed external resources associated with a field. A (still slowly evolving) proposal to add an annotation to do so is at https://docs.google.com/document/d/1yMC4VzZobMQTrVAraMy7xBdWPCJ0p7G5r_43yaq… In many ways, this is inherently a compromise. But in the vast majority of cases, it greatly reduces the required source code changes over all but (4) above. And I think I could usually explain to an author of currently broken code in under 5 minutes exactly what they need to do to fix it. And I wouldn't have to lie much to do so. I don't think (0)-(3) above share that property. This has already benefited from comments provided by a few people. (Thanks to Doug, Jeremy, and Martin, among others.) But I would really like more feedback, including suggestions about how to proceed. Hans

4 12

RFR: jsr166 jdk integration 2017-12-XX
by Martin Buchholz 07 Dec '17

07 Dec '17

http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.… With the change to the openjdk release model, jsr166 integrations will simply be "jdk integrations" instead of e.g. "jdk10 integrations" from now on. (Nevertheless, we try to get in important bug fixes before jdk release gates shut) 8193174: SubmissionPublisher invokes the Subscriber's onComplete before all of its submitted items have been published http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/Submissio… https://bugs.openjdk.java.net/browse/JDK-8193174 8192943: Optimize atomic accumulators using VarHandle getAndSet http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/getAndSet… https://bugs.openjdk.java.net/browse/JDK-8192943 8192944: Miscellaneous changes imported from jsr166 CVS 2017-12-XX http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellan… https://bugs.openjdk.java.net/browse/JDK-8192944

3 2

RFR(XS) : 8181118 : update java/time tests to use RandomFactory from the top level testlibrary
by Igor Ignatyev 07 Dec '17

07 Dec '17

http://cr.openjdk.java.net/~iignatyev/8181118/webrev.00 > 115 lines changed: 0 ins; 108 del; 7 mod; Hi all, could you please review this small fix for java/time tests? RandomFactory has been moved to the top level testlibrary by 8180805[1], but java/time weren't updated when b/c jtreg didn't use external root for libraries listed in lib.dirs test property file[2]. it has been fixed in jtreg4.2b09, now java/time tests can be updated to use top level testlibrary and @deprecated RandomFactory (from test/jdk/lib/testlibrary) can be removed. webrev: http://cr.openjdk.java.net/~iignatyev/8181118/webrev.00 JBS: https://bugs.openjdk.java.net/browse/JDK-8181118 testing: java/time/jck and java/time/tests [1] https://bugs.openjdk.java.net/browse/JDK-8180805 [2] https://bugs.openjdk.java.net/browse/CODETOOLS-7901987 Thanks, -- Igor

2 3

Review Request: JDK-8193159: Reduce the number of classes loaded due to NativeLibrary
by mandy chung 07 Dec '17

07 Dec '17

A tiny startup fix - useArrayDeque instead of LinkedList for ClassLoader.NativeLibrary which is typically loaded at startup for example when loading a JAR file. Thanks Mandy diff --git a/src/java.base/share/classes/java/lang/ClassLoader.java b/src/java.base/share/classes/java/lang/ClassLoader.java --- a/src/java.base/share/classes/java/lang/ClassLoader.java +++ b/src/java.base/share/classes/java/lang/ClassLoader.java @@ -38,6 +38,7 @@ import java.security.PrivilegedAction; import java.security.ProtectionDomain; import java.security.cert.Certificate; +import java.util.ArrayDeque; import java.util.Arrays; import java.util.Collections; import java.util.Deque; @@ -45,7 +46,6 @@ import java.util.HashMap; import java.util.HashSet; import java.util.Hashtable; -import java.util.LinkedList; import java.util.Map; import java.util.NoSuchElementException; import java.util.Objects; @@ -2496,7 +2496,7 @@ } // native libraries being loaded - static Deque<NativeLibrary> nativeLibraryContext = new LinkedList<>(); + static Deque<NativeLibrary> nativeLibraryContext = new ArrayDeque<>(); /* * The run() method will be invoked when this class loader becomes

4 6

Change in properties for logging: deliberate?
by Jeremy Manson 07 Dec '17

07 Dec '17

Hey folks, I can't find reference to this in a relnote, so I thought I would ask. If we have the following files: logging.properties: # Set the level of the root logger .level = INFO # Send the root logger's output to the console .handlers = java.util.logging.ConsoleHandler Test.java: public class Test { public static void main(String[] args) { java.util.logging.Logger.getAnonymousLogger().info("Hi!"); } } In Java 8, we will see console output, and in Java 9, we won't. # Java 8 $ java -Djava.util.logging.config.file=logging.properties Test Nov 08, 2017 5:02:05 PM Test main INFO: Hi! # Java 9 $ java -Djava.util.logging.config.file=logging.properties Test I thought that, perhaps, a decision was made to have the empty string no longer mean the root logger, so I took it off of .handlers: logging.properties: # Set the level of the root logger .level = INFO # Send the root logger's output to the console handlers = java.util.logging.ConsoleHandler Success in the sense that this got me output in Java 9. However, .level still seems to work; if I then have: # Set the level of the root logger .level = WARNING # Send the root logger's output to the console handlers = java.util.logging.ConsoleHandler it sets the root logger's level to WARNING. I don't see any of this in a relnote anywhere, and I don't see an obvious bug about it anywhere. There seem to have been a fair few changes to java.util.logging in Java 9. Was a documented decision made to have .handlers stop meaning handlers on the root logger, but to allow .level to continue meaning level on the root logger? Or do I just have the wrong end of the stick on this? Thanks! Jeremy

5 17

Re: Java SE Maths questions.
by David Holmes 07 Dec '17

07 Dec '17

cc'ing core-libs-dev. Despite the notation on JEP 306 I don't think there's anyone from hotspot active in this area and most of the below is about SE library classes. David On 7/12/2017 11:39 AM, A Z wrote: > These are Java SE questions. > > -Is it likely that JEP 306 could be updated in a Java update, earlier? > Apart from the assertion 'will not fix', accurate floating point > is a massive requirement. It isn't very possible to do within-range > float or double multiplies, divides, powers, roots, or even things > in other classes like obtaining the distances between two points > (in Java2D and Java3D). > > -Could there be a BigDecimal version of StrictMath > being put in to the standard libraries, under Java's own umbrella, > and not as someone else's separate library? >

2 1