From jonathan.gibbons at oracle.com Tue Feb 4 21:31:50 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 4 Feb 2020 13:31:50 -0800 Subject: RFR: JDK-8219475: javap man page needs to be updated Message-ID: Please review a small change for the javap command-line help. A place-holder Option is added for -J, so that it is included in the command-line help. The option itself is handled by the launcher. Some dead-code, in JavapTask:953, is also removed, since there are no options whose primary name is `-h` or `-verify`.? (`-h` exists, but is just a synonym for `--help`, and `-verify` went away a long time ago.) In the properties file, a duplicate entry for `main.usage.summary` is also removed. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8219475 Webrev: http://cr.openjdk.java.net/~jjg/8219475/webrev/ From mandy.chung at oracle.com Tue Feb 4 21:38:10 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 4 Feb 2020 13:38:10 -0800 Subject: RFR: JDK-8219475: javap man page needs to be updated In-Reply-To: References: Message-ID: <275347b6-555a-0a17-58f6-dac83053fc93@oracle.com> On 2/4/20 1:31 PM, Jonathan Gibbons wrote: > Please review a small change for the javap command-line help. > > : > > JBS: https://bugs.openjdk.java.net/browse/JDK-8219475 > Webrev: http://cr.openjdk.java.net/~jjg/8219475/webrev/ > Looks fine to me. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Feb 5 15:04:31 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 5 Feb 2020 15:04:31 +0000 Subject: RFR: JDK-8219475: javap man page needs to be updated In-Reply-To: References: Message-ID: Hi there, again, our scripts noticed that a bug is private ?? Is there a chance to open up https://bugs.openjdk.java.net/browse/JDK-8219475? Thanks Christoph > -----Original Message----- > From: compiler-dev On Behalf > Of Jonathan Gibbons > Sent: Dienstag, 4. Februar 2020 22:32 > To: compiler-dev at openjdk.java.net; Mandy Chung > > Subject: RFR: JDK-8219475: javap man page needs to be updated > > Please review a small change for the javap command-line help. > > A place-holder Option is added for -J, so that it is included in the > command-line help. The option itself is handled by the launcher. > > Some dead-code, in JavapTask:953, is also removed, since there are no > options whose primary name is `-h` or `-verify`.? (`-h` exists, but is > just a synonym for `--help`, and `-verify` went away a long time ago.) > > In the properties file, a duplicate entry for `main.usage.summary` is > also removed. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8219475 > Webrev: http://cr.openjdk.java.net/~jjg/8219475/webrev/ From vicente.romero at oracle.com Wed Feb 5 22:36:08 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 5 Feb 2020 17:36:08 -0500 Subject: Fwd: RFR: JDK-8238239: java.lang.Record spec clarifications In-Reply-To: <36075136-0e1d-4cdb-747f-b5bf622845ff@oracle.com> References: <36075136-0e1d-4cdb-747f-b5bf622845ff@oracle.com> Message-ID: <93aa13fb-1d57-e717-5e7b-51cc27369bb3@oracle.com> forwarding to compiler dev, I need a reviewer for this change, Thanks, Vicente -------- Forwarded Message -------- Subject: RFR: JDK-8238239: java.lang.Record spec clarifications Date: Tue, 4 Feb 2020 15:38:02 -0500 From: Vicente Romero To: core-libs-dev Please review the fix for [1] at [2] along with the corresponding CSR at [3]. The fix clarifies the specification for java.lang.Record. Please see the CSR for more detail, Thanks, Vicente PS, thanks to John Rose for proposing this fix [1] https://bugs.openjdk.java.net/browse/JDK-8238239 [2] http://cr.openjdk.java.net/~vromero/8238239/webrev.00/ [3] https://bugs.openjdk.java.net/browse/JDK-8238240 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Wed Feb 5 22:58:43 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 5 Feb 2020 14:58:43 -0800 Subject: RFR: JDK-8238239: java.lang.Record spec clarifications In-Reply-To: <93aa13fb-1d57-e717-5e7b-51cc27369bb3@oracle.com> References: <36075136-0e1d-4cdb-747f-b5bf622845ff@oracle.com> <93aa13fb-1d57-e717-5e7b-51cc27369bb3@oracle.com> Message-ID: <436A9A7E-E8A8-419D-A780-416F3775F5F4@oracle.com> +1 Paul. > On Feb 5, 2020, at 2:36 PM, Vicente Romero wrote: > > forwarding to compiler dev, I need a reviewer for this change, > > Thanks, > Vicente > > > -------- Forwarded Message -------- > Subject: RFR: JDK-8238239: java.lang.Record spec clarifications > Date: Tue, 4 Feb 2020 15:38:02 -0500 > From: Vicente Romero > To: core-libs-dev

> > Please review the fix for [1] at [2] along with the corresponding CSR at [3]. The fix clarifies the specification for java.lang.Record. Please see the CSR for more detail, > > Thanks, > Vicente > > PS, thanks to John Rose for proposing this fix > > [1] https://bugs.openjdk.java.net/browse/JDK-8238239 > [2] http://cr.openjdk.java.net/~vromero/8238239/webrev.00/ > [3] https://bugs.openjdk.java.net/browse/JDK-8238240 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Feb 6 01:05:17 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 5 Feb 2020 20:05:17 -0500 Subject: RFR: JDK-8238239: java.lang.Record spec clarifications In-Reply-To: <652b7491-402b-ddfb-cdb5-b74ed7a22f46@oracle.com> References: <36075136-0e1d-4cdb-747f-b5bf622845ff@oracle.com> <652b7491-402b-ddfb-cdb5-b74ed7a22f46@oracle.com> Message-ID: Hi Leonid, Thanks for the comment, I have updated the CSR [1] Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8238240 On 2/5/20 7:55 PM, Leonid Kuskov wrote: > Although methods (toString, hashCode)? return different > representations of a record (either textual or algorithmic) > > Spec for String toString();? everywhere refers to "the object": > > * Returns a string representation of the object. > * @return? a string representation of the object. > > from the other side hashCode(); spec uses "the record" as the object > of the sentences: > > * Returns a hash code value for the record. > * @return? a hash code value for this record. > > Does it make sense to use a sole pattern in the descriptions? > > Thanks, > Leonid > > On 2/4/20 12:38, Vicente Romero wrote: >> Please review the fix for [1] at [2] along with the corresponding CSR >> at [3]. The fix pretends to clarify the specification for >> java.lang.Record. Please see the CSR for more detail, >> >> Thanks, >> Vicente >> >> PS, thanks to John Rose for proposing this fix >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8238239 >> [2] http://cr.openjdk.java.net/~vromero/8238239/webrev.00/ >> [3] https://bugs.openjdk.java.net/browse/JDK-8238240 From pavel.rappo at oracle.com Fri Feb 7 12:18:31 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 7 Feb 2020 12:18:31 +0000 Subject: RFR [15] 8238598: Tighten up com.sun.source.doctree.DocTree API Message-ID: Hello, Please review the change for https://bugs.openjdk.java.net/browse/JDK-8238598: http://cr.openjdk.java.net/~prappo/8238598/webrev.00/ The crux of the proposed change is implementing and specifying semantically dependent methods across the DocTree hierarchy of interfaces. The design of the com.sun.source.doctree.DocTree API intentionally provides some flexibility. Tree nodes can be interacted-with using an OOP style (the Visitor design pattern), a structured programming style (boolean expressions on enum constants), or a mixed style of `instanceof` checks. Each subtype of the DocTree interface has these two methods: R accept(DocTreeVisitor visitor, D data); Kind getKind(); To process a tree node, you can implement visitor's visitXYZ methods of interest and then pass that visitor to this node's `accept` method. Or, you can first check this node's "flavor" explicitly by switching the result returned by `getKind()` on a set of enum constants or using a series of `instanceof ` checks, and then based on this information, cast the node to a more specific type. For this to work, the kind and the type of a node must be firmly linked. The expectation is that if there's the `XYZ` type of a tree node, it has to return the `XYZe` enum constant from its `getKind` method and vice versa [*]. That said, the implementations of the `accept` and `getKind` methods are currently deferred until concrete classes, com.sun.tools.javac.tree.DCTree, and their specification is absent. The proposed patch tries to address both issues by moving the said methods' implementation to the most specific interfaces and specifying their behavior. This collocates and ties both methods in a more explicit way. I cannot think of any likely compatibility risks caused by introducing default methods in this particular case. Still, if this is approved I will file a CSR. I'm also aware that if approved the DocTree API will become less consistent with the com.sun.source.tree.Tree API which it has been modeled after. It would be nice to get feedback from the original designers of those two APIs. I couldn't help cleaning up some of the javadoc comments issues along the way. This includes typos, formatting, and non-normative clarifications. Thanks, -Pavel ------------------------------------------------------------------------------- [*] The mapping from the Kind enum to the subtype of the DocTree interface is not bidirectional. Some of the tags are modeled using the same interface.\ For example, @throws and @exception, @link and @linkplain, @code and @literal, share the ThrowsTree, LinkTree, and LiteralTree interfaces respectively. When dispatching the call to the visitor, sharing tags use the same method. The visitor then might need to resolve the ambiguity by additionally querying the kind of the node it visits. For example, @Override public Boolean visitLiteral(LiteralTree node, Content c) { String s = node.getBody().getBody(); Content content = new StringContent(utils.normalizeNewlines(s)); * if (node.getKind() == CODE) content = HtmlTree.CODE(content); result.add(content); return false; } Thus, the visitor or the `instanceof` alone is not enough. I'm not sure why it was done like that, but as a thought experiment, we could consider what it would take to split those 3 pairs of shared tags in a compatible way. If we were to introduce, say, the `CodeTree` type, we would have to do the following (most of the javadoc comments are not included for brevity). 1. Create a new subinterface of `LiteralTree`: public interface CodeTree extends LiteralTree { /** * Returns {@link Kind#CODE}. * @return {@link Kind#CODE} */ @Override default Kind getKind() { return Kind.CODE; } /** * @implSpec This implementation calls {@code visitor.visitCode(this, data)}. */ @Override default R accept(DocTreeVisitor visitor, D data) { return visitor.visitCode(this, data); } } Why is `CodeTree` a subinterface of `LiteralTree` rather than a sibling (i.e. `CodeTree extends InlineTagTree`)? Because of compatibility with existing implementations that might use `instanceof` instead of `getKind()`. 2. Introduce a new method in `DocTreeVisitor`, which by default forwards the calls to the old path: @Override default R visitCode(CodeTree node, P data) { return visitLiteral(node, data); } From bsrbnd at gmail.com Fri Feb 7 20:22:50 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 7 Feb 2020 21:22:50 +0100 Subject: Possible compiler bug? Code compiles on 8 but not 11 In-Reply-To: References:

