From vicente.romero at oracle.com Thu Feb 6 05:26:14 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 06 Feb 2020 05:26:14 +0000 Subject: hg: amber/amber: the compiler should not enforce a modifier on subclasses of non-sealed classes Message-ID: <202002060526.0165QE0R018300@aojmv0008.oracle.com> Changeset: 3d518ea9b6c8 Author: vromero Date: 2020-02-06 00:24 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/3d518ea9b6c8 the compiler should not enforce a modifier on subclasses of non-sealed classes ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java ! test/langtools/tools/javac/sealed/SealedDiffConfigurationsTest.java From maurizio.cimadamore at oracle.com Thu Feb 6 05:31:07 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 06 Feb 2020 05:31:07 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002060531.0165V7Gc022096@aojmv0008.oracle.com> Changeset: 66a3d3226070 Author: mcimadamore Date: 2020-02-06 05:30 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/66a3d3226070 Automatic merge with sealed-types ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java ! test/langtools/tools/javac/sealed/SealedDiffConfigurationsTest.java From jan.lahoda at oracle.com Thu Feb 6 20:18:52 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 6 Feb 2020 21:18:52 +0100 Subject: Pattern Matching for instanceof (Preview 2) Message-ID: <8d30d504-dd25-de1f-a54d-1a80fe1f6c5d@oracle.com> Hi, Thanks to Gavin, Brian and Alex, there is a new draft JEP for Pattern Matching for instanceof (Preview 2): https://bugs.openjdk.java.net/browse/JDK-8235186 Any feedback on the JEP is more than welcome! Thanks, Jan From forax at univ-mlv.fr Thu Feb 6 22:18:55 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 6 Feb 2020 23:18:55 +0100 (CET) Subject: Changing the bootstrap protocol of ObjectMethods Message-ID: <677786244.589323.1581027535142.JavaMail.zimbra@u-pem.fr> We discuss sometime ago about changing the bootstrap protocol for the indy call inside the methods equals()/hashCode() and toString() of a record, seeing Chris (Hegarty) Monday at the OCW, remind me that i had said to Brian that i will write a prototype. Here is my take on it. Currently the bootstrap method receives as argument - the record class - a string (the record component names for toString) - an array of accessor This changes - separate the API for the record used by javac from the implementation of equals/hashCode and toString allowing other JVM languages to reuse the implementation even for classes that are non record - for that a new class RecordLikeMirror is introduced as an abstraction on anything that defines components with a name and a type. - 3 new public API points are created, createEquals/createHashCode/createToString This is basically what Maurizio has suggested. - so now the method "bootstrap" can be specialized only for records and use reflection to extract the record components instead passing them as bootstrap arguments moreover, the instance of RecordLikeMirror can be created once and stored in the constant pool and reused for each call of boostrap (using condy) - for that a new API point recordLikeMirrorConstant have been introduce and - a new variant of "bootstrap" now only takes a RecordLikeMirror has parameter. - the old variant of "bootstrap" is marked deprecated but because the compiler is not changed, it has to be kept around. The patch tries to minimize the objects creation while not trusting neither the caller of RecordLikeMirror.of() nor the fact that someone can create a record classfile with a malformed attribute that can still be decoded by the reflection thuis having either a record component name or accessor null. This patch doesn't - change javac to emit the right indy + condy - change the code of toString to make it faster by calling the StringConcatFactory (i will do that later) - have the right level of documentation it should. jtreg test tier1 is okay. regards, R?mi diff -r 1c4286ec9e45 src/java.base/share/classes/java/lang/runtime/ObjectMethods.java --- a/src/java.base/share/classes/java/lang/runtime/ObjectMethods.java Wed Feb 05 10:14:40 2020 +0100 +++ b/src/java.base/share/classes/java/lang/runtime/ObjectMethods.java Thu Feb 06 22:51:46 2020 +0100 @@ -29,8 +29,9 @@ import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodHandles; import java.lang.invoke.MethodType; import java.lang.invoke.TypeDescriptor; +import java.lang.invoke.WrongMethodTypeException; import java.security.AccessController; import java.security.PrivilegedAction; import java.util.Arrays; import java.util.HashMap; @@ -298,78 +299,256 @@ return formatter; } /** + * A class that represent a record-like class, with the component names and accessor methods. + */ + public static final class RecordLikeMirror { + private final Class type; + private final List names; + private final List accessors; + + private RecordLikeMirror(Class type, List names, List accessors) { + this.type = type; + this.names = names; + this.accessors = accessors; + } + + /** + * Create a record-like mirror from a class a list of names and a list of + * accessors. + * + * @param type the class to mirror. + * @param names the names of the components. + * @param accessors the accessors of the components. + * @return a new record-like mirror. + */ + public static RecordLikeMirror of(Class type, List names, List accessors) { + Objects.requireNonNull(type); + List nameList = List.copyOf(names); + List accessorList = List.copyOf(accessors); + if (nameList.size() != accessorList.size()) { + throw new IllegalArgumentException("names.size() != accessors.size()"); + } + for(MethodHandle accessor: accessorList) { + MethodType methodType = accessor.type(); + if (methodType.returnType() == void.class || methodType.parameterCount() != 1 || methodType.parameterType(0) != type) { + throw new WrongMethodTypeException(methodType.toString()); + } + } + return new RecordLikeMirror(type, nameList, accessorList); + } + + /** + * Create a record-like mirror from a record. + * + * @param lookup the lookup used to create the accessor from the record + * components. + * @param recordClass the record class to mirror. + * @return a new record-like mirror. + * @throws IllegalAccessException if the lookup can not access to the accessors. + */ + public static RecordLikeMirror fromRecord(MethodHandles.Lookup lookup, Class recordClass) throws IllegalAccessException { + Objects.requireNonNull(lookup); + @SuppressWarnings("preview") + var recordComponents = recordClass.getRecordComponents(); // implicit nullcheck + if (recordComponents == null) { + throw new IllegalArgumentException("the class taken as argument is not a record"); + } + int length = recordComponents.length; + String[] names = new String[length]; + MethodHandle[] accessors = new MethodHandle[length]; + for(int i = 0; i < length; i++) { + var recordComponent = recordComponents[i]; + names[i] = recordComponent.getName(); + accessors[i] = lookup.unreflect(recordComponent.getAccessor()); + } + return new RecordLikeMirror(recordClass, List.of(names), List.of(accessors)); + } + } + + /** + * Creates a method handle able to perform an equals from a record-like mirror + * with the semantics defined in {@link java.lang.Record#equals(Object)}. + * + * @param mirror a record-like mirror defining the components. + * @return a method handle able to perform an equals from a record-like mirror. + */ + public static MethodHandle createEquals(RecordLikeMirror mirror) { + return makeEquals(mirror.type, mirror.accessors); + } + + /** + * Creates a method handle able to perform a hashCode from a record-like mirror + * with the semantics defined in {@link java.lang.Record#hashCode()}. + * + * @param mirror a record-like mirror defining the components. + * @return a method handle able to perform an equals from a record-like mirror. + */ + public static MethodHandle createHashCode(RecordLikeMirror mirror) { + return makeHashCode(mirror.type, mirror.accessors); + } + + /** + * Creates a method handle able to perform a toString from a record-like mirror + * with the semantics defined in {@link java.lang.Record#toString()}. + * + * @param mirror a record-like mirror defining the components. + * @return a method handle able to perform an equals from a record-like mirror. + */ + public static MethodHandle createToString(RecordLikeMirror mirror) { + return makeToString(mirror.type, mirror.accessors, mirror.names); + } + + /** + * A bootstrap method for a constant dynamic that creates a record-like mirror + * from a record class. + * + * @param lookup the lookup used to retrieve the accessors. + * @param name any name. + * @param type the type of the constant ({@code RecordLikeMirror}). + * @param recordClass the record class. + * @return a record-like mirror created from the recordClass. + * @throws IllegalArgumentException if the type is not {@code RecordLikeMirror}. + * @throws IllegalAccessError if the lookup can not access to the + * accessors. + */ + public static RecordLikeMirror recordLikeMirrorConstant(MethodHandles.Lookup lookup, + String name, + Class type, + Class recordClass) { + Objects.requireNonNull(lookup); + Objects.requireNonNull(name); + Objects.requireNonNull(type); + Objects.requireNonNull(recordClass); + if (type != RecordLikeMirror.class) { + throw new IllegalArgumentException("type should be equals to RecordLikeMirror"); + } + try { + return RecordLikeMirror.fromRecord(lookup, recordClass); + } catch (IllegalAccessException e) { + throw (IllegalAccessError)new IllegalAccessError().initCause(e); + } + } + + /** * Bootstrap method to generate the {@link Object#equals(Object)}, - * {@link Object#hashCode()}, and {@link Object#toString()} methods, based - * on a description of the component names and accessor methods, for either + * {@link Object#hashCode()}, and {@link Object#toString()} methods, from a + * record-like mirror, for either {@code invokedynamic} call sites or dynamic + * constant pool entries. + * + * For more detail on the semantics of the generated methods see the + * specification of {@link java.lang.Record#equals(Object)}, + * {@link java.lang.Record#hashCode()} and {@link java.lang.Record#toString()}. + * + * @param lookup Every bootstrap method is expected to have a {@code lookup} + * which usually represents a lookup context with the + * accessibility privileges of the caller. This is because + * {@code invokedynamic} call sites always provide a + * {@code lookup} to the corresponding bootstrap method, but + * this method just ignores the {@code lookup} parameter + * @param methodName the name of the method to generate, which must be one of + * {@code "equals"}, {@code "hashCode"}, or {@code "toString"} + * @param type a {@link MethodType} corresponding the descriptor type for + * the method, which must correspond to the descriptor for the + * corresponding {@link Object} method, if linking an + * {@code invokedynamic} call site, or the constant + * {@code MethodHandle.class}, if linking a dynamic constant + * @param mirror a description of a record-like class + * @return a call site if invoked by indy, or a method handle if invoked by a + * condy + * @throws IllegalArgumentException if the bootstrap arguments are invalid or + * inconsistent + */ + public static Object bootstrap(MethodHandles.Lookup lookup, + String methodName, + TypeDescriptor type, + RecordLikeMirror mirror) { + Objects.requireNonNull(lookup); + Objects.requireNonNull(methodName); + Objects.requireNonNull(type); + Objects.requireNonNull(mirror); + MethodType methodType; + if (type instanceof MethodType) { + methodType = (MethodType) type; + } else { + if (MethodHandle.class != type) { + throw new IllegalArgumentException(type.toString()); + } + methodType = null; + } + MethodHandle handle = switch (methodName) { + case "equals" -> { + if (methodType != null && + (methodType.returnType() != boolean.class || methodType.parameterCount() != 2 || + methodType.parameterType(0) != mirror.type || methodType.parameterType(1) != Object.class)) { + throw new IllegalArgumentException("Bad method type: " + methodType); + } + yield createEquals(mirror); + } + case "hashCode" -> { + if (methodType != null && + (methodType.returnType() != int.class || methodType.parameterCount() != 1 || + methodType.parameterType(0) != mirror.type)) { + throw new IllegalArgumentException("Bad method type: " + methodType); + } + yield createHashCode(mirror); + } + case "toString" -> { + if (methodType != null && + (methodType.returnType() != String.class || methodType.parameterCount() != 1 || + methodType.parameterType(0) != mirror.type)) { + throw new IllegalArgumentException("Bad method type: " + methodType); + } + yield createToString(mirror); + } + default -> throw new IllegalArgumentException(methodName); + }; + return methodType != null ? new ConstantCallSite(handle) : handle; + } + + /** + * Bootstrap method to generate the {@link Object#equals(Object)}, + * {@link Object#hashCode()}, and {@link Object#toString()} methods, based on a + * description of the component names and accessor methods, for either * {@code invokedynamic} call sites or dynamic constant pool entries. * - * For more detail on the semantics of the generated methods see the specification - * of {@link java.lang.Record#equals(Object)}, {@link java.lang.Record#hashCode()} and - * {@link java.lang.Record#toString()}. - * + * For more detail on the semantics of the generated methods see the + * specification of {@link java.lang.Record#equals(Object)}, + * {@link java.lang.Record#hashCode()} and {@link java.lang.Record#toString()}. * - * @param lookup Every bootstrap method is expected to have a {@code lookup} - * which usually represents a lookup context with the - * accessibility privileges of the caller. This is because - * {@code invokedynamic} call sites always provide a {@code lookup} - * to the corresponding bootstrap method, but this method just - * ignores the {@code lookup} parameter - * @param methodName the name of the method to generate, which must be one of - * {@code "equals"}, {@code "hashCode"}, or {@code "toString"} - * @param type a {@link MethodType} corresponding the descriptor type - * for the method, which must correspond to the descriptor - * for the corresponding {@link Object} method, if linking - * an {@code invokedynamic} call site, or the - * constant {@code MethodHandle.class}, if linking a - * dynamic constant - * @param recordClass the record class hosting the record components - * @param names the list of component names, joined into a string - * separated by ";", or the empty string if there are no - * components. Maybe be null, if the {@code methodName} - * is {@code "equals"} or {@code "hashCode"}. - * @param getters method handles for the accessor methods for the components - * @return a call site if invoked by indy, or a method handle - * if invoked by a condy - * @throws IllegalArgumentException if the bootstrap arguments are invalid - * or inconsistent - * @throws Throwable if any exception is thrown during call site construction + * @param lookup Every bootstrap method is expected to have a + * {@code lookup} which usually represents a lookup context + * with the accessibility privileges of the caller. This is + * because {@code invokedynamic} call sites always provide a + * {@code lookup} to the corresponding bootstrap method, but + * this method just ignores the {@code lookup} parameter + * @param methodName the name of the method to generate, which must be one of + * {@code "equals"}, {@code "hashCode"}, or + * {@code "toString"} + * @param type a {@link MethodType} corresponding the descriptor type for + * the method, which must correspond to the descriptor for + * the corresponding {@link Object} method, if linking an + * {@code invokedynamic} call site, or the constant + * {@code MethodHandle.class}, if linking a dynamic constant + * @param recordClass the record class hosting the record components + * @param names unused. + * @param getters unused + * @return a call site if invoked by indy, or a method handle if invoked by a + * condy + * @throws IllegalArgumentException if the bootstrap arguments are invalid or + * inconsistent + * @throws Throwable if any exception is thrown during call site + * construction + * + * @deprecated this method is deprecated and replaced by + * {@link #bootstrap(java.lang.invoke.MethodHandles.Lookup, String, TypeDescriptor, RecordLikeMirror)} */ + @Deprecated(forRemoval = true) public static Object bootstrap(MethodHandles.Lookup lookup, String methodName, TypeDescriptor type, - Class recordClass, - String names, - MethodHandle... getters) throws Throwable { - MethodType methodType; - if (type instanceof MethodType) - methodType = (MethodType) type; - else { - methodType = null; - if (!MethodHandle.class.equals(type)) - throw new IllegalArgumentException(type.toString()); - } - List getterList = List.of(getters); - MethodHandle handle; - switch (methodName) { - case "equals": - if (methodType != null && !methodType.equals(MethodType.methodType(boolean.class, recordClass, Object.class))) - throw new IllegalArgumentException("Bad method type: " + methodType); - handle = makeEquals(recordClass, getterList); - return methodType != null ? new ConstantCallSite(handle) : handle; - case "hashCode": - if (methodType != null && !methodType.equals(MethodType.methodType(int.class, recordClass))) - throw new IllegalArgumentException("Bad method type: " + methodType); - handle = makeHashCode(recordClass, getterList); - return methodType != null ? new ConstantCallSite(handle) : handle; - case "toString": - if (methodType != null && !methodType.equals(MethodType.methodType(String.class, recordClass))) - throw new IllegalArgumentException("Bad method type: " + methodType); - List nameList = "".equals(names) ? List.of() : List.of(names.split(";")); - if (nameList.size() != getterList.size()) - throw new IllegalArgumentException("Name list and accessor list do not match"); - handle = makeToString(recordClass, getterList, nameList); - return methodType != null ? new ConstantCallSite(handle) : handle; - default: - throw new IllegalArgumentException(methodName); - } + Class recordClass, + String names, + MethodHandle... getters) throws Throwable { + RecordLikeMirror mirror = recordLikeMirrorConstant(lookup, "recordLikeMirrorConstant", RecordLikeMirror.class, recordClass); + return bootstrap(lookup, methodName, type, mirror); } } From brian.goetz at oracle.com Thu Feb 6 23:42:06 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 6 Feb 2020 18:42:06 -0500 Subject: Changing the bootstrap protocol of ObjectMethods In-Reply-To: <677786244.589323.1581027535142.JavaMail.zimbra@u-pem.fr> References: <677786244.589323.1581027535142.JavaMail.zimbra@u-pem.fr> Message-ID: <5702c5e7-266f-a7f8-f43e-1487ddcac7ae@oracle.com> At the time, I recall asking "But, what is the point?? What problem are you actually trying to solve?"? I am still hazy on this.? There's nothing _wrong_ with the design you're suggesting, but I am having a hard time seeing how it is better, or that there's something wrong with what we've got that needs changing. > This changes > - separate the API for the record used by javac from the implementation of equals/hashCode and toString allowing other JVM languages to reuse the implementation even for classes that are non record I still don't see the problem.? For a non-record class, there is still, abstractly, a set of "state variables"; they can each be accessed with a method handle (field accessor, getter method, etc), and they each have a name that will be used in the toString.? How is the current bootstrap unsuitable for non-record classes?? With the current bootstrap, it is equally useful to records and non-records alike, with no bias towards records.? Surely that is better than having two separate bootstraps, one for records and one for everyone else? > - for that a new class RecordLikeMirror is introduced as an abstraction on anything that defines components with a name and a type. OK, another new abstraction.? What value does it serve? > - 3 new public API points are created, createEquals/createHashCode/createToString This is a valid direction, but again I think it's unnecessary.? We have the the name/type channel in indy whether we use it or not; having three entry points which have to be separately specified and tested doesn't seem simpler than one.? Further, the current mechanism is extensible to other methods that can be generated from the same metadata (such as, perhaps, compareTo), whereas three separate bootstraps would not be.? Yes, the equals/hashCode bootstrap could take one fewer parameter than toString, but even this is not a win -- because then the BMT entry can't be shared. > - so now the method "bootstrap" can be specialized only for records and use reflection to extract the record components instead passing them as bootstrap arguments That seems like a negative, not a positive? Can we back up?? What problem are we solving? From reinier at zwitserloot.com Fri Feb 7 00:53:06 2020 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Fri, 7 Feb 2020 01:53:06 +0100 Subject: if (!(x instanceof String y)) syntax - better syntax? Message-ID: I'm not sure if now is an appropriate time (or how one should bring up something like this), but I noticed a bit of friction in regards to this particular style of code: if (!(x instanceof String y)) return; // carry on, with y available of type Strin. This is a stated goal of why the instanceof patternmatch feature's rules on where the declared 'y' variable is available ('binding variables') works as it does. That's great; we've debated it at length before. However, the syntax of this particular construct is a bit unfortunate; I see newbies write if (!x instanceof String) or if (x !instanceof String) relatively often; the second one gives a straight up syntax error, but the first is a bit more convoluted ('x is not boolean'). Even disregarding the anecdotal evidence that those new to java fairly consistently misjudge how to do an if-not-an-instance-of check, the correct syntax is rather unwieldy. Maybe it's comfortable to any LISP fans in the audience, but it's a few too many parentheses for my tastes. Given that a new language feature is being introduced which is catering rather explicitly to this particular 'if not an instance of, then' style, is there room to add a small, entirely backwards compatible syntax feature [1]? Something like: if (x !instanceof String y) return; Any form of the *ReferenceType* AST node accepts this form, so also the older form: boolean z = x !instanceof String; // valid. equivalent to z = !(x instanceof String). I'm not sure if it would be appropriate to debate here if this should be tagged onto the aims for e.g. JDK15's expanded instanceof support ( Preview-2 [2] ), or if this should be its own proposal, or if this is even the appropriate channel for such ideas. [1] I'm jumping the gun a little bit on how backwards compatible this is. I _think_ so, as it's a straight up syntax error right now, but before I write a PoC patch to javac, I thought I'd check if the idea itself is sound before delving that deep. [2] https://bugs.openjdk.java.net/browse/JDK-8235186 --Reinier Zwitserloot From brian.goetz at oracle.com Fri Feb 7 16:02:55 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 7 Feb 2020 11:02:55 -0500 Subject: if (!(x instanceof String y)) syntax - better syntax? In-Reply-To: References: Message-ID: <8daab2e0-3c37-4c36-6c1e-29d6101b38d0@oracle.com> > I'm not sure if now is an appropriate time (or how one should bring up > something like this) Heh, it's never a good time, and there's never a good way, but you came about as close as is possible! > I noticed a bit of friction in regards to this > particular style of code: > > if (!(x instanceof String y)) return; > // carry on, with y available of type Strin. Indeed, it is definitely an "idiom" that may take a little getting used to. > Given that a new language feature is being introduced which is catering > rather explicitly to this particular 'if not an instance of, then' style, > is there room to add a small, entirely backwards compatible syntax feature > [1]? > > Something like: > > if (x !instanceof String y) return; Not a terrible idea!? Something worth considering. > I'm not sure if it would be appropriate to debate here if this should be > tagged onto the aims for e.g. JDK15's expanded instanceof support ( > Preview-2 [2] ), or if this should be its own proposal, or if this is even > the appropriate channel for such ideas. My inclination is not to load down pattern matching with this, and give us time to gather evidence about how much of a friction point it is. > [1] I'm jumping the gun a little bit on how backwards compatible this is. I > _think_ so, as it's a straight up syntax error right now, but before I > write a PoC patch to javac, I thought I'd check if the idea itself is sound > before delving that deep. The claim that it is a simple rewriting and introduces no ambiguities is credible; would have to be verified. From forax at univ-mlv.fr Fri Feb 7 16:57:32 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 7 Feb 2020 17:57:32 +0100 (CET) Subject: Changing the bootstrap protocol of ObjectMethods In-Reply-To: <5702c5e7-266f-a7f8-f43e-1487ddcac7ae@oracle.com> References: <677786244.589323.1581027535142.JavaMail.zimbra@u-pem.fr> <5702c5e7-266f-a7f8-f43e-1487ddcac7ae@oracle.com> Message-ID: <619573637.953962.1581094652587.JavaMail.zimbra@u-pem.fr> > De: "Brian Goetz" > ?: "Remi Forax" , "amber-dev" > Envoy?: Vendredi 7 F?vrier 2020 00:42:06 > Objet: Re: Changing the bootstrap protocol of ObjectMethods > At the time, I recall asking "But, what is the point? What problem are you > actually trying to solve?" I am still hazy on this. There's nothing _wrong_ > with the design you're suggesting, but I am having a hard time seeing how it is > better, or that there's something wrong with what we've got that needs > changing. >> This changes >> - separate the API for the record used by javac from the implementation of >> equals/hashCode and toString allowing other JVM languages to reuse the >> implementation even for classes that are non record > I still don't see the problem. For a non-record class, there is still, > abstractly, a set of "state variables"; they can each be accessed with a method > handle (field accessor, getter method, etc), and they each have a name that > will be used in the toString. How is the current bootstrap unsuitable for > non-record classes? With the current bootstrap, it is equally useful to records > and non-records alike, with no bias towards records. Surely that is better than > having two separate bootstraps, one for records and one for everyone else? >> - for that a new class RecordLikeMirror is introduced as an abstraction on >> anything that defines components with a name and a type. > OK, another new abstraction. What value does it serve? >> - 3 new public API points are created, >> createEquals/createHashCode/createToString > This is a valid direction, but again I think it's unnecessary. We have the the > name/type channel in indy whether we use it or not; having three entry points > which have to be separately specified and tested doesn't seem simpler than one. > Further, the current mechanism is extensible to other methods that can be > generated from the same metadata (such as, perhaps, compareTo), whereas three > separate bootstraps would not be. Yes, the equals/hashCode bootstrap could take > one fewer parameter than toString, but even this is not a win -- because then > the BMT entry can't be shared. >> - so now the method "bootstrap" can be specialized only for records and use >> reflection to extract the record components instead passing them as bootstrap >> arguments > That seems like a negative, not a positive? > Can we back up? What problem are we solving? There are mostly three problems with the actual protocol: - information duplication, the actual classfile contains twice the same abstract description of what a record is, in the Record attribute and in the list of bootstrap arguments the method ''bootstrap", unifying them is better in the long term because we don't have to deal with de-synchronization of them. - information hiding, the current protocol shows the array of method handles in plain sight, in the signature of the BSM, so we can not to change the implementation without asking for recompiling all record classfiles, which is bad in the long term. - the validation of those arguments is done once per indy callsite instead of once per class using a condy. The class RecordLikeMirror has several purposes : - it hides from where the info comes from, the Record attribute or some user provided data (from another language runtime) - its factory methods check that the arguments are valid - it's used has the return type of condy so the validation is done once per class. I agree with you that the 3 API entry-points are not necessary because one can call the method "bootstrap" instead. So i've remove them from the patch (below). cheers, R?mi --- diff -r 1c4286ec9e45 src/java.base/share/classes/java/lang/runtime/ObjectMethods.java --- a/src/java.base/share/classes/java/lang/runtime/ObjectMethods.java Wed Feb 05 10:14:40 2020 +0100 +++ b/src/java.base/share/classes/java/lang/runtime/ObjectMethods.java Fri Feb 07 16:49:47 2020 +0100 @@ -29,8 +29,9 @@ import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodHandles; import java.lang.invoke.MethodType; import java.lang.invoke.TypeDescriptor; +import java.lang.invoke.WrongMethodTypeException; import java.security.AccessController; import java.security.PrivilegedAction; import java.util.Arrays; import java.util.HashMap; @@ -298,78 +299,223 @@ return formatter; } /** + * A class that represent a record-like class, with the component names and accessor methods. + */ + public static final class RecordLikeMirror { + private final Class type; + private final List names; + private final List accessors; + + private RecordLikeMirror(Class type, List names, List accessors) { + this.type = type; + this.names = names; + this.accessors = accessors; + } + + /** + * Create a record-like mirror from a class a list of names and a list of + * accessors. + * + * @param type the class to mirror. + * @param names the names of the components. + * @param accessors the accessors of the components. + * @return a new record-like mirror. + */ + public static RecordLikeMirror of(Class type, List names, List accessors) { + Objects.requireNonNull(type); + List nameList = List.copyOf(names); + List accessorList = List.copyOf(accessors); + if (nameList.size() != accessorList.size()) { + throw new IllegalArgumentException("names.size() != accessors.size()"); + } + for(MethodHandle accessor: accessorList) { + MethodType methodType = accessor.type(); + if (methodType.returnType() == void.class || methodType.parameterCount() != 1 || methodType.parameterType(0) != type) { + throw new WrongMethodTypeException(methodType.toString()); + } + } + return new RecordLikeMirror(type, nameList, accessorList); + } + + /** + * Create a record-like mirror from a record. + * + * @param lookup the lookup used to create the accessor from the record + * components. + * @param recordClass the record class to mirror. + * @return a new record-like mirror. + * @throws IllegalAccessException if the lookup can not access to the accessors. + */ + public static RecordLikeMirror fromRecord(MethodHandles.Lookup lookup, Class recordClass) throws IllegalAccessException { + Objects.requireNonNull(lookup); + @SuppressWarnings("preview") + var recordComponents = recordClass.getRecordComponents(); // implicit nullcheck + if (recordComponents == null) { + throw new IllegalArgumentException("the class taken as argument is not a record"); + } + int length = recordComponents.length; + String[] names = new String[length]; + MethodHandle[] accessors = new MethodHandle[length]; + for(int i = 0; i < length; i++) { + var recordComponent = recordComponents[i]; + names[i] = recordComponent.getName(); + accessors[i] = lookup.unreflect(recordComponent.getAccessor()); + } + return new RecordLikeMirror(recordClass, List.of(names), List.of(accessors)); + } + } + + /** + * A bootstrap method for a constant dynamic that creates a record-like mirror + * from a record class. + * + * @param lookup the lookup used to retrieve the accessors. + * @param name any name. + * @param type the type of the constant ({@code RecordLikeMirror}). + * @param recordClass the record class. + * @return a record-like mirror created from the recordClass. + * @throws IllegalArgumentException if the type is not {@code RecordLikeMirror}. + * @throws IllegalAccessError if the lookup can not access to the + * accessors. + */ + public static RecordLikeMirror recordLikeMirrorConstant(MethodHandles.Lookup lookup, + String name, + Class type, + Class recordClass) { + Objects.requireNonNull(lookup); + Objects.requireNonNull(name); + Objects.requireNonNull(type); + Objects.requireNonNull(recordClass); + if (type != RecordLikeMirror.class) { + throw new IllegalArgumentException("type should be equals to RecordLikeMirror"); + } + try { + return RecordLikeMirror.fromRecord(lookup, recordClass); + } catch (IllegalAccessException e) { + throw (IllegalAccessError)new IllegalAccessError().initCause(e); + } + } + + /** * Bootstrap method to generate the {@link Object#equals(Object)}, - * {@link Object#hashCode()}, and {@link Object#toString()} methods, based - * on a description of the component names and accessor methods, for either + * {@link Object#hashCode()}, and {@link Object#toString()} methods, from a + * record-like mirror, for either {@code invokedynamic} call sites or dynamic + * constant pool entries. + * + * For more detail on the semantics of the generated methods see the + * specification of {@link java.lang.Record#equals(Object)}, + * {@link java.lang.Record#hashCode()} and {@link java.lang.Record#toString()}. + * + * @param lookup Every bootstrap method is expected to have a {@code lookup} + * which usually represents a lookup context with the + * accessibility privileges of the caller. This is because + * {@code invokedynamic} call sites always provide a + * {@code lookup} to the corresponding bootstrap method, but + * this method just ignores the {@code lookup} parameter + * @param methodName the name of the method to generate, which must be one of + * {@code "equals"}, {@code "hashCode"}, or {@code "toString"} + * @param type a {@link MethodType} corresponding the descriptor type for + * the method, which must correspond to the descriptor for the + * corresponding {@link Object} method, if linking an + * {@code invokedynamic} call site, or the constant + * {@code MethodHandle.class}, if linking a dynamic constant + * @param mirror a description of a record-like class + * @return a call site if invoked by indy, or a method handle if invoked by a + * condy + * @throws IllegalArgumentException if the bootstrap arguments are invalid or + * inconsistent + */ + public static Object bootstrap(MethodHandles.Lookup lookup, + String methodName, + TypeDescriptor type, + RecordLikeMirror mirror) { + Objects.requireNonNull(lookup); + Objects.requireNonNull(methodName); + Objects.requireNonNull(type); + Objects.requireNonNull(mirror); + MethodType methodType; + if (type instanceof MethodType) { + methodType = (MethodType) type; + } else { + if (MethodHandle.class != type) { + throw new IllegalArgumentException(type.toString()); + } + methodType = null; + } + MethodHandle handle = switch (methodName) { + case "equals" -> { + if (methodType != null && + (methodType.returnType() != boolean.class || methodType.parameterCount() != 2 || + methodType.parameterType(0) != mirror.type || methodType.parameterType(1) != Object.class)) { + throw new IllegalArgumentException("Bad method type: " + methodType); + } + yield makeEquals(mirror.type, mirror.accessors); + } + case "hashCode" -> { + if (methodType != null && + (methodType.returnType() != int.class || methodType.parameterCount() != 1 || + methodType.parameterType(0) != mirror.type)) { + throw new IllegalArgumentException("Bad method type: " + methodType); + } + yield makeHashCode(mirror.type, mirror.accessors); + } + case "toString" -> { + if (methodType != null && + (methodType.returnType() != String.class || methodType.parameterCount() != 1 || + methodType.parameterType(0) != mirror.type)) { + throw new IllegalArgumentException("Bad method type: " + methodType); + } + yield makeToString(mirror.type, mirror.accessors, mirror.names); + } + default -> throw new IllegalArgumentException(methodName); + }; + return methodType != null ? new ConstantCallSite(handle) : handle; + } + + /** + * Bootstrap method to generate the {@link Object#equals(Object)}, + * {@link Object#hashCode()}, and {@link Object#toString()} methods, based on a + * description of the component names and accessor methods, for either * {@code invokedynamic} call sites or dynamic constant pool entries. * - * For more detail on the semantics of the generated methods see the specification - * of {@link java.lang.Record#equals(Object)}, {@link java.lang.Record#hashCode()} and - * {@link java.lang.Record#toString()}. - * + * For more detail on the semantics of the generated methods see the + * specification of {@link java.lang.Record#equals(Object)}, + * {@link java.lang.Record#hashCode()} and {@link java.lang.Record#toString()}. * - * @param lookup Every bootstrap method is expected to have a {@code lookup} - * which usually represents a lookup context with the - * accessibility privileges of the caller. This is because - * {@code invokedynamic} call sites always provide a {@code lookup} - * to the corresponding bootstrap method, but this method just - * ignores the {@code lookup} parameter - * @param methodName the name of the method to generate, which must be one of - * {@code "equals"}, {@code "hashCode"}, or {@code "toString"} - * @param type a {@link MethodType} corresponding the descriptor type - * for the method, which must correspond to the descriptor - * for the corresponding {@link Object} method, if linking - * an {@code invokedynamic} call site, or the - * constant {@code MethodHandle.class}, if linking a - * dynamic constant - * @param recordClass the record class hosting the record components - * @param names the list of component names, joined into a string - * separated by ";", or the empty string if there are no - * components. Maybe be null, if the {@code methodName} - * is {@code "equals"} or {@code "hashCode"}. - * @param getters method handles for the accessor methods for the components - * @return a call site if invoked by indy, or a method handle - * if invoked by a condy - * @throws IllegalArgumentException if the bootstrap arguments are invalid - * or inconsistent - * @throws Throwable if any exception is thrown during call site construction + * @param lookup Every bootstrap method is expected to have a + * {@code lookup} which usually represents a lookup context + * with the accessibility privileges of the caller. This is + * because {@code invokedynamic} call sites always provide a + * {@code lookup} to the corresponding bootstrap method, but + * this method just ignores the {@code lookup} parameter + * @param methodName the name of the method to generate, which must be one of + * {@code "equals"}, {@code "hashCode"}, or + * {@code "toString"} + * @param type a {@link MethodType} corresponding the descriptor type for + * the method, which must correspond to the descriptor for + * the corresponding {@link Object} method, if linking an + * {@code invokedynamic} call site, or the constant + * {@code MethodHandle.class}, if linking a dynamic constant + * @param recordClass the record class hosting the record components + * @param names unused. + * @param getters unused + * @return a call site if invoked by indy, or a method handle if invoked by a + * condy + * @throws IllegalArgumentException if the bootstrap arguments are invalid or + * inconsistent + * @throws Throwable if any exception is thrown during call site + * construction + * + * @deprecated this method is deprecated and replaced by + * {@link #bootstrap(java.lang.invoke.MethodHandles.Lookup, String, TypeDescriptor, RecordLikeMirror)} */ + @Deprecated(forRemoval = true) public static Object bootstrap(MethodHandles.Lookup lookup, String methodName, TypeDescriptor type, - Class recordClass, - String names, - MethodHandle... getters) throws Throwable { - MethodType methodType; - if (type instanceof MethodType) - methodType = (MethodType) type; - else { - methodType = null; - if (!MethodHandle.class.equals(type)) - throw new IllegalArgumentException(type.toString()); - } - List getterList = List.of(getters); - MethodHandle handle; - switch (methodName) { - case "equals": - if (methodType != null && !methodType.equals(MethodType.methodType(boolean.class, recordClass, Object.class))) - throw new IllegalArgumentException("Bad method type: " + methodType); - handle = makeEquals(recordClass, getterList); - return methodType != null ? new ConstantCallSite(handle) : handle; - case "hashCode": - if (methodType != null && !methodType.equals(MethodType.methodType(int.class, recordClass))) - throw new IllegalArgumentException("Bad method type: " + methodType); - handle = makeHashCode(recordClass, getterList); - return methodType != null ? new ConstantCallSite(handle) : handle; - case "toString": - if (methodType != null && !methodType.equals(MethodType.methodType(String.class, recordClass))) - throw new IllegalArgumentException("Bad method type: " + methodType); - List nameList = "".equals(names) ? List.of() : List.of(names.split(";")); - if (nameList.size() != getterList.size()) - throw new IllegalArgumentException("Name list and accessor list do not match"); - handle = makeToString(recordClass, getterList, nameList); - return methodType != null ? new ConstantCallSite(handle) : handle; - default: - throw new IllegalArgumentException(methodName); - } + Class recordClass, + String names, + MethodHandle... getters) throws Throwable { + RecordLikeMirror mirror = recordLikeMirrorConstant(lookup, "recordLikeMirrorConstant", RecordLikeMirror.class, recordClass); + return bootstrap(lookup, methodName, type, mirror); } } From anthonyv.be at outlook.com Fri Feb 7 18:36:45 2020 From: anthonyv.be at outlook.com (Anthony Vanelverdinghe) Date: Fri, 7 Feb 2020 19:36:45 +0100 Subject: @Language annotation for JDK 13 text blocks In-Reply-To: References: Message-ID: [moving discussion to amber-dev] Hi Geertjan Not sure if there's been public mailing list discussions about it, but I'm pretty sure the amber team has already considered the idea of attaching this kind of metadata to text blocks. I don't know of any related decisions, though. One issue with annotations in particular, is that text blocks can appear in contexts where annotations can't, such as arguments to a method call, or annotation element values (JPA's @NamedQuery comes to mind). Another issue would be: where/how to standardize the set of "languages"? The IANA registry with media types doesn't contain things like SQL (let alone all its dialects), JSP, JSX, etc. And it's not Java SE's job to maintain such a registry either. Kind regards, Anthony PS: the Text Blocks JEP [1] specifies amber-dev as the mailing list for discussion, so I took the liberty to change the mailing lists. As I understand it, ide-support-dev is meant for IDE/tooling support when working on the OpenJDK codebase itself [1] http://openjdk.java.net/jeps/368 On 07/02/2020 12:58, Geertjan Wielenga wrote: > Hi all, > > It would be of great support for IDEs, editors, and tools of various kinds > if a @Language annotation would be part of the support for text blocks, so > that tooling would be able to determine which editor should be injected > within the text block. > > For example, imagine this annotation on top of a text block: > > @Language="text/html" > > That would then be used by IDEs, editors, tools, etc, to determine that the > text within the block is HTML and that therefore, for the tools that > support this (e.g., NetBeans, IntelliJ IDEA), an HTML editor would then be > injected within the text block, which would make HTML-oriented syntax > coloring, code completion, etc, available within the text block. > > If this meets with enthusiasm, what would the next steps be? An addition to > the text block spec or a new spec or something different? > > Thanks, > > Geertjan From alex.buckley at oracle.com Fri Feb 7 19:15:13 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 7 Feb 2020 11:15:13 -0800 Subject: @Language annotation for JDK 13 text blocks In-Reply-To: References: Message-ID: <837ad3ce-54e7-3313-08e1-0825d062604a@oracle.com> Anthony, thanks for the mailing list move. Geertjan, text blocks are just expressions of type String, and annotations on expressions (or statements) is an incredibly hard problem. The issue is that the java.lang.reflect and javax.lang.model APIs don't expose individual expressions and statements, such as those within a method body or on the RHS of a field initializer. IDEs which maintain direct access to the AST might be able to retrieve the annotations, but frameworks which work on class files or during annotation processing would not be able to retrieve them. This severely dials back the case for annotatable expressions in the Java language. That said, I recall some discussion here last year about using the space immediately to the right of the opening delimiter to denote a control language, governing the text to follow -- have a look for that. Alex On 2/7/2020 10:36 AM, Anthony Vanelverdinghe wrote: > [moving discussion to amber-dev] > > Hi Geertjan > > Not sure if there's been public mailing list discussions about it, but > I'm pretty sure the amber team has already considered the idea of > attaching this kind of metadata to text blocks. I don't know of any > related decisions, though. > > One issue with annotations in particular, is that text blocks can appear > in contexts where annotations can't, such as arguments to a method call, > or annotation element values (JPA's @NamedQuery comes to mind). > Another issue would be: where/how to standardize the set of "languages"? > The IANA registry with media types doesn't contain things like SQL (let > alone all its dialects), JSP, JSX, etc. And it's not Java SE's job to > maintain such a registry either. > > Kind regards, Anthony > > PS: the Text Blocks JEP [1] specifies amber-dev as the mailing list for > discussion, so I took the liberty to change the mailing lists. As I > understand it, ide-support-dev is meant for IDE/tooling support when > working on the OpenJDK codebase itself > > [1] http://openjdk.java.net/jeps/368 > > On 07/02/2020 12:58, Geertjan Wielenga wrote: >> Hi all, >> >> It would be of great support for IDEs, editors, and tools of various >> kinds >> if a @Language annotation would be part of the support for text >> blocks, so >> that tooling would be able to determine which editor should be injected >> within the text block. >> >> For example, imagine this annotation on top of a text block: >> >> @Language="text/html" >> >> That would then be used by IDEs, editors, tools, etc, to determine >> that the >> text within the block is HTML and that therefore, for the tools that >> support this (e.g., NetBeans, IntelliJ IDEA), an HTML editor would >> then be >> injected within the text block, which would make HTML-oriented syntax >> coloring, code completion, etc, available within the text block. >> >> If this meets with enthusiasm, what would the next steps be? An >> addition to >> the text block spec or a new spec or something different? >> >> Thanks, >> >> Geertjan From vicente.romero at oracle.com Fri Feb 7 20:38:53 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 07 Feb 2020 20:38:53 +0000 Subject: hg: amber/amber: 66 new changesets Message-ID: <202002072038.017KcxX1006337@aojmv0008.oracle.com> Changeset: 8482ab8f9b4c Author: iignatyev Date: 2020-01-30 08:55 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/8482ab8f9b4c 8237953: vmTestbase/jit/tiered/Test.java failure after JDK-8237798 Reviewed-by: iveresov ! test/hotspot/jtreg/vmTestbase/jit/tiered/Test.java Changeset: 085463e75652 Author: jjg Date: 2020-01-30 15:50 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/085463e75652 8238259: new tests do not account for Windows file separators Reviewed-by: vromero ! test/langtools/jdk/javadoc/doclet/testDocLintOption/TestDocLintOption.java ! test/langtools/jdk/javadoc/tool/testWErrorOption/TestWErrorOption.java Changeset: 0905868db490 Author: chagedorn Date: 2020-01-31 09:32 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/0905868db490 8235332: TestInstanceCloneAsLoadsStores.java fails with -XX:+StressGCM Summary: Account for GC barriers when skipping a cloned ArrayCopyNode in ConnectionGraph::find_inst_mem() Reviewed-by: roland, neliasso ! src/hotspot/share/opto/escape.cpp + test/hotspot/jtreg/compiler/arraycopy/TestCloneAccessStressGCM.java Changeset: 298f81208333 Author: iklam Date: 2020-01-31 14:18 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/298f81208333 8238198: Avoid using @ tags in TestOptionsWithRanges_generate.sh Reviewed-by: iignatyev ! test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges_generate.sh Changeset: a2320a988013 Author: egahlin Date: 2020-02-01 09:55 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/a2320a988013 8238241: Clean up problem list for JFR tests Reviewed-by: mgronlun, mseledtsov ! test/jdk/ProblemList.txt Changeset: 44cc199fac64 Author: ysuenaga Date: 2020-02-02 18:35 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/44cc199fac64 8238203: Return value of GetUserDefaultUILanguage() should be handled as LANGID Reviewed-by: naoto ! src/java.base/windows/native/libjava/java_props_md.c Changeset: 1dba80ef03e9 Author: jiefu Date: 2020-01-31 20:49 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/1dba80ef03e9 8238284: [macos] Zero VM build fails due to an obvious typo Reviewed-by: dholmes ! src/hotspot/os_cpu/bsd_zero/atomic_bsd_zero.hpp ! src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp ! src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp Changeset: d9e09b01ad0c Author: ihse Date: 2020-02-03 08:30 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/d9e09b01ad0c 8196875: Update run-test instructions for TEST_MODE Reviewed-by: erikj ! doc/testing.html ! doc/testing.md Changeset: c3d2fc56206f Author: tschatzl Date: 2020-02-03 10:45 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/c3d2fc56206f 8215297: Remove ParallelTaskTerminator Summary: Remove ParallelTaskTerminator as the alternate OWSTTaskTerminator algorithm has worked well for more than a year now. Reviewed-by: zgu, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1FullGCMarkTask.cpp ! src/hotspot/share/gc/g1/g1FullGCMarkTask.hpp ! src/hotspot/share/gc/g1/g1FullGCMarker.cpp ! src/hotspot/share/gc/g1/g1FullGCMarker.hpp ! src/hotspot/share/gc/g1/g1FullGCReferenceProcessorExecutor.hpp ! src/hotspot/share/gc/parallel/psCompactionManager.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/owstTaskTerminator.cpp ! src/hotspot/share/gc/shared/owstTaskTerminator.hpp ! src/hotspot/share/gc/shared/taskqueue.cpp ! src/hotspot/share/gc/shared/taskqueue.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp Changeset: dbb94c2ceaf8 Author: tschatzl Date: 2020-02-03 10:45 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/dbb94c2ceaf8 8238220: Rename OWSTTaskTerminator to TaskTerminator Reviewed-by: sjohanss, sangheki ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1FullGCMarkTask.hpp ! src/hotspot/share/gc/g1/g1FullGCMarker.cpp ! src/hotspot/share/gc/g1/g1FullGCMarker.hpp ! src/hotspot/share/gc/g1/g1FullGCReferenceProcessorExecutor.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/taskTerminator.cpp < src/hotspot/share/gc/shared/owstTaskTerminator.cpp ! src/hotspot/share/gc/shared/taskTerminator.hpp < src/hotspot/share/gc/shared/owstTaskTerminator.hpp ! src/hotspot/share/gc/shared/taskqueue.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp Changeset: 1617236f5cbb Author: tschatzl Date: 2020-02-03 10:45 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/1617236f5cbb 8238229: Remove TRACESPINNING debug code Reviewed-by: kbarrett, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/taskTerminator.cpp ! src/hotspot/share/gc/shared/taskTerminator.hpp Changeset: 6d9ac97c7d2f Author: lkorinth Date: 2020-02-03 18:20 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/6d9ac97c7d2f 8233220: Space::_par_seq_tasks is unused after CMS removal Reviewed-by: pliden, tschatzl, lkorinth Contributed-by: Ivan Walulya ! src/hotspot/share/gc/shared/space.hpp Changeset: 4639cbdcbf27 Author: mbaesken Date: 2020-02-03 09:39 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/4639cbdcbf27 8237962: give better error output for invalid OCSP response intervals in CertPathValidator checks Reviewed-by: clanger, mullan ! src/java.base/share/classes/sun/security/provider/certpath/OCSPResponse.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithParams.java Changeset: c7152f7e01a6 Author: roland Date: 2020-01-28 13:36 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/c7152f7e01a6 8237951: CTW: C2 compilation fails with "malformed control flow" Reviewed-by: vlivanov, kvn ! src/hotspot/share/opto/phaseX.cpp Changeset: 9b3d5cc71cea Author: dnsimon Date: 2020-02-04 09:33 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/9b3d5cc71cea 8238190: [JVMCI] Fix single implementor speculation for diamond shapes. Reviewed-by: kvn Contributed-by: david.leopoldseder at oracle.com ! src/hotspot/share/oops/instanceKlass.cpp + test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestSingleImplementor.java Changeset: f0cd8603f11e Author: almatvee Date: 2020-02-04 11:44 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/f0cd8603f11e 8235954: [dmg] Default DMG background tiff of jpackage not retina ready Reviewed-by: herrick, asemenyuk ! src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/background_dmg.tiff Changeset: 78e0dd9ac15f Author: dfuchs Date: 2020-02-04 18:35 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/78e0dd9ac15f 8238231: Custom DatagramSocketImpl's create method not called when with protected constructor Summary: Allow the socket to be lazily created if not created by the constructor. Reviewed-by: alanb ! src/java.base/share/classes/java/net/DatagramSocket.java ! test/jdk/java/net/DatagramSocket/SetReceiveBufferSize.java + test/jdk/java/net/DatagramSocketImpl/TestCreate.java Changeset: cf7c8e28ff9a Author: zgu Date: 2020-02-04 14:48 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/cf7c8e28ff9a 8238162: Shenandoah: Remove ShenandoahTaskTerminator wrapper Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.hpp Changeset: ca6c676cab64 Author: weijun Date: 2020-02-04 13:15 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/ca6c676cab64 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION Reviewed-by: wetmore, coffeys, mullan ! src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp Changeset: 4f9dc5bee9c4 Author: jjg Date: 2020-02-04 14:02 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/4f9dc5bee9c4 8219475: javap man page needs to be updated Reviewed-by: mchung ! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap.properties Changeset: 84e55cb3894e Author: prappo Date: 2020-02-04 22:05 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/84e55cb3894e 8238467: Clean up annotations on overridden/implemented methods Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/api/JavadocTaskImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/api/JavadocTool.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeFieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DocFilesHandlerImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialFieldWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialMethodWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkFactoryImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkInfoImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkOutputImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/WriterFactoryImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Comment.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/FixedStringContent.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/RawHtml.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/StringContent.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/DocletElement.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/OverviewElement.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeFieldBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstantsSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstructorBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/EnumConstantBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/FieldBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MethodBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/PropertyBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/BasePropertyTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/BaseTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/ThrowsTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/UserTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPath.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Group.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocToolProvider.java Changeset: 6e49fb6ad4ee Author: weijun Date: 2020-02-05 11:09 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/6e49fb6ad4ee 8237804: sun/security/mscapi tests fail with "Key pair not generated, alias already exists" Reviewed-by: mullan ! test/jdk/sun/security/mscapi/KeyAlgorithms.java ! test/jdk/sun/security/mscapi/PublicKeyInterop.java Changeset: a23e471deb84 Author: diazhou Date: 2020-01-30 18:02 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/a23e471deb84 8236092: Remove EA from JDK 14 version string starting with Initial RC promotion Reviewed-by: tbell, erikj ! make/autoconf/version-numbers Changeset: f8bf9cb16b5e Author: mgronlun Date: 2020-01-31 12:17 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/f8bf9cb16b5e 8236743: JFR: assert(klass != __null) failed: invariant in ObjectSampleCheckpoint::add_to_leakp_set Reviewed-by: egahlin ! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp ! src/hotspot/share/jfr/recorder/stacktrace/jfrStackTrace.cpp ! src/hotspot/share/jfr/recorder/stacktrace/jfrStackTrace.hpp + src/hotspot/share/jfr/support/jfrMethodLookup.cpp + src/hotspot/share/jfr/support/jfrMethodLookup.hpp Changeset: 2a0de7812409 Author: bpb Date: 2020-01-31 08:04 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/2a0de7812409 8237514: Spec Clarification - ByteBuffer::alignmentOffset Spec Reviewed-by: alanb, psandoz ! src/java.base/share/classes/java/nio/X-Buffer.java.template ! test/jdk/java/nio/Buffer/Basic-X.java.template ! test/jdk/java/nio/Buffer/Basic.java ! test/jdk/java/nio/Buffer/BasicByte.java Changeset: 66ecee0023e1 Author: ljiang Date: 2020-02-04 16:26 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/66ecee0023e1 8238377: JDK 14 L10N resource file update - msgdrop 20 Reviewed-by: naoto, herrick, mchung ! src/jdk.incubator.jpackage/windows/classes/jdk/incubator/jpackage/internal/resources/MsiInstallerStrings_ja.wxl ! src/jdk.incubator.jpackage/windows/classes/jdk/incubator/jpackage/internal/resources/MsiInstallerStrings_zh_CN.wxl ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_ja.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_zh_CN.properties ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_ja.properties ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_zh_CN.properties Changeset: 3e021f5c81f5 Author: jwilhelm Date: 2020-02-05 03:24 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/3e021f5c81f5 Merge ! make/autoconf/version-numbers Changeset: d0ee21ac3329 Author: jwilhelm Date: 2020-02-05 03:26 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/d0ee21ac3329 8238515: Backout JDK-8236092 from jdk/jdk Reviewed-by: dholmes ! make/autoconf/version-numbers Changeset: 689d165369ac Author: clanger Date: 2020-02-05 06:33 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/689d165369ac 8238375: JFR Test TestJcmdStartFlushInterval is not run Reviewed-by: egahlin, mseledtsov ! test/jdk/jdk/jfr/jcmd/TestJcmdStartFlushInterval.java Changeset: 932418820c80 Author: ihse Date: 2020-02-05 10:45 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/932418820c80 8238281: Raise minimum gcc version needed to 5.0 Reviewed-by: erikj, dholmes, jwilhelm, mbaesken ! doc/building.html ! doc/building.md ! make/autoconf/flags-cflags.m4 ! make/autoconf/flags.m4 ! make/autoconf/toolchain.m4 ! make/hotspot/lib/CompileJvm.gmk ! src/hotspot/share/memory/operator_new.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/utilities/compilerWarnings_gcc.hpp ! src/hotspot/share/utilities/debug.hpp ! src/hotspot/share/utilities/globalDefinitions_gcc.hpp ! src/hotspot/share/utilities/ostream.cpp Changeset: 9e54ea7d9cd9 Author: qpzhang Date: 2020-02-05 20:31 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/9e54ea7d9cd9 8238388: libj2gss/NativeFunc.o "multiple definition" link errors with GCC10 Summary: Fixed libj2gss link errors caused by GCC10 default -fno-common Reviewed-by: weijun ! src/java.security.jgss/share/native/libj2gss/NativeFunc.c ! src/java.security.jgss/share/native/libj2gss/NativeFunc.h Changeset: 5a0b13e3715d Author: mseledtsov Date: 2020-02-05 07:31 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/5a0b13e3715d 8179317: [TESTBUG] rewrite runtime shell tests in java Summary: Converted shell tests to Java Reviewed-by: dholmes, iignatyev, lmesnik ! make/test/JtregNativeHotspot.gmk ! test/hotspot/jtreg/TEST.groups - test/hotspot/jtreg/runtime/7162488/Test7162488.sh + test/hotspot/jtreg/runtime/7162488/TestUnrecognizedVmOption.java + test/hotspot/jtreg/runtime/StackGap/TestStackGap.java - test/hotspot/jtreg/runtime/StackGap/testme.sh + test/hotspot/jtreg/runtime/StackGuardPages/TestStackGuardPages.java - test/hotspot/jtreg/runtime/StackGuardPages/testme.sh + test/hotspot/jtreg/runtime/TLS/TestTLS.java - test/hotspot/jtreg/runtime/TLS/testtls.sh ! test/hotspot/jtreg/runtime/signal/SigTestDriver.java + test/hotspot/jtreg/testlibrary_tests/process/Test.java + test/hotspot/jtreg/testlibrary_tests/process/TestNativeProcessBuilder.java + test/hotspot/jtreg/testlibrary_tests/process/exejvm-test-launcher.c - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/TestDescription.java + test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/TestMaxMetaspaceSize.java - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/maxMetaspaceSize.sh ! test/lib/jdk/test/lib/Platform.java ! test/lib/jdk/test/lib/process/ProcessTools.java Changeset: ba74310b0b69 Author: simonis Date: 2020-02-05 16:39 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/ba74310b0b69 8235699: ArrayIndexOutOfBoundsException in CalendarBuilder.toString Reviewed-by: phh, alanb, weijun, simonis, rriggs Contributed-by: verghese at amazon.com ! src/java.base/share/classes/java/text/CalendarBuilder.java + test/jdk/java/text/Format/DateFormat/Bug8235699.java + test/jdk/java/text/Format/DateFormat/java.base/java/text/CalendarBuilderTest.java Changeset: 175867bc8928 Author: dcubed Date: 2020-02-05 11:38 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/175867bc8928 8235931: add OM_CACHE_LINE_SIZE and use smaller size on SPARCv9 and X64 Reviewed-by: dholmes, redestad, mdoerr ! src/hotspot/cpu/sparc/globalDefinitions_sparc.hpp ! src/hotspot/cpu/x86/globalDefinitions_x86.hpp ! src/hotspot/share/runtime/objectMonitor.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp Changeset: 00470b6c0eaf Author: dcubed Date: 2020-02-05 11:39 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/00470b6c0eaf 8236035: refactor ObjectMonitor::set_owner() and _owner field setting Reviewed-by: dholmes, kbarrett, rehn ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp ! src/hotspot/share/runtime/objectMonitor.inline.hpp ! src/hotspot/share/runtime/synchronizer.cpp Changeset: b353416faedf Author: dcubed Date: 2020-02-05 11:40 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/b353416faedf 8235795: replace monitor list mux{Acquire,Release}(&gListLock) with spin locks Reviewed-by: dholmes, coleenp, rehn ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp ! src/hotspot/share/runtime/objectMonitor.inline.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/runtime/thread.hpp Changeset: 023df178388e Author: erikj Date: 2020-02-05 09:33 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/023df178388e 8238225: Issues reported after replacing symlink at Contents/MacOS/libjli.dylib with binary Reviewed-by: clanger, alanb, ihse ! src/java.base/macosx/native/libjli/java_md_macosx.m ! test/jdk/tools/launcher/JliLaunchTest.java Changeset: ce9ddf7062e5 Author: mchung Date: 2020-02-05 09:53 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/ce9ddf7062e5 8230047: Remove legacy java.lang.reflect.ProxyGenerator_v49 Reviewed-by: rriggs, sundar ! src/java.base/share/classes/java/lang/reflect/Proxy.java - src/java.base/share/classes/java/lang/reflect/ProxyGenerator_v49.java ! test/jdk/java/lang/reflect/Proxy/ProxyGeneratorCombo.java ! test/micro/org/openjdk/bench/java/lang/reflect/Proxy/ProxyBench.java Changeset: 62b5bfef8d61 Author: jjg Date: 2020-02-05 11:01 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/62b5bfef8d61 8222793: Javadoc tool ignores "-locale" param and uses default locale for all messages and texts Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Messages.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Resources.java + test/langtools/jdk/javadoc/tool/testLocaleOption/TestLocaleOption.java Changeset: 7b57401deb0c Author: jwilhelm Date: 2020-02-06 02:54 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/7b57401deb0c Added tag jdk-15+9 for changeset 62b5bfef8d61 ! .hgtags Changeset: 1c4286ec9e45 Author: mbaesken Date: 2020-02-05 10:14 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/1c4286ec9e45 8238530: OPT_SPEED_SRC list misses some files with cpu-dependend file names Reviewed-by: ihse, redestad ! make/hotspot/lib/JvmFeatures.gmk Changeset: 6e507ee93768 Author: neliasso Date: 2020-02-06 11:21 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/6e507ee93768 8237581: Improve allocation expansion Reviewed-by: vlivanov, redestad ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/macro.hpp + test/hotspot/jtreg/compiler/allocation/TestAllocation.java + test/micro/org/openjdk/bench/vm/compiler/ArrayAllocation.java Changeset: f9f766fa1125 Author: ihse Date: 2020-02-06 13:38 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/f9f766fa1125 8218480: Automatically add -Werror in FLAGS_COMPILER_CHECK_ARGUMENTS Reviewed-by: erikj ! make/autoconf/flags-cflags.m4 ! make/autoconf/flags.m4 Changeset: 227542943648 Author: ihse Date: 2020-02-06 13:40 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/227542943648 8238542: When warning about C/C++ compiler mismatch, be clear if this is about build compilers Reviewed-by: erikj ! make/autoconf/toolchain.m4 Changeset: 885b23ef907d Author: ihse Date: 2020-02-06 13:40 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/885b23ef907d 8212986: Make Visual Studio compiler check less strict Reviewed-by: erikj ! make/autoconf/toolchain.m4 Changeset: c35eac313084 Author: ihse Date: 2020-02-06 13:41 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/c35eac313084 8201349: build broken when configured with --with-zlib=bundled on gcc 7.3 Reviewed-by: erikj ! make/lib/CoreLibraries.gmk Changeset: 4a4d185098e2 Author: lfoltan Date: 2020-02-06 14:29 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/4a4d185098e2 8230199: consolidate signature parsing code in HotSpot sources Summary: Add a new Signature class to support basic signature queries and enhance SignatureStream class to parse field signatures in addition to methods. Reviewed-by: coleenp, dholmes, fparain, hseigel Contributed-by: lois.foltan at oracle.com, john.r.rose at oracle.com ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/sparc/sharedRuntime_sparc.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/c1/c1_ValueMap.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciField.cpp ! src/hotspot/share/ci/ciKlass.hpp ! src/hotspot/share/ci/ciObjArrayKlass.cpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/ci/ciSignature.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/classListParser.cpp ! src/hotspot/share/classfile/defaultMethods.cpp ! src/hotspot/share/classfile/placeholders.cpp ! src/hotspot/share/classfile/stackMapTable.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/verificationType.cpp ! src/hotspot/share/classfile/vmSymbols.cpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/compiler/methodMatcher.cpp ! src/hotspot/share/interpreter/bytecode.cpp ! src/hotspot/share/interpreter/bytecodeUtils.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/oopMapCache.cpp ! src/hotspot/share/interpreter/rewriter.cpp ! src/hotspot/share/jvmci/compilerRuntime.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp ! src/hotspot/share/oops/constMethod.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/generateOopMap.cpp ! src/hotspot/share/oops/generateOopMap.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/oops/methodData.cpp ! src/hotspot/share/oops/symbol.cpp ! src/hotspot/share/oops/symbol.hpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvmtiImpl.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/prims/methodHandles.hpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/fieldDescriptor.hpp ! src/hotspot/share/runtime/fieldDescriptor.inline.hpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/javaCalls.cpp ! src/hotspot/share/runtime/reflection.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/signature.cpp ! src/hotspot/share/runtime/signature.hpp ! src/hotspot/share/utilities/globalDefinitions.cpp ! src/hotspot/share/utilities/globalDefinitions.hpp Changeset: d3caf06ac9ae Author: lfoltan Date: 2020-02-06 15:28 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/d3caf06ac9ae 8238600: Remove runtime/fieldType.hpp and fieldType.cpp Summary: Remove obsolesced source files fieldType.hpp and fieldType.cpp. Reviewed-by: hseigel Contributed-by: lois.foltan at oracle.com - src/hotspot/share/runtime/fieldType.cpp - src/hotspot/share/runtime/fieldType.hpp Changeset: 4a87bb7ebfd7 Author: roland Date: 2020-01-31 14:36 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/4a87bb7ebfd7 8237776: Shenandoah: Wrong result with Lucene test Reviewed-by: rkennke, zgu, shade ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp Changeset: e08e21ca813f Author: jwilhelm Date: 2020-02-06 02:52 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/e08e21ca813f Added tag jdk-14+35 for changeset 4a87bb7ebfd7 ! .hgtags Changeset: c17f7a28ee8d Author: jwilhelm Date: 2020-02-06 17:14 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/c17f7a28ee8d Merge ! .hgtags ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp Changeset: 8d8916159b62 Author: zgu Date: 2020-02-06 13:08 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/8d8916159b62 8238574: Shenandoah: Assertion failure due to missing null check Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp Changeset: 9544e515be4e Author: dtitov Date: 2020-02-06 11:23 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/9544e515be4e 8196729: Add jstatd option to specify RMI connector port Reviewed-by: cjplummer, sspitsyn ! src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java ! src/jdk.jstatd/share/classes/sun/tools/jstatd/RemoteHostImpl.java ! test/jdk/sun/tools/jstatd/JstatdTest.java + test/jdk/sun/tools/jstatd/TestJstatdRmiPort.java ! test/jdk/sun/tools/jstatd/TestJstatdUsage.java Changeset: adc5b0998235 Author: jjg Date: 2020-02-06 12:44 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/adc5b0998235 8238503: Remove unused field and accessor for docLocale from ToolOptions Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOptions.java Changeset: 59daa8db33ce Author: kbarrett Date: 2020-02-06 19:09 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/59daa8db33ce 8237143: Eliminate DirtyCardQ_cbl_mon Summary: Replace locked data structures with lock-free data structures. Reviewed-by: tschatzl, sangheki ! src/hotspot/share/gc/g1/g1BarrierSet.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.hpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp ! src/hotspot/share/gc/shared/ptrQueue.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: 5e402c63694f Author: dholmes Date: 2020-02-06 21:03 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/5e402c63694f 8238460: Provide warnings about the use of JNI RegisterNatives to rebind native methods for boot/platform classes in other classloaders Reviewed-by: jwilhelm, lfoltan ! src/hotspot/share/prims/jni.cpp + test/hotspot/jtreg/runtime/jni/registerNativesWarning/TestRegisterNativesWarning.java + test/hotspot/jtreg/runtime/jni/registerNativesWarning/libregisterNativesWarning.c Changeset: e0fca02bb611 Author: redestad Date: 2020-02-07 09:47 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/e0fca02bb611 8238599: Refactor and simplify implAddOpensToAllUnnamed Reviewed-by: alanb ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java Changeset: 538611d777d2 Author: redestad Date: 2020-02-07 10:15 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/538611d777d2 8236272: Improve fidelity between contents of default CDS archive and classes loaded at runtime Reviewed-by: erikj, jiangli, iklam ! make/GenerateLinkOptData.gmk ! make/jdk/src/classes/build/tools/classlist/HelloClasslist.java Changeset: 84920d352dc4 Author: redestad Date: 2020-02-07 10:23 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/84920d352dc4 8237484: Improve module system bootstrap Reviewed-by: alanb ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java Changeset: f41394559814 Author: pconcannon Date: 2020-02-07 11:10 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/f41394559814 7021373: DatagramPacket exception conditions are not clear Summary: Specification is clarified by adding or clarifying @throws clauses where required Reviewed-by: alanb, chegar, darcy, dfuchs ! src/java.base/share/classes/java/net/DatagramPacket.java ! test/jdk/java/net/DatagramPacket/Constructor.java + test/jdk/java/net/DatagramPacket/Setters.java Changeset: f2cefce4859b Author: roland Date: 2020-01-14 14:58 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/f2cefce4859b 8237086: assert(is_MachReturn()) running CTW with fix for JDK-8231291 Reviewed-by: kvn, vlivanov ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/graphKit.cpp Changeset: 51fb05ec531d Author: roland Date: 2019-12-20 17:17 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/51fb05ec531d 8231291: C2: loop opts before EA should maximally unroll loops Reviewed-by: kvn, vlivanov ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/loopnode.cpp Changeset: f1f8562f3ad2 Author: egahlin Date: 2020-02-07 18:24 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/f1f8562f3ad2 8215452: Logged repo location is wrong when using delayed recording start Reviewed-by: mgronlun, mseledtsov ! src/jdk.jfr/share/classes/jdk/jfr/FlightRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/Repository.java Changeset: bc54620a3848 Author: naoto Date: 2020-02-06 10:10 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/bc54620a3848 8238605: Correct the CLDR version number in cldr.md files Reviewed-by: joehw, alanb ! src/java.base/share/legal/cldr.md ! src/jdk.localedata/share/legal/cldr.md Changeset: e568ce785bdf Author: jwilhelm Date: 2020-02-07 00:17 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/e568ce785bdf Added tag jdk-14+36 for changeset bc54620a3848 ! .hgtags Changeset: adda073e3c33 Author: jwilhelm Date: 2020-02-07 17:24 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/adda073e3c33 Merge ! .hgtags From maurizio.cimadamore at oracle.com Fri Feb 7 20:40:02 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 07 Feb 2020 20:40:02 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202002072040.017Ke3nR007314@aojmv0008.oracle.com> Changeset: e2b66a04ca50 Author: mcimadamore Date: 2020-02-07 20:39 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/e2b66a04ca50 Automatic merge with default ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/vmSymbols.hpp - src/hotspot/share/gc/shared/owstTaskTerminator.cpp - src/hotspot/share/gc/shared/owstTaskTerminator.hpp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/prims/jvm.cpp - src/hotspot/share/runtime/fieldType.cpp - src/hotspot/share/runtime/fieldType.hpp - src/java.base/share/classes/java/lang/reflect/ProxyGenerator_v49.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkInfoImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java - test/hotspot/jtreg/runtime/7162488/Test7162488.sh - test/hotspot/jtreg/runtime/StackGap/testme.sh - test/hotspot/jtreg/runtime/StackGuardPages/testme.sh - test/hotspot/jtreg/runtime/TLS/testtls.sh - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/TestDescription.java - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/maxMetaspaceSize.sh From maurizio.cimadamore at oracle.com Fri Feb 7 20:40:26 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 07 Feb 2020 20:40:26 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202002072040.017KeQXe007727@aojmv0008.oracle.com> Changeset: 653fda4d1c0c Author: mcimadamore Date: 2020-02-07 20:40 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/653fda4d1c0c Automatic merge with default - src/hotspot/share/gc/shared/owstTaskTerminator.cpp - src/hotspot/share/gc/shared/owstTaskTerminator.hpp - src/hotspot/share/runtime/fieldType.cpp - src/hotspot/share/runtime/fieldType.hpp - src/java.base/share/classes/java/lang/reflect/ProxyGenerator_v49.java - test/hotspot/jtreg/runtime/7162488/Test7162488.sh - test/hotspot/jtreg/runtime/StackGap/testme.sh - test/hotspot/jtreg/runtime/StackGuardPages/testme.sh - test/hotspot/jtreg/runtime/TLS/testtls.sh - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/TestDescription.java - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/maxMetaspaceSize.sh From maurizio.cimadamore at oracle.com Fri Feb 7 20:40:49 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 07 Feb 2020 20:40:49 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202002072040.017Kensc008183@aojmv0008.oracle.com> Changeset: 71be3205373d Author: mcimadamore Date: 2020-02-07 20:40 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/71be3205373d Automatic merge with default - src/hotspot/share/gc/shared/owstTaskTerminator.cpp - src/hotspot/share/gc/shared/owstTaskTerminator.hpp - src/hotspot/share/runtime/fieldType.cpp - src/hotspot/share/runtime/fieldType.hpp - src/java.base/share/classes/java/lang/reflect/ProxyGenerator_v49.java - test/hotspot/jtreg/runtime/7162488/Test7162488.sh - test/hotspot/jtreg/runtime/StackGap/testme.sh - test/hotspot/jtreg/runtime/StackGuardPages/testme.sh - test/hotspot/jtreg/runtime/TLS/testtls.sh - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/TestDescription.java - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/maxMetaspaceSize.sh From maurizio.cimadamore at oracle.com Fri Feb 7 20:41:11 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 07 Feb 2020 20:41:11 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202002072041.017KfBP5008719@aojmv0008.oracle.com> Changeset: 2568bcf17169 Author: mcimadamore Date: 2020-02-07 20:40 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/2568bcf17169 Automatic merge with default - src/hotspot/share/gc/shared/owstTaskTerminator.cpp - src/hotspot/share/gc/shared/owstTaskTerminator.hpp - src/hotspot/share/runtime/fieldType.cpp - src/hotspot/share/runtime/fieldType.hpp - src/java.base/share/classes/java/lang/reflect/ProxyGenerator_v49.java - test/hotspot/jtreg/runtime/7162488/Test7162488.sh - test/hotspot/jtreg/runtime/StackGap/testme.sh - test/hotspot/jtreg/runtime/StackGuardPages/testme.sh - test/hotspot/jtreg/runtime/TLS/testtls.sh - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/TestDescription.java - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/maxMetaspaceSize.sh From maurizio.cimadamore at oracle.com Fri Feb 7 20:41:34 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 07 Feb 2020 20:41:34 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202002072041.017KfYo2010129@aojmv0008.oracle.com> Changeset: 8e4c82c28869 Author: mcimadamore Date: 2020-02-07 20:41 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/8e4c82c28869 Automatic merge with default - src/hotspot/share/gc/shared/owstTaskTerminator.cpp - src/hotspot/share/gc/shared/owstTaskTerminator.hpp - src/hotspot/share/runtime/fieldType.cpp - src/hotspot/share/runtime/fieldType.hpp - src/java.base/share/classes/java/lang/reflect/ProxyGenerator_v49.java - test/hotspot/jtreg/runtime/7162488/Test7162488.sh - test/hotspot/jtreg/runtime/StackGap/testme.sh - test/hotspot/jtreg/runtime/StackGuardPages/testme.sh - test/hotspot/jtreg/runtime/TLS/testtls.sh - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/TestDescription.java - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/maxMetaspaceSize.sh From maurizio.cimadamore at oracle.com Fri Feb 7 20:41:56 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 07 Feb 2020 20:41:56 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202002072041.017KfuBa010497@aojmv0008.oracle.com> Changeset: 9208ac057fe5 Author: mcimadamore Date: 2020-02-07 20:41 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/9208ac057fe5 Automatic merge with default - src/hotspot/share/gc/shared/owstTaskTerminator.cpp - src/hotspot/share/gc/shared/owstTaskTerminator.hpp - src/hotspot/share/runtime/fieldType.cpp - src/hotspot/share/runtime/fieldType.hpp - src/java.base/share/classes/java/lang/reflect/ProxyGenerator_v49.java - test/hotspot/jtreg/runtime/7162488/Test7162488.sh - test/hotspot/jtreg/runtime/StackGap/testme.sh - test/hotspot/jtreg/runtime/StackGuardPages/testme.sh - test/hotspot/jtreg/runtime/TLS/testtls.sh - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/TestDescription.java - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/maxMetaspaceSize.sh From maurizio.cimadamore at oracle.com Fri Feb 7 20:42:18 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 07 Feb 2020 20:42:18 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202002072042.017KgIqh010896@aojmv0008.oracle.com> Changeset: 05bd8e20647c Author: mcimadamore Date: 2020-02-07 20:42 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/05bd8e20647c Automatic merge with default - src/hotspot/share/gc/shared/owstTaskTerminator.cpp - src/hotspot/share/gc/shared/owstTaskTerminator.hpp - src/hotspot/share/runtime/fieldType.cpp - src/hotspot/share/runtime/fieldType.hpp - src/java.base/share/classes/java/lang/reflect/ProxyGenerator_v49.java - test/hotspot/jtreg/runtime/7162488/Test7162488.sh - test/hotspot/jtreg/runtime/StackGap/testme.sh - test/hotspot/jtreg/runtime/StackGuardPages/testme.sh - test/hotspot/jtreg/runtime/TLS/testtls.sh - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/TestDescription.java - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/maxMetaspaceSize.sh From maurizio.cimadamore at oracle.com Fri Feb 7 20:42:42 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 07 Feb 2020 20:42:42 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002072042.017KggE1011284@aojmv0008.oracle.com> Changeset: add2251baf29 Author: mcimadamore Date: 2020-02-07 20:42 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/add2251baf29 Automatic merge with sealed-types ! .hgtags ! doc/building.html ! doc/testing.html ! doc/testing.md ! make/autoconf/flags-cflags.m4 ! make/hotspot/lib/CompileJvm.gmk ! make/jdk/src/classes/build/tools/classlist/HelloClasslist.java ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/sparc/sharedRuntime_sparc.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp ! src/hotspot/share/gc/parallel/psCompactionManager.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp - src/hotspot/share/gc/shared/owstTaskTerminator.cpp - src/hotspot/share/gc/shared/owstTaskTerminator.hpp ! src/hotspot/share/gc/shared/ptrQueue.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/deoptimization.cpp - src/hotspot/share/runtime/fieldType.cpp - src/hotspot/share/runtime/fieldType.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp ! src/hotspot/share/runtime/objectMonitor.inline.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java - src/java.base/share/classes/java/lang/reflect/ProxyGenerator_v49.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkInfoImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/hotspot/jtreg/TEST.groups - test/hotspot/jtreg/runtime/7162488/Test7162488.sh - test/hotspot/jtreg/runtime/StackGap/testme.sh - test/hotspot/jtreg/runtime/StackGuardPages/testme.sh - test/hotspot/jtreg/runtime/TLS/testtls.sh - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/TestDescription.java - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/maxMetaspaceSize.sh ! test/jdk/ProblemList.txt ! test/lib/jdk/test/lib/process/ProcessTools.java From forax at univ-mlv.fr Fri Feb 7 22:11:07 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 7 Feb 2020 23:11:07 +0100 (CET) Subject: if (!(x instanceof String y)) syntax - better syntax? In-Reply-To: <8daab2e0-3c37-4c36-6c1e-29d6101b38d0@oracle.com> References: <8daab2e0-3c37-4c36-6c1e-29d6101b38d0@oracle.com> Message-ID: <792413689.1005161.1581113467148.JavaMail.zimbra@u-pem.fr> One problem i see is that this idiom is currently popular because until 14 most of the time you had to do a cast and store the result in a local variable after the instanceof, now that we can do an instanceof and create a local variable with one expression, i'm not sure this idiom will be used a lot anymore, I think that Tagir (correct me if i'm wrong) has already said that IntelliJ is/will be able to refactor this idiom to return x instanceof String s && ... R?mi ----- Mail original ----- > De: "Brian Goetz" > ?: "Reinier Zwitserloot" , "amber-dev" > Envoy?: Vendredi 7 F?vrier 2020 17:02:55 > Objet: Re: if (!(x instanceof String y)) syntax - better syntax? >> I'm not sure if now is an appropriate time (or how one should bring up >> something like this) > > Heh, it's never a good time, and there's never a good way, but you came > about as close as is possible! > >> I noticed a bit of friction in regards to this >> particular style of code: >> >> if (!(x instanceof String y)) return; >> // carry on, with y available of type Strin. > > Indeed, it is definitely an "idiom" that may take a little getting used to. > >> Given that a new language feature is being introduced which is catering >> rather explicitly to this particular 'if not an instance of, then' style, >> is there room to add a small, entirely backwards compatible syntax feature >> [1]? >> >> Something like: >> >> if (x !instanceof String y) return; > > Not a terrible idea!? Something worth considering. > >> I'm not sure if it would be appropriate to debate here if this should be >> tagged onto the aims for e.g. JDK15's expanded instanceof support ( >> Preview-2 [2] ), or if this should be its own proposal, or if this is even >> the appropriate channel for such ideas. > > My inclination is not to load down pattern matching with this, and give > us time to gather evidence about how much of a friction point it is. > >> [1] I'm jumping the gun a little bit on how backwards compatible this is. I >> _think_ so, as it's a straight up syntax error right now, but before I >> write a PoC patch to javac, I thought I'd check if the idea itself is sound >> before delving that deep. > > The claim that it is a simple rewriting and introduces no ambiguities is > credible; would have to be verified. From jesper at selskabet.org Fri Feb 7 22:14:50 2020 From: jesper at selskabet.org (=?utf-8?Q?Jesper_Steen_M=C3=B8ller?=) Date: Fri, 7 Feb 2020 23:14:50 +0100 Subject: if (!(x instanceof String y)) syntax - better syntax? In-Reply-To: <792413689.1005161.1581113467148.JavaMail.zimbra@u-pem.fr> References: <8daab2e0-3c37-4c36-6c1e-29d6101b38d0@oracle.com> <792413689.1005161.1581113467148.JavaMail.zimbra@u-pem.fr> Message-ID: <1A72A6E6-89FA-4139-8FFF-DFC2498809A1@selskabet.org> Additionally, javac could consider giving better help for "if (!obj instanceof SomeClass ..." since it will always be a typo, requiring parenthesis (as instanceof will never autobox a boolean). Alternatively, we can leave it to IDEs to hint. -Jesper > On 7 Feb 2020, at 23.11, Remi Forax wrote: > > One problem i see is that this idiom is currently popular because until 14 most of the time you had to do a cast and store the result in a local variable after the instanceof, > now that we can do an instanceof and create a local variable with one expression, i'm not sure this idiom will be used a lot anymore, > > I think that Tagir (correct me if i'm wrong) has already said that IntelliJ is/will be able to refactor this idiom to > return x instanceof String s && ... > > R?mi > > ----- Mail original ----- >> De: "Brian Goetz" >> ?: "Reinier Zwitserloot" , "amber-dev" >> Envoy?: Vendredi 7 F?vrier 2020 17:02:55 >> Objet: Re: if (!(x instanceof String y)) syntax - better syntax? > >>> I'm not sure if now is an appropriate time (or how one should bring up >>> something like this) >> >> Heh, it's never a good time, and there's never a good way, but you came >> about as close as is possible! >> >>> I noticed a bit of friction in regards to this >>> particular style of code: >>> >>> if (!(x instanceof String y)) return; >>> // carry on, with y available of type Strin. >> >> Indeed, it is definitely an "idiom" that may take a little getting used to. >> >>> Given that a new language feature is being introduced which is catering >>> rather explicitly to this particular 'if not an instance of, then' style, >>> is there room to add a small, entirely backwards compatible syntax feature >>> [1]? >>> >>> Something like: >>> >>> if (x !instanceof String y) return; >> >> Not a terrible idea! Something worth considering. >> >>> I'm not sure if it would be appropriate to debate here if this should be >>> tagged onto the aims for e.g. JDK15's expanded instanceof support ( >>> Preview-2 [2] ), or if this should be its own proposal, or if this is even >>> the appropriate channel for such ideas. >> >> My inclination is not to load down pattern matching with this, and give >> us time to gather evidence about how much of a friction point it is. >> >>> [1] I'm jumping the gun a little bit on how backwards compatible this is. I >>> _think_ so, as it's a straight up syntax error right now, but before I >>> write a PoC patch to javac, I thought I'd check if the idea itself is sound >>> before delving that deep. >> >> The claim that it is a simple rewriting and introduces no ambiguities is >> credible; would have to be verified. From vicente.romero at oracle.com Fri Feb 7 22:26:30 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 07 Feb 2020 22:26:30 +0000 Subject: hg: amber/amber: fixing bug that was breaking the build Message-ID: <202002072226.017MQV5N008922@aojmv0008.oracle.com> Changeset: 1439a0462604 Author: vromero Date: 2020-02-07 17:26 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/1439a0462604 fixing bug that was breaking the build ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java From maurizio.cimadamore at oracle.com Fri Feb 7 22:30:48 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 07 Feb 2020 22:30:48 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002072230.017MUncl012012@aojmv0008.oracle.com> Changeset: e78d3c28153c Author: mcimadamore Date: 2020-02-07 22:30 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/e78d3c28153c Automatic merge with sealed-types ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java From brian.goetz at oracle.com Sat Feb 8 00:10:32 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 7 Feb 2020 19:10:32 -0500 Subject: @Language annotation for JDK 13 text blocks In-Reply-To: References: Message-ID: <7e75e5bf-8ad7-7a27-7c7d-749a2be4e63a@oracle.com> Alex has correctly pointed out that annotations on expressions are not currently supported (and in fact the original design never really considered them a serious target of opportunity, because the design center at the time was squarely "class, method, and field metadata").? This would be a major investment, and frankly, I don't see the return on it. Separately ... > Another issue would be: where/how to standardize the set of > "languages"? The IANA registry with media types doesn't contain things > like SQL (let alone all its dialects), JSP, JSX, etc. And it's not > Java SE's job to maintain such a registry either. Indeed it is not.? But, this is closely related to another problem which we care about, which is: if I am constructing (say) an SQL string, whether by concatenation or by some future interpolation feature (please, no discussion of this now, it is not on the table right now), I would like to use some sort of SQL-specific sanitizer on arguments to avoid injection attacks. As Alex mentions, in addition to nonexistent annotations on expressions, there are a few places where we can stash additional metadata, all of them ugly: ? - inside the delimiter:? String s = ""{SQL}" ...SQL content starts on next line... """; ? - on the first line after the delimiter, which currently must be blank: ??? String s = """ I AM A SQL STRING [1] ???????????????????? SELECT * from Foo"""; ? - inside the string itself, using escapes: String s = """\$blahSQLblah$ ... SQL content on next line... """;? [1] and I'm sure you can think of others, equally ugly. [1] Deliberately stupid syntax used for conceptual illustration only. > > Kind regards, Anthony > > PS: the Text Blocks JEP [1] specifies amber-dev as the mailing list > for discussion, so I took the liberty to change the mailing lists. As > I understand it, ide-support-dev is meant for IDE/tooling support when > working on the OpenJDK codebase itself > > [1] http://openjdk.java.net/jeps/368 > > On 07/02/2020 12:58, Geertjan Wielenga wrote: >> Hi all, >> >> It would be of great support for IDEs, editors, and tools of various >> kinds >> if a @Language annotation would be part of the support for text >> blocks, so >> that tooling would be able to determine which editor should be injected >> within the text block. >> >> For example, imagine this annotation on top of a text block: >> >> @Language="text/html" >> >> That would then be used by IDEs, editors, tools, etc, to determine >> that the >> text within the block is HTML and that therefore, for the tools that >> support this (e.g., NetBeans, IntelliJ IDEA), an HTML editor would >> then be >> injected within the text block, which would make HTML-oriented syntax >> coloring, code completion, etc, available within the text block. >> >> If this meets with enthusiasm, what would the next steps be? An >> addition to >> the text block spec or a new spec or something different? >> >> Thanks, >> >> Geertjan From john.r.rose at oracle.com Sat Feb 8 00:23:28 2020 From: john.r.rose at oracle.com (John Rose) Date: Fri, 7 Feb 2020 16:23:28 -0800 Subject: @Language annotation for JDK 13 text blocks In-Reply-To: <7e75e5bf-8ad7-7a27-7c7d-749a2be4e63a@oracle.com> References: <7e75e5bf-8ad7-7a27-7c7d-749a2be4e63a@oracle.com> Message-ID: On Feb 7, 2020, at 4:10 PM, Brian Goetz wrote: > > As Alex mentions, in addition to nonexistent annotations on expressions, there are a few places where we can stash additional metadata, all of them ugly: And if you pull some more on this ?string?, you can make the following additional moves: * The annotated thingy is no longer a string but an AnnotatedString with at least two properties: String value() and String annotation(). So we are no longer doing String literals. * But annotations are classes, so the annotation should be a class name, and then you get String value() and Class annotation(). And the annotation in the syntax is revealed as a class name, to be resolved and access checked. * The annotated thingy should have a stronger type, such as SQLString. In that case, you want the class name to be at the head of the syntax, not tucked away inside. It? more like a constructor call. At this point you can dip into Java?s current repertoire of syntaxes and just say that we are going to call a factory method SQLString.of(String), which returns whatever. * But wait, that?s not my nice bespoke syntax, that?s just an old-school method call! Well, OK, this is a place where we might want to add new syntax, but it?s probably a syntax that starts with a class name and continues with a string literal. Like C++ programmable string literals. * But wait, why do strings get all the fun? Where we end up is with some sort of programmable literal syntax which starts with a class name and continues with something that looks like a literal for a string, a list, a map, etc. For now, I think the sweet spot is List.of, Map.of, SQLString.of. ? John From john.r.rose at oracle.com Sat Feb 8 00:28:04 2020 From: john.r.rose at oracle.com (John Rose) Date: Fri, 7 Feb 2020 16:28:04 -0800 Subject: @Language annotation for JDK 13 text blocks In-Reply-To: References: <7e75e5bf-8ad7-7a27-7c7d-749a2be4e63a@oracle.com> Message-ID: <21EEB880-1D1E-4DC0-BAB2-9DC827B1A544@oracle.com> On Feb 7, 2020, at 4:23 PM, John Rose wrote: > > For now, I think the sweet spot is List.of, Map.of, SQLString.of. P.S. If you add some kind of a compile-time checking to SQLString.of, you can even check for potential injection weaknesses, and issue warnings or errors at javac time. In other words, doing things via methods puts you in the position of receiving more benefits when methods themselves are enhanced, with extra special treatment at compile time, link time, etc. Consider current explorations to do early binding of String.format based on the format string: Those are likely to expand into mechanisms that other types like SQLString can use, IMO. (The same point goes for any kind of ?programmable literal?: It should probably be sugar for method calls of some sort.) Doing a one-off annotation thing on expressions is a dead end by comparison. From amaembo at gmail.com Sat Feb 8 03:39:08 2020 From: amaembo at gmail.com (Tagir Valeev) Date: Sat, 8 Feb 2020 10:39:08 +0700 Subject: if (!(x instanceof String y)) syntax - better syntax? In-Reply-To: References: Message-ID: This discussion motivated me to implement a very small feature in IntelliJ IDEA: adding parentheses automatically: https://twitter.com/tagir_valeev/status/1225979390330314752 Hopefully, now this problem will be less frustrating, at least during the typing. I thought about making `instanceof` priority higher than logical complement operator priority. However, this will also make `instanceof` priority higher than binary plus, changing the semantics of this expression: System.out.println("a" + "b" instanceof String) // now prints 'true", will print "atrue" after the change However, such kind of expression is completely silly, so probably such a semantics change is acceptable. Other binary operators never accept boolean (result of instanceof) or produce reference type (argument of instanceof), so this change should not affect them. For reference, here's the proposed grammar change. 1. Exclude RelationalExpression instanceof ReferenceType from RelationalExpression productions 2. Update MultiplicativeExpression productions: MultiplicativeExpression: InstanceOfOrUnaryExpression MultiplicativeExpression * UnaryExpression MultiplicativeExpression / UnaryExpression MultiplicativeExpression % UnaryExpression 3. Add more productions: InstanceOfOrUnaryExpression: InstanceOfOrUnaryExpressionNotLogicalComplement ! InstanceOfOrUnaryExpression InstanceOfOrUnaryExpressionNotLogicalComplement: UnaryExpressionNotLogicalComplement InstanceOfOrUnaryExpressionNotLogicalComplement instanceof ReferenceType UnaryExpressionNotLogicalComplement: PreIncrementExpression PreDecrementExpression + UnaryExpression - UnaryExpression UnaryExpressionNotPlusMinusLogicalComplement UnaryExpressionNotPlusMinusLogicalComplement: PostfixExpression ~ InstanceOfOrUnaryExpression CastExpression 4. Remove UnaryExpression and UnaryExpressionNotPlusMinus productions. With best regards, Tagir Valeev. On Fri, Feb 7, 2020 at 7:53 AM Reinier Zwitserloot wrote: > > I'm not sure if now is an appropriate time (or how one should bring up > something like this), but I noticed a bit of friction in regards to this > particular style of code: > > if (!(x instanceof String y)) return; > // carry on, with y available of type Strin. > > This is a stated goal of why the instanceof patternmatch feature's rules on > where the declared 'y' variable is available ('binding variables') works as > it does. > > That's great; we've debated it at length before. > > However, the syntax of this particular construct is a bit unfortunate; I > see newbies write if (!x instanceof String) or if (x !instanceof String) > relatively often; the second one gives a straight up syntax error, but the > first is a bit more convoluted ('x is not boolean'). Even disregarding the > anecdotal evidence that those new to java fairly consistently misjudge how > to do an if-not-an-instance-of check, the correct syntax is rather > unwieldy. Maybe it's comfortable to any LISP fans in the audience, but it's > a few too many parentheses for my tastes. > > Given that a new language feature is being introduced which is catering > rather explicitly to this particular 'if not an instance of, then' style, > is there room to add a small, entirely backwards compatible syntax feature > [1]? > > Something like: > > if (x !instanceof String y) return; > > Any form of the *ReferenceType* AST node accepts this form, so also the > older form: > > boolean z = x !instanceof String; // valid. equivalent to z = !(x > instanceof String). > > I'm not sure if it would be appropriate to debate here if this should be > tagged onto the aims for e.g. JDK15's expanded instanceof support ( > Preview-2 [2] ), or if this should be its own proposal, or if this is even > the appropriate channel for such ideas. > > [1] I'm jumping the gun a little bit on how backwards compatible this is. I > _think_ so, as it's a straight up syntax error right now, but before I > write a PoC patch to javac, I thought I'd check if the idea itself is sound > before delving that deep. > [2] https://bugs.openjdk.java.net/browse/JDK-8235186 > > > --Reinier Zwitserloot From amaembo at gmail.com Sat Feb 8 03:52:49 2020 From: amaembo at gmail.com (Tagir Valeev) Date: Sat, 8 Feb 2020 10:52:49 +0700 Subject: @Language annotation for JDK 13 text blocks In-Reply-To: References: Message-ID: Hello! Here I share the IntelliJ IDEA experience without making any specific suggestions about the proposal. We have a Language annotation in JetBrains annotations pack: https://github.com/JetBrains/java-annotations/blob/89bb0eb829bf7f63b6504009e592199fae45cac9/common/src/main/java/org/intellij/lang/annotations/Language.java This accepts plain language name like "JAVA", "XML", "RegExp", "SQL", etc. The complete list is not specified and actually what is recognized depends on the installed IntelliJ IDEA plugins, so you can support new language writing a plugin. Also, the annotation has a prefix and a suffix, which are useful when we want to supply a part of the valid program. E.g. `@Language(value="JAVA", prefix="class X {", suffix="}")` allows to pass a Java method that will be properly highlighted (however, any other Java member like field will be also recognized, so it's not so easy to restrict to methods only). Usually, we annotate method parameters. In this case, call-site annotation is inferred using a sophisticated procedure. E.g. ResultSet executeQuery(@Language("SQL") String query); void foo() { String sql = "SELECT 1 FROM DUAL"; executeQuery(sql); } In this case, we detect that the `sql` variable is later passed to the method whose parameter is annotated as @Language("SQL"), so we highlight the `sql` initializer. This is complex, not very fast and hard to specify, but allows to greatly reduce the number of annotations in user code, especially when the library code is pre-annotated. We ship external annotations for standard Java library. Also, it's allowed to annotate arrays of strings (in this case every string inside the array is assumed to be annotated) and something more. With best regards, Tagir Valeev. On Sat, Feb 8, 2020 at 1:37 AM Anthony Vanelverdinghe wrote: > > [moving discussion to amber-dev] > > Hi Geertjan > > Not sure if there's been public mailing list discussions about it, but > I'm pretty sure the amber team has already considered the idea of > attaching this kind of metadata to text blocks. I don't know of any > related decisions, though. > > One issue with annotations in particular, is that text blocks can appear > in contexts where annotations can't, such as arguments to a method call, > or annotation element values (JPA's @NamedQuery comes to mind). > Another issue would be: where/how to standardize the set of "languages"? > The IANA registry with media types doesn't contain things like SQL (let > alone all its dialects), JSP, JSX, etc. And it's not Java SE's job to > maintain such a registry either. > > Kind regards, Anthony > > PS: the Text Blocks JEP [1] specifies amber-dev as the mailing list for > discussion, so I took the liberty to change the mailing lists. As I > understand it, ide-support-dev is meant for IDE/tooling support when > working on the OpenJDK codebase itself > > [1] http://openjdk.java.net/jeps/368 > > On 07/02/2020 12:58, Geertjan Wielenga wrote: > > Hi all, > > > > It would be of great support for IDEs, editors, and tools of various kinds > > if a @Language annotation would be part of the support for text blocks, so > > that tooling would be able to determine which editor should be injected > > within the text block. > > > > For example, imagine this annotation on top of a text block: > > > > @Language="text/html" > > > > That would then be used by IDEs, editors, tools, etc, to determine that the > > text within the block is HTML and that therefore, for the tools that > > support this (e.g., NetBeans, IntelliJ IDEA), an HTML editor would then be > > injected within the text block, which would make HTML-oriented syntax > > coloring, code completion, etc, available within the text block. > > > > If this meets with enthusiasm, what would the next steps be? An addition to > > the text block spec or a new spec or something different? > > > > Thanks, > > > > Geertjan From jan.lahoda at oracle.com Mon Feb 10 13:34:04 2020 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Mon, 10 Feb 2020 13:34:04 +0000 Subject: hg: amber/amber: 4 new changesets Message-ID: <202002101334.01ADY5mq006265@aojmv0008.oracle.com> Changeset: 1d70a6ddd798 Author: jlahoda Date: 2020-02-10 13:35 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/1d70a6ddd798 Simplifications for the patterns-stage-2 branch - deps.txt - src/java.base/share/classes/java/lang/runtime/PatternCarriers.java - src/java.base/share/classes/java/lang/runtime/PatternHandle.java - src/java.base/share/classes/java/lang/runtime/PatternHandles.java - src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java - test/jdk/java/lang/lang-runtime/PatternHandleTest.java - test/jdk/java/lang/lang-runtime/SwitchBootstrapsTest.java - test/jdk/java/lang/lang-runtime/boottest/TEST.properties - test/jdk/java/lang/lang-runtime/boottest/java.base/java/lang/runtime/CarrierTest.java + test/langtools/tools/javac/patterns/DeconstructionPatternErrors.java + test/langtools/tools/javac/patterns/DeconstructionPatternErrors.out ! test/langtools/tools/javac/patterns/SimpleDeconstructionPattern.java Changeset: db7c2fc8a4e7 Author: jlahoda Date: 2020-02-10 14:10 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/db7c2fc8a4e7 Merging branch patterns-stage-2 into patterns. ! deps.txt - src/java.base/share/classes/java/lang/runtime/PatternCarriers.java - src/java.base/share/classes/java/lang/runtime/PatternHandle.java - src/java.base/share/classes/java/lang/runtime/PatternHandles.java - src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - test/jdk/java/lang/lang-runtime/PatternHandleTest.java - test/jdk/java/lang/lang-runtime/SwitchBootstrapsTest.java - test/jdk/java/lang/lang-runtime/boottest/TEST.properties - test/jdk/java/lang/lang-runtime/boottest/java.base/java/lang/runtime/CarrierTest.java Changeset: 46884b6652e2 Author: jlahoda Date: 2020-02-10 14:32 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/46884b6652e2 Merging recent default branch changes into patterns-stage-2 - src/hotspot/share/gc/shared/owstTaskTerminator.cpp - src/hotspot/share/gc/shared/owstTaskTerminator.hpp - src/hotspot/share/runtime/fieldType.cpp - src/hotspot/share/runtime/fieldType.hpp - src/java.base/share/classes/java/lang/reflect/ProxyGenerator_v49.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/external/jquery/jquery.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java - test/hotspot/jtreg/runtime/7162488/Test7162488.sh - test/hotspot/jtreg/runtime/StackGap/testme.sh - test/hotspot/jtreg/runtime/StackGuardPages/testme.sh - test/hotspot/jtreg/runtime/TLS/testtls.sh - test/hotspot/jtreg/vmTestbase/jit/escape/LockCoarsening/LockCoarsening001/TestDescription.java - test/hotspot/jtreg/vmTestbase/jit/escape/LockCoarsening/LockCoarsening002/TestDescription.java - test/hotspot/jtreg/vmTestbase/jit/escape/LockCoarsening/run.sh - test/hotspot/jtreg/vmTestbase/jit/tiered/TestDescription.java - test/hotspot/jtreg/vmTestbase/jit/tiered/tieredTest.sh - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/TestDescription.java - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/maxMetaspaceSize.sh - test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfo/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfo/run.sh - test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfoOnCompilation/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfoOnCompilation/run.sh - test/jdk/jdk/jfr/event/io/EvilInstrument.java - test/jdk/jdk/jfr/event/sampling/libTestNative.c - test/langtools/jdk/javadoc/doclet/testOptions/help.html Changeset: b76d63c75770 Author: jlahoda Date: 2020-02-10 14:33 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/b76d63c75770 Merging branch patterns-stage-2 into patterns. - src/hotspot/share/gc/shared/owstTaskTerminator.cpp - src/hotspot/share/gc/shared/owstTaskTerminator.hpp - src/hotspot/share/runtime/fieldType.cpp - src/hotspot/share/runtime/fieldType.hpp - src/java.base/share/classes/java/lang/reflect/ProxyGenerator_v49.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/external/jquery/jquery.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java - test/hotspot/jtreg/runtime/7162488/Test7162488.sh - test/hotspot/jtreg/runtime/StackGap/testme.sh - test/hotspot/jtreg/runtime/StackGuardPages/testme.sh - test/hotspot/jtreg/runtime/TLS/testtls.sh - test/hotspot/jtreg/vmTestbase/jit/escape/LockCoarsening/LockCoarsening001/TestDescription.java - test/hotspot/jtreg/vmTestbase/jit/escape/LockCoarsening/LockCoarsening002/TestDescription.java - test/hotspot/jtreg/vmTestbase/jit/escape/LockCoarsening/run.sh - test/hotspot/jtreg/vmTestbase/jit/tiered/TestDescription.java - test/hotspot/jtreg/vmTestbase/jit/tiered/tieredTest.sh - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/TestDescription.java - test/hotspot/jtreg/vmTestbase/metaspace/flags/maxMetaspaceSize/maxMetaspaceSize.sh - test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfo/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfo/run.sh - test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfoOnCompilation/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfoOnCompilation/run.sh - test/jdk/jdk/jfr/event/io/EvilInstrument.java - test/jdk/jdk/jfr/event/sampling/libTestNative.c - test/langtools/jdk/javadoc/doclet/testOptions/help.html ! test/langtools/tools/javac/annotations/typeAnnotations/classfile/Patterns.java ! test/langtools/tools/javac/patterns/LocalVariableTable.java From maurizio.cimadamore at oracle.com Mon Feb 10 13:41:14 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 10 Feb 2020 13:41:14 +0000 Subject: hg: amber/amber: Automatic merge with pattern-runtime Message-ID: <202002101341.01ADfFuk011282@aojmv0008.oracle.com> Changeset: 7180e3e806c2 Author: mcimadamore Date: 2020-02-10 13:41 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/7180e3e806c2 Automatic merge with pattern-runtime From samuel.maurice.andres at gmail.com Sat Feb 8 16:45:46 2020 From: samuel.maurice.andres at gmail.com (=?UTF-8?Q?Samuel_Andr=c3=a9s?=) Date: Sat, 8 Feb 2020 17:45:46 +0100 Subject: Make records not implicitly final Message-ID: <5a9da063-ae23-d1b5-7f22-1456edbeb03e@gmail.com> Hi to all, I hope this is the correct place for comment about Records. I saw discussions about extension of records here ( https://cr.openjdk.java.net/~briangoetz/amber/datum.html ) leading to the conclusion that "we should hold this possibility in reserve". I understand the main reasons to make records implicitly final and not extensible. Nevertheless, stuctures like records could also be very usefull for modeling purposes if they would be extensible. May be the usage could lead to a compromise on this point (for example, generating default equals() / hashCode() implementations, only for explicitly final records, using all the members of the parent class hierarchy). I am not a language specialist, but I share my point of view, just in case... In any case, I think the better way "to hold [the record extension] possibility in reserve" is to make them not implicitly final, even if the final keyword should be mandatory in a first step. Then, with time, it will be possible to make the final keyword optional for records either a) to make them implicitly final, or b) to allow record inheritance. Thanks for reading. I'm sorry for my bad english. Samuel Andr?s From forax at univ-mlv.fr Mon Feb 10 20:48:43 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 10 Feb 2020 21:48:43 +0100 (CET) Subject: Make records not implicitly final In-Reply-To: <5a9da063-ae23-d1b5-7f22-1456edbeb03e@gmail.com> References: <5a9da063-ae23-d1b5-7f22-1456edbeb03e@gmail.com> Message-ID: <90624027.944521.1581367723789.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Samuel Andr?s" > ?: "amber-dev" > Envoy?: Samedi 8 F?vrier 2020 17:45:46 > Objet: Make records not implicitly final > Hi to all, > Hi Samuel, > I hope this is the correct place for comment about Records. > > I saw discussions about extension of records here ( > https://cr.openjdk.java.net/~briangoetz/amber/datum.html ) leading to > the conclusion that "we should hold this possibility in reserve". I > understand the main reasons to make records implicitly final and not > extensible. > > Nevertheless, stuctures like records could also be very useful for > modelling purposes if they would be extensible. Hum, modelling doesn't require inheritance. > May be the usage could lead to a compromise on this point (for example, generating default > equals() / hashCode() implementations, only for explicitly final > records, using all the members of the parent class hierarchy). I am not > a language specialist, but I share my point of view, just in case... We had a kind of similar discussion (you can browse the spec-expert list for more info). The idea is that you don't need inheritance to be able to specify that several "structures" share the same components, an interface is enough. So instead of abstract record Base(int age) {} final record Person(String name, int age) extends Base(age) {} you can write interface Base { int age(); } record Person(String name, int age) implements Base {} This avoid to introduce the concept of abstract record (or its dual final record) in the language which is a huge win in term of simplicity. [...] > > Thanks for reading. I'm sorry for my bad english. > > Samuel Andr?s regards, R?mi From samuel.maurice.andres at gmail.com Tue Feb 11 00:52:38 2020 From: samuel.maurice.andres at gmail.com (=?UTF-8?Q?Samuel_Andr=c3=a9s?=) Date: Tue, 11 Feb 2020 01:52:38 +0100 Subject: Make records not implicitly final In-Reply-To: <90624027.944521.1581367723789.JavaMail.zimbra@u-pem.fr> References: <5a9da063-ae23-d1b5-7f22-1456edbeb03e@gmail.com> <90624027.944521.1581367723789.JavaMail.zimbra@u-pem.fr> Message-ID: Hi R?mi, Thank you very much for answering with some explanations. I focused on implementation. But Records combined with interface hierarchy is definitely the good way to address the kind of issue I was talking about. I'm confused... oops ! Thanks a lot ! Best regards. Samuel Le 10/02/2020 ? 21:48, Remi Forax a ?crit?: > ----- Mail original ----- >> De: "Samuel Andr?s" >> ?: "amber-dev" >> Envoy?: Samedi 8 F?vrier 2020 17:45:46 >> Objet: Make records not implicitly final >> Hi to all, >> > Hi Samuel, > >> I hope this is the correct place for comment about Records. >> >> I saw discussions about extension of records here ( >> https://cr.openjdk.java.net/~briangoetz/amber/datum.html ) leading to >> the conclusion that "we should hold this possibility in reserve". I >> understand the main reasons to make records implicitly final and not >> extensible. >> >> Nevertheless, stuctures like records could also be very useful for >> modelling purposes if they would be extensible. > Hum, modelling doesn't require inheritance. > >> May be the usage could lead to a compromise on this point (for >> example, generating default >> equals() / hashCode() implementations, only for explicitly final >> records, using all the members of the parent class hierarchy). I am not >> a language specialist, but I share my point of view, just in case... > We had a kind of similar discussion (you can browse the spec-expert > list for more info). > The idea is that you don't need inheritance to be able to specify that > several "structures" share the same components, an interface is enough. > So instead of > abstract record Base(int age) {} > final record Person(String name, int age) extends Base(age) {} > > you can write > interface Base { > int age(); > } > record Person(String name, int age) implements Base {} > > This avoid to introduce the concept of abstract record (or its dual > final record) in the language which is a huge win in term of simplicity. > > [...] > >> Thanks for reading. I'm sorry for my bad english. >> >> Samuel Andr?s > regards, > R?mi From jonathan.gibbons at oracle.com Wed Feb 12 01:12:14 2020 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 12 Feb 2020 01:12:14 +0000 Subject: hg: amber/amber: fix bad merge Message-ID: <202002120112.01C1CFkD015569@aojmv0008.oracle.com> Changeset: a3bbdb1487c1 Author: jjg Date: 2020-02-11 17:09 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/a3bbdb1487c1 fix bad merge ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java From maurizio.cimadamore at oracle.com Wed Feb 12 01:16:09 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 12 Feb 2020 01:16:09 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002120116.01C1GAUV018914@aojmv0008.oracle.com> Changeset: bc6745035cb3 Author: mcimadamore Date: 2020-02-12 01:15 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/bc6745035cb3 Automatic merge with sealed-types ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java From vicente.romero at oracle.com Wed Feb 12 01:43:12 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 12 Feb 2020 01:43:12 +0000 Subject: hg: amber/amber: sync-ing the implementation with current spec Message-ID: <202002120143.01C1hCYX004361@aojmv0008.oracle.com> Changeset: a81e34480b9f Author: vromero Date: 2020-02-11 20:42 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/a81e34480b9f sync-ing the implementation with current spec ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/tools/javac/sealed/SealedCompilationTests.java ! test/langtools/tools/javac/sealed/SealedDiffConfigurationsTest.java From maurizio.cimadamore at oracle.com Wed Feb 12 01:46:03 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 12 Feb 2020 01:46:03 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002120146.01C1k3aY006616@aojmv0008.oracle.com> Changeset: b14c57e9d2af Author: mcimadamore Date: 2020-02-12 01:45 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/b14c57e9d2af Automatic merge with sealed-types ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/tools/javac/sealed/SealedCompilationTests.java ! test/langtools/tools/javac/sealed/SealedDiffConfigurationsTest.java From maurizio.cimadamore at oracle.com Thu Feb 13 19:11:24 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 13 Feb 2020 19:11:24 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002131911.01DJBP36016657@aojmv0008.oracle.com> Changeset: 3a2e3d4c8e86 Author: mcimadamore Date: 2020-02-13 19:11 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/3a2e3d4c8e86 Automatic merge with sealed-types ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java ! test/langtools/tools/javac/sealed/SealedDiffConfigurationsTest.java From vicente.romero at oracle.com Thu Feb 13 19:06:23 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 13 Feb 2020 19:06:23 +0000 Subject: hg: amber/amber: additional syncing with the latest spec Message-ID: <202002131906.01DJ6OxT010906@aojmv0008.oracle.com> Changeset: dc313d4aad10 Author: vromero Date: 2020-02-13 14:05 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/dc313d4aad10 additional syncing with the latest spec checking that there are no duplicates in the permits list checking that subtypes listed in the permits list have the sealed type as a direct supertype checking that sealed and super are in same package if in unnamed module or in same module in other case checking that type variables are not listed in the permits clause checking that a sealed type has at least one subtype ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java ! test/langtools/tools/javac/sealed/SealedDiffConfigurationsTest.java From reinier at zwitserloot.com Thu Feb 13 21:57:51 2020 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Thu, 13 Feb 2020 22:57:51 +0100 Subject: if (!(x instanceof String y)) syntax - better syntax? In-Reply-To: References: Message-ID: Did some research; this is not a bad idea! Right now, this: if (! instanceof ) {} is necessarily a compile time error. The type of ! is necessarily `boolean` (or ! itself is already a compile-time error) - even if the type of is `Boolean` (that expression itself is legal; javac will auto-unbox, making !Boolean of type boolean). And instanceof, explicitly, does not autobox. This: boolean z = true; if (z instanceof Boolean) {} does not compile (javac: types incompatible. Expected: reference, found: boolean. ecj: boolean is not compatible with Boolean). So, that hacky way to cook up an example of backwards incompatibility won't lead us to any problems, leaving Tagir's string concat example. I agree the string concat break is probably an acceptable break, given that the code is so meaningless already (insofar that it does 'break' any code, that code was likely to be buggy in the first place), but I've gone on record as having no good grasp on what core openjdk contributors consider 'unacceptably backwards incompatible' already, so perhaps I'm not the best judge on this one :) Note that this: if ("a" + "b" instanceof X) {} is a compile-time error unless X is either java.lang.String or one of its supertypes (Serializable, CharSequence, Comparable, or Object). Therefore, if it is not a compile-time error, then the whole expression necessarily resolves to 'true', though it does not count as a compile time constant. Surely this does not occur in real life java code and if it does, it's already a buggy line. I can try to contribute a patch for either form. I assume supporting both is not desired? I'm honestly not sure which version I prefer. I guess I prefer !instanceof but that is a very light precedence and I've clearly arrived at the bikeshed painting phase of syntax debate here. if (!x instanceof String) {} or if (x !instanceof String) {} assuming the string concat case can justifiably be considered as acceptable collateral damage, which one is more intuitive? --Reinier Zwitserloot On Sat, 8 Feb 2020 at 04:40, Tagir Valeev wrote: > This discussion motivated me to implement a very small feature in > IntelliJ IDEA: adding parentheses automatically: > https://twitter.com/tagir_valeev/status/1225979390330314752 > Hopefully, now this problem will be less frustrating, at least during > the typing. > > I thought about making `instanceof` priority higher than logical > complement operator priority. However, this will also make > `instanceof` priority higher than binary plus, changing the semantics > of this expression: > > System.out.println("a" + "b" instanceof String) // now prints 'true", > will print "atrue" after the change > > However, such kind of expression is completely silly, so probably such > a semantics change is acceptable. Other binary operators never accept > boolean (result of instanceof) or produce reference type (argument of > instanceof), so this change should not affect them. > > For reference, here's the proposed grammar change. > > 1. Exclude RelationalExpression instanceof ReferenceType from > RelationalExpression productions > 2. Update MultiplicativeExpression productions: > MultiplicativeExpression: > InstanceOfOrUnaryExpression > MultiplicativeExpression * UnaryExpression > MultiplicativeExpression / UnaryExpression > MultiplicativeExpression % UnaryExpression > > 3. Add more productions: > InstanceOfOrUnaryExpression: > InstanceOfOrUnaryExpressionNotLogicalComplement > ! InstanceOfOrUnaryExpression > > InstanceOfOrUnaryExpressionNotLogicalComplement: > UnaryExpressionNotLogicalComplement > InstanceOfOrUnaryExpressionNotLogicalComplement instanceof ReferenceType > > UnaryExpressionNotLogicalComplement: > PreIncrementExpression > PreDecrementExpression > + UnaryExpression > - UnaryExpression > UnaryExpressionNotPlusMinusLogicalComplement > > UnaryExpressionNotPlusMinusLogicalComplement: > PostfixExpression > ~ InstanceOfOrUnaryExpression > CastExpression > > 4. Remove UnaryExpression and UnaryExpressionNotPlusMinus productions. > > With best regards, > Tagir Valeev. > > On Fri, Feb 7, 2020 at 7:53 AM Reinier Zwitserloot > wrote: > > > > I'm not sure if now is an appropriate time (or how one should bring up > > something like this), but I noticed a bit of friction in regards to this > > particular style of code: > > > > if (!(x instanceof String y)) return; > > // carry on, with y available of type Strin. > > > > This is a stated goal of why the instanceof patternmatch feature's rules > on > > where the declared 'y' variable is available ('binding variables') works > as > > it does. > > > > That's great; we've debated it at length before. > > > > However, the syntax of this particular construct is a bit unfortunate; I > > see newbies write if (!x instanceof String) or if (x !instanceof String) > > relatively often; the second one gives a straight up syntax error, but > the > > first is a bit more convoluted ('x is not boolean'). Even disregarding > the > > anecdotal evidence that those new to java fairly consistently misjudge > how > > to do an if-not-an-instance-of check, the correct syntax is rather > > unwieldy. Maybe it's comfortable to any LISP fans in the audience, but > it's > > a few too many parentheses for my tastes. > > > > Given that a new language feature is being introduced which is catering > > rather explicitly to this particular 'if not an instance of, then' style, > > is there room to add a small, entirely backwards compatible syntax > feature > > [1]? > > > > Something like: > > > > if (x !instanceof String y) return; > > > > Any form of the *ReferenceType* AST node accepts this form, so also the > > older form: > > > > boolean z = x !instanceof String; // valid. equivalent to z = !(x > > instanceof String). > > > > I'm not sure if it would be appropriate to debate here if this should be > > tagged onto the aims for e.g. JDK15's expanded instanceof support ( > > Preview-2 [2] ), or if this should be its own proposal, or if this is > even > > the appropriate channel for such ideas. > > > > [1] I'm jumping the gun a little bit on how backwards compatible this > is. I > > _think_ so, as it's a straight up syntax error right now, but before I > > write a PoC patch to javac, I thought I'd check if the idea itself is > sound > > before delving that deep. > > [2] https://bugs.openjdk.java.net/browse/JDK-8235186 > > > > > > --Reinier Zwitserloot > From maurizio.cimadamore at oracle.com Thu Feb 13 22:05:00 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 13 Feb 2020 22:05:00 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202002132205.01DM50kt001714@aojmv0008.oracle.com> Changeset: c389ca962c0d Author: mcimadamore Date: 2020-02-13 22:04 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/c389ca962c0d Automatic merge with default - make/CopyInterimCLDRConverter.gmk ! src/java.base/share/classes/module-info.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.min.js - src/jdk.javadoc/share/legal/jszip.md - test/hotspot/jtreg/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java - test/jdk/java/net/httpclient/ssltest/bad.keystore - test/jdk/java/net/httpclient/ssltest/good.keystore - test/jdk/java/net/httpclient/ssltest/loopback.keystore From maurizio.cimadamore at oracle.com Thu Feb 13 22:05:46 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 13 Feb 2020 22:05:46 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202002132205.01DM5kuC002427@aojmv0008.oracle.com> Changeset: 4a51efe43d9a Author: mcimadamore Date: 2020-02-13 22:05 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/4a51efe43d9a Automatic merge with default - make/CopyInterimCLDRConverter.gmk ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/classFileParser.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/method.cpp ! src/java.base/share/classes/java/lang/Class.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.min.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java - src/jdk.javadoc/share/legal/jszip.md - test/hotspot/jtreg/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java - test/jdk/java/net/httpclient/ssltest/bad.keystore - test/jdk/java/net/httpclient/ssltest/good.keystore - test/jdk/java/net/httpclient/ssltest/loopback.keystore From maurizio.cimadamore at oracle.com Thu Feb 13 22:06:08 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 13 Feb 2020 22:06:08 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202002132206.01DM685u002750@aojmv0008.oracle.com> Changeset: 1f0d22fac01e Author: mcimadamore Date: 2020-02-13 22:05 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/1f0d22fac01e Automatic merge with default - make/CopyInterimCLDRConverter.gmk ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.min.js - src/jdk.javadoc/share/legal/jszip.md - test/hotspot/jtreg/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java - test/jdk/java/net/httpclient/ssltest/bad.keystore - test/jdk/java/net/httpclient/ssltest/good.keystore - test/jdk/java/net/httpclient/ssltest/loopback.keystore From maurizio.cimadamore at oracle.com Thu Feb 13 22:06:35 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 13 Feb 2020 22:06:35 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202002132206.01DM6Zh6003058@aojmv0008.oracle.com> Changeset: c4112a51f542 Author: mcimadamore Date: 2020-02-13 22:06 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/c4112a51f542 Automatic merge with default - make/CopyInterimCLDRConverter.gmk ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.min.js - src/jdk.javadoc/share/legal/jszip.md - test/hotspot/jtreg/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java - test/jdk/java/net/httpclient/ssltest/bad.keystore - test/jdk/java/net/httpclient/ssltest/good.keystore - test/jdk/java/net/httpclient/ssltest/loopback.keystore From maurizio.cimadamore at oracle.com Thu Feb 13 22:07:20 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 13 Feb 2020 22:07:20 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202002132207.01DM7KPq004031@aojmv0008.oracle.com> Changeset: 175735635b5f Author: mcimadamore Date: 2020-02-13 22:07 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/175735635b5f Automatic merge with default - make/CopyInterimCLDRConverter.gmk ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.min.js - src/jdk.javadoc/share/legal/jszip.md - test/hotspot/jtreg/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java - test/jdk/java/net/httpclient/ssltest/bad.keystore - test/jdk/java/net/httpclient/ssltest/good.keystore - test/jdk/java/net/httpclient/ssltest/loopback.keystore From maurizio.cimadamore at oracle.com Thu Feb 13 22:08:03 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 13 Feb 2020 22:08:03 +0000 Subject: hg: amber/amber: Automatic merge with patterns-stage-2 Message-ID: <202002132208.01DM83Ev004881@aojmv0008.oracle.com> Changeset: 1662ecac0932 Author: mcimadamore Date: 2020-02-13 22:07 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/1662ecac0932 Automatic merge with patterns-stage-2 ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties From maurizio.cimadamore at oracle.com Thu Feb 13 22:08:27 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 13 Feb 2020 22:08:27 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002132208.01DM8RTx005709@aojmv0008.oracle.com> Changeset: 4057f45b992a Author: mcimadamore Date: 2020-02-13 22:08 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/4057f45b992a Automatic merge with sealed-types ! .hgtags - make/CopyInterimCLDRConverter.gmk ! make/Main.gmk ! make/jdk/src/classes/build/tools/classlist/HelloClasslist.java ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/classFileParser.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp ! src/hotspot/share/gc/parallel/psCompactionManager.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psPromotionManager.cpp ! src/hotspot/share/gc/parallel/psPromotionManager.hpp ! src/hotspot/share/gc/parallel/psYoungGen.cpp ! src/hotspot/share/gc/shared/generation.cpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/include/cds.h ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/memory/filemap.cpp ! src/hotspot/share/memory/filemap.hpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vmOperations.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/Record.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/reflect/Method.java ! src/java.base/share/classes/java/util/regex/Pattern.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/conf/security/java.security ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.min.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/CommentUtils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/ParamTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java - src/jdk.javadoc/share/legal/jszip.md ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.groups - test/hotspot/jtreg/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java ! test/hotspot/jtreg/runtime/cds/appcds/CommandLineFlagComboNegative.java ! test/hotspot/jtreg/runtime/cds/appcds/JarBuilder.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/DifferentHeapSizes.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/IncompatibleOptions.java ! test/jdk/ProblemList.txt - test/jdk/java/net/httpclient/ssltest/bad.keystore - test/jdk/java/net/httpclient/ssltest/good.keystore - test/jdk/java/net/httpclient/ssltest/loopback.keystore ! test/langtools/tools/javac/records/RecordCompilationTests.java From maurizio.cimadamore at oracle.com Thu Feb 13 22:05:23 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 13 Feb 2020 22:05:23 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202002132205.01DM5O4r002121@aojmv0008.oracle.com> Changeset: f9a8545546ae Author: mcimadamore Date: 2020-02-13 22:05 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/f9a8545546ae Automatic merge with default - make/CopyInterimCLDRConverter.gmk ! src/java.base/share/classes/module-info.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.min.js - src/jdk.javadoc/share/legal/jszip.md - test/hotspot/jtreg/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java - test/jdk/java/net/httpclient/ssltest/bad.keystore - test/jdk/java/net/httpclient/ssltest/good.keystore - test/jdk/java/net/httpclient/ssltest/loopback.keystore From maurizio.cimadamore at oracle.com Thu Feb 13 22:06:57 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 13 Feb 2020 22:06:57 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <202002132206.01DM6vgH003450@aojmv0008.oracle.com> Changeset: f16f6d00cecc Author: mcimadamore Date: 2020-02-13 22:06 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/f16f6d00cecc Automatic merge with default - make/CopyInterimCLDRConverter.gmk ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.min.js - src/jdk.javadoc/share/legal/jszip.md - test/hotspot/jtreg/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java - test/jdk/java/net/httpclient/ssltest/bad.keystore - test/jdk/java/net/httpclient/ssltest/good.keystore - test/jdk/java/net/httpclient/ssltest/loopback.keystore From maurizio.cimadamore at oracle.com Thu Feb 13 22:07:43 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 13 Feb 2020 22:07:43 +0000 Subject: hg: amber/amber: Automatic merge with pattern-runtime Message-ID: <202002132207.01DM7hsg004420@aojmv0008.oracle.com> Changeset: f41821a144b2 Author: mcimadamore Date: 2020-02-13 22:07 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/f41821a144b2 Automatic merge with pattern-runtime - make/CopyInterimCLDRConverter.gmk ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.min.js - src/jdk.javadoc/share/legal/jszip.md - test/hotspot/jtreg/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java - test/jdk/java/net/httpclient/ssltest/bad.keystore - test/jdk/java/net/httpclient/ssltest/good.keystore - test/jdk/java/net/httpclient/ssltest/loopback.keystore From vicente.romero at oracle.com Thu Feb 13 23:06:59 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 13 Feb 2020 23:06:59 +0000 Subject: hg: amber/amber: fixing NPE bug that was provoking several regression tests to fail Message-ID: <202002132306.01DN6xCW007702@aojmv0008.oracle.com> Changeset: 2a8310d5265d Author: vromero Date: 2020-02-13 18:06 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/2a8310d5265d fixing NPE bug that was provoking several regression tests to fail ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java From maurizio.cimadamore at oracle.com Thu Feb 13 23:11:03 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 13 Feb 2020 23:11:03 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002132311.01DNB3DB011351@aojmv0008.oracle.com> Changeset: 2d039936dbb4 Author: mcimadamore Date: 2020-02-13 23:10 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/2d039936dbb4 Automatic merge with sealed-types ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java From amaembo at gmail.com Fri Feb 14 01:00:25 2020 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 14 Feb 2020 08:00:25 +0700 Subject: if (!(x instanceof String y)) syntax - better syntax? In-Reply-To: References: Message-ID: Please note that it's not just about a compiler patch. It requires significant rewrite of the specification and full CSR process. Also, this would be effectively a new preview feature so you would need to support parsing in old and new way, depending on the compilation options. Finally, probably some JCK tests may fail and this should be addressed as well. So I believe, it will still take a fair amount of time for Oracle folks. Not sure whether they'll agree to spend their time this way :-) With best regards, Tagir Valeev. ??, 14 ????. 2020 ?., 5:00 Reinier Zwitserloot : > Did some research; this is not a bad idea! > > Right now, this: > > if (! instanceof ) {} > > is necessarily a compile time error. The type of ! is necessarily > `boolean` (or ! itself is already a compile-time error) - even if the > type of is `Boolean` (that expression itself is legal; javac will > auto-unbox, making !Boolean of type boolean). And instanceof, explicitly, > does not autobox. This: > > boolean z = true; > if (z instanceof Boolean) {} > > does not compile (javac: types incompatible. Expected: reference, found: > boolean. ecj: boolean is not compatible with Boolean). > > So, that hacky way to cook up an example of backwards incompatibility won't > lead us to any problems, leaving Tagir's string concat example. > > I agree the string concat break is probably an acceptable break, given that > the code is so meaningless already (insofar that it does 'break' any code, > that code was likely to be buggy in the first place), but I've gone on > record as having no good grasp on what core openjdk contributors consider > 'unacceptably backwards incompatible' already, so perhaps I'm not the best > judge on this one :) > > Note that this: > > if ("a" + "b" instanceof X) {} > > is a compile-time error unless X is either java.lang.String or one of its > supertypes (Serializable, CharSequence, Comparable, or Object). Therefore, > if it is not a compile-time error, then the whole expression necessarily > resolves to 'true', though it does not count as a compile time constant. > Surely this does not occur in real life java code and if it does, it's > already a buggy line. > > I can try to contribute a patch for either form. I assume supporting both > is not desired? I'm honestly not sure which version I prefer. I guess I > prefer !instanceof but that is a very light precedence and I've clearly > arrived at the bikeshed painting phase of syntax debate here. > > if (!x instanceof String) {} > > or > > if (x !instanceof String) {} > > assuming the string concat case can justifiably be considered as acceptable > collateral damage, which one is more intuitive? > > --Reinier Zwitserloot > > > On Sat, 8 Feb 2020 at 04:40, Tagir Valeev wrote: > > > This discussion motivated me to implement a very small feature in > > IntelliJ IDEA: adding parentheses automatically: > > https://twitter.com/tagir_valeev/status/1225979390330314752 > > Hopefully, now this problem will be less frustrating, at least during > > the typing. > > > > I thought about making `instanceof` priority higher than logical > > complement operator priority. However, this will also make > > `instanceof` priority higher than binary plus, changing the semantics > > of this expression: > > > > System.out.println("a" + "b" instanceof String) // now prints 'true", > > will print "atrue" after the change > > > > However, such kind of expression is completely silly, so probably such > > a semantics change is acceptable. Other binary operators never accept > > boolean (result of instanceof) or produce reference type (argument of > > instanceof), so this change should not affect them. > > > > For reference, here's the proposed grammar change. > > > > 1. Exclude RelationalExpression instanceof ReferenceType from > > RelationalExpression productions > > 2. Update MultiplicativeExpression productions: > > MultiplicativeExpression: > > InstanceOfOrUnaryExpression > > MultiplicativeExpression * UnaryExpression > > MultiplicativeExpression / UnaryExpression > > MultiplicativeExpression % UnaryExpression > > > > 3. Add more productions: > > InstanceOfOrUnaryExpression: > > InstanceOfOrUnaryExpressionNotLogicalComplement > > ! InstanceOfOrUnaryExpression > > > > InstanceOfOrUnaryExpressionNotLogicalComplement: > > UnaryExpressionNotLogicalComplement > > InstanceOfOrUnaryExpressionNotLogicalComplement instanceof > ReferenceType > > > > UnaryExpressionNotLogicalComplement: > > PreIncrementExpression > > PreDecrementExpression > > + UnaryExpression > > - UnaryExpression > > UnaryExpressionNotPlusMinusLogicalComplement > > > > UnaryExpressionNotPlusMinusLogicalComplement: > > PostfixExpression > > ~ InstanceOfOrUnaryExpression > > CastExpression > > > > 4. Remove UnaryExpression and UnaryExpressionNotPlusMinus productions. > > > > With best regards, > > Tagir Valeev. > > > > On Fri, Feb 7, 2020 at 7:53 AM Reinier Zwitserloot > > wrote: > > > > > > I'm not sure if now is an appropriate time (or how one should bring up > > > something like this), but I noticed a bit of friction in regards to > this > > > particular style of code: > > > > > > if (!(x instanceof String y)) return; > > > // carry on, with y available of type Strin. > > > > > > This is a stated goal of why the instanceof patternmatch feature's > rules > > on > > > where the declared 'y' variable is available ('binding variables') > works > > as > > > it does. > > > > > > That's great; we've debated it at length before. > > > > > > However, the syntax of this particular construct is a bit unfortunate; > I > > > see newbies write if (!x instanceof String) or if (x !instanceof > String) > > > relatively often; the second one gives a straight up syntax error, but > > the > > > first is a bit more convoluted ('x is not boolean'). Even disregarding > > the > > > anecdotal evidence that those new to java fairly consistently misjudge > > how > > > to do an if-not-an-instance-of check, the correct syntax is rather > > > unwieldy. Maybe it's comfortable to any LISP fans in the audience, but > > it's > > > a few too many parentheses for my tastes. > > > > > > Given that a new language feature is being introduced which is catering > > > rather explicitly to this particular 'if not an instance of, then' > style, > > > is there room to add a small, entirely backwards compatible syntax > > feature > > > [1]? > > > > > > Something like: > > > > > > if (x !instanceof String y) return; > > > > > > Any form of the *ReferenceType* AST node accepts this form, so also the > > > older form: > > > > > > boolean z = x !instanceof String; // valid. equivalent to z = !(x > > > instanceof String). > > > > > > I'm not sure if it would be appropriate to debate here if this should > be > > > tagged onto the aims for e.g. JDK15's expanded instanceof support ( > > > Preview-2 [2] ), or if this should be its own proposal, or if this is > > even > > > the appropriate channel for such ideas. > > > > > > [1] I'm jumping the gun a little bit on how backwards compatible this > > is. I > > > _think_ so, as it's a straight up syntax error right now, but before I > > > write a PoC patch to javac, I thought I'd check if the idea itself is > > sound > > > before delving that deep. > > > [2] https://bugs.openjdk.java.net/browse/JDK-8235186 > > > > > > > > > --Reinier Zwitserloot > > > From vicente.romero at oracle.com Fri Feb 14 17:41:46 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 14 Feb 2020 17:41:46 +0000 Subject: hg: amber/amber: fix NPE for classes extending type variables Message-ID: <202002141741.01EHfkZp018468@aojmv0008.oracle.com> Changeset: 146827c3c8e9 Author: vromero Date: 2020-02-14 12:41 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/146827c3c8e9 fix NPE for classes extending type variables ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java From maurizio.cimadamore at oracle.com Fri Feb 14 17:46:01 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 14 Feb 2020 17:46:01 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002141746.01EHk1Zb022139@aojmv0008.oracle.com> Changeset: 0ef08b8bd812 Author: mcimadamore Date: 2020-02-14 17:45 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/0ef08b8bd812 Automatic merge with sealed-types ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java From harold.seigel at oracle.com Fri Feb 14 20:40:19 2020 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Fri, 14 Feb 2020 20:40:19 +0000 Subject: hg: amber/amber: Summary: Fix hotspot sealed types tests Message-ID: <202002142040.01EKeKO3007153@aojmv0008.oracle.com> Changeset: 575b12fbc09b Author: hseigel Date: 2020-02-14 20:39 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/575b12fbc09b Summary: Fix hotspot sealed types tests Reviewed-by: vromero ! test/hotspot/jtreg/runtime/modules/SealedModuleTest.java ! test/hotspot/jtreg/runtime/modules/sealedP1/c1.java - test/hotspot/jtreg/runtime/modules/sealedP1/superClass.java + test/hotspot/jtreg/runtime/modules/sealedP1/superClass.jcod ! test/hotspot/jtreg/runtime/modules/sealedP2/c2.java ! test/hotspot/jtreg/runtime/modules/sealedP3/c3.java ! test/hotspot/jtreg/runtime/sealedTypes/Pkg/Permitted.java - test/hotspot/jtreg/runtime/sealedTypes/Pkg/sealedInterface.java + test/hotspot/jtreg/runtime/sealedTypes/Pkg/sealedInterface.jcod ! test/hotspot/jtreg/runtime/sealedTypes/RedefineSealedType.java ! test/hotspot/jtreg/runtime/sealedTypes/SealedUnnamedModuleIntfTest.java ! test/hotspot/jtreg/runtime/sealedTypes/SealedUnnamedModuleTest.java ! test/hotspot/jtreg/runtime/sealedTypes/abstractSealedTest.java ! test/hotspot/jtreg/runtime/sealedTypes/asteroids/Pluto.java ! test/hotspot/jtreg/runtime/sealedTypes/getPermittedSubtypesTest.java ! test/hotspot/jtreg/runtime/sealedTypes/otherPkg/wrongPackage.java ! test/hotspot/jtreg/runtime/sealedTypes/overrideSealedTest.java ! test/hotspot/jtreg/runtime/sealedTypes/planets/Neptune.java - test/hotspot/jtreg/runtime/sealedTypes/planets/outerPlanets.java + test/hotspot/jtreg/runtime/sealedTypes/planets/outerPlanets.jcod ! test/hotspot/jtreg/runtime/sealedTypes/sealedTest.java From maurizio.cimadamore at oracle.com Fri Feb 14 20:46:03 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 14 Feb 2020 20:46:03 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002142046.01EKk3G1012869@aojmv0008.oracle.com> Changeset: 9d08b2857f6f Author: mcimadamore Date: 2020-02-14 20:45 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/9d08b2857f6f Automatic merge with sealed-types ! test/hotspot/jtreg/runtime/modules/SealedModuleTest.java ! test/hotspot/jtreg/runtime/modules/sealedP1/c1.java - test/hotspot/jtreg/runtime/modules/sealedP1/superClass.java ! test/hotspot/jtreg/runtime/modules/sealedP2/c2.java ! test/hotspot/jtreg/runtime/modules/sealedP3/c3.java ! test/hotspot/jtreg/runtime/sealedTypes/Pkg/Permitted.java - test/hotspot/jtreg/runtime/sealedTypes/Pkg/sealedInterface.java ! test/hotspot/jtreg/runtime/sealedTypes/SealedUnnamedModuleIntfTest.java ! test/hotspot/jtreg/runtime/sealedTypes/SealedUnnamedModuleTest.java ! test/hotspot/jtreg/runtime/sealedTypes/abstractSealedTest.java ! test/hotspot/jtreg/runtime/sealedTypes/asteroids/Pluto.java ! test/hotspot/jtreg/runtime/sealedTypes/getPermittedSubtypesTest.java ! test/hotspot/jtreg/runtime/sealedTypes/otherPkg/wrongPackage.java ! test/hotspot/jtreg/runtime/sealedTypes/overrideSealedTest.java ! test/hotspot/jtreg/runtime/sealedTypes/planets/Neptune.java - test/hotspot/jtreg/runtime/sealedTypes/planets/outerPlanets.java ! test/hotspot/jtreg/runtime/sealedTypes/sealedTest.java From vicente.romero at oracle.com Fri Feb 14 21:11:54 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 14 Feb 2020 21:11:54 +0000 Subject: hg: amber/amber: fix for test ListModuleDeps Message-ID: <202002142111.01ELBt37029138@aojmv0008.oracle.com> Changeset: 1843d6037b1b Author: vromero Date: 2020-02-14 16:11 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/1843d6037b1b fix for test ListModuleDeps ! test/langtools/tools/jdeps/listdeps/ListModuleDeps.java From maurizio.cimadamore at oracle.com Fri Feb 14 21:16:06 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 14 Feb 2020 21:16:06 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002142116.01ELG6As002458@aojmv0008.oracle.com> Changeset: 29385ffa3eb0 Author: mcimadamore Date: 2020-02-14 21:15 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/29385ffa3eb0 Automatic merge with sealed-types ! test/langtools/tools/jdeps/listdeps/ListModuleDeps.java From maurizio.cimadamore at oracle.com Fri Feb 14 22:21:04 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 14 Feb 2020 22:21:04 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002142221.01EML45g009044@aojmv0008.oracle.com> Changeset: 380a4051d443 Author: mcimadamore Date: 2020-02-14 22:20 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/380a4051d443 Automatic merge with sealed-types ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/tools/javac/diags/examples/CantInheritFromSealed.java From vicente.romero at oracle.com Fri Feb 14 22:17:41 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 14 Feb 2020 22:17:41 +0000 Subject: hg: amber/amber: refactoring: removing outdated code, adding diagnostics Message-ID: <202002142217.01EMHfZE007238@aojmv0008.oracle.com> Changeset: 15489d82799e Author: vromero Date: 2020-02-14 17:17 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/15489d82799e refactoring: removing outdated code, adding diagnostics ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/tools/javac/diags/examples/CantInheritFromSealed.java + test/langtools/tools/javac/diags/examples/DuplicateTypeInPermits.java + test/langtools/tools/javac/diags/examples/NonSealedWithNoSealedSuper.java + test/langtools/tools/javac/diags/examples/PermitsInNoSealedClass.java + test/langtools/tools/javac/diags/examples/SealedMustHaveSubtypes.java + test/langtools/tools/javac/diags/examples/SubtypeDoesntExtendSealed.java + test/langtools/tools/javac/diags/examples/TypeVarInPermits.java From jonathan.gibbons at oracle.com Sat Feb 15 00:24:22 2020 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 15 Feb 2020 00:24:22 +0000 Subject: hg: amber/amber: javadoc: update handling of "not exhaustive" permits list Message-ID: <202002150024.01F0ONC3014822@aojmv0008.oracle.com> Changeset: 61dc64ca3023 Author: jjg Date: 2020-02-14 16:23 -0800 URL: https://hg.openjdk.java.net/amber/amber/rev/61dc64ca3023 javadoc: update handling of "not exhaustive" permits list ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! test/langtools/jdk/javadoc/doclet/testSealedTypes/TestSealedTypes.java From maurizio.cimadamore at oracle.com Sat Feb 15 01:20:45 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Sat, 15 Feb 2020 01:20:45 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002150120.01F1Kkgb014225@aojmv0008.oracle.com> Changeset: 020b43d344aa Author: mcimadamore Date: 2020-02-15 01:20 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/020b43d344aa Automatic merge with sealed-types ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! test/langtools/jdk/javadoc/doclet/testSealedTypes/TestSealedTypes.java From brian.goetz at oracle.com Sat Feb 15 19:13:50 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 15 Feb 2020 14:13:50 -0500 Subject: if (!(x instanceof String y)) syntax - better syntax? In-Reply-To: References: Message-ID: <6f733515-274b-eff2-4fb2-6c19a19d486a@oracle.com> > I can try to contribute a patch for either form. I assume supporting both > is not desired? I'm honestly not sure which version I prefer. I guess I > prefer !instanceof but that is a very light precedence and I've clearly > arrived at the bikeshed painting phase of syntax debate here. > > if (!x instanceof String) {} > > or > > if (x !instanceof String) {} > > The latter form is far preferable; with the prefix notation, there is an ambiguity of how much the unary operator "eats", whereas in the latter, `!instanceof` just becomes a new binary operator. All that said, while perfectly defensible, it is not clear whether it is justified as an alternative to !(x instanceof P).? So let's leave it on the shelf for a while and see how we feel about it after we can see how much of an issue it is in real code? From nlisker at gmail.com Mon Feb 17 15:03:49 2020 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 17 Feb 2020 17:03:49 +0200 Subject: Retrofitting classes as records in the JDK Message-ID: Hi, Is there a discussion somewhere about which existing classes in the JDK are planned to become records? As an OpenJFX contributor, I'd like to get a head start and see how we can utilize records correctly. Seeing how the JDK does it is the best approach in my opinion. - Nir From brian.goetz at oracle.com Mon Feb 17 18:20:12 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 17 Feb 2020 13:20:12 -0500 Subject: Retrofitting classes as records in the JDK In-Reply-To: References: Message-ID: <9a2c3b3a-20cd-c3b2-08a0-f26110b4eaf8@oracle.com> So, it will be very easy to get the wrong idea from what the JDK will eventually do here.? It is pretty likely that the JDK will not expose very many records at all, but instead is more likely to use them in implementations. Where we've landed with records makes them more suitable for _internal_ abstractions and implementation details than public API abstractions if the API has to meet a high compatibility bar.? The reason is that evolving them in significant ways -- such as adding, removing, changing, or reordering components, or migrating them from a record to an ordinary class -- has compatibility consequences that are probably more than the JDK would be willing to take (though other libraries will surely feel differently.) (Bear in mind that the JDK is surely the only library in the world that has this high a bar for compatibility expectations, so what is a problem for us is not a problem for the rest of the ecosystem.? For example, it is impossible to refactor an enum or record to a class with 100% compatibility -- because of the restricted Enum and Record superclasses.? This is a blocker for the JDK, but for just about the entire rest of the ecosystem, is often not a problem in practice, because the 99% you can get is generally good enough for them.) Where we expect to use records in the JDK is in streamlining implementations, and maybe as far as private implementations of public interfaces (e.g., Map.Entry).? But I wouldn't expect a lot of public records. On 2/17/2020 10:03 AM, Nir Lisker wrote: > Hi, > > Is there a discussion somewhere about which existing classes in the JDK are > planned to become records? As an OpenJFX contributor, I'd like to get a > head start and see how we can utilize records correctly. Seeing how the JDK > does it is the best approach in my opinion. > > - Nir From nlisker at gmail.com Mon Feb 17 23:17:48 2020 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 18 Feb 2020 01:17:48 +0200 Subject: Retrofitting classes as records in the JDK In-Reply-To: <9a2c3b3a-20cd-c3b2-08a0-f26110b4eaf8@oracle.com> References: <9a2c3b3a-20cd-c3b2-08a0-f26110b4eaf8@oracle.com> Message-ID: > > Bear in mind that the JDK is surely the only library in the world that has > this high a bar for compatibility expectations >From my past work on OpenJFX, we have the same backwards compatibility obligations (or at least very close). Where we've landed with records makes them more suitable for _internal_ abstractions and implementation details than public API abstractions if the API has to meet a high compatibility bar. I agree. This is mostly what I would be looking at. Where we expect to use records in the JDK is in streamlining > implementations, and maybe as far as private implementations of public > interfaces (e.g., Map.Entry). I take it that these migrations are only at the abstract discussion level then? I'm interested in a more concrete list of places where migration would happen. What list/issue should I be monitoring? On Mon, Feb 17, 2020 at 8:20 PM Brian Goetz wrote: > So, it will be very easy to get the wrong idea from what the JDK will > eventually do here. It is pretty likely that the JDK will not expose very > many records at all, but instead is more likely to use them in > implementations. > > Where we've landed with records makes them more suitable for _internal_ > abstractions and implementation details than public API abstractions if the > API has to meet a high compatibility bar. The reason is that evolving them > in significant ways -- such as adding, removing, changing, or reordering > components, or migrating them from a record to an ordinary class -- has > compatibility consequences that are probably more than the JDK would be > willing to take (though other libraries will surely feel differently.) > > (Bear in mind that the JDK is surely the only library in the world that > has this high a bar for compatibility expectations, so what is a problem > for us is not a problem for the rest of the ecosystem. For example, it is > impossible to refactor an enum or record to a class with 100% compatibility > -- because of the restricted Enum and Record superclasses. This is a > blocker for the JDK, but for just about the entire rest of the ecosystem, > is often not a problem in practice, because the 99% you can get is > generally good enough for them.) > > Where we expect to use records in the JDK is in streamlining > implementations, and maybe as far as private implementations of public > interfaces (e.g., Map.Entry). But I wouldn't expect a lot of public > records. > > > > On 2/17/2020 10:03 AM, Nir Lisker wrote: > > Hi, > > Is there a discussion somewhere about which existing classes in the JDK are > planned to become records? As an OpenJFX contributor, I'd like to get a > head start and see how we can utilize records correctly. Seeing how the JDK > does it is the best approach in my opinion. > > - Nir > > > From forax at univ-mlv.fr Tue Feb 18 14:49:49 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 18 Feb 2020 15:49:49 +0100 (CET) Subject: Retrofitting classes as records in the JDK In-Reply-To: References: <9a2c3b3a-20cd-c3b2-08a0-f26110b4eaf8@oracle.com> Message-ID: <584818508.802116.1582037389797.JavaMail.zimbra@u-pem.fr> Here is a small script [0] using ASM that tries to find classes that can be retrofitted to be records. A potential record is a non-visible class (non public or public but non in an exported package) that have only final fields and have methods that looks like accessors (the logic is fuzzy, it looks for variation of "return this.foo" with possible operations in between). Given that record is a preview feature, there is no point to try to convert those classes now, but in the future why not, it will make those classes more readable. One fun thing (at least for me) is that the class "ConstantDynamic", "Handle" and "TypeReference" of ASM (that are vendorized/shaded in the package jdk/internal/org/objectweb/asm) can be converted to record. But again, it will take time given that the source code of ASM is compatible with Java 8. cheers, R?mi [0] https://github.com/forax/amber-record/blob/master/src/main/java/fr.umlv.record.recordfinder/fr/umlv/record/recordfinder/RecordFinder.java On java.base, you get sun/util/logging/PlatformLogger sun/util/locale/LocaleExtensions sun/security/x509/AVA sun/security/x509/CertificatePolicySet sun/security/x509/GeneralNames sun/security/x509/GeneralSubtrees sun/security/util/ConstraintsParameters sun/security/ssl/SecureKey sun/security/ssl/SessionId sun/security/internal/spec/TlsKeyMaterialSpec sun/security/internal/spec/TlsMasterSecretParameterSpec sun/security/internal/spec/TlsPrfParameterSpec sun/reflect/generics/tree/ArrayTypeSignature sun/reflect/generics/tree/ClassSignature sun/reflect/generics/tree/ClassTypeSignature sun/reflect/generics/tree/FormalTypeParameter sun/reflect/generics/tree/MethodTypeSignature sun/reflect/generics/tree/SimpleClassTypeSignature sun/reflect/generics/tree/TypeVariableSignature sun/reflect/generics/reflectiveObjects/GenericArrayTypeImpl sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl sun/reflect/generics/factory/CoreReflectionFactory sun/reflect/annotation/AnnotationType sun/reflect/annotation/TypeAnnotation sun/nio/ch/NativeSocketAddress sun/nio/ch/ThreadPool jdk/internal/org/objectweb/asm/ConstantDynamic jdk/internal/org/objectweb/asm/Handle jdk/internal/org/objectweb/asm/TypeReference jdk/internal/org/objectweb/asm/tree/analysis/BasicValue jdk/internal/org/objectweb/asm/tree/analysis/SourceValue jdk/internal/org/objectweb/asm/commons/Method jdk/internal/module/IllegalAccessMaps jdk/internal/module/ModuleHashes jdk/internal/module/ModulePatcher jdk/internal/module/ModuleResolution jdk/internal/module/ModuleTarget jdk/internal/loader/LoaderPool jdk/internal/jrtfs/JrtFileAttributes jdk/internal/jimage/ImageHeader jdk/internal/jimage/decompressor/CompressedResourceHeader java/util/KeyValueHolder java/time/chrono/ChronoLocalDateTimeImpl java/time/chrono/ChronoZonedDateTimeImpl java/net/UrlDeserializedState java/lang/NamedPackage java/lang/invoke/InfoFromMemberName java/lang/invoke/LambdaFormEditor java/lang/constant/DirectMethodHandleDescImpl java/lang/constant/MethodTypeDescImpl java/lang/constant/ReferenceClassDescImpl ----- Mail original ----- > De: "Nir Lisker" > ?: "Brian Goetz" > Cc: "amber-dev" > Envoy?: Mardi 18 F?vrier 2020 00:17:48 > Objet: Re: Retrofitting classes as records in the JDK >> >> Bear in mind that the JDK is surely the only library in the world that has >> this high a bar for compatibility expectations > > > From my past work on OpenJFX, we have the same backwards compatibility > obligations (or at least very close). > > Where we've landed with records makes them more suitable for _internal_ > abstractions and implementation details than public API abstractions if the > API has to meet a high compatibility bar. > > > I agree. This is mostly what I would be looking at. > > Where we expect to use records in the JDK is in streamlining >> implementations, and maybe as far as private implementations of public >> interfaces (e.g., Map.Entry). > > > I take it that these migrations are only at the abstract discussion level > then? I'm interested in a more concrete list of places where migration > would happen. What list/issue should I be monitoring? > > On Mon, Feb 17, 2020 at 8:20 PM Brian Goetz wrote: > >> So, it will be very easy to get the wrong idea from what the JDK will >> eventually do here. It is pretty likely that the JDK will not expose very >> many records at all, but instead is more likely to use them in >> implementations. >> >> Where we've landed with records makes them more suitable for _internal_ >> abstractions and implementation details than public API abstractions if the >> API has to meet a high compatibility bar. The reason is that evolving them >> in significant ways -- such as adding, removing, changing, or reordering >> components, or migrating them from a record to an ordinary class -- has >> compatibility consequences that are probably more than the JDK would be >> willing to take (though other libraries will surely feel differently.) >> >> (Bear in mind that the JDK is surely the only library in the world that >> has this high a bar for compatibility expectations, so what is a problem >> for us is not a problem for the rest of the ecosystem. For example, it is >> impossible to refactor an enum or record to a class with 100% compatibility >> -- because of the restricted Enum and Record superclasses. This is a >> blocker for the JDK, but for just about the entire rest of the ecosystem, >> is often not a problem in practice, because the 99% you can get is >> generally good enough for them.) >> >> Where we expect to use records in the JDK is in streamlining >> implementations, and maybe as far as private implementations of public >> interfaces (e.g., Map.Entry). But I wouldn't expect a lot of public >> records. >> >> >> >> On 2/17/2020 10:03 AM, Nir Lisker wrote: >> >> Hi, >> >> Is there a discussion somewhere about which existing classes in the JDK are >> planned to become records? As an OpenJFX contributor, I'd like to get a >> head start and see how we can utilize records correctly. Seeing how the JDK >> does it is the best approach in my opinion. >> >> - Nir >> >> From nlisker at gmail.com Tue Feb 18 15:33:21 2020 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 18 Feb 2020 17:33:21 +0200 Subject: Retrofitting classes as records in the JDK In-Reply-To: <584818508.802116.1582037389797.JavaMail.zimbra@u-pem.fr> References: <9a2c3b3a-20cd-c3b2-08a0-f26110b4eaf8@oracle.com> <584818508.802116.1582037389797.JavaMail.zimbra@u-pem.fr> Message-ID: > > Given that record is a preview feature, there is no point to try to > convert those classes now, but in the future why not, it will make those > classes more readable. Yeah, OpenJFX N maintains backwards compatibility with JDK N-1, so we have some time until we do the conversion. I want to get a head start on this large task and test preview records while at it. The script is a nice idea, I'll try it. Thanks! On Tue, Feb 18, 2020 at 4:57 PM Remi Forax wrote: > Here is a small script [0] using ASM that tries to find classes that can > be retrofitted to be records. > A potential record is a non-visible class (non public or public but non in > an exported package) that have only final fields and have methods that > looks like accessors (the logic is fuzzy, it looks for variation of "return > this.foo" with possible operations in between). > > Given that record is a preview feature, there is no point to try to > convert those classes now, but in the future why not, it will make those > classes more readable. > > One fun thing (at least for me) is that the class "ConstantDynamic", > "Handle" and "TypeReference" of ASM (that are vendorized/shaded in the > package jdk/internal/org/objectweb/asm) can be converted to record. > But again, it will take time given that the source code of ASM is > compatible with Java 8. > > cheers, > R?mi > > [0] > https://github.com/forax/amber-record/blob/master/src/main/java/fr.umlv.record.recordfinder/fr/umlv/record/recordfinder/RecordFinder.java > > On java.base, you get > sun/util/logging/PlatformLogger > sun/util/locale/LocaleExtensions > sun/security/x509/AVA > sun/security/x509/CertificatePolicySet > sun/security/x509/GeneralNames > sun/security/x509/GeneralSubtrees > sun/security/util/ConstraintsParameters > sun/security/ssl/SecureKey > sun/security/ssl/SessionId > sun/security/internal/spec/TlsKeyMaterialSpec > sun/security/internal/spec/TlsMasterSecretParameterSpec > sun/security/internal/spec/TlsPrfParameterSpec > sun/reflect/generics/tree/ArrayTypeSignature > sun/reflect/generics/tree/ClassSignature > sun/reflect/generics/tree/ClassTypeSignature > sun/reflect/generics/tree/FormalTypeParameter > sun/reflect/generics/tree/MethodTypeSignature > sun/reflect/generics/tree/SimpleClassTypeSignature > sun/reflect/generics/tree/TypeVariableSignature > sun/reflect/generics/reflectiveObjects/GenericArrayTypeImpl > sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl > sun/reflect/generics/factory/CoreReflectionFactory > sun/reflect/annotation/AnnotationType > sun/reflect/annotation/TypeAnnotation > sun/nio/ch/NativeSocketAddress > sun/nio/ch/ThreadPool > jdk/internal/org/objectweb/asm/ConstantDynamic > jdk/internal/org/objectweb/asm/Handle > jdk/internal/org/objectweb/asm/TypeReference > jdk/internal/org/objectweb/asm/tree/analysis/BasicValue > jdk/internal/org/objectweb/asm/tree/analysis/SourceValue > jdk/internal/org/objectweb/asm/commons/Method > jdk/internal/module/IllegalAccessMaps > jdk/internal/module/ModuleHashes > jdk/internal/module/ModulePatcher > jdk/internal/module/ModuleResolution > jdk/internal/module/ModuleTarget > jdk/internal/loader/LoaderPool > jdk/internal/jrtfs/JrtFileAttributes > jdk/internal/jimage/ImageHeader > jdk/internal/jimage/decompressor/CompressedResourceHeader > java/util/KeyValueHolder > java/time/chrono/ChronoLocalDateTimeImpl > java/time/chrono/ChronoZonedDateTimeImpl > java/net/UrlDeserializedState > java/lang/NamedPackage > java/lang/invoke/InfoFromMemberName > java/lang/invoke/LambdaFormEditor > java/lang/constant/DirectMethodHandleDescImpl > java/lang/constant/MethodTypeDescImpl > java/lang/constant/ReferenceClassDescImpl > > > ----- Mail original ----- > > De: "Nir Lisker" > > ?: "Brian Goetz" > > Cc: "amber-dev" > > Envoy?: Mardi 18 F?vrier 2020 00:17:48 > > Objet: Re: Retrofitting classes as records in the JDK > > >> > >> Bear in mind that the JDK is surely the only library in the world that > has > >> this high a bar for compatibility expectations > > > > > > From my past work on OpenJFX, we have the same backwards compatibility > > obligations (or at least very close). > > > > Where we've landed with records makes them more suitable for _internal_ > > abstractions and implementation details than public API abstractions if > the > > API has to meet a high compatibility bar. > > > > > > I agree. This is mostly what I would be looking at. > > > > Where we expect to use records in the JDK is in streamlining > >> implementations, and maybe as far as private implementations of public > >> interfaces (e.g., Map.Entry). > > > > > > I take it that these migrations are only at the abstract discussion level > > then? I'm interested in a more concrete list of places where migration > > would happen. What list/issue should I be monitoring? > > > > On Mon, Feb 17, 2020 at 8:20 PM Brian Goetz > wrote: > > > >> So, it will be very easy to get the wrong idea from what the JDK will > >> eventually do here. It is pretty likely that the JDK will not expose > very > >> many records at all, but instead is more likely to use them in > >> implementations. > >> > >> Where we've landed with records makes them more suitable for _internal_ > >> abstractions and implementation details than public API abstractions if > the > >> API has to meet a high compatibility bar. The reason is that evolving > them > >> in significant ways -- such as adding, removing, changing, or reordering > >> components, or migrating them from a record to an ordinary class -- has > >> compatibility consequences that are probably more than the JDK would be > >> willing to take (though other libraries will surely feel differently.) > >> > >> (Bear in mind that the JDK is surely the only library in the world that > >> has this high a bar for compatibility expectations, so what is a problem > >> for us is not a problem for the rest of the ecosystem. For example, it > is > >> impossible to refactor an enum or record to a class with 100% > compatibility > >> -- because of the restricted Enum and Record superclasses. This is a > >> blocker for the JDK, but for just about the entire rest of the > ecosystem, > >> is often not a problem in practice, because the 99% you can get is > >> generally good enough for them.) > >> > >> Where we expect to use records in the JDK is in streamlining > >> implementations, and maybe as far as private implementations of public > >> interfaces (e.g., Map.Entry). But I wouldn't expect a lot of public > >> records. > >> > >> > >> > >> On 2/17/2020 10:03 AM, Nir Lisker wrote: > >> > >> Hi, > >> > >> Is there a discussion somewhere about which existing classes in the JDK > are > >> planned to become records? As an OpenJFX contributor, I'd like to get a > >> head start and see how we can utilize records correctly. Seeing how the > JDK > >> does it is the best approach in my opinion. > >> > >> - Nir > >> > >> > From amaembo at gmail.com Tue Feb 18 15:45:18 2020 From: amaembo at gmail.com (Tagir Valeev) Date: Tue, 18 Feb 2020 22:45:18 +0700 Subject: Retrofitting classes as records in the JDK In-Reply-To: <9a2c3b3a-20cd-c3b2-08a0-f26110b4eaf8@oracle.com> References: <9a2c3b3a-20cd-c3b2-08a0-f26110b4eaf8@oracle.com> Message-ID: > Where we expect to use records in the JDK is in streamlining > implementations, and maybe as far as private implementations of public > interfaces (e.g., Map.Entry). But I wouldn't expect a lot of public > records. Speaking specifically about Map.Entry, records are not ideal fit there. Taking aside weird component names like Entry(K getKey, V getValue), one should redefine hashCode because its contract is specified for the Map.Entry and it differs from record hashCode contract. Also, setValue should be defined. By the way, it would be nice to have a default implementation for setValue throwing UnsupportedOperationException, similar to Iterator.remove. WDYT? In general, I agree: records are totally great for local/private/package-private usages, and I see dozens of places in IntelliJ IDEA sources where they could be used. However, I'm not sure there are many places where they could be exposed as an API. With best regards, Tagir Valeev. On Tue, Feb 18, 2020 at 1:20 AM Brian Goetz wrote: > > So, it will be very easy to get the wrong idea from what the JDK will > eventually do here. It is pretty likely that the JDK will not expose > very many records at all, but instead is more likely to use them in > implementations. > > Where we've landed with records makes them more suitable for _internal_ > abstractions and implementation details than public API abstractions if > the API has to meet a high compatibility bar. The reason is that > evolving them in significant ways -- such as adding, removing, changing, > or reordering components, or migrating them from a record to an ordinary > class -- has compatibility consequences that are probably more than the > JDK would be willing to take (though other libraries will surely feel > differently.) > > (Bear in mind that the JDK is surely the only library in the world that > has this high a bar for compatibility expectations, so what is a problem > for us is not a problem for the rest of the ecosystem. For example, it > is impossible to refactor an enum or record to a class with 100% > compatibility -- because of the restricted Enum and Record > superclasses. This is a blocker for the JDK, but for just about the > entire rest of the ecosystem, is often not a problem in practice, > because the 99% you can get is generally good enough for them.) > > > > > On 2/17/2020 10:03 AM, Nir Lisker wrote: > > Hi, > > > > Is there a discussion somewhere about which existing classes in the JDK are > > planned to become records? As an OpenJFX contributor, I'd like to get a > > head start and see how we can utilize records correctly. Seeing how the JDK > > does it is the best approach in my opinion. > > > > - Nir > From brian.goetz at oracle.com Tue Feb 18 15:50:40 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 18 Feb 2020 10:50:40 -0500 Subject: Retrofitting classes as records in the JDK In-Reply-To: <584818508.802116.1582037389797.JavaMail.zimbra@u-pem.fr> References: <9a2c3b3a-20cd-c3b2-08a0-f26110b4eaf8@oracle.com> <584818508.802116.1582037389797.JavaMail.zimbra@u-pem.fr> Message-ID: <525a6292-c240-8f6c-bdf8-60cd42b14c95@oracle.com> On 2/18/2020 9:49 AM, Remi Forax wrote: > Given that record is a preview feature, there is no point to try to convert those classes now, but in the future why not, it will make those classes more readable. I disagree completely!? Now is the time to _explore_ converting these classes, so if you run into something we didn't plan for, you can provided feedback in time for us to actually do something about it.? You may not want to _ship_ these, but now is the ideal time to be trying it out, and reporting back feedback. From nlisker at gmail.com Tue Feb 18 16:05:32 2020 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 18 Feb 2020 18:05:32 +0200 Subject: Retrofitting classes as records in the JDK In-Reply-To: References: <9a2c3b3a-20cd-c3b2-08a0-f26110b4eaf8@oracle.com> <584818508.802116.1582037389797.JavaMail.zimbra@u-pem.fr> Message-ID: I took a quick look at sun.util.logging.PlatformLogger to start with. The class does not declare an accessor for its field 'PlatformLogger.Bridge loggerProxy', so it seems like records are not suitable here. However, this brings up a question: can the visibility of an accessor method be changed or the method removed? Looking at the specs I found [1], it seems that the answer is no, but it's not that clear to me: 8.10.3 Record Members > A record type R has the following members: > An implicitly declared public accessor method with the same name as the > record component, whose return type is the declared type of the record > component, unless a public method with the same signature is explicitly > declared in the body of the declaration of R. So if a non-public method with the same signature is explicitly declared, is it a compile time error? Compile time error is only mentioned in: It is a compile-time error if an explicitly declared accessor method has a > throws clause. [1] http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191031/specs/records-jls.html#jls-8.10.3 On Tue, Feb 18, 2020 at 5:33 PM Nir Lisker wrote: > Given that record is a preview feature, there is no point to try to >> convert those classes now, but in the future why not, it will make those >> classes more readable. > > > Yeah, OpenJFX N maintains backwards compatibility with JDK N-1, so we have > some time until we do the conversion. I want to get a head start on this > large task and test preview records while at it. > > The script is a nice idea, I'll try it. Thanks! > > On Tue, Feb 18, 2020 at 4:57 PM Remi Forax wrote: > >> Here is a small script [0] using ASM that tries to find classes that can >> be retrofitted to be records. >> A potential record is a non-visible class (non public or public but non >> in an exported package) that have only final fields and have methods that >> looks like accessors (the logic is fuzzy, it looks for variation of "return >> this.foo" with possible operations in between). >> >> Given that record is a preview feature, there is no point to try to >> convert those classes now, but in the future why not, it will make those >> classes more readable. >> >> One fun thing (at least for me) is that the class "ConstantDynamic", >> "Handle" and "TypeReference" of ASM (that are vendorized/shaded in the >> package jdk/internal/org/objectweb/asm) can be converted to record. >> But again, it will take time given that the source code of ASM is >> compatible with Java 8. >> >> cheers, >> R?mi >> >> [0] >> https://github.com/forax/amber-record/blob/master/src/main/java/fr.umlv.record.recordfinder/fr/umlv/record/recordfinder/RecordFinder.java >> >> On java.base, you get >> sun/util/logging/PlatformLogger >> sun/util/locale/LocaleExtensions >> sun/security/x509/AVA >> sun/security/x509/CertificatePolicySet >> sun/security/x509/GeneralNames >> sun/security/x509/GeneralSubtrees >> sun/security/util/ConstraintsParameters >> sun/security/ssl/SecureKey >> sun/security/ssl/SessionId >> sun/security/internal/spec/TlsKeyMaterialSpec >> sun/security/internal/spec/TlsMasterSecretParameterSpec >> sun/security/internal/spec/TlsPrfParameterSpec >> sun/reflect/generics/tree/ArrayTypeSignature >> sun/reflect/generics/tree/ClassSignature >> sun/reflect/generics/tree/ClassTypeSignature >> sun/reflect/generics/tree/FormalTypeParameter >> sun/reflect/generics/tree/MethodTypeSignature >> sun/reflect/generics/tree/SimpleClassTypeSignature >> sun/reflect/generics/tree/TypeVariableSignature >> sun/reflect/generics/reflectiveObjects/GenericArrayTypeImpl >> sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl >> sun/reflect/generics/factory/CoreReflectionFactory >> sun/reflect/annotation/AnnotationType >> sun/reflect/annotation/TypeAnnotation >> sun/nio/ch/NativeSocketAddress >> sun/nio/ch/ThreadPool >> jdk/internal/org/objectweb/asm/ConstantDynamic >> jdk/internal/org/objectweb/asm/Handle >> jdk/internal/org/objectweb/asm/TypeReference >> jdk/internal/org/objectweb/asm/tree/analysis/BasicValue >> jdk/internal/org/objectweb/asm/tree/analysis/SourceValue >> jdk/internal/org/objectweb/asm/commons/Method >> jdk/internal/module/IllegalAccessMaps >> jdk/internal/module/ModuleHashes >> jdk/internal/module/ModulePatcher >> jdk/internal/module/ModuleResolution >> jdk/internal/module/ModuleTarget >> jdk/internal/loader/LoaderPool >> jdk/internal/jrtfs/JrtFileAttributes >> jdk/internal/jimage/ImageHeader >> jdk/internal/jimage/decompressor/CompressedResourceHeader >> java/util/KeyValueHolder >> java/time/chrono/ChronoLocalDateTimeImpl >> java/time/chrono/ChronoZonedDateTimeImpl >> java/net/UrlDeserializedState >> java/lang/NamedPackage >> java/lang/invoke/InfoFromMemberName >> java/lang/invoke/LambdaFormEditor >> java/lang/constant/DirectMethodHandleDescImpl >> java/lang/constant/MethodTypeDescImpl >> java/lang/constant/ReferenceClassDescImpl >> >> >> ----- Mail original ----- >> > De: "Nir Lisker" >> > ?: "Brian Goetz" >> > Cc: "amber-dev" >> > Envoy?: Mardi 18 F?vrier 2020 00:17:48 >> > Objet: Re: Retrofitting classes as records in the JDK >> >> >> >> >> Bear in mind that the JDK is surely the only library in the world that >> has >> >> this high a bar for compatibility expectations >> > >> > >> > From my past work on OpenJFX, we have the same backwards compatibility >> > obligations (or at least very close). >> > >> > Where we've landed with records makes them more suitable for _internal_ >> > abstractions and implementation details than public API abstractions if >> the >> > API has to meet a high compatibility bar. >> > >> > >> > I agree. This is mostly what I would be looking at. >> > >> > Where we expect to use records in the JDK is in streamlining >> >> implementations, and maybe as far as private implementations of public >> >> interfaces (e.g., Map.Entry). >> > >> > >> > I take it that these migrations are only at the abstract discussion >> level >> > then? I'm interested in a more concrete list of places where migration >> > would happen. What list/issue should I be monitoring? >> > >> > On Mon, Feb 17, 2020 at 8:20 PM Brian Goetz >> wrote: >> > >> >> So, it will be very easy to get the wrong idea from what the JDK will >> >> eventually do here. It is pretty likely that the JDK will not expose >> very >> >> many records at all, but instead is more likely to use them in >> >> implementations. >> >> >> >> Where we've landed with records makes them more suitable for _internal_ >> >> abstractions and implementation details than public API abstractions >> if the >> >> API has to meet a high compatibility bar. The reason is that evolving >> them >> >> in significant ways -- such as adding, removing, changing, or >> reordering >> >> components, or migrating them from a record to an ordinary class -- has >> >> compatibility consequences that are probably more than the JDK would be >> >> willing to take (though other libraries will surely feel differently.) >> >> >> >> (Bear in mind that the JDK is surely the only library in the world that >> >> has this high a bar for compatibility expectations, so what is a >> problem >> >> for us is not a problem for the rest of the ecosystem. For example, >> it is >> >> impossible to refactor an enum or record to a class with 100% >> compatibility >> >> -- because of the restricted Enum and Record superclasses. This is a >> >> blocker for the JDK, but for just about the entire rest of the >> ecosystem, >> >> is often not a problem in practice, because the 99% you can get is >> >> generally good enough for them.) >> >> >> >> Where we expect to use records in the JDK is in streamlining >> >> implementations, and maybe as far as private implementations of public >> >> interfaces (e.g., Map.Entry). But I wouldn't expect a lot of public >> >> records. >> >> >> >> >> >> >> >> On 2/17/2020 10:03 AM, Nir Lisker wrote: >> >> >> >> Hi, >> >> >> >> Is there a discussion somewhere about which existing classes in the >> JDK are >> >> planned to become records? As an OpenJFX contributor, I'd like to get a >> >> head start and see how we can utilize records correctly. Seeing how >> the JDK >> >> does it is the best approach in my opinion. >> >> >> >> - Nir >> >> >> >> >> > From nlisker at gmail.com Tue Feb 18 16:13:34 2020 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 18 Feb 2020 18:13:34 +0200 Subject: Retrofitting classes as records in the JDK In-Reply-To: References: <9a2c3b3a-20cd-c3b2-08a0-f26110b4eaf8@oracle.com> <584818508.802116.1582037389797.JavaMail.zimbra@u-pem.fr> Message-ID: By the way, looking at the rules for the constructors, it seems that explicitly declaring the (implicitly public) canonical constructor with a different visibility modifier is allowed (8.10.4). On Tue, Feb 18, 2020 at 6:05 PM Nir Lisker wrote: > I took a quick look at sun.util.logging.PlatformLogger to start with. The > class does not declare an accessor for its field 'PlatformLogger.Bridge > loggerProxy', so it seems like records are not suitable here. > However, this brings up a question: can the visibility of an accessor > method be changed or the method removed? Looking at the specs I found [1], > it seems that the answer is no, but it's not that clear to me: > > 8.10.3 Record Members >> A record type R has the following members: >> An implicitly declared public accessor method with the same name as the >> record component, whose return type is the declared type of the record >> component, unless a public method with the same signature is explicitly >> declared in the body of the declaration of R. > > > So if a non-public method with the same signature is explicitly declared, > is it a compile time error? Compile time error is only mentioned in: > > It is a compile-time error if an explicitly declared accessor method has a >> throws clause. > > > [1] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191031/specs/records-jls.html#jls-8.10.3 > > On Tue, Feb 18, 2020 at 5:33 PM Nir Lisker wrote: > >> Given that record is a preview feature, there is no point to try to >>> convert those classes now, but in the future why not, it will make those >>> classes more readable. >> >> >> Yeah, OpenJFX N maintains backwards compatibility with JDK N-1, so we >> have some time until we do the conversion. I want to get a head start on >> this large task and test preview records while at it. >> >> The script is a nice idea, I'll try it. Thanks! >> >> On Tue, Feb 18, 2020 at 4:57 PM Remi Forax wrote: >> >>> Here is a small script [0] using ASM that tries to find classes that can >>> be retrofitted to be records. >>> A potential record is a non-visible class (non public or public but non >>> in an exported package) that have only final fields and have methods that >>> looks like accessors (the logic is fuzzy, it looks for variation of "return >>> this.foo" with possible operations in between). >>> >>> Given that record is a preview feature, there is no point to try to >>> convert those classes now, but in the future why not, it will make those >>> classes more readable. >>> >>> One fun thing (at least for me) is that the class "ConstantDynamic", >>> "Handle" and "TypeReference" of ASM (that are vendorized/shaded in the >>> package jdk/internal/org/objectweb/asm) can be converted to record. >>> But again, it will take time given that the source code of ASM is >>> compatible with Java 8. >>> >>> cheers, >>> R?mi >>> >>> [0] >>> https://github.com/forax/amber-record/blob/master/src/main/java/fr.umlv.record.recordfinder/fr/umlv/record/recordfinder/RecordFinder.java >>> >>> On java.base, you get >>> sun/util/logging/PlatformLogger >>> sun/util/locale/LocaleExtensions >>> sun/security/x509/AVA >>> sun/security/x509/CertificatePolicySet >>> sun/security/x509/GeneralNames >>> sun/security/x509/GeneralSubtrees >>> sun/security/util/ConstraintsParameters >>> sun/security/ssl/SecureKey >>> sun/security/ssl/SessionId >>> sun/security/internal/spec/TlsKeyMaterialSpec >>> sun/security/internal/spec/TlsMasterSecretParameterSpec >>> sun/security/internal/spec/TlsPrfParameterSpec >>> sun/reflect/generics/tree/ArrayTypeSignature >>> sun/reflect/generics/tree/ClassSignature >>> sun/reflect/generics/tree/ClassTypeSignature >>> sun/reflect/generics/tree/FormalTypeParameter >>> sun/reflect/generics/tree/MethodTypeSignature >>> sun/reflect/generics/tree/SimpleClassTypeSignature >>> sun/reflect/generics/tree/TypeVariableSignature >>> sun/reflect/generics/reflectiveObjects/GenericArrayTypeImpl >>> sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl >>> sun/reflect/generics/factory/CoreReflectionFactory >>> sun/reflect/annotation/AnnotationType >>> sun/reflect/annotation/TypeAnnotation >>> sun/nio/ch/NativeSocketAddress >>> sun/nio/ch/ThreadPool >>> jdk/internal/org/objectweb/asm/ConstantDynamic >>> jdk/internal/org/objectweb/asm/Handle >>> jdk/internal/org/objectweb/asm/TypeReference >>> jdk/internal/org/objectweb/asm/tree/analysis/BasicValue >>> jdk/internal/org/objectweb/asm/tree/analysis/SourceValue >>> jdk/internal/org/objectweb/asm/commons/Method >>> jdk/internal/module/IllegalAccessMaps >>> jdk/internal/module/ModuleHashes >>> jdk/internal/module/ModulePatcher >>> jdk/internal/module/ModuleResolution >>> jdk/internal/module/ModuleTarget >>> jdk/internal/loader/LoaderPool >>> jdk/internal/jrtfs/JrtFileAttributes >>> jdk/internal/jimage/ImageHeader >>> jdk/internal/jimage/decompressor/CompressedResourceHeader >>> java/util/KeyValueHolder >>> java/time/chrono/ChronoLocalDateTimeImpl >>> java/time/chrono/ChronoZonedDateTimeImpl >>> java/net/UrlDeserializedState >>> java/lang/NamedPackage >>> java/lang/invoke/InfoFromMemberName >>> java/lang/invoke/LambdaFormEditor >>> java/lang/constant/DirectMethodHandleDescImpl >>> java/lang/constant/MethodTypeDescImpl >>> java/lang/constant/ReferenceClassDescImpl >>> >>> >>> ----- Mail original ----- >>> > De: "Nir Lisker" >>> > ?: "Brian Goetz" >>> > Cc: "amber-dev" >>> > Envoy?: Mardi 18 F?vrier 2020 00:17:48 >>> > Objet: Re: Retrofitting classes as records in the JDK >>> >>> >> >>> >> Bear in mind that the JDK is surely the only library in the world >>> that has >>> >> this high a bar for compatibility expectations >>> > >>> > >>> > From my past work on OpenJFX, we have the same backwards compatibility >>> > obligations (or at least very close). >>> > >>> > Where we've landed with records makes them more suitable for _internal_ >>> > abstractions and implementation details than public API abstractions >>> if the >>> > API has to meet a high compatibility bar. >>> > >>> > >>> > I agree. This is mostly what I would be looking at. >>> > >>> > Where we expect to use records in the JDK is in streamlining >>> >> implementations, and maybe as far as private implementations of public >>> >> interfaces (e.g., Map.Entry). >>> > >>> > >>> > I take it that these migrations are only at the abstract discussion >>> level >>> > then? I'm interested in a more concrete list of places where migration >>> > would happen. What list/issue should I be monitoring? >>> > >>> > On Mon, Feb 17, 2020 at 8:20 PM Brian Goetz >>> wrote: >>> > >>> >> So, it will be very easy to get the wrong idea from what the JDK will >>> >> eventually do here. It is pretty likely that the JDK will not expose >>> very >>> >> many records at all, but instead is more likely to use them in >>> >> implementations. >>> >> >>> >> Where we've landed with records makes them more suitable for >>> _internal_ >>> >> abstractions and implementation details than public API abstractions >>> if the >>> >> API has to meet a high compatibility bar. The reason is that >>> evolving them >>> >> in significant ways -- such as adding, removing, changing, or >>> reordering >>> >> components, or migrating them from a record to an ordinary class -- >>> has >>> >> compatibility consequences that are probably more than the JDK would >>> be >>> >> willing to take (though other libraries will surely feel differently.) >>> >> >>> >> (Bear in mind that the JDK is surely the only library in the world >>> that >>> >> has this high a bar for compatibility expectations, so what is a >>> problem >>> >> for us is not a problem for the rest of the ecosystem. For example, >>> it is >>> >> impossible to refactor an enum or record to a class with 100% >>> compatibility >>> >> -- because of the restricted Enum and Record superclasses. This is a >>> >> blocker for the JDK, but for just about the entire rest of the >>> ecosystem, >>> >> is often not a problem in practice, because the 99% you can get is >>> >> generally good enough for them.) >>> >> >>> >> Where we expect to use records in the JDK is in streamlining >>> >> implementations, and maybe as far as private implementations of public >>> >> interfaces (e.g., Map.Entry). But I wouldn't expect a lot of public >>> >> records. >>> >> >>> >> >>> >> >>> >> On 2/17/2020 10:03 AM, Nir Lisker wrote: >>> >> >>> >> Hi, >>> >> >>> >> Is there a discussion somewhere about which existing classes in the >>> JDK are >>> >> planned to become records? As an OpenJFX contributor, I'd like to get >>> a >>> >> head start and see how we can utilize records correctly. Seeing how >>> the JDK >>> >> does it is the best approach in my opinion. >>> >> >>> >> - Nir >>> >> >>> >> >>> >> From nlisker at gmail.com Tue Feb 18 17:37:37 2020 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 18 Feb 2020 19:37:37 +0200 Subject: Retrofitting classes as records in the JDK In-Reply-To: References: <9a2c3b3a-20cd-c3b2-08a0-f26110b4eaf8@oracle.com> Message-ID: > > By the way, it would be nice to have a default implementation for setValue > throwing UnsupportedOperationException, similar to Iterator.remove. WDYT? > That could work if backwards compatibility allows it. I took a quick look and found about 6 implementing classes that throw UOE. On Tue, Feb 18, 2020 at 5:45 PM Tagir Valeev wrote: > > Where we expect to use records in the JDK is in streamlining > > implementations, and maybe as far as private implementations of public > > interfaces (e.g., Map.Entry). But I wouldn't expect a lot of public > > records. > > Speaking specifically about Map.Entry, records are not ideal fit > there. Taking aside weird component names like Entry(K getKey, V > getValue), one should redefine hashCode because its contract is > specified for the Map.Entry and it differs from record hashCode > contract. Also, setValue should be defined. By the way, it would be > nice to have a default implementation for setValue throwing > UnsupportedOperationException, similar to Iterator.remove. WDYT? > > In general, I agree: records are totally great for > local/private/package-private usages, and I see dozens of places in > IntelliJ IDEA sources where they could be used. However, I'm not sure > there are many places where they could be exposed as an API. > > With best regards, > Tagir Valeev. > > > > On Tue, Feb 18, 2020 at 1:20 AM Brian Goetz > wrote: > > > > So, it will be very easy to get the wrong idea from what the JDK will > > eventually do here. It is pretty likely that the JDK will not expose > > very many records at all, but instead is more likely to use them in > > implementations. > > > > Where we've landed with records makes them more suitable for _internal_ > > abstractions and implementation details than public API abstractions if > > the API has to meet a high compatibility bar. The reason is that > > evolving them in significant ways -- such as adding, removing, changing, > > or reordering components, or migrating them from a record to an ordinary > > class -- has compatibility consequences that are probably more than the > > JDK would be willing to take (though other libraries will surely feel > > differently.) > > > > (Bear in mind that the JDK is surely the only library in the world that > > has this high a bar for compatibility expectations, so what is a problem > > for us is not a problem for the rest of the ecosystem. For example, it > > is impossible to refactor an enum or record to a class with 100% > > compatibility -- because of the restricted Enum and Record > > superclasses. This is a blocker for the JDK, but for just about the > > entire rest of the ecosystem, is often not a problem in practice, > > because the 99% you can get is generally good enough for them.) > > > > > > > > > > On 2/17/2020 10:03 AM, Nir Lisker wrote: > > > Hi, > > > > > > Is there a discussion somewhere about which existing classes in the > JDK are > > > planned to become records? As an OpenJFX contributor, I'd like to get a > > > head start and see how we can utilize records correctly. Seeing how > the JDK > > > does it is the best approach in my opinion. > > > > > > - Nir > > > From harold.seigel at oracle.com Tue Feb 18 18:01:07 2020 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 18 Feb 2020 18:01:07 +0000 Subject: hg: amber/amber: Summary: Fix sealed types class redefinition test Message-ID: <202002181801.01II17ND008647@aojmv0008.oracle.com> Changeset: 55985ba51fa8 Author: hseigel Date: 2020-02-18 18:00 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/55985ba51fa8 Summary: Fix sealed types class redefinition test Reviewed-by: vromero ! test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/HostA/Host.java ! test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/HostA/redef/Host.java ! test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/HostAB/Host.java ! test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/HostAB/redef/Host.java ! test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/HostABC/Host.java ! test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/HostABC/redef/Host.java ! test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/HostABCD/redef/Host.java ! test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/HostABD/redef/Host.java ! test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/HostAC/redef/Host.java ! test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/HostACB/redef/Host.java ! test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/HostB/redef/Host.java ! test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/HostBA/redef/Host.java ! test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/HostBAC/redef/Host.java ! test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/HostBCA/redef/Host.java ! test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/HostCAB/redef/Host.java ! test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/HostCBA/redef/Host.java ! test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/TestPermittedSubtypesAttr.java + test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/classFour.java + test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/classOne.java + test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/classThree.java + test/jdk/java/lang/instrument/RedefinePermittedSubtypesAttr/classTwo.java From maurizio.cimadamore at oracle.com Tue Feb 18 18:06:10 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 18 Feb 2020 18:06:10 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002181806.01II6AG4011198@aojmv0008.oracle.com> Changeset: 40865a85217a Author: mcimadamore Date: 2020-02-18 18:05 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/40865a85217a Automatic merge with sealed-types From naokikishida at gmail.com Thu Feb 20 07:48:00 2020 From: naokikishida at gmail.com (kishida naoki) Date: Thu, 20 Feb 2020 16:48:00 +0900 Subject: Is 'record' a restricted type name since 13, right? Message-ID: On JDK 14.ea.36, Using 'record' as a type name with '--enable-preview' produces a message as below. But I can't find any specification to restrict 'record' on the JLS 13. Is the message true, or where can I find the description? ``` $ jshell --enable-preview | Welcome to JShell -- Version 14 | For an introduction type: /help intro jshell> class record{} | Error: | 'record' not allowed here | as of release 13, 'record' is a restricted type name and cannot be used for type declarations | class record{} | ^ ``` -- Naoki Kishida From alex.buckley at oracle.com Thu Feb 20 17:59:36 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 20 Feb 2020 09:59:36 -0800 Subject: Is 'record' a restricted type name since 13, right? In-Reply-To: References: Message-ID: <4daf5818-8bfd-4fea-c07c-bdac74f88aa3@oracle.com> The jshell error message is wrong -- it should say "as of release 14". Java SE 13 / JLS13 had no notion of records. Alex On 2/19/2020 11:48 PM, kishida naoki wrote: > On JDK 14.ea.36, Using 'record' as a type name with '--enable-preview' > produces a message as below. > But I can't find any specification to restrict 'record' on the JLS 13. > Is the message true, or where can I find the description? > > ``` > $ jshell --enable-preview > | Welcome to JShell -- Version 14 > | For an introduction type: /help intro > > jshell> class record{} > | Error: > | 'record' not allowed here > | as of release 13, 'record' is a restricted type name and cannot be > used for type declarations > | class record{} > | ^ > ``` > From maurizio.cimadamore at oracle.com Mon Feb 24 22:21:30 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 24 Feb 2020 22:21:30 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002242221.01OMLVJs007449@aojmv0008.oracle.com> Changeset: 965b8b804f43 Author: mcimadamore Date: 2020-02-24 22:21 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/965b8b804f43 Automatic merge with sealed-types ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/langtools/tools/javac/diags/examples/CantInheritFromSealed.java From vicente.romero at oracle.com Mon Feb 24 22:15:31 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 24 Feb 2020 22:15:31 +0000 Subject: hg: amber/amber: adding more diags examples Message-ID: <202002242215.01OMFVo0004534@aojmv0008.oracle.com> Changeset: dc8ed953f851 Author: vromero Date: 2020-02-24 17:14 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/dc8ed953f851 adding more diags examples ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/langtools/tools/javac/diags/examples/CantInheritFromSealed.java ! test/langtools/tools/javac/diags/examples/DuplicateTypeInPermits.java + test/langtools/tools/javac/diags/examples/LocalCantInheritFromSealed.java ! test/langtools/tools/javac/diags/examples/NonSealedWithNoSealedSuper.java ! test/langtools/tools/javac/diags/examples/PermitsInNoSealedClass.java ! test/langtools/tools/javac/diags/examples/SealedMustHaveSubtypes.java + test/langtools/tools/javac/diags/examples/SealedNotAllowedInLocalClass.java + test/langtools/tools/javac/diags/examples/SealedTypes.java ! test/langtools/tools/javac/diags/examples/SubtypeDoesntExtendSealed.java ! test/langtools/tools/javac/diags/examples/TypeVarInPermits.java From nlisker at gmail.com Tue Feb 25 12:47:33 2020 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 25 Feb 2020 14:47:33 +0200 Subject: Retrofitting classes as records in the JDK In-Reply-To: References: <9a2c3b3a-20cd-c3b2-08a0-f26110b4eaf8@oracle.com> <584818508.802116.1582037389797.JavaMail.zimbra@u-pem.fr> Message-ID: Was this missed? I could not find the answers still. On Tue, Feb 18, 2020 at 6:05 PM Nir Lisker wrote: > I took a quick look at sun.util.logging.PlatformLogger to start with. The > class does not declare an accessor for its field 'PlatformLogger.Bridge > loggerProxy', so it seems like records are not suitable here. > However, this brings up a question: can the visibility of an accessor > method be changed or the method removed? Looking at the specs I found [1], > it seems that the answer is no, but it's not that clear to me: > > 8.10.3 Record Members >> A record type R has the following members: >> An implicitly declared public accessor method with the same name as the >> record component, whose return type is the declared type of the record >> component, unless a public method with the same signature is explicitly >> declared in the body of the declaration of R. > > > So if a non-public method with the same signature is explicitly declared, > is it a compile time error? Compile time error is only mentioned in: > > It is a compile-time error if an explicitly declared accessor method has a >> throws clause. > > > [1] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191031/specs/records-jls.html#jls-8.10.3 > > On Tue, Feb 18, 2020 at 5:33 PM Nir Lisker wrote: > >> Given that record is a preview feature, there is no point to try to >>> convert those classes now, but in the future why not, it will make those >>> classes more readable. >> >> >> Yeah, OpenJFX N maintains backwards compatibility with JDK N-1, so we >> have some time until we do the conversion. I want to get a head start on >> this large task and test preview records while at it. >> >> The script is a nice idea, I'll try it. Thanks! >> >> On Tue, Feb 18, 2020 at 4:57 PM Remi Forax wrote: >> >>> Here is a small script [0] using ASM that tries to find classes that can >>> be retrofitted to be records. >>> A potential record is a non-visible class (non public or public but non >>> in an exported package) that have only final fields and have methods that >>> looks like accessors (the logic is fuzzy, it looks for variation of "return >>> this.foo" with possible operations in between). >>> >>> Given that record is a preview feature, there is no point to try to >>> convert those classes now, but in the future why not, it will make those >>> classes more readable. >>> >>> One fun thing (at least for me) is that the class "ConstantDynamic", >>> "Handle" and "TypeReference" of ASM (that are vendorized/shaded in the >>> package jdk/internal/org/objectweb/asm) can be converted to record. >>> But again, it will take time given that the source code of ASM is >>> compatible with Java 8. >>> >>> cheers, >>> R?mi >>> >>> [0] >>> https://github.com/forax/amber-record/blob/master/src/main/java/fr.umlv.record.recordfinder/fr/umlv/record/recordfinder/RecordFinder.java >>> >>> On java.base, you get >>> sun/util/logging/PlatformLogger >>> sun/util/locale/LocaleExtensions >>> sun/security/x509/AVA >>> sun/security/x509/CertificatePolicySet >>> sun/security/x509/GeneralNames >>> sun/security/x509/GeneralSubtrees >>> sun/security/util/ConstraintsParameters >>> sun/security/ssl/SecureKey >>> sun/security/ssl/SessionId >>> sun/security/internal/spec/TlsKeyMaterialSpec >>> sun/security/internal/spec/TlsMasterSecretParameterSpec >>> sun/security/internal/spec/TlsPrfParameterSpec >>> sun/reflect/generics/tree/ArrayTypeSignature >>> sun/reflect/generics/tree/ClassSignature >>> sun/reflect/generics/tree/ClassTypeSignature >>> sun/reflect/generics/tree/FormalTypeParameter >>> sun/reflect/generics/tree/MethodTypeSignature >>> sun/reflect/generics/tree/SimpleClassTypeSignature >>> sun/reflect/generics/tree/TypeVariableSignature >>> sun/reflect/generics/reflectiveObjects/GenericArrayTypeImpl >>> sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl >>> sun/reflect/generics/factory/CoreReflectionFactory >>> sun/reflect/annotation/AnnotationType >>> sun/reflect/annotation/TypeAnnotation >>> sun/nio/ch/NativeSocketAddress >>> sun/nio/ch/ThreadPool >>> jdk/internal/org/objectweb/asm/ConstantDynamic >>> jdk/internal/org/objectweb/asm/Handle >>> jdk/internal/org/objectweb/asm/TypeReference >>> jdk/internal/org/objectweb/asm/tree/analysis/BasicValue >>> jdk/internal/org/objectweb/asm/tree/analysis/SourceValue >>> jdk/internal/org/objectweb/asm/commons/Method >>> jdk/internal/module/IllegalAccessMaps >>> jdk/internal/module/ModuleHashes >>> jdk/internal/module/ModulePatcher >>> jdk/internal/module/ModuleResolution >>> jdk/internal/module/ModuleTarget >>> jdk/internal/loader/LoaderPool >>> jdk/internal/jrtfs/JrtFileAttributes >>> jdk/internal/jimage/ImageHeader >>> jdk/internal/jimage/decompressor/CompressedResourceHeader >>> java/util/KeyValueHolder >>> java/time/chrono/ChronoLocalDateTimeImpl >>> java/time/chrono/ChronoZonedDateTimeImpl >>> java/net/UrlDeserializedState >>> java/lang/NamedPackage >>> java/lang/invoke/InfoFromMemberName >>> java/lang/invoke/LambdaFormEditor >>> java/lang/constant/DirectMethodHandleDescImpl >>> java/lang/constant/MethodTypeDescImpl >>> java/lang/constant/ReferenceClassDescImpl >>> >>> >>> ----- Mail original ----- >>> > De: "Nir Lisker" >>> > ?: "Brian Goetz" >>> > Cc: "amber-dev" >>> > Envoy?: Mardi 18 F?vrier 2020 00:17:48 >>> > Objet: Re: Retrofitting classes as records in the JDK >>> >>> >> >>> >> Bear in mind that the JDK is surely the only library in the world >>> that has >>> >> this high a bar for compatibility expectations >>> > >>> > >>> > From my past work on OpenJFX, we have the same backwards compatibility >>> > obligations (or at least very close). >>> > >>> > Where we've landed with records makes them more suitable for _internal_ >>> > abstractions and implementation details than public API abstractions >>> if the >>> > API has to meet a high compatibility bar. >>> > >>> > >>> > I agree. This is mostly what I would be looking at. >>> > >>> > Where we expect to use records in the JDK is in streamlining >>> >> implementations, and maybe as far as private implementations of public >>> >> interfaces (e.g., Map.Entry). >>> > >>> > >>> > I take it that these migrations are only at the abstract discussion >>> level >>> > then? I'm interested in a more concrete list of places where migration >>> > would happen. What list/issue should I be monitoring? >>> > >>> > On Mon, Feb 17, 2020 at 8:20 PM Brian Goetz >>> wrote: >>> > >>> >> So, it will be very easy to get the wrong idea from what the JDK will >>> >> eventually do here. It is pretty likely that the JDK will not expose >>> very >>> >> many records at all, but instead is more likely to use them in >>> >> implementations. >>> >> >>> >> Where we've landed with records makes them more suitable for >>> _internal_ >>> >> abstractions and implementation details than public API abstractions >>> if the >>> >> API has to meet a high compatibility bar. The reason is that >>> evolving them >>> >> in significant ways -- such as adding, removing, changing, or >>> reordering >>> >> components, or migrating them from a record to an ordinary class -- >>> has >>> >> compatibility consequences that are probably more than the JDK would >>> be >>> >> willing to take (though other libraries will surely feel differently.) >>> >> >>> >> (Bear in mind that the JDK is surely the only library in the world >>> that >>> >> has this high a bar for compatibility expectations, so what is a >>> problem >>> >> for us is not a problem for the rest of the ecosystem. For example, >>> it is >>> >> impossible to refactor an enum or record to a class with 100% >>> compatibility >>> >> -- because of the restricted Enum and Record superclasses. This is a >>> >> blocker for the JDK, but for just about the entire rest of the >>> ecosystem, >>> >> is often not a problem in practice, because the 99% you can get is >>> >> generally good enough for them.) >>> >> >>> >> Where we expect to use records in the JDK is in streamlining >>> >> implementations, and maybe as far as private implementations of public >>> >> interfaces (e.g., Map.Entry). But I wouldn't expect a lot of public >>> >> records. >>> >> >>> >> >>> >> >>> >> On 2/17/2020 10:03 AM, Nir Lisker wrote: >>> >> >>> >> Hi, >>> >> >>> >> Is there a discussion somewhere about which existing classes in the >>> JDK are >>> >> planned to become records? As an OpenJFX contributor, I'd like to get >>> a >>> >> head start and see how we can utilize records correctly. Seeing how >>> the JDK >>> >> does it is the best approach in my opinion. >>> >> >>> >> - Nir >>> >> >>> >> >>> >> From brian.goetz at oracle.com Tue Feb 25 14:24:23 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 25 Feb 2020 09:24:23 -0500 Subject: Retrofitting classes as records in the JDK In-Reply-To: References: <9a2c3b3a-20cd-c3b2-08a0-f26110b4eaf8@oracle.com> <584818508.802116.1582037389797.JavaMail.zimbra@u-pem.fr> Message-ID: > However, this brings up a question: can the visibility?of an accessor > method be changed or the method removed? Looking at the specs I found > [1], it seems that the answer is no, but it's not that clear to me: The method cannot be removed.? Under the current spec, it _must_ be public.? Under the spec current in revision, the rule will be relaxed that it has the same accessibility as the class, but can be made _more_ accessible, but not less.? It is part of the API; removing it / hiding it would violate this. You can implement it to through UOE, but in that case, you should question whether you should be using records in the first place. From vicente.romero at oracle.com Wed Feb 26 00:55:40 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 26 Feb 2020 00:55:40 +0000 Subject: hg: amber/amber: making enums with subclasses sealed Message-ID: <202002260055.01Q0tevk027615@aojmv0008.oracle.com> Changeset: 335223833edc Author: vromero Date: 2020-02-25 19:23 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/335223833edc making enums with subclasses sealed ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java From maurizio.cimadamore at oracle.com Wed Feb 26 01:01:02 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 26 Feb 2020 01:01:02 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002260101.01Q113qx002405@aojmv0008.oracle.com> Changeset: 01e18578f527 Author: mcimadamore Date: 2020-02-26 01:00 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/01e18578f527 Automatic merge with sealed-types ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java From vicente.romero at oracle.com Thu Feb 27 04:59:54 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 27 Feb 2020 04:59:54 +0000 Subject: hg: amber/amber: issue an error if a type in the permits list refers to declaring class or a supertype Message-ID: <202002270459.01R4xsEw003054@aojmv0008.oracle.com> Changeset: 0988d6372138 Author: vromero Date: 2020-02-26 23:48 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/0988d6372138 issue an error if a type in the permits list refers to declaring class or a supertype ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java From maurizio.cimadamore at oracle.com Thu Feb 27 05:05:52 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 27 Feb 2020 05:05:52 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002270505.01R55r0E005404@aojmv0008.oracle.com> Changeset: 749031d7910f Author: mcimadamore Date: 2020-02-27 05:05 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/749031d7910f Automatic merge with sealed-types ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java From vicente.romero at oracle.com Thu Feb 27 18:51:07 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 27 Feb 2020 18:51:07 +0000 Subject: hg: amber/amber: adding regression tests Message-ID: <202002271851.01RIp7NO013544@aojmv0008.oracle.com> Changeset: 02506a5c9735 Author: vromero Date: 2020-02-27 13:49 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/02506a5c9735 adding regression tests + test/langtools/tools/javac/diags/examples/PermitsCantListDeclaringClass.java + test/langtools/tools/javac/diags/examples/PermitsCantListSuperType.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java From maurizio.cimadamore at oracle.com Thu Feb 27 18:55:51 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 27 Feb 2020 18:55:51 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002271855.01RItq9f019792@aojmv0008.oracle.com> Changeset: 6458f95494be Author: mcimadamore Date: 2020-02-27 18:55 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/6458f95494be Automatic merge with sealed-types ! test/langtools/tools/javac/sealed/SealedCompilationTests.java From vicente.romero at oracle.com Fri Feb 28 03:58:50 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 28 Feb 2020 03:58:50 +0000 Subject: hg: amber/amber: refactoring: relocating checks to attribution phase Message-ID: <202002280358.01S3wpCr002122@aojmv0008.oracle.com> Changeset: f358ec606422 Author: vromero Date: 2020-02-27 22:56 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/f358ec606422 refactoring: relocating checks to attribution phase ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java From maurizio.cimadamore at oracle.com Fri Feb 28 04:00:55 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 28 Feb 2020 04:00:55 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002280400.01S40t2X003526@aojmv0008.oracle.com> Changeset: 67525d425cf7 Author: mcimadamore Date: 2020-02-28 04:00 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/67525d425cf7 Automatic merge with sealed-types ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java From vicente.romero at oracle.com Fri Feb 28 21:29:29 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 28 Feb 2020 21:29:29 +0000 Subject: hg: amber/amber: adding specs Message-ID: <202002282129.01SLTThC003276@aojmv0008.oracle.com> Changeset: a631c875d3bc Author: vromero Date: 2020-02-28 16:29 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/a631c875d3bc adding specs ! src/java.base/share/classes/java/lang/Class.java ! src/java.compiler/share/classes/javax/lang/model/element/Modifier.java ! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java From maurizio.cimadamore at oracle.com Fri Feb 28 21:35:54 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 28 Feb 2020 21:35:54 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002282135.01SLZsxP006036@aojmv0008.oracle.com> Changeset: cd6d50f2124a Author: mcimadamore Date: 2020-02-28 21:35 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/cd6d50f2124a Automatic merge with sealed-types ! src/java.base/share/classes/java/lang/Class.java ! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java From vicente.romero at oracle.com Sat Feb 29 04:40:31 2020 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sat, 29 Feb 2020 04:40:31 +0000 Subject: hg: amber/amber: spec fixes, removing experimental code Message-ID: <202002290440.01T4eVUU012244@aojmv0008.oracle.com> Changeset: 0b92ffe01e54 Author: vromero Date: 2020-02-28 23:31 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/0b92ffe01e54 spec fixes, removing experimental code ! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/jdk.compiler/share/classes/com/sun/source/tree/ClassTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java From maurizio.cimadamore at oracle.com Sat Feb 29 04:45:53 2020 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Sat, 29 Feb 2020 04:45:53 +0000 Subject: hg: amber/amber: Automatic merge with sealed-types Message-ID: <202002290445.01T4jsNH015032@aojmv0008.oracle.com> Changeset: c35f1585204b Author: mcimadamore Date: 2020-02-29 04:45 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/c35f1585204b Automatic merge with sealed-types ! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/jdk.compiler/share/classes/com/sun/source/tree/ClassTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java