May 2014 - core-libs-dev

How to mount a volume with file owners being nobody?
by Wang Weijun 07 May '14

07 May '14

I have seen such things before but cannot create one now. I would like to simulate a problematic environment on my own machines. Any suggestion is welcomed, I have Mac OS X and Windows at hand but Linux and Solaris are also OK. Thanks Max

4 3

RFR [8011537]: (fs) Path.register(..) clears interrupt status of thread with no InterruptedException
by Ivan Gerasimov 06 May '14

06 May '14

Hello! The interrupted status of a thread gets cleared with a call to Path.register(). This is due to call to Object.wait(). Below is the fix with an updated regtest. Would you please help review it? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8011537 WEBREV: http://cr.openjdk.java.net/~igerasim/8011537/0/webrev/ Sincerely yours, Ivan

2 4

JDK-8042355 stream with sorted() causes downstream ops not to be lazy
by Paul Sandoz 06 May '14

06 May '14

Hi, https://bugs.openjdk.java.net/browse/JDK-8042355 http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8042355-sorted-short-circuit/w… This is an optimization to ensure that sorted() in sequential pipelines does not aggressively push all sorted elements downstream if the pipeline is known to be short-circuiting. Note that it is not an error that more elements, than strictly required to produce a result, may flow through the pipeline. This can occur, in general (not restricted to just sorting), for short-circuiting parallel pipelines. Paul.

4 4

Fedora sun.misc.Unsafe statistics
by Florian Weimer 06 May '14

06 May '14

Out of curiosity, I looked at JAR files in all RPMs in Fedora rawhide (the development version of Fedora that will turn into Fedora 21) and counted the number of RPM packages which had Java classes referencing individual methods in sun.misc.Unsafe. The attached table is sorted by decreasing package count, and grouped by method name and descriptor. These numbers do not include references through reflection, for obvious reasons. Java programming practices are sometimes at odds with distribution packaging, and due to licensing bias, the Fedora repository might not be representative of the general Java ecosystem. However, the statistics cover 1177 Java source RPMs containing 550829 classes in 570477 versions, so it's quite a bit of code, despite the fairly low number of references to sun.misc.Unsafe. -- Florian Weimer / Red Hat Product Security Team

3 4

Re: Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes
by Mandy Chung 06 May '14

06 May '14

On 3/7/14 2:20 PM, Sergey Bylokhov wrote: > On 3/8/14 12:19 AM, Mandy Chung wrote: >> On 3/7/14 7:03 AM, Sergey Bylokhov wrote: >>> Is this absolutely necessary? Does it mean that Get**Actions are >>> deprecated now? >> >> The question should be whether this dependency is absolutely >> necessary and it's not. Get**Action classes are simple convenient >> classes that you could either use lambda or implement your own one. >> AWT and other client code in the JDK is another heavy user of >> sun.security.action that you can consider simply have your own >> convenient class as module-private API. If sun.security.action were >> private to the security library, they would not be used in the client >> code in the first place (there are external code depending on it too >> [1 for example]). Now we are retrofitting and eliminate unnecessary >> dependency. > But after this fix: size of class files are increased, instead of > usage of one or two classes we get 50 new lambdas, and of course this > horrible cast. > new GetPropertyAction("user.home")); > vs > (PrivilegedAction<String>) () -> System.getProperty("user.home")); I don't like the cast either and can leave with it as the explicit method call is actually a plus. JDK-8019851 will re-examine this in 9 to bring something better. I'll need to find out from the performance team if the footprint is an issue. I'll follow this up and if it turns out to be an issue, we will fix it differently. The main fix here is to remove the dependency. Sergey - for client code, I do think it's good to eliminate such dependency. On the other hand, as the client code (desktop module) depends on many other internal APIs in the base module, I'll leave it as it is and revisit it later. thanks Mandy

2 1

Infiniband-SDP in Java
by Alex Fanando 06 May '14

06 May '14

