August 2018 - core-libs-dev

Moderator Responsibilities
by mr rupplin 17 Aug '18

17 Aug '18

Hello. I have been contacted by someone who has stated that there are complaints that we ask the channel about debug questions. I have 12+ years in Software and a Masters Degree in Computer Science. There will be no more kid games. If you are asked, please answer fully and promptly. Debugging a long compile stack can be complicated. Also, if recurring questions become irksome make a JDK wiki on github. This is the least we can expect. That is all. Thank you for your understanding. Max R. (Sr. Software Fellow)

3 2

Arrays.asList returned List - Its modifying/write-through semantics
by Jaikiran Pai 17 Aug '18

17 Aug '18

Consider the following code: import java.util.Arrays; import java.util.List; public class ArraysAsListTest { public static void main(final String[] args) throws Exception { final List<String> someList = Arrays.asList(new String[] {"a"}); System.out.println("Removed? " + someList.remove("a")); } } It uses Arrays.asList to create a java.util.List and then calls a list.remove(...) on it. This currently runs intothe following exception: Exception in thread "main" java.lang.UnsupportedOperationException: remove at java.base/java.util.Iterator.remove(Iterator.java:102) at java.base/java.util.AbstractCollection.remove(AbstractCollection.java:299) at ArraysAsListTest.main(ArraysAsListTest.java:8) The javadoc of Arrays.asList[1] states the following: "Returns a fixed-size list backed by the specified array. (Changes to the returned list "write through" to the array.)..." and has no other mention of how it's supposed to behave with "write" operations. Given that the javadoc states that the returned list is "write through", would that mean a "add/removal" is allowed? Probably not, because it does say it's a fixed size list.So the size altering, write operations (like add(), remove()) aren't allowed, but that isn't clear from the javadoc. So should the javadoc be updated to clarify the semantics of what changes are "write through" and what changes are not supported? Furthermore, the UnsupportedOperationException isn't always thrown from such a returned list. Consider this minor modification to the above code: final List<String> someList = Arrays.asList(new String[] {"a"}); System.out.println("Removed? " + someList.remove("b")); I add "a" and remove "b". This now runs fine without exceptions and prints "Removed? false". Should the implementation just throw the UnsupportedOperationException irrespective of whether or not the element is contained insuch a returned list? If not, should that be made clear in the javadoc (maybe same for addoperations)? [1] https://docs.oracle.com/javase/10/docs/api/java/util/Arrays.html#asList(T..… -Jaikiran

4 6

Re: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix included)
by Adam Farley8 17 Aug '18

17 Aug '18

Hi Mandy, Hans, Tried out the below (after removing my previous fix, the volatile compare), and it appears to solve the problem just fine. If I generate a webrev and get it attached to the bug, would one of you mind approving the change? ----------...at the end of getBundleImpl in jdk8 ------------ keepAlive(loader); return bundle; } //To keep the argument ClassLoader alive. private static void keepAlive(ClassLoader loaderone){ //Do nothing. } ---------------------- Best Regards Adam Farley Hans Boehm <hboehm(a)google.com> wrote on 15/08/2018 06:44:08: > From: Hans Boehm <hboehm(a)google.com> > To: Mandy Chung <mandy.chung(a)oracle.com> > Cc: adam.farley(a)uk.ibm.com, core-libs-dev <core-libs- > dev(a)openjdk.java.net>, i18n-dev(a)openjdk.java.net > Date: 15/08/2018 06:44 > Subject: Re: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix included) > > FWIW, since there was agreement that empty static methods should > work in this context, that seems like the best option to me. > > On Tue, Aug 14, 2018 at 4:54 PM mandy chung <mandy.chung(a)oracle.com> wrote: > Thanks for the information. Not sure what's the best option we can do > in 8u. I think it's acceptable to have a fix that works in the > current context (like empty static method). > > Thoughts? > > Mandy > > On 8/14/18 4:22 PM, Hans Boehm wrote: > > I haven't looked at the details here, but comparing against a volatile > > is not in general a portable way to keep an object live. Like empty > > static methods, it may be fine in the current (OpenJDK) context. > > > > Volatile loads have roach motel semantics and can be advanced past other > > operations. The comparison can be done early, too, keeping only the > > condition code. There is no guarantee the reference will still be around > > when you expect it. > > > > I haven't come up with a great compiler-independent replacement for > > reachabilityFence. > > > > On Tue, Aug 14, 2018 at 8:25 AM mandy chung <mandy.chung(a)oracle.com > > <mailto:mandy.chung@oracle.com>> wrote: > > > > Hi Adam, > > > > Have you tried Peter's suggestion if an empty static method taking an > > Object parameter? Does it work for you? > > > > Your proposed approach seems fine and I would suggest to put the > > check in a static keepAlive method that will make it explicitly. > > > > Mandy > > > > On 8/10/18 8:42 AM, Adam Farley8 wrote: > > > Hi All, > > > > > > This bug could be fixed by comparing the Class Loader with a blank > > > static volatile Object (defined outside the method scope) at the > > > end of the getBundleImpl class. > > > > > > E.g. > > > > > > ----------------------------------------- > > > +1322 > > > /** > > > * volatile reference object to guard the ClassLoader object > > > * being garbage collected before getBundleImpl() method > > completes > > > * the caching and retrieving of requested Resourcebundle object > > > */ > > > private static volatile Object vo = new Object(); > > > > > > > > > +1400 > > > //Should never be true. Using the loader here prevents it being GC'd. > > > if (loader == vo) throw new Error("Unexpected error."); > > > ----------------------------------------- > > > > > > Will upload a webrev after debate. > > > > > > - Adam > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with > > number > > > 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, > > Hampshire PO6 3AU > > > > > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