Message-ID: Alex, David, Here is a simpler reproducer: public class Factory { public Factory() { String ok = gen(StringGenerator.class); // @SuppressWarnings("unchecked") String ko = gen(Generator.class); } public > T gen(Class c) { return null; } } class StringGenerator extends SimpleGenerator {} class Generator extends SimpleGenerator {} $ javac -Xlint:unchecked Factory.java Factory.java:5: warning: [unchecked] unchecked method invocation: method gen in class Factory is applied to given types String ko = gen(Generator.class); ^ required: Class found: Class where F,T are type-variables: F extends SimpleGenerator declared in method gen(Class) T extends Object declared in method gen(Class) Factory.java:5: error: incompatible types: Object cannot be converted to String String ko = gen(Generator.class); ^ 1 error 1 warning JLS ?15.8.2 states: "The type of C.class, where C is the name of a class, interface, or array type (?4.3), is Class" which means that the found type 'Class' triggers the following rule from ?18.2.2: "A constraint formula of the form ? S ? T ? is reduced as follows: [...] ? Otherwise, if T is a parameterized type of the form G , and there exists no type of the form G< ... > that is a supertype of S , but the raw type G is a supertype of S , then the constraint reduces to true. [...] The fourth and fifth cases are implicit uses of unchecked conversion (?5.1.9)." implying then ?18.5.2.1: "If unchecked conversion was necessary for the method to be applicable during constraint set reduction in ?18.5.1, the constraint formula ?| R | ? T ? is reduced and incorporated with B 2 ." meaning that erasing the return type of 'gen()' to 'Object' looks, at first sight, correct. I'm not exactly sure what could have changed between 8 and 11, but we've still made a small fix in this area some years ago [1], as far as I can remember. Any feedback is welcome, Bernard [1] http://hg.openjdk.java.net/jdk/jdk/rev/39446351e625 On Fri, 31 Jan 2020 at 20:00, Alex Buckley wrote: > > Hi David, > > This is a question of whether javac is conforming to the JLS, and if so, > whether the JLS is correct. It's best in such cases to quote the > smallest possible code sample in inline text. Oracle's javac team is not > looking to reproduce issues in the manner of a support organization, but > rather to understand as precisely as possible what's going on in the > type system. > > Alex > > On 1/31/2020 10:36 AM, David Grieve wrote: > > I have some code that compiles on 8 but not on 11. With 11 (11.0.5, to be exact), the compiler gives an error: > > > >> Factory.java > >> Error:(9, 25) java: incompatible types: java.lang.Object cannot be converted to Manager > > > > This can be fixed with an explicit cast. But it seems to me that the cast should not be needed. > > > > I'm hoping to get an answer for why this compiles cleanly on 8, but not 11. > > > > I have uploaded a small sample that reproduces to http://cr.openjdk.java.net/~dgrieve/javac-bug.zip > > From bsrbnd at gmail.com Fri Feb 7 20:45:22 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 7 Feb 2020 21:45:22 +0100 Subject: Possible compiler bug? Code compiles on 8 but not 11 In-Reply-To: References:

Message-ID: My reproducer seems to be missing one line, see below. Bernard On Fri, 7 Feb 2020 at 21:22, B. Blaser wrote: > > Alex, David, > > Here is a simpler reproducer: > > public class Factory { > public Factory() { > String ok = gen(StringGenerator.class); > // @SuppressWarnings("unchecked") > String ko = gen(Generator.class); > } > > public > T gen(Class c) { return null; } > } > > class StringGenerator extends SimpleGenerator {} > class Generator extends SimpleGenerator {} abstract class SimpleGenerator {} > $ javac -Xlint:unchecked Factory.java > Factory.java:5: warning: [unchecked] unchecked method invocation: > method gen in class Factory is applied to given types > String ko = gen(Generator.class); > ^ > required: Class > found: Class > where F,T are type-variables: > F extends SimpleGenerator declared in method gen(Class) > T extends Object declared in method gen(Class) > Factory.java:5: error: incompatible types: Object cannot be converted to String > String ko = gen(Generator.class); > ^ > 1 error > 1 warning > > JLS ?15.8.2 states: > > "The type of C.class, where C is the name of a class, interface, or > array type (?4.3), is Class" > > which means that the found type 'Class' triggers the > following rule from ?18.2.2: > > "A constraint formula of the form ? S ? T ? is reduced as follows: > [...] > ? Otherwise, if T is a parameterized type of the form G > , and there exists no type of the form G< ... > that is a supertype > of S , but the raw type G is a supertype of S , then the constraint > reduces to true. > [...] > The fourth and fifth cases are implicit uses of unchecked conversion (?5.1.9)." > > implying then ?18.5.2.1: > > "If unchecked conversion was necessary for the method to be applicable > during constraint set reduction in ?18.5.1, the constraint formula ?| > R | ? T ? is reduced and incorporated with B 2 ." > > meaning that erasing the return type of 'gen()' to 'Object' looks, at > first sight, correct. I'm not exactly sure what could have changed > between 8 and 11, but we've still made a small fix in this area some > years ago [1], as far as I can remember. > > Any feedback is welcome, > Bernard > > [1] http://hg.openjdk.java.net/jdk/jdk/rev/39446351e625 > > On Fri, 31 Jan 2020 at 20:00, Alex Buckley wrote: > > > > Hi David, > > > > This is a question of whether javac is conforming to the JLS, and if so, > > whether the JLS is correct. It's best in such cases to quote the > > smallest possible code sample in inline text. Oracle's javac team is not > > looking to reproduce issues in the manner of a support organization, but > > rather to understand as precisely as possible what's going on in the > > type system. > > > > Alex > > > > On 1/31/2020 10:36 AM, David Grieve wrote: > > > I have some code that compiles on 8 but not on 11. With 11 (11.0.5, to be exact), the compiler gives an error: > > > > > >> Factory.java > > >> Error:(9, 25) java: incompatible types: java.lang.Object cannot be converted to Manager > > > > > > This can be fixed with an explicit cast. But it seems to me that the cast should not be needed. > > > > > > I'm hoping to get an answer for why this compiles cleanly on 8, but not 11. > > > > > > I have uploaded a small sample that reproduces to http://cr.openjdk.java.net/~dgrieve/javac-bug.zip > > > From jonathan.gibbons at oracle.com Fri Feb 7 23:15:37 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 7 Feb 2020 15:15:37 -0800 Subject: RFR [15] 8238598: Tighten up com.sun.source.doctree.DocTree API In-Reply-To: References: Message-ID: <95862d7a-e677-9925-cbf7-b1ebccfd3617@oracle.com> Pavel, Thanks for looking at this. First, some general comments. 1. There is no description in the JBS entry. It should have one, especially for a change like this. 2. There's 3 aspects to the changes here. ??? i) Fixing bugs or otherwise improving the existing specification. ??? ??? This is always welcome, assuming the changes are correct. More details later. ??? ii) Providing new specification for what was previously missing. ??? ??? This is generally welcome, but there may be more than one way to do it. ??? iii) Moving the implementation of some methods. ??? ??? This is the most questionable part of the proposal. I agree it is an issue that we do not specify the getKind or accept methods very well, but it is not clear to me that adding overriding methods is the best way to provide the documentation, since the new methods "bloat" the overall generated documentation for most of the classses in the package. For getKind(), the kind of each subtype of DocTree could be narratively specified in the class-level doc comment for each class. For example, for AuthorTree, you could add ??? The {@link #getKind()} of an {@code AuthorTree} is {@link Kind.AUTHOR AUTHOR}. That would extend to the "combo nodes" like ThrowsTree as follows: ??? The {@link #getKind()} of an {@code ThrowsTree} is either ??? {@link Kind.EXCEPTION EXCEPTION} or {@link Kind.THROWS THROWS}. I would add such text after the example, before the @since tag. You could also add more text to DocTree.getKind: ??? For each concrete subtype of {@code DocTree}, {@code getKind} returns a value that is ??? specific to the subtype. ??? For example, {@link AuthorTree#getKind()} returns {@link DocTree.Kind.AUTHOR}. For the "accept" methods, I would suggest that we just provide a more detailed specification on the base method DocTree.accept. I think you could add something like the following, to DocTree.accept: ??? For each concrete subtype of {@code DocTree}, the implementation of {@code accept} ??? calls the appropriate visit method on the provided visitor, for which the ??? type of the first argument is assignable from the subtype. ??? For example, {@link AuthorTree#accept} will return the result of calling ??? ??? {@link DocTreeVisitor#visitAuthor(AuthorTree, P) visitor.visitAuthor(this, data) }. It is not uncomon in Java/JDK API for a package or type to provide high-level general comments, to impose requirements on types, subtypes, and overriding methods. For example, some packages state that, "Unless otherwise specified, all methods in all classes in this package will throw NPE if given null arguments."? Or, look at the Collections methods to see how they impose requirements on impl classes. In terms of your specific proposal, I do not particularly like the inconsistency in the documentation of the getKind methods: some use @implSpec, some don't. I realize the correlation with the "combo types", but splitting the impl of the "combo types" to make the documentation consistent is definitely the tail wagging the dog. FInally, for this part of the feedback, we could give more narrative specification of the use of the visitor pattern in either the package description for com.sun.source.doctree, or in the class-level docs for DocTree itself, which would further reduce the need for any additional specification on each subtype's getKind and accept methods. ------ As for moving the implementations ... the code is not wrong the way it is, and adding default methods to an interface is a potentially incompatible change. JLS 13.5.6 https://docs.oracle.com/javase/specs/jls/se13/html/jls-13.html#jls-13.5.6 says this: > Adding a |default| method, or changing a method from |abstract| to > |default|, does not break compatibility with pre-existing binaries, > but may cause an |IncompatibleClassChangeError| if a pre-existing > binary attempts to invoke the method. This error occurs if the > qualifying type, T, is a subtype of two interfaces, I and J, where > both I and J declare a |default| method with the same signature and > result, and neither I nor J is a subinterface of the other. I have some sympathy for declaring a default method for the accept methods, because that is the only reasonable default implementation in all instances, and if we were talking about writing a new class hierarchy, it might be reasonable to use default methods for accept.? But as much as we might want to go back and rewrite JDK history when new language feature arrive, that's just not realistic. Although default interface methods were added in JDK 8, javac and javadoc are always constrained to use JDK N-1 language features. and so could not use default methods when the API was created. I have less sympathy for moving the impl of the getKind() methods, if only because they cannot *all* be moved ... some of them depend on impl state. For me, the bottom line is that if we can fix the *spec* issues, the *impl* issues are not significant enough to warrant the change, including the suggested need for a CSR. If it ain't broke, don't fix it. ------ Looking at the individual changes ... I can't decide how much we should improve the examples to be more realistic. for example, "{@docroot}" is normally only used inside but maybe this is not the place to get into that level of detail. Maybe at some point, as a separate pass, we link each node page to the corresponding place in the doc comment spec. All the tags on that page should have suitable ids defined.? This will be easier if/when we get a custom '{@spec}' tag. DocTree.Kind, ... I see we already link each Kind to its subtype (just, not the other way around!) DocTreeVisitor ... there are lots of type names that should be in {@code}. e.g.? "Visits a node". ErroneousTree: remove "a" in "stand in for a malformed text". DocSourcePositions:57? "CompilationUnit" -> "the compilation unit" DocSourcePositions:60 add "the":? "the tree for which a position is sought" DocTreePath:37? use {@code} around the DocCommentTree type name DocTreePath:97,98 more type names; use {@code} or convert to English words (minor, style) These days, I use IntelliJ to reformat doc comments, to align the params, etc DocTreePath:167? good catch :-) DCTree, suggest reverting this file and removing the default methods in the interfaces. ---------- Summary: I agree the specification can be improved, but I think it is better to drop all the default methods and fix the specification issues in some other more concise and/or centralized way that does not require overriding methods in each subinterface of DocTree.? I think a paragraph in the package doc or DocTree doc about using the "visitor pattern", switch on "getKind()", or using instanceof would go a long way to reduce any confusion.? I note that you can search online for info about the visitor pattern in general, so I wouldn't go into excess detail on the basic mechanics of the visitor pattern. If you'd like me to propose high-level spec updates, I can do that. I agree with all of your typographic changes, and suggested a few more for you. -- Jon On 02/07/2020 04:18 AM, Pavel Rappo wrote: > Hello, > > Please review the change for https://bugs.openjdk.java.net/browse/JDK-8238598: > > http://cr.openjdk.java.net/~prappo/8238598/webrev.00/ > > The crux of the proposed change is implementing and specifying semantically > dependent methods across the DocTree hierarchy of interfaces. > > The design of the com.sun.source.doctree.DocTree API intentionally provides some > flexibility. Tree nodes can be interacted-with using an OOP style (the Visitor > design pattern), a structured programming style (boolean expressions on enum > constants), or a mixed style of `instanceof` checks. > > Each subtype of the DocTree interface has these two methods: > > R accept(DocTreeVisitor visitor, D data); > Kind getKind(); > > To process a tree node, you can implement visitor's visitXYZ methods of interest > and then pass that visitor to this node's `accept` method. Or, you can first > check this node's "flavor" explicitly by switching the result returned by > `getKind()` on a set of enum constants or using a series of `instanceof ` > checks, and then based on this information, cast the node to a more specific > type. > > For this to work, the kind and the type of a node must be firmly linked. > The expectation is that if there's the `XYZ` type of a tree node, > it has to return the `XYZe` enum constant from its `getKind` method > and vice versa [*]. > > That said, the implementations of the `accept` and `getKind` methods are > currently deferred until concrete classes, com.sun.tools.javac.tree.DCTree, and > their specification is absent. The proposed patch tries to address both issues > by moving the said methods' implementation to the most specific interfaces and > specifying their behavior. This collocates and ties both methods in a more > explicit way. > > I cannot think of any likely compatibility risks caused by introducing default > methods in this particular case. Still, if this is approved I will file a CSR. > I'm also aware that if approved the DocTree API will become less consistent with > the com.sun.source.tree.Tree API which it has been modeled after. It would be > nice to get feedback from the original designers of those two APIs. > > I couldn't help cleaning up some of the javadoc comments issues along the way. > This includes typos, formatting, and non-normative clarifications. > > Thanks, > -Pavel > > ------------------------------------------------------------------------------- > [*] The mapping from the Kind enum to the subtype of the DocTree interface is > not bidirectional. Some of the tags are modeled using the same interface.\ > For example, @throws and @exception, @link and @linkplain, @code and @literal, > share the ThrowsTree, LinkTree, and LiteralTree interfaces respectively. When > dispatching the call to the visitor, sharing tags use the same method. > The visitor then might need to resolve the ambiguity by additionally querying > the kind of the node it visits. For example, > > @Override > public Boolean visitLiteral(LiteralTree node, Content c) { > String s = node.getBody().getBody(); > Content content = new StringContent(utils.normalizeNewlines(s)); > * if (node.getKind() == CODE) > content = HtmlTree.CODE(content); > result.add(content); > return false; > } > > Thus, the visitor or the `instanceof` alone is not enough. I'm not sure why it > was done like that, but as a thought experiment, we could consider what it would > take to split those 3 pairs of shared tags in a compatible way. > > If we were to introduce, say, the `CodeTree` type, we would have to do the > following (most of the javadoc comments are not included for brevity). > > 1. Create a new subinterface of `LiteralTree`: > > public interface CodeTree extends LiteralTree { > /** > * Returns {@link Kind#CODE}. > * @return {@link Kind#CODE} > */ > @Override > default Kind getKind() { > return Kind.CODE; > } > > /** > * @implSpec This implementation calls {@code visitor.visitCode(this, data)}. > */ > @Override > default R accept(DocTreeVisitor visitor, D data) { > return visitor.visitCode(this, data); > } > } > > Why is `CodeTree` a subinterface of `LiteralTree` rather than a sibling > (i.e. `CodeTree extends InlineTagTree`)? Because of compatibility with existing > implementations that might use `instanceof` instead of `getKind()`. > > 2. Introduce a new method in `DocTreeVisitor`, which by default forwards the > calls to the old path: > > @Override > default R visitCode(CodeTree node, P data) { > return visitLiteral(node, data); > } > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.illig at gmx.de Sat Feb 8 19:05:46 2020 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 8 Feb 2020 20:05:46 +0100 Subject: Possible compiler bug: continue is skipped after or-condition Message-ID: <2725303a-cef0-8ca7-e159-1335a1414c4b@gmx.de> /* - */ public class Demo { /* - */ static String[] strings = {"1a", "1b", "2", "3"}; /* - */ /* - */ public static void main(String[] args) { /* 5 */ for (String s : strings) { /* 6 */ if (s.equals("1a") || s.equals("1b")) { /* 7 */ continue; /* - */ } /* 9 */ if (s.equals("2")) { /* - */ continue; /* - */ } /* - */ System.out.println(s); /* - */ } /* - */ } /* - */ } The generated code for the if statement in line 6 is: if (token.equals("1a")) goto line 5 to continue the loop; if (!token.equals("1b")) goto line 9; implicitly goto line 7; Instead of the shortcut "goto line 5 to continue the loop" I had expected the more obvious "goto line 7", so that a possible breakpoint in line 7 is visited. This affects not only breakpoints but also code coverage tools, which will report that line 7 is only reached once, even though the source code says it is reached twice: once for 1a and once for 1b. I tested this using JDK 1.8.0_201 and JDK 13.0.1. Both compile to the same bytecode. From maurizio.cimadamore at oracle.com Mon Feb 10 12:29:53 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 10 Feb 2020 12:29:53 +0000 Subject: Possible compiler bug? Code compiles on 8 but not 11 In-Reply-To: References:

Message-ID: <3d4d2a90-281a-85a6-c028-3947d7c448a2@oracle.com> I believe your analysis is correct. And I also believe this is related to this thread from a couple of years ago: https://mail.openjdk.java.net/pipermail/compiler-dev/2016-January/009947.html Basically, when doing some optimization in the inference engine, we came across a bug in the javac compiler, where the 'unchecked' status of a call was overwritten and not taken into account. We have also tightened up inference, as certain checks were (erroneously!) not giving errors: https://bugs.openjdk.java.net/browse/JDK-8078024 and https://bugs.openjdk.java.net/browse/JDK-8039214 (in both cases a release note has been added, to warn users about potential source compatibility issues). Cheers Maurizio On 07/02/2020 20:45, B. Blaser wrote: > My reproducer seems to be missing one line, see below. > Bernard > > On Fri, 7 Feb 2020 at 21:22, B. Blaser wrote: >> Alex, David, >> >> Here is a simpler reproducer: >> >> public class Factory { >> public Factory() { >> String ok = gen(StringGenerator.class); >> // @SuppressWarnings("unchecked") >> String ko = gen(Generator.class); >> } >> >> public > T gen(Class c) { return null; } >> } >> >> class StringGenerator extends SimpleGenerator {} >> class Generator extends SimpleGenerator {} > abstract class SimpleGenerator {} > >> $ javac -Xlint:unchecked Factory.java >> Factory.java:5: warning: [unchecked] unchecked method invocation: >> method gen in class Factory is applied to given types >> String ko = gen(Generator.class); >> ^ >> required: Class >> found: Class >> where F,T are type-variables: >> F extends SimpleGenerator declared in method gen(Class) >> T extends Object declared in method gen(Class) >> Factory.java:5: error: incompatible types: Object cannot be converted to String >> String ko = gen(Generator.class); >> ^ >> 1 error >> 1 warning >> >> JLS ?15.8.2 states: >> >> "The type of C.class, where C is the name of a class, interface, or >> array type (?4.3), is Class" >> >> which means that the found type 'Class' triggers the >> following rule from ?18.2.2: >> >> "A constraint formula of the form ? S ? T ? is reduced as follows: >> [...] >> ? Otherwise, if T is a parameterized type of the form G>> , and there exists no type of the form G< ... > that is a supertype >> of S , but the raw type G is a supertype of S , then the constraint >> reduces to true. >> [...] >> The fourth and fifth cases are implicit uses of unchecked conversion (?5.1.9)." >> >> implying then ?18.5.2.1: >> >> "If unchecked conversion was necessary for the method to be applicable >> during constraint set reduction in ?18.5.1, the constraint formula ?| >> R | ? T ? is reduced and incorporated with B 2 ." >> >> meaning that erasing the return type of 'gen()' to 'Object' looks, at >> first sight, correct. I'm not exactly sure what could have changed >> between 8 and 11, but we've still made a small fix in this area some >> years ago [1], as far as I can remember. >> >> Any feedback is welcome, >> Bernard >> >> [1] http://hg.openjdk.java.net/jdk/jdk/rev/39446351e625 >> >> On Fri, 31 Jan 2020 at 20:00, Alex Buckley wrote: >>> Hi David, >>> >>> This is a question of whether javac is conforming to the JLS, and if so, >>> whether the JLS is correct. It's best in such cases to quote the >>> smallest possible code sample in inline text. Oracle's javac team is not >>> looking to reproduce issues in the manner of a support organization, but >>> rather to understand as precisely as possible what's going on in the >>> type system. >>> >>> Alex >>> >>> On 1/31/2020 10:36 AM, David Grieve wrote: >>>> I have some code that compiles on 8 but not on 11. With 11 (11.0.5, to be exact), the compiler gives an error: >>>> >>>>> Factory.java >>>>> Error:(9, 25) java: incompatible types: java.lang.Object cannot be converted to Manager >>>> This can be fixed with an explicit cast. But it seems to me that the cast should not be needed. >>>> >>>> I'm hoping to get an answer for why this compiles cleanly on 8, but not 11. >>>> >>>> I have uploaded a small sample that reproduces to http://cr.openjdk.java.net/~dgrieve/javac-bug.zip >>>> From David.Grieve at microsoft.com Tue Feb 11 18:59:33 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Tue, 11 Feb 2020 18:59:33 +0000 Subject: [EXTERNAL] Re: Possible compiler bug? Code compiles on 8 but not 11 In-Reply-To: <3d4d2a90-281a-85a6-c028-3947d7c448a2@oracle.com> References:

href="{@docroot}/..."> > but maybe this is not the place to get into that level of detail. > > Maybe at some point, as a separate pass, we link each node page to the > corresponding > place in the doc comment spec. All the tags on that page should have > suitable ids > defined.? This will be easier if/when we get a custom '{@spec}' tag. > > DocTree.Kind, ... I see we already link each Kind to its subtype > (just, not the other > way around!) > > DocTreeVisitor ... there are lots of type names that should be in {@code}. > e.g.? "Visits a node". > > > ErroneousTree: remove "a" in "stand in for a malformed text". > > DocSourcePositions:57? "CompilationUnit" -> "the compilation unit" > DocSourcePositions:60 add "the":? "the tree for which a position is > sought" > > DocTreePath:37? use {@code} around the DocCommentTree type name > DocTreePath:97,98 more type names; use {@code} or convert to English words > > (minor, style) > These days, I use IntelliJ to reformat doc comments, to align the > params, etc > > DocTreePath:167? good catch :-) > > DCTree, suggest reverting this file and removing the default methods > in the interfaces. > > > ---------- > > Summary: > > I agree the specification can be improved, but I think it is better to > drop all the > default methods and fix the specification issues in some other more > concise > and/or centralized way that does not require overriding methods in each > subinterface of DocTree.? I think a paragraph in the package doc or > DocTree > doc about using the "visitor pattern", switch on "getKind()", or using > instanceof > would go a long way to reduce any confusion.? I note that you can search > online for info about the visitor pattern in general, so I wouldn't go > into excess > detail on the basic mechanics of the visitor pattern. > > If you'd like me to propose high-level spec updates, I can do that. > > I agree with all of your typographic changes, and suggested a few more > for you. > > -- Jon > > > On 02/07/2020 04:18 AM, Pavel Rappo wrote: >> Hello, >> >> Please review the change forhttps://bugs.openjdk.java.net/browse/JDK-8238598: >> >> http://cr.openjdk.java.net/~prappo/8238598/webrev.00/ >> >> The crux of the proposed change is implementing and specifying semantically >> dependent methods across the DocTree hierarchy of interfaces. >> >> The design of the com.sun.source.doctree.DocTree API intentionally provides some >> flexibility. Tree nodes can be interacted-with using an OOP style (the Visitor >> design pattern), a structured programming style (boolean expressions on enum >> constants), or a mixed style of `instanceof` checks. >> >> Each subtype of the DocTree interface has these two methods: >> >> R accept(DocTreeVisitor visitor, D data); >> Kind getKind(); >> >> To process a tree node, you can implement visitor's visitXYZ methods of interest >> and then pass that visitor to this node's `accept` method. Or, you can first >> check this node's "flavor" explicitly by switching the result returned by >> `getKind()` on a set of enum constants or using a series of `instanceof ` >> checks, and then based on this information, cast the node to a more specific >> type. >> >> For this to work, the kind and the type of a node must be firmly linked. >> The expectation is that if there's the `XYZ` type of a tree node, >> it has to return the `XYZe` enum constant from its `getKind` method >> and vice versa [*]. >> >> That said, the implementations of the `accept` and `getKind` methods are >> currently deferred until concrete classes, com.sun.tools.javac.tree.DCTree, and >> their specification is absent. The proposed patch tries to address both issues >> by moving the said methods' implementation to the most specific interfaces and >> specifying their behavior. This collocates and ties both methods in a more >> explicit way. >> >> I cannot think of any likely compatibility risks caused by introducing default >> methods in this particular case. Still, if this is approved I will file a CSR. >> I'm also aware that if approved the DocTree API will become less consistent with >> the com.sun.source.tree.Tree API which it has been modeled after. It would be >> nice to get feedback from the original designers of those two APIs. >> >> I couldn't help cleaning up some of the javadoc comments issues along the way. >> This includes typos, formatting, and non-normative clarifications. >> >> Thanks, >> -Pavel >> >> ------------------------------------------------------------------------------- >> [*] The mapping from the Kind enum to the subtype of the DocTree interface is >> not bidirectional. Some of the tags are modeled using the same interface.\ >> For example, @throws and @exception, @link and @linkplain, @code and @literal, >> share the ThrowsTree, LinkTree, and LiteralTree interfaces respectively. When >> dispatching the call to the visitor, sharing tags use the same method. >> The visitor then might need to resolve the ambiguity by additionally querying >> the kind of the node it visits. For example, >> >> @Override >> public Boolean visitLiteral(LiteralTree node, Content c) { >> String s = node.getBody().getBody(); >> Content content = new StringContent(utils.normalizeNewlines(s)); >> * if (node.getKind() == CODE) >> content = HtmlTree.CODE(content); >> result.add(content); >> return false; >> } >> >> Thus, the visitor or the `instanceof` alone is not enough. I'm not sure why it >> was done like that, but as a thought experiment, we could consider what it would >> take to split those 3 pairs of shared tags in a compatible way. >> >> If we were to introduce, say, the `CodeTree` type, we would have to do the >> following (most of the javadoc comments are not included for brevity). >> >> 1. Create a new subinterface of `LiteralTree`: >> >> public interface CodeTree extends LiteralTree { >> /** >> * Returns {@link Kind#CODE}. >> * @return {@link Kind#CODE} >> */ >> @Override >> default Kind getKind() { >> return Kind.CODE; >> } >> >> /** >> * @implSpec This implementation calls {@code visitor.visitCode(this, data)}. >> */ >> @Override >> default R accept(DocTreeVisitor visitor, D data) { >> return visitor.visitCode(this, data); >> } >> } >> >> Why is `CodeTree` a subinterface of `LiteralTree` rather than a sibling >> (i.e. `CodeTree extends InlineTagTree`)? Because of compatibility with existing >> implementations that might use `instanceof` instead of `getKind()`. >> >> 2. Introduce a new method in `DocTreeVisitor`, which by default forwards the >> calls to the old path: >> >> @Override >> default R visitCode(CodeTree node, P data) { >> return visitLiteral(node, data); >> } >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Feb 14 17:41:41 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 14 Feb 2020 09:41:41 -0800 Subject: JDK 15 RFR of JDK-8239092: Provide explicit specification for getKinds methods of javax.lang.model Message-ID: <495df283-8200-5006-edb5-1e1803efa58d@oracle.com> Hello, As discussed in the review of Pavel's JDK-8238598, the getKind methods in javax.lang.model don't give an explicit type-to-kind mapping. Please review the webrev and CSR to add such a mapping: ??? JDK-8239092: Provide explicit specification for getKinds methods of javax.lang.model ??? http://cr.openjdk.java.net/~darcy/8239092.0/ ??? https://bugs.openjdk.java.net/browse/JDK-8239093 The text as rendered is below. Thanks, -Joe ElementKind getKind() Returns the kind of this element. ??? The kind of a package is PACKAGE. ??? The kind of a module is MODULE. ??? The kind of a type element is one of ANNOTATION, CLASS, ENUM, INTERFACE, or RECORD. ??? The kind of a variable is one of ENUM_CONSTANT, EXCEPTION_PARAMETER, FIELD, LOCAL_VARIABLE, PARAMETER, RESOURCE_VARIABLE, or BINDING_VARIABLE. ??? The kind of an executable is one of CONSTRUCTOR, INSTANCE_INIT, METHOD, or STATIC_INIT. ??? The kind of a type parameter is TYPE_PARAMETER. ??? The kind of a record component is RECORD_COMPONENT. ModuleElement.DirectiveKind getKind() Returns the kind of this directive. ??? The kind of an requires directive is REQUIRES. ??? The kind of an exports directive is EXPORTS. ??? The kind of an opens directive is OPNES. ??? The kind of an uses directive is USES. ??? The kind of an provides directive is PROVIDES. TypeKind getKind() Returns the kind of this type. ??? The kind of a primitive type is one of the kinds for which TypeKind.isPrimitive() returns true. ??? The kind of a null type is NULL. ??? The kind of an array type is ARRAY. ??? The kind of an declared type is DECLARED. ??? The kind of an error type is ERROR. ??? The kind of a type variable is TYPEVAR. ??? The kind of a wildcard type is WILDCARD. ??? The kind of an executable type is EXECUTABLE. ??? The kind of an pseudo-type type is one of VOID, PACKAGE, MODULE, or NONE. ??? The kind of an union typeis UNION. ??? The kind of an intersection type is INTERSECTION. From pavel.rappo at oracle.com Fri Feb 14 18:14:26 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 14 Feb 2020 18:14:26 +0000 Subject: JDK 15 RFR of JDK-8239092: Provide explicit specification for getKinds methods of javax.lang.model In-Reply-To: <495df283-8200-5006-edb5-1e1803efa58d@oracle.com> References: <495df283-8200-5006-edb5-1e1803efa58d@oracle.com> Message-ID: Hi Joe, Thanks for doing that! I guess the point is that we should provide something similar in the DocTree (and maybe Tree) API? ================================================= There's a typo, "OPNES". Should we terminate

elements in the list of items with a full stop? > On 14 Feb 2020, at 17:41, Joe Darcy wrote: > > Hello, > > As discussed in the review of Pavel's JDK-8238598, the getKind methods in javax.lang.model don't give an explicit type-to-kind mapping. Please review the webrev and CSR to add such a mapping: > > JDK-8239092: Provide explicit specification for getKinds methods of javax.lang.model > http://cr.openjdk.java.net/~darcy/8239092.0/ > https://bugs.openjdk.java.net/browse/JDK-8239093 > > The text as rendered is below. > > Thanks, > > -Joe > > ElementKind getKind() > Returns the kind of this element. > > The kind of a package is PACKAGE. > The kind of a module is MODULE. > The kind of a type element is one of ANNOTATION, CLASS, ENUM, INTERFACE, or RECORD. > The kind of a variable is one of ENUM_CONSTANT, EXCEPTION_PARAMETER, FIELD, LOCAL_VARIABLE, PARAMETER, RESOURCE_VARIABLE, or BINDING_VARIABLE. > The kind of an executable is one of CONSTRUCTOR, INSTANCE_INIT, METHOD, or STATIC_INIT. > The kind of a type parameter is TYPE_PARAMETER. > The kind of a record component is RECORD_COMPONENT. > > ModuleElement.DirectiveKind getKind() > Returns the kind of this directive. > > The kind of an requires directive is REQUIRES. > The kind of an exports directive is EXPORTS. > The kind of an opens directive is OPNES. > The kind of an uses directive is USES. > The kind of an provides directive is PROVIDES. > > > TypeKind getKind() > Returns the kind of this type. > > The kind of a primitive type is one of the kinds for which TypeKind.isPrimitive() returns true. > The kind of a null type is NULL. > The kind of an array type is ARRAY. > The kind of an declared type is DECLARED. > The kind of an error type is ERROR. > The kind of a type variable is TYPEVAR. > The kind of a wildcard type is WILDCARD. > The kind of an executable type is EXECUTABLE. > The kind of an pseudo-type type is one of VOID, PACKAGE, MODULE, or NONE. > The kind of an union typeis UNION. > The kind of an intersection type is INTERSECTION. > From jonathan.gibbons at oracle.com Fri Feb 14 18:44:49 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 14 Feb 2020 10:44:49 -0800 Subject: JDK 15 RFR of JDK-8239092: Provide explicit specification for getKinds methods of javax.lang.model In-Reply-To: <495df283-8200-5006-edb5-1e1803efa58d@oracle.com> References: <495df283-8200-5006-edb5-1e1803efa58d@oracle.com> Message-ID: <6a1e0fde-0d82-42d6-92ce-796abddd70ad@oracle.com> Joe, I fixed a few grammatical and typographic errors in the CSR for you. I guess I had considered (as an alternative) adding a sentence to the class-level comment for each subtype, or maybe using a to describe the mapping, but the narrative list is OK too, and at least makes it easier to describe the "non-standard" entries in the mapping. CSR reviewed. -- Jon On 02/14/2020 09:41 AM, Joe Darcy wrote: > Hello, > > As discussed in the review of Pavel's JDK-8238598, the getKind methods > in javax.lang.model don't give an explicit type-to-kind mapping. > Please review the webrev and CSR to add such a mapping: > > ??? JDK-8239092: Provide explicit specification for getKinds methods > of javax.lang.model > ??? http://cr.openjdk.java.net/~darcy/8239092.0/ > ??? https://bugs.openjdk.java.net/browse/JDK-8239093 > > The text as rendered is below. > > Thanks, > > -Joe > > ElementKind getKind() > Returns the kind of this element. > > ??? The kind of a package is PACKAGE. > ??? The kind of a module is MODULE. > ??? The kind of a type element is one of ANNOTATION, CLASS, ENUM, > INTERFACE, or RECORD. > ??? The kind of a variable is one of ENUM_CONSTANT, > EXCEPTION_PARAMETER, FIELD, LOCAL_VARIABLE, PARAMETER, > RESOURCE_VARIABLE, or BINDING_VARIABLE. > ??? The kind of an executable is one of CONSTRUCTOR, INSTANCE_INIT, > METHOD, or STATIC_INIT. > ??? The kind of a type parameter is TYPE_PARAMETER. > ??? The kind of a record component is RECORD_COMPONENT. > > ModuleElement.DirectiveKind getKind() > Returns the kind of this directive. > > ??? The kind of an requires directive is REQUIRES. > ??? The kind of an exports directive is EXPORTS. > ??? The kind of an opens directive is OPNES. > ??? The kind of an uses directive is USES. > ??? The kind of an provides directive is PROVIDES. > > > TypeKind getKind() > Returns the kind of this type. > > ??? The kind of a primitive type is one of the kinds for which > TypeKind.isPrimitive() returns true. > ??? The kind of a null type is NULL. > ??? The kind of an array type is ARRAY. > ??? The kind of an declared type is DECLARED. > ??? The kind of an error type is ERROR. > ??? The kind of a type variable is TYPEVAR. > ??? The kind of a wildcard type is WILDCARD. > ??? The kind of an executable type is EXECUTABLE. > ??? The kind of an pseudo-type type is one of VOID, PACKAGE, MODULE, > or NONE. > ??? The kind of an union typeis UNION. > ??? The kind of an intersection type is INTERSECTION. > From joe.darcy at oracle.com Fri Feb 14 18:27:15 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 14 Feb 2020 10:27:15 -0800 Subject: JDK 15 RFR of JDK-8239092: Provide explicit specification for getKinds methods of javax.lang.model In-Reply-To: References: <495df283-8200-5006-edb5-1e1803efa58d@oracle.com> Message-ID: <03baddf1-985d-7cee-691a-592d76044c03@oracle.com> Hi Pavel, On 2/14/2020 10:14 AM, Pavel Rappo wrote: > Hi Joe, > > Thanks for doing that! I guess the point is that we should provide something > similar in the DocTree (and maybe Tree) API? If we decide this technique is reasonable for javax.lang.model, then I think it should be emulated to related APIs. > > ================================================= > There's a typo, "OPNES". Fixed :-) > Should we terminate

Message-ID: FWIW, this may be interesting: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013678.html Jan On 19. 02. 20 20:45, B. Blaser wrote: > Starting with Roland's experiment which is failing some langtools > tests, I tried a similar fix (here under) focusing only on "continue" > to have a clearer idea of its potential impact on C2 (tier1 being OK): > > $ cat Demo.java > /* - */ public class Demo { > /* - */ static String[] strings = {"1a", "1b", "2", "3"}; > /* - */ > /* - */ public static void main(String[] args) { > /* 5 */ for (String s : strings) { > /* 6 */ if (s.equals("1a") || s.equals("1b")) { > /* 7 */ continue; > /* - */ } > /* 9 */ if (s.equals("2")) { > /* - */ continue; > /* - */ } > /* - */ System.out.println(s); > /* - */ } > /* - */ } > /* - */ } > > $ javac -g Demo.java > $ javap -v Demo.class > 8<------8<------ > 19: aload 4 > 21: ldc #13 // String 1a > 23: invokevirtual #15 // Method > java/lang/String.equals:(Ljava/lang/Object;)Z > 26: ifne 39 > 29: aload 4 > 31: ldc #21 // String 1b > 33: invokevirtual #15 // Method > java/lang/String.equals:(Ljava/lang/Object;)Z > 36: ifeq 42 > 39: goto 63 > 8<------8<------ > LineNumberTable: > line 5: 0 > line 6: 19 > line 7: 39 > line 9: 42 > line 10: 52 > line 12: 55 > line 5: 63 > line 14: 69 > 8<------8<------ > > $ jdb Demo > Initializing jdb ... >> stop at Demo:7 > Deferring breakpoint Demo:7. > It will be set after the class is loaded. >> run > run Demo > Set uncaught java.lang.Throwable > Set deferred uncaught java.lang.Throwable >> > VM Started: Set deferred breakpoint Demo:7 > > Breakpoint hit: "thread=main", Demo.main(), line=7 bci=39 > 7 /* 7 */ continue; > > main[1] cont >> > Breakpoint hit: "thread=main", Demo.main(), line=7 bci=39 > 7 /* 7 */ continue; > > main[1] cont >> 3 > > The application exited > > $ java -Xcomp -XX:-TieredCompilation -XX:CompileCommand=print,Demo.main* Demo > CompileCommand: print Demo.main* > OpenJDK 64-Bit Server VM warning: printing of assembly code is > enabled; turning on DebugNonSafepoints to gain additional output > > ============================= C2-compiled nmethod ============================== > 8<------8<------ > > 03c B5: # out( N1 ) <- in( B11 B2 ) Freq: 0.999938 > 8<------8<------ > 04b ret > 8<------8<------ > > 050 B6: # out( B7 ) <- in( B10 ) top-of-loop Freq: 4.49944 > 8<------8<------ > > 06b B8: # out( B22 B9 ) <- in( B7 ) Freq: 4.99949 > 8<------8<------ > 097 call,static java.lang.String::equals > # Demo::main @ bci:23 > > 09c B9: # out( B12 B10 ) <- in( B8 ) Freq: 4.99939 > # Block is sole successor of call > 09c testl RAX, RAX > 09e je,s B12 P=0.100000 C=-1.000000 > > 0a0 B10: # out( B6 B11 ) <- in( B13 B9 B15 ) Freq: 4.99938 > 8<------8<------ > 0ad jl,s B6 # loop end P=0.900000 C=-1.000000 > > 0af B11: # out( B5 ) <- in( B10 ) Freq: 0.499938 > 0af jmp,s B5 > > 0b1 B12: # out( B21 B13 ) <- in( B9 ) Freq: 0.499939 > 8<------8<------ > 0c3 call,static java.lang.String::equals > # Demo::main @ bci:33 > > 0c8 B13: # out( B10 B14 ) <- in( B12 ) Freq: 0.499929 > # Block is sole successor of call > 0c8 testl RAX, RAX > 0ca jne,s B10 P=0.900000 C=-1.000000 > > Some JVM expert (like Andrew) might confirm, but I believe the C2 > generated code (x86_64) would still be optimal with a "continue" > elision reversion as here under. As we can see, both bci:23 and bci:33 > would go directly to B10 which either starts a new iteration at B6 or > exits through B5. > > Should I file a JBS issue to track this potential fix or would we > prefer investigating a much more holistic refactoring in this area? > > Thanks, > Bernard > > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java > @@ -1457,6 +1457,10 @@ > */ > public Chain branch(int opcode) { > Chain result = null; > +// if (opcode == goto_) { > +// result = pendingJumps; > +// pendingJumps = null; > +// } > if (opcode == goto_) { > result = pendingJumps; > pendingJumps = null; > @@ -1471,6 +1475,18 @@ > return result; > } > > + public Chain continue_() { > + Chain result = null; > + if (isAlive()) { > + result = new Chain(emitJump(goto_), > + result, > + state.dup()); > + fixedPc = fatcode; > + alive = false; > + } > + return result; > + } > + > /** Resolve chain to point to given target. > */ > public void resolve(Chain chain, int target) { > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java > @@ -1797,7 +1797,8 @@ > Env targetEnv = unwind(tree.target, env); > code.pendingStatPos = tmpPos; > Assert.check(code.isStatementStart()); > - targetEnv.info.addCont(code.branch(goto_)); > +// targetEnv.info.addCont(code.branch(goto_)); > + targetEnv.info.addCont(code.continue_()); > endFinalizerGaps(env, targetEnv); > } > > On Mon, 17 Feb 2020 at 22:23, Maurizio Cimadamore > wrote: >> >> Forgot the link: >> >> [1] - https://openjdk.java.net/jeps/303 >> >> On 17/02/2020 21:20, Maurizio Cimadamore wrote: >>> They are _generally_ very reliable - to be clear, nothing has changed >>> in this area to make less reliable. You "just" came across a quirk in >>> javac code generation strategy that has been there for the last 20 years. >>> >>> There are other situations where putting a breakpoint won't >>> necessarily result in anything meaningful to occur - for instance, if >>> you put a breakpoint on a local variable declaration. This is not to >>> say that nothing should be done about it _ever_ - but as you said, you >>> lived for 20 years w/o realizing that this hiccup has been there all >>> along (along with other hiccups) - so please also understand a certain >>> reticence in making an abrupt change in the code generation strategy >>> (or worse, supporting multiple code generation strategies) for what >>> feels like something that is annoying, yes, but hardly a breaking issue. >>> >>> As I said in my last email, I'd like to address this as part as a more >>> holistic investigation on how bytecode fidelity is retained from class >>> files. Note that we have features in the pipeline like constant >>> folding (see [1]) which are going to cause an even bigger impact to >>> how source files relates to classfiles. So I'd just like to think this >>> through properly, as I think this needs more thinking and more time >>> than what we've available right now - to fully assess the extent of >>> this and other 'premature' optimizations javac might do to the code, >>> verify that changing code shape won't hurt C1, C2 compilers, and make >>> sure that no relevant functional regression is introduced. >>> >>> Maurizio >>> >>> On 17/02/2020 17:35, Roland Illig wrote: >>>> How would you explain to an average developer that breakpoints are not >>>> reliable? Up to now, they have been very reliable to me, and after more >>>> than 20 years of using Java, this is really the first time that the >>>> breakpoints surprise me. From adinn at redhat.com Thu Feb 20 10:03:21 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 20 Feb 2020 10:03:21 +0000 Subject: Possible compiler bug: continue is skipped after or-condition In-Reply-To: References: <2725303a-cef0-8ca7-e159-1335a1414c4b@gmx.de> <2f056de4-7930-87aa-344d-da22664ba692@gmx.de> <38dda627-cb84-3858-a634-9c1008919abb@gmx.de> <7957c447-c150-7ea0-88a6-3a59b1276caf@oracle.com>

Message-ID: <29656853-4316-f586-28f4-01d94b2532f5@redhat.com> On 19/02/2020 19:45, B. Blaser wrote: > Some JVM expert (like Andrew) might confirm, but I believe the C2 > generated code (x86_64) would still be optimal with a "continue" > elision reversion as here under. As we can see, both bci:23 and bci:33 > would go directly to B10 which either starts a new iteration at B6 or > exits through B5. The problem with this experiment is that it misses an important aspect of how compiler branch optimization works. The organization of branching structure in the JITted code is heavily conditioned by branch profile information. Branch conditions may be (and often are) flipped to place a hot path in the direct drop-through line, moving the cold path out of line. Note that such re-location of code paths does not just imply re-ordering them between the loop start and back edge. A branch to a cold path may well jump out beyond the loop back edge terminating with a jump back into the middle of the loop body. The idea is to improve instruction cache locality by ensuring that as much hot code as possible is contained in a tight, contiguous segment. This usually works very efficiently with standard hw branch predictors + cache prefetchers. So, I am afraid the code your test has generated is not necessarily going to reflect the code layout that would happen in production code executing a method with a similar loop + loop exit structure. The branch layout might even vary from one run to the next (or even from one C2 JIT compile to a C2 JIT recompile if a deopt happens). That said, what I think the test does show is that the compiler does know how to unravel the sort of indirect jump this reversion might introduce. > Should I file a JBS issue to track this potential fix or would we > prefer investigating a much more holistic refactoring in this area? Well, I'd follow Maurizio's advice and add this to a slate for a later reckoning of highest priorities against most effective remedies. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From jonathan.gibbons at oracle.com Thu Feb 20 23:13:18 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 20 Feb 2020 15:13:18 -0800 Subject: JDK 15 RFR of 8225495: Note whether returned annotations are declaration annotations or type annotations, take 2 In-Reply-To: References: Message-ID: There's a typo, "declarations annotations" in AnnotatedConstruct.java. Looks OK to me, but I recommend also getting approval from the author of the previous round of feedback. -- Jon On 2/18/20 9:19 PM, Joe Darcy wrote: > Hello, > > Please review a second iteration of the fix for > > ??? 8225495: Note whether returned annotations are declaration > annotations or type annotations > ??? http://cr.openjdk.java.net/~darcy/8225495.1/ > > In response to previous feedback [1], I made additional ties between > the javadoc specs and the JLS. Also, a note was added to > Elements.getAllAnnotationMirrors. > > As an RFE for the inline @jls tag, if there was a "@jlsPlain" tag > allowed linkage without displaying the section numbers, I would have > used that in a few locations in this changeset. > > Thanks, > > -Joe > > [1] > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013455.html > From joe.darcy at oracle.com Fri Feb 21 17:38:09 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 21 Feb 2020 09:38:09 -0800 Subject: JDK 15 initial RFR of 8193553: Provide better guidance on using javax.lang.model visitors Message-ID: <72f2b8e4-9131-4194-867d-c8db22bd3005@oracle.com> Hello, Please review the initial fix for ??? 8193553 : Provide better guidance on using javax.lang.model visitors ??? http://cr.openjdk.java.net/~darcy/8193553.0/ Once wording is agree to for the element visitor case, I'll write analogous additions for the type visitor and annotation value visitor classes and send around the set of changes for another round of review. Thanks, -Joe --- old/src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java 2020-02-21 09:33:06.898482673 -0800 +++ new/src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java 2020-02-21 09:33:06.598482673 -0800 @@ -64,6 +64,53 @@ ? * packages that are only required to run on Java SE 8 and higher ? * platform versions. ? * + * @apiNote + * + * There are several families of classes implementing this visitor + * interface in the {@linkplain javax.lang.model.util util + * package}. The families follow a naming pattern along the lines of + * {@code FooVisitor}N where N indicates the + * {@linkplain javax.lang.model.SourceVersion source version} the + * visitor is appropriate for. + * + * That is, a {@code FooVisitor}N is expected + * to handle all language constructs present in source version + * N. If there are no new language constructs added in version + * N + 1 (or subsequent releases), {@code + * FooVisitor}N may also handle that later source version; in + * that case, the {@link + * javax.annotation.processing.SupportedSourceVersion + * SupportedSourceVersion} annotation on the {@code + * FooVisitor}N class will indicate a later version. + * + * When visiting an element representing a language construct + * introduced after source version N, a {@code + * FooVisitor}N will throw an {@link UnknownElementException} + * unless that behavior is overridden. + * + *

When choosing which member of a visitor family to subclass, + * subclassing the most recent one increases the range of source + * versions covered. When choosing which visitor family to subclass, + * consider their built-in capabilities: + * + *

{@link AbstractElementVisitor6 AbstractElementVisitor}s: + * Skeletal visitor implementations. + * + *
{@link SimpleElementVisitor6 SimpleElementVisitor}s: Support + * default actions and a default return value. + * + *
{@link ElementKindVisitor6 ElementKindVisitor}s: Visit methods + * provided on a {@linkplain Element#getKind per-kind} granularity as + * some categories of elements can have more than one kind. + * + *
{@link ElementScanner6 ElementScanner}s: Scanners are visitors + * which traverse an element and the elements {@linkplain + * Element#getEnclosedElements enclosed} by it and associated with it. + * + *

+ * ? * @param the return type of this visitor's methods. Use {@link ? *??????????? Void} for visitors that do not need to return results. ? * @param

the type of the additional parameter to this visitor's From jonathan.gibbons at oracle.com Tue Feb 25 17:58:20 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 25 Feb 2020 09:58:20 -0800 Subject: JDK 15 initial RFR of 8193553: Provide better guidance on using javax.lang.model visitors In-Reply-To: <72f2b8e4-9131-4194-867d-c8db22bd3005@oracle.com> References: <72f2b8e4-9131-4194-867d-c8db22bd3005@oracle.com> Message-ID: <7e214d90-304b-7358-87a2-f16044208c38@oracle.com> Joe, Generally OK. Use of "That is," seems very idiomatic. You have a mix of and in the same sentence Either stay semantic and use and or typographic and I'm not a big fan of pluralizing types in links, as in {@link Foo}s? but it's not awful. -- Jon On 2/21/20 9:38 AM, Joe Darcy wrote: > Hello, > > Please review the initial fix for > > ??? 8193553 : Provide better guidance on using javax.lang.model visitors > ??? http://cr.openjdk.java.net/~darcy/8193553.0/ > > Once wording is agree to for the element visitor case, I'll write > analogous additions for the type visitor and annotation value visitor > classes and send around the set of changes for another round of review. > > Thanks, > > -Joe > > --- > old/src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java > 2020-02-21 09:33:06.898482673 -0800 > +++ > new/src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java > 2020-02-21 09:33:06.598482673 -0800 > @@ -64,6 +64,53 @@ > ? * packages that are only required to run on Java SE 8 and higher > ? * platform versions. > ? * > + * @apiNote > + * > + * There are several families of classes implementing this visitor > + * interface in the {@linkplain javax.lang.model.util util > + * package}. The families follow a naming pattern along the lines of > + * {@code FooVisitor}N where N indicates the > + * {@linkplain javax.lang.model.SourceVersion source version} the > + * visitor is appropriate for. > + * > + * That is, a {@code FooVisitor}N is expected > + * to handle all language constructs present in source version > + * N. If there are no new language constructs added in version > + * N + 1 (or subsequent releases), {@code > + * FooVisitor}N may also handle that later source version; in > + * that case, the {@link > + * javax.annotation.processing.SupportedSourceVersion > + * SupportedSourceVersion} annotation on the {@code > + * FooVisitor}N class will indicate a later version. > + * > + * When visiting an element representing a language construct > + * introduced after source version N, a {@code > + * FooVisitor}N will throw an {@link UnknownElementException} > + * unless that behavior is overridden. > + * > + *

When choosing which member of a visitor family to subclass, > + * subclassing the most recent one increases the range of source > + * versions covered. When choosing which visitor family to subclass, > + * consider their built-in capabilities: > + * > + *

> + * > + *
{@link AbstractElementVisitor6 AbstractElementVisitor}s: > + * Skeletal visitor implementations. > + * > + *
{@link SimpleElementVisitor6 SimpleElementVisitor}s: Support > + * default actions and a default return value. > + * > + *
{@link ElementKindVisitor6 ElementKindVisitor}s: Visit methods > + * provided on a {@linkplain Element#getKind per-kind} granularity as > + * some categories of elements can have more than one kind. > + * > + *
{@link ElementScanner6 ElementScanner}s: Scanners are visitors > + * which traverse an element and the elements {@linkplain > + * Element#getEnclosedElements enclosed} by it and associated with it. > + * > + *