Hi All, As you all know, OFED's Socket Direct protocol is deprecated and OFED's 3.x releases do not come with SDP at all. Hence, Java's SDP also fails to work. I was wondering what is the proper method to program infiniband in Java? Is there any portable solution other than just writing JNI code? My requirement is achieve RDMA among collection of infiniband powered machines. Regards,Robo

1 0

RFR [8040806]: BitSet.toString() can throw IndexOutOfBoundsException
by Ivan Gerasimov 05 May '14

05 May '14

Hello! If a BitSet has the bit Integer.MAX_VALUE set, then calling toString() will throw an exception. The same thing happens if the bit (Integer.MAX_VALUE-1) is set. Would you please help review the fix for this issue? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8040806 WEBREV: http://cr.openjdk.java.net/~igerasim/8040806/0/webrev/ Sincerely yours, Ivan

3 6

RFR 9: 8034906: Fix typos, errors and Javadoc differences in java.time
by roger riggs 05 May '14

05 May '14

Please review for JDK 9, editorial corrections and cleanup for java.time classes. The grammar has been improved and some redundant @throws NPE clauses removed. Javadoc links have been corrected. Original patch from Stephen Colebourne, some additions and corrections by me. webrev: http://cr.openjdk.java.net/~rriggs/webrev-typos-8034906.patch/ Issue: https://bugs.openjdk.java.net/browse/JDK-8034906 Thanks, Roger

2 1

Draft JEP: JDK Core Libraries Test Stabilization
by Stuart Marks 05 May '14

05 May '14

Hi all, Here's a draft JEP for stabilizing the core libraries regression test suite, that is, fixing up the spuriously failing tests. Please review and comment. Thanks! s'marks Title: JDK Core Libraries Test Stabilization Author: Stuart Marks Organization: Oracle Discussion: core-libs-dev(a)openjdk.java.net [...other metadata elided...] Summary ------- The JDK Regression Test Suite has several thousand fully automated tests. These tests are valuable and effective in that they serve to prevent bugs from entering the code base. However, they suffer from many intermittent failures. Many of these failures are "spurious" in that they are not caused by bugs in the product. Spurious failures add considerable noise to test reports; they make it impossible for developers to ascertain whether a particular change has introduced a bug; and they obscure actual failures. The reliability of the regression suite has improved considerably over the past few years. However, there are perhaps still 100-200 tests that fail intermittently, and most of these failures are spurious. This project aims to reduce the number and frequency of spuriously failing tests to a level where it no longer is an impediment to development. This project targets tests from the regression suite that cover the JDK Core Libraries, including base packages (java.lang, io, nio, util) I18N, Networking, RMI, Security, and Serviceability. JAXP and CORBA are also included, although they have relatively few regression tests at present. Non-Goals --------- Regression tests for other areas, including Hotspot, Langtools, and Client areas, are not included in this project. This project does not address operational issues that might cause builds or test runs to fail or for reports not to be delivered in a timely fashion. This project is not focused on product bugs that cause test failures. Such test failures are "good" in that the test suite is providing valid information about the product. Test runs on embedded platforms are not covered by this project. Success Metrics --------------- The reliability of a successful test run (100% pass) currently stands at approximately 0.5%. The goal is to improve this success rate to 98%, exclusive of true failures (i.e., those caused by bugs in the product). At a 98% success rate, a continuous build system that runs ten jobs per day, five days a week would have one or fewer spurious failures per week. Motivation ---------- Developers are continually hampered by the unreliability of the regression test suite. Intermittently failing tests add significant noise to the results of every test run. The consequence is that developers cannot tell whether test failures were caused by bugs introduced by a recent change or whether they are spurious failures. In addition, the intermittent failures mask actual failures in the product, slowing development and reducing quality. Developers should be able to rely on the test suite telling them accurate information: test failures should indicate the introduction of a bug into the system, and absence of test failures should be usable as evidence that changes are correct. Description ----------- Spurious test failures fall into two broad categories: - test bugs - environmental issues Our working assumption for most intermittent test failures is that they are spurious, and further, that they are caused by bugs in the test itself. While it is possible for a product bug to cause an intermittent failure, this is relatively rare. The majority of intermittent failures encountered so far have indeed proven to be test bugs. "Environmental" issues, such as misconfigured test machines, temporary dysfunction on the machine running the test job (e.g., filesystem full), or transient network failures, also contribute to spurious failures. Test should be made more robust, if possible. Environment issues should be fed back to the infrastructure team for resolution and future infrastructure improvements. A variety of techniques will be employed to diagnose, track, and help develop fixes for intermittently failing tests: - track all test failures in JBS - repeated test runs against the same build - gather statistics about failure rates, # tests with bugs, and track continuously - investigate pathologies for common test failure modes - develop techniques for fixing common test bugs - develop test library code to improve commonality across tests and to avoid typical failure modes - add instrumentation to tests (and to the test suite) to improve diagnosability - exclude tests judiciously, preferably only as a last resort - change reviews - code inspections Alternatives ------------ The most likely alternative to diagnosing and fixing intermittent failures is to aggressively exclude intermittently failing tests from the test suite. This trades off code coverage in favor of test reliability, adding risk of undetected bug introduction. Testing ------- The subject of the project is the test suite itself. The main "testing" of the test suite is running it repeatedly in a variety of environments, including continuous build-and-test systems, as well as recurring "same-binary" test runs on promoted builds. This will help flush out intermittent failures and detect newly introduced failures. Risks and Assumptions --------------------- We are working on a long tail of intermittent failures, which may become increasingly frustrating as time goes on, resulting in the project stalling out. New intermittent failures may be introduced or discovered more quickly than they can be resolved. The main work of fixing up the tests will be spread across several development groups. This requires good cross-group coordination and focus. The culture in the development group has (mostly) been to ignore test failures, or to find ways to cope with them. As intermittent failures are removed, we hope to decrease the group's tolerance of test failures. Dependences ----------- No dependences on other JEPs or components. Impact ------ No impact on specific parts of the platform or product, except for developer time and effort being spent on it, across various component teams. ==========