2 4

RFR: 8209465: [TESTBUG] Fix jtreg test cases of jdk about file name too long in AUFS file system
by Yang Zhang 17 Aug '18

17 Aug '18

Hi, Could you please help review the fix to jtreg test cases in jdk? java/io/File/DeleteOnExitLong.java java/io/File/MaxPathLength.java The failure happens in Linux AUFS file system. The maximum file name length in AUFS is 242. JBS: https://bugs.openjdk.java.net/browse/JDK-8209465 Webrev: http://cr.openjdk.java.net/~yzhang/8209465/webrev.00/ Regards, Yang

1 0

Compile Error
by mr rupplin 17 Aug '18

17 Aug '18

Spot what's the issue here: Compiling 4 files for BUILD_JIGSAW_TOOLS Error occurred during initialization of VM java.lang.NullPointerException at jdk.internal.misc.VM.saveAndRemoveProperties(java.base/VM.java:176) at java.lang.System.initPhase1(java.base/System.java:802) >> make/Main.gmk:356: recipe for target 'exploded-image-optimize' failed

2 1

RFR(XXS) : 8209386 : [error-prone] StreamResourceLeak in jdk.internal.ed module
by Igor Ignatyev 16 Aug '18

16 Aug '18

http://cr.openjdk.java.net/~iignatyev//8209386/webrev.00/index.html > 4 lines changed: 1 ins; 0 del; 3 mod; Hi all, could you please review this small fix for the error detected in jdk.internal.ed by error-prone? webrev: http://cr.openjdk.java.net/~iignatyev//8209386/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8209386 Thanks, -- Igor

2 2

RFR(XXS) : 8209549 : remove VMPropsExt from TEST.ROOT
by Igor Ignatyev 16 Aug '18

16 Aug '18

http://cr.openjdk.java.net/~iignatyev//8209549/webrev.00/index.html > 2 lines changed: 0 ins; 0 del; 2 mod; Hi all, could you please review this tiny patch which removes unused (and actually non-existed) file from requires.extraPropDefns and simplifies paths in requires.extraPropDefns and requires.extraPropDefns.bootlibs? webrev: http://cr.openjdk.java.net/~iignatyev//8209549/webrev.00/index.html testing: jdk/tier1 Thanks, -- Igor

2 1

Removing the Barrier
by mr rupplin 15 Aug '18

15 Aug '18

Can you explain how to remove the requirement for comments in the OpenJDK build in the Java source files? It's really killing my schedule to have to reinsert comments by hand. Thanks. Max R. Software Developer

3 2

JDK 12 RFR of 5075463 : (enum) Serialized Form javadoc for java.lang.Enum is misleading
by joe darcy 15 Aug '18

15 Aug '18

Hello, Cleaning out an old bug, please review the CSR and fix for: JDK-5075463 : (enum) Serialized Form javadoc for java.lang.Enum is misleading http://cr.openjdk.java.net/~darcy/5075463.0/ CSR: https://bugs.openjdk.java.net/browse/JDK-8209524 The abstract class java.lang.Enum implements Serializable and is the superclass of all enum types. By default a serializable type is added to the serialized form page of the javadoc output. However, in the case of java.lang.Enum, including the type in the serialized form output is misleading since java.lang.Enum cannot be directly instantiated and enum types have special-cased handling in serialization. Adding a "@serial exclude" javadoc tag to the class-level javadoc of java.lang.Enum prevent an entry the the type in the serialized form page. Patch below. Thanks, -Joe --- old/src/java.base/share/classes/java/lang/Enum.java 2018-08-14 20:48:04.202000000 -0700 +++ new/src/java.base/share/classes/java/lang/Enum.java 2018-08-14 20:48:04.058000000 -0700 @@ -45,6 +45,7 @@ * java.util.EnumMap map} implementations are available. * * @param <E> The enum type subclass + * @serial exclude * @author Josh Bloch * @author Neal Gafter * @see Class#getEnumConstants()

3 3

Core Type Compilation Issues
by mr rupplin 15 Aug '18

15 Aug '18

Three problems that I run into when running the 'make jdk' after minor work on the System.java class for JNI and custom JDK: java/lang/memory/GroupListener.java:111: warning: [rawtypes] found raw type: Class Class basetype = null; -- -- java/lang/memory/GroupListener.java:7: error: package java.rmi does not exist import java.rmi.Remote; -- -- java/lang/memory/GroupListener.java:13: warning: [exports] class Group in module java.base is not accessible to clients that require this module public final ArrayList<Group> groups = new ArrayList<Group>(); == == Can we get explanations for each of these? Also the solutions or workarounds. OkQ! Thanks, Max R. Software Lead

4 4