May 2016 - core-libs-dev

JDK 9 RFR of JDK-8155963: Fix deprecation warning in windows java.net implementation
by joe darcy 03 May '16

03 May '16

Hello, Please review the patch below is address windows-specific code which was overlooked on the cleanup passes ahead of fixing JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract. Thanks, -Joe diff -r 03453120a011 src/java.base/windows/classes/java/net/DefaultDatagramSocketImplFactory.java --- a/src/java.base/windows/classes/java/net/DefaultDatagramSocketImplFactory.java Tue May 03 10:40:54 2016 -0700 +++ b/src/java.base/windows/classes/java/net/DefaultDatagramSocketImplFactory.java Tue May 03 12:12:09 2016 -0700 @@ -90,7 +90,9 @@ throws SocketException { if (prefixImplClass != null) { try { - return (DatagramSocketImpl) prefixImplClass.newInstance(); + @SuppressWarnings("deprecation") + Object result = prefixImplClass.newInstance(); + return (DatagramSocketImpl) result; } catch (Exception e) { throw new SocketException("can't instantiate DatagramSocketImpl"); }

2 1

JEP 118 Parameter Names by default
by Steven Schlansker 03 May '16

03 May '16

Hi core-libs-dev, Apologies in advance if this is the wrong list, I was torn between this one and compiler-dev, but I'm already subscribed here so we'll try this first :) I am trying to understand why the javac '-parameters' option is not enabled by default. Normally it would not be too onerous, but due to some limitations in e.g. Maven it is surprisingly difficult to configure correctly in a world where you must build code that both targets e.g. 1.8 and 1.7 (and soon 1.9): http://mail-archives.apache.org/mod_mbox/maven-dev/201604.mbox/browser While I am happy to work with the Maven project to improve their support for sending compiler arguments more flexibly, I did wonder -- why is this feature not on by default? I did some brief searching and was unable to come up with any downside, but maybe I missed something obvious? Can we turn it on by default for Java 9? Thanks for humoring me, Steven

2 2

RFR: 8155939: sun.launcher.LauncherHelper INSTANCE is unused
by Claes Redestad 03 May '16

03 May '16

Hi, sun.launcher.LauncherHelper is currently a singleton enum class, but the INSTANCE is never used. With encapsulation in place we shouldn't worry about cleaning this up. jdeps data show no usage of this helper class outside of the JDK. Bug: https://bugs.openjdk.java.net/browse/JDK-8155939 Patch: diff -r 930d3aef37ee src/java.base/share/classes/sun/launcher/LauncherHelper.java --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java Tue May 03 15:50:54 2016 +0200 +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java Tue May 03 16:23:26 2016 +0200 @@ -84,8 +84,10 @@ import jdk.internal.misc.VM; -public enum LauncherHelper { - INSTANCE; +public final class LauncherHelper { + + // No instantiation + private LauncherHelper() {} // used to identify JavaFX applications private static final String JAVAFX_APPLICATION_MARKER = Thanks! /Claes

2 2

RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them
by Steve Drach 03 May '16

03 May '16

I’ve updated the webrev to change all instances of the word “reified” to “real” as in getRealName(). Issue: https://bugs.openjdk.java.net/browse/JDK-8151542 <https://bugs.openjdk.java.net/browse/JDK-8151542> Webrev: http://cr.openjdk.java.net/~sdrach/8151542/webrev.01/ <http://cr.openjdk.java.net/~sdrach/8151542/webrev.01/>

5 19

[9] RFR: 8155859: Problem list tools/pack200/Pack200Props.java
by Artem Smotrakov 02 May '16

02 May '16

Hello, tools/pack200/Pack200Props.java fails on multiple platforms. Please see details in https://bugs.openjdk.java.net/browse/JDK-8155857 Please review the following patch below which adds the test to ProblemList.txt Bug: https://bugs.openjdk.java.net/browse/JDK-8155859 diff -r 2bf84670f079 test/ProblemList.txt --- a/test/ProblemList.txt Sat Apr 30 16:08:48 2016 -0700 +++ b/test/ProblemList.txt Mon May 02 12:02:42 2016 -0700 @@ -319,6 +319,8 @@ tools/launcher/FXLauncherTest.java 8068049 linux-all,macosx-all +tools/pack200/Pack200Props.java 8155857 generic-all + ############################################################################ # jdk_jdi Artem

2 1

RFR (M) 8155739: [TESTBUG] VarHandles/Unsafe tests for weakCAS should allow spurious failures
by Aleksey Shipilev 02 May '16

02 May '16

Hi, I would like to fix a simple testbug in our weakCompareAndSet VarHandles and Unsafe intrinsics tests. weakCompareAndSet is spec-ed to allow spurious failures, but current tests do not allow that. This blocks development and testing on non-x86 platforms. Bug: https://bugs.openjdk.java.net/browse/JDK-8155739 Webrevs: http://cr.openjdk.java.net/~shade/8155739/webrev.hs.00/ http://cr.openjdk.java.net/~shade/8155739/webrev.jdk.00/ The tests are auto-generated, and the substantiative changes are in *.template files. I also removed obsolete generate-unsafe-tests.sh. I would like to push through hs-comp to expose this to Power and AArch64 folks early. Testing: x86_64, jdk:java/lang/invoke/VarHandle, hotspot:compiler/unsafe Thanks, -Aleksey

3 4

RFR: 8139982 Re-examine java.management dependency on java.util.logging.LoggingMXBean
by Daniel Fuchs 02 May '16

02 May '16

Hi, Please find below a patch [2] that eliminates a static dependency of java.lang.management on java.util.logging.LoggingMXBean. When JDK-6876135 was fixed, it introduced the PlatformLoggingMXBean interface, and recommended using PlatformLoggingMXBean over LoggingMXBean. However, it left a static dependency on java.util.logging.LoggingMXBean in java.lang.management: The MBean registered in the MBeanServer was a private class in ManagementFactoryHelper implementing a non standard interface that extended both PlatformLoggingMXBean and LoggingMXBean. (sun.management.ManagementFactoryHelper$LoggingMXBean) (see https://bugs.openjdk.java.net/browse/JDK-6876135) This patch proposes to relax the constraint on the PlatformLoggingMXBean implementation - by no longer forcing it to implement LoggingMXBean. This will allow to get rid of the non standard interface, and make the MBean declare "java.lang.management.PlatformLoggingMXBean" as its MXBean interface. To make it clear that PlatformLoggingMXBean should be used instead of LoggingMXBean we also propose to deprecate the java.util.logging.LoggingMXBean interface as well as the LogManager.getLoggingMXBean() method (since it returns a deprecated type). As of yet, there no intention of removing any of these. Backward Compatibility considerations: -------------------------------------- 1. Local clients which obtain an instance of the logging MXBean by calling ManagementFactory.getPlatformMXBean( "java.util.logging:type=Logging", PlatformLoggingMXBean.class) will no longer be able to cast the result on java.util.logging.LoggingMXBean. [There should be few, given that PlatformLoggingMXBean already has all the methods defined in LoggingMXBean] 2. ManagementFactory.getPlatformMBeanServer().isInstanceOf( ObjectName, "java.util.logging.LoggingMXBean") will now return 'false' instead of 'true'. 3. The Logging MXBean MBeanInfo will now report that its management interface is "java.lang.management.PlatformLoggingMXBean" instead of "sun.management.ManagementFactoryHelper$LoggingMXBean". 4. Calls to ManagementFactory.newPlatformMXBeanProxy( MBeanServerConnection, ObjectName, java.util.logging.LoggingMXBean.class); and JMX.newMXBeanProxy(MBeanServerConnection, ObjectName, java.util.logging.LoggingMXBean.class) will continue to work as before. 5. Remote clients running previous version of the JDK should see no changes, except for the interface name in MBeanInfo, and the change in isInstanceOf reported in 2. [1] JBS issue: https://bugs.openjdk.java.net/browse/JDK-8139982 [2] webrev: http://cr.openjdk.java.net/~dfuchs/8139982_webrev/webrev.06/index.html best regards, -- daniel

2 6

RFR: 8155775: Re-examine naming of privileged methods to access System properties
by Claes Redestad 02 May '16

02 May '16

Hi, JDK-8154231 added methods to simplify access to system properties from internal code, but after some discussion it's been decided to rename these methods and document them to make it abundantly clear that they are performing a privileged action and that care needs to be taken to tread the input and output accordingly: Webrev: http://cr.openjdk.java.net/~redestad/8155775/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8155775 Thanks! /Claes

2 3

String.equalsIgnoreCase(...) optimization
by Andrey 01 May '16

01 May '16

Hello! I read source code equalsIgnoreCase(...) in String class and saw that it is not optimal. This method check length and call regionMatches(...) with 'constant' values http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classe… ... && (anotherString.value.length == value.length) && regionMatches(true, 0, anotherString, 0, value.length); ... But regionMatches(...) check 'constant' values http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classe… // Note: toffset, ooffset, or len might be near -1>>>1. if ((ooffset < 0) || (toffset < 0) || (toffset > (long)value.length - len) || (ooffset > (long)other.value.length - len)) { return false; } and increment equalent variables to==po in loop http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classe… while (len-- > 0) { char c1 = ta[to++]; char c2 = pa[po++]; ... } and use if(...) in while loop http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classe… if (ignoreCase) { ... } May be can create optimized regionMatches(...) for use in equalsIgnoreCase(...)?

3 7

Re: RFR(m): 8140281 deprecate Optional.get()
by Paul Benedict 01 May '16

01 May '16

Are you asking Brian to set up another survey monkey for the masses? I expect a happy silent majority and a raucous minority.... just based on past results. :-) On Apr 26, 2016 6:38 PM, "Vitaly Davidovich" <vitalyd(a)gmail.com> wrote: I've yet to hear one supporter on this thread besides yourself and Stuart. Is there some usability survey or something that actually indicates a significant sample of people don't like the name? Guava Optional behaves and is named the same way, and I've not heard anyone complain about that (I and many people I know used it for years). I think the conversation would be *maybe* different if picking a name for a new thing, but the deprecation churn here adds no value, IMO, and is going to be viewed as an annoyance by a large swath of people. On Tuesday, April 26, 2016, Brian Goetz <brian.goetz(a)oracle.com> wrote: > As the person who chose the original (terrible) name, let me weigh in... > > I think calling this method "get()" was our biggest API mistake in Java > 8. Now, one could argue that, if this is the biggest mistake we made, then > we did pretty darn good. Which may be true, but ... make no mistake, it > was the wrong name (mea culpa), and experience has borne out that it is > widely misused. Subjectively, about half the uses of .get() I see are > wrong -- and wrong in the obvious, avoidable way -- they don't consider the > optional might be empty. So they've just traded an unexpected NPE for an > unexpected NSEE. > > Its problem is, essentially: it looks harmless, but isn't, but it sure > seems like the method you obviously want when you're browsing the > autocomplete list / javadoc. It's a hazard both to code writers (pick the > wrong method because the name is bad) and to code readers (deceptively > harmless looking.) > > Methods like orElse or ifPresent look harmless, and are; methods like > orElseThrow have potentially harmful side-effects but have names that are > transparent about what harm they could do. But Optional.get() is neither > safe nor transparent -- and yet awfully tempting-looking -- and this leads > to frequent misuse. Naming matters, and this one was wrong, and the harm > is observable. I wish I'd caught it before 8 shipped. > > Stepping back a bit ... one of the most frequent complaints we get is > "mistakes never get fixed". So, we've decided to be more serious about > deprecation -- Dr. Deprecator is suiting up! But that means, for any given > item, some people are going to disagree about whether deprecation is > suitable, and some will be inconvenienced by the deprecation -- this is > unavoidable. > > Why prioritize this one? In part, because it's a *new* mistake, and has > had less time to become entrenched -- and this is the very first > opportunity we have to fix it. If we can't fix an API mistake at the very > first opportunity, the logical consequence is we can't ever fix anything. > And that doesn't seem to be the world we want to retreat to. > > Similarly, is this the worst mistake in all of Java? Surely not. But its > also not reasonable to say "you can't fix X until you've fixed everything > worse than X" -- again, that's a recipe for never fixing anything. So, in > the context of a deprecation effort, this seems an entirely reasonable > candidate. > > I'd like to see it fixed, and the sooner the better. > > > On 4/26/2016 6:43 AM, Stephen Colebourne wrote: > >> In OpenGamma Strata we have 546 uses of Optional.get(). Renaming this >> would be painful and add no value. >> >> While I understand the pain from some developers not understanding the >> feature, this is hardly unique in the world of Java. Developers learn >> the right way of doing something soon enough. >> >> And while >> >> if (opt.isPresent()) { >> opt.get() >> } >> >> is sometimes not ideal, in other cases it is the only practical choice >> (eg. where the method needs to have a return statement inside the if >> statement). >> >> Changing this to >> >> if (opt.isPresent()) { >> opt.getWhenPresent() >> } >> >> is just noise - I can see the "present" part twice. >> >> I just don't think I can support the rename (although many of the >> webrev tidy-ups are probably good). >> >> Stephen >> >> >> >> On 26 April 2016 at 00:05, Stuart Marks <stuart.marks(a)oracle.com> wrote: >> >>> Hi all, >>> >>> Please review these webrevs that deprecate Optional.get() and to replace >>> it >>> with Optional.getWhenPresent(). The corresponding changes are also >>> applied >>> to OptionalDouble.getAsDouble(), OptionalInt.getAsInt(), and >>> OptionalLong.getAsLong(). >>> >>> Unlike most deprecations, this isn't about the function or the utility of >>> some API, it's about the name. The solution is basically to rename the >>> API. >>> The problem is that "get" shows up as the "obvious" choice in things like >>> IDE code completion, leading to code that mishandles empty Optionals. >>> Typical Stack Overflow discourse runs something like this: >>> >>> Q: what do I do with this Optional thing >>> >>> A: just call get() >>> >>> Q: thanks, it works! >>> >>> Of course, it works until it doesn't. >>> >>> Examining the JDK's use of Optional.get(), I didn't see very many cases >>> that >>> called get() without first checking for the presence of a value. But I >>> did >>> see quite a number of cases like this: >>> >>> if (opt.isPresent()) { >>> doSomething(opt.get()); >>> } else { >>> doSomethingElse(); >>> } >>> >>> In many of these cases, the code could be refactored to use other >>> Optional >>> methods such as filter(), map(), or ifPresent(). >>> >>> In any case this reinforces the contention that use of get() leads to >>> poor >>> code. >>> >>> For this changeset, in just about all cases I've simply replaced the >>> call to >>> get() with a call to getWhenPresent(). In a couple cases I replaced the >>> stream calls >>> >>> .filter(Optional::isPresent).map(Optional::get) >>> >>> with >>> >>> .flatMap(Optional::stream) >>> >>> which I hope will become the new idiom for unwrapping a stream of >>> Optionals. >>> >>> While many cases could be cleaned up further, I didn't change them. The >>> reasons are that I didn't want to spend too much time putting code >>> cleanup >>> into the critical path of this changeset (I'd be happy to help later); >>> doing >>> so would create potential conflicts with code coming in from the Jigsaw >>> forest; and there are non-obvious places where converting from a >>> conditional >>> to one of the lambda-based methods could cause performance problems at >>> startup. >>> >>> There are also a few cases where simplification is prevented because it >>> would end up causing the resulting lambda expressions to throw checked >>> exceptions. :-( >>> >>> Webrevs here: >>> >>> >>> http://cr.openjdk.java.net/~smarks/reviews/8140281/webrev.0.langtools/ >>> >>> http://cr.openjdk.java.net/~smarks/reviews/8140281/webrev.0.jdk/ >>> >>> Thanks, >>> >>> s'marks >>> >> > -- Sent from my phone

4 4