2 1

Covariant overrides on the Buffer Hierachy
by Richard Warburton 05 May '14

05 May '14

Hi, I'd like to have a discussion about tidying up a few core library method signatures in a way that (I think) is backwards compatible. I've been using ByteBuffer quite a lot recently which is designed to be a fluent API. Unfortunately its quite inconvenient to use because there's a hierarchy of classes at play (MappedByteBuffer, ByteBuffer and Buffer) and methods which are inherited from parent classes aren't overridden with covariant return types. For example the following code doesn't compile because clear is defined on Buffer and putInt is defined on ByteBuffer. ByteBuffer buffer = ByteBuffer.allocate(256); ByteBuffer other = buffer.duplicate() .clear() .putInt(0, 4); If clear was overridden in ByteBuffer with ByteBuffer as its return type then this would compile. Now I can appreciate that these classes were introduced in Java 1.4, which was before covariant overriding was possible, but I was wondering what the situation was with fixing it. To my mind, and by all means correct me if I've overlooked something, changing these methods to return their own type rather than the parent type should be backwards compatible at the source and binary levels. The only issue that I'm aware of that is related to this kind of change is the requirement to recompile all the classes in the hierarchy when making a change [0]. If you don't do this its possible for an infinite recursion and eventual stackoverflow to occur. Now as far as I can tell the entire hierarchy of Buffer classes are all either package scoped classes, or they are public classes with package scoped constructors. So I'm not aware of a way to sub class them without the code being part of the JDK. This would mean that the subclasses all need to be recompiled, satisfying the safety criteria. I'd be most appreciative of any feedback on this issue. regards, Richard Warburton http://insightfullogic.com @RichardWarburto <http://twitter.com/richardwarburto> [0] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/009119.ht… (thanks to Stuart Marks for pointing this one out to me)

9 26