February 2018 - core-libs-dev

[11] RFR: JDK-8198385: Remove property sun.locale.formatasdefault
by naoto.sato＠oracle.com 22 Feb '18

22 Feb '18

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8198385 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8198385/webrev.00/ The property was introduced in JDK7 for the backward compatibility, which at this point is no longer needed. Corresponding CSR is already approved. Naoto

4 3

Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.
by Xueming Shen 22 Feb '18

22 Feb '18

This draft JEP contains a proposal to use UTF-8 as the default charset for the JVM, so that APIs that depend on the default charset behave consistently cross all platforms. For more details, please see: https://bugs.openjdk.java.net/browse/JDK-8187041 Sherman

8 15

[11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit
by mandy chung 22 Feb '18

22 Feb '18

Runtime.runFinalizersOnExit has been deprecated since 1.2 (1998) and deprecated for removal in JDK 9. We analyzed the maven central artifacts few years ago that show very few uses of it. I also survey a recent version of most of the maven artifacts that references runFinalizatsOnExit no longer references it. I propose to remove Runtime.runFinalizersOnExit and System.runFinalizersOnExit methods in JDK 11. CSR: https://bugs.openjdk.java.net/browse/JDK-8198250 Webrev: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198249/webrev.00/ Thanks Mandy [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-January/031041.ht…

6 21

RFR: 8198523: Refactor BootstrapMethodInvoker to further avoid runtime type checks
by Claes Redestad 22 Feb '18

22 Feb '18

Hi, BootstrapMethodInvoker can be improved a bit further by providing static information about the type argument, and additionally teaching it about StringConcatFactory BSM: Patch: http://cr.openjdk.java.net/~redestad/8198523/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8198523 This slightly improves startup on string concat tests. Thanks! /Claes

2 1

RFR 8189330 Cleanup FileDescriptor implementation
by Roger Riggs 21 Feb '18

21 Feb '18

Please review a cleanup and refactoring of FileDescriptor.java. The Unix and Windows versions are merged to ease maintenance remove replicated code The FileCleanable class is extracted and SocketCleanable is updated. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-fd-cleanup-8189330/ Issue: https://bugs.openjdk.java.net/browse/JDK-8189330 Thanks, Roger

2 1

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux
by yumin qi 21 Feb '18

21 Feb '18

Hi, I have update the webrev: http://cr.openjdk.java.net/~minqi/8194154/webrev1/ In this version, as suggested by Alan(thanks!), property of "user.dir" is cached and behave like it is 'read only'. The change made to *inux as well as windows. Since property of "user.dir" is cached, any changes via property setting for it has no effect. Thanks Yumin On Wed, Feb 7, 2018 at 10:54 PM, Alan Bateman <Alan.Bateman(a)oracle.com> wrote: > On 07/02/2018 20:10, yumin qi wrote: > >> Hi, >> >> Please review the fix (extra small) for: >> bug 8194154: https://bugs.openjdk.java.net/browse/JDK-8194154 >> webrev: http://cr.openjdk.java.net/~minqi/8194154/ >> >> Summary: canonicalize will check and fold double (or more) slashes, but >> in function collapsible(char*) and splitNames(char*, char**), it failed to >> process strings like "//". This results in the former does not give a >> correct number of substrings and the later does not give a correct array >> of >> substrings. The fix add a check if the character is '/' after a '/'. >> >> The JDK has never supported setting user.dir in this way (it breaks > several things). There is a thread discussing this on core-libs-dev so best > to bring it to that mailing list to discuss again. > > -Alan >

4 22

RFR JDK-8198526
by Liam Miller-Cushon 21 Feb '18

21 Feb '18

Hello, Please review this fix to the handling of static nested classes in getAnnotatedOwnerType. webrev: http://cr.openjdk.java.net/~cushon/8198526/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8198526

1 0

RFR Passing 'null' value to lookup param of ConstantBootstraps.invoke does not throw NullPointerException
by Paul Sandoz 21 Feb '18

21 Feb '18

Hi, Correction to the specification of ConstantBootstraps.invoke [1], the lookup parameter is not used: diff -r b75c9e2e3b1f src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java --- a/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java Tue Feb 20 21:47:54 2018 +0100 +++ b/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java Tue Feb 20 14:38:56 2018 -0800 @@ -209,8 +209,7 @@ * Returns the result of invoking a method handle with the provided * arguments. * - * @param lookup the lookup context describing the class performing the - * operation (normally stacked by the JVM) + * @param lookup unused * @param name unused * @param type the type of the value to be returned, which must be * compatible with the return type of the method handle CSR is here: https://bugs.openjdk.java.net/browse/JDK-8198469 Paul. [1] /** * Returns the result of invoking a method handle with the provided * arguments. * * @param lookup unused * @param name unused * @param type the type of the value to be returned, which must be * compatible with the return type of the method handle * @param handle the method handle to be invoked * @param args the arguments to pass to the method handle, as if with * {@link MethodHandle#invokeWithArguments}. Each argument may be * {@code null}. * @return the result of invoking the method handle * @throws WrongMethodTypeException if the handle's return type cannot be * adjusted to the desired type * @throws ClassCastException if an argument cannot be converted by * reference casting * @throws Throwable anything thrown by the method handle invocation */ public static Object invoke(MethodHandles.Lookup lookup, String name, Class<?> type, MethodHandle handle, Object... args) throws Throwable {

2 1

8196830: publicLookup().findVirtual should not return method handle to AccessibleObject.setAccessible
by Alan Bateman 20 Feb '18

20 Feb '18

AccessibleObject's setAccessible(boolean) is currently not caller sensitive but the overrides in Method/Field/Constructor are. This awkwardness stems from its constructor being protected and the method not being final. It is thus possible to extend the class outside of the java.lang.reflect package and override this method (at least one popular library does this). Ideally the constructor should have been package private and/or the method be final but it's not possible to change this after 20 years. The consequence of the method in the base class not being caller sensitive is that it's possible to use a minimally trusted lookup to get a method handle to the method. Paul, Mandy and I chatted about this one recently. We prototyped changes to the MH implementation to special case this method and treat it "as if" it is caller sensitive. This maximizes compatibility but has the downside that it makes it harder to audit and somewhat fragile. In the end, we concluded it would be simpler to add the @CS annotation to this method so that it is treated consistently. The downside of this is that custom AccessibleObject implementations need to override setAccessible if they want to be invoked using method handles obtained from a minimally trusted lookup. The proposed changes are simple. The removal of "checkMemberAccess" from canBeCalledVirtual is just a clean-up because this method is no longer needs special casing (it was degraded for Java SE 10 as envisaged in JEP 176). It's not the goal here to improve the performance of canBeCalledVirtual but there may be opportunities to look at that with a separate issue: http://cr.openjdk.java.net/~alanb/8196830/webrev/ -Alan

3 2

[11] RFR: 8198418: Invoke LambdaMetafactory::metafactory exactly from the BootstrapMethodInvoker
by Claes Redestad 20 Feb '18

20 Feb '18

Hi, a small regression to lambda bootstrapping came in with the recent condy merge, and it took me a while to figure out why. Before condy, the first three parameters of calls from the BSM invoker to the six parameter LambdaMetafactory::metafactory were statically known, so only the fourth through sixth param were dynamically bound to enforce runtime type checks (MH.invoke -> MH.checkGenericInvoker -> MH.asType(MT) -> MHI.makePairwiseConvertByEditor -> generates a slew of filterArguments, rebinds, casting MHs etc). With condy, the third parameter is now an Object (in reality either a Class or a MethodType), thus not statically known. This means the MethodType sent to checkGenericInvoker will have to add a cast for this param too, thus in makePairwiseConvertByEditor we see an additional rebind, some additional time spent spinning classes etc. Effectively increasing the cost of first lambda initialization by a small amount (a couple of ms). Here came the realization that much of the static overhead of the lambda bootstrapping could be avoided altogether since we can determine and cast arguments statically for the special-but-common case of LambdaMetafactory::metafactory. By using exact type information, and even bootstrapMethod.invokeExact, no dynamic runtime checking is needed, so the time spent in makePairwiseConvertByEditor is avoided entirely. This might be a hack, but a hack that removes a large chunk of the code executed (~75% less bytecode) for the initial lambda bootstrap. Startup tests exercising lambdas show a 10-15ms improvement - the static overhead of using lambdas is now just a few milliseconds in total. Webrev: http://cr.openjdk.java.net/~redestad/8198418/jdk.00/ RFE: https://bugs.openjdk.java.net/browse/JDK-8198418 The patch includes a test for an experimental new metafactory method that exists only in the amber condy-folding branch. I can easily break it out and push that directly to amber once this patch syncs up there, but have tested that keeping it in here does no harm. Thanks! /Claes

5 9