From vicente.romero at oracle.com Fri Nov 1 04:11:19 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 1 Nov 2019 00:11:19 -0400 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> Message-ID: Hi all, Thanks for all the feedback so far. I have published another iteration at [1]. New in this iteration: Flags.java: - I have sync the javadoc and the comment on the RECORD flag - renamed MemberRecordClassFlags -> MemberRecordFlags com.sun.tools.javac.code.Kinds.java: - in order to generate better error messages I have added two new kinds: RECORD_COMPONENT and RECORD Symbols.java - moved method isRecord to ClassSymbol for the rest of the symbols moved back to using the bitwise test - removed method ::isDynamic from MethodSymbol Attr.java - implemented a spec change to relax that constraint that every non-canonical constructor should call the canonical constructor. Now the spec forces every non-canonical constructor to invoke a different constructor as its first statement. This actually implied removing some code. Check.java - at method ::duplicateError, there is new code to avoid generating two errors when the user declares a record with duplicated record component names. If this happens, then a compiler generated canonical constructor would have duplicated parameters. This code is preventing the compiler to generate a second error referring to a method that is not visible to the user. Another option is to not generate the canonical constructor at all if there are duplicate record components - at method ::checkUnique, there is new code to improve the error message when the user defines a constructor with the same erasure as the canonical constructor. Still the error message is not perfect because it shows in both cases the erasure of the methods, so they seem to be the same. But this is not related to records code, that's a simplification that happens at the moment of reporting the error. TypeEnter - removed some commented code - ::addRecordMembersIfNeeded here I added new code to avoid generating accessor methods for forbidden record component names. This is to avoid spurious errors later as any way the compiler will complain because of the forbidden record component names. The issue with this solution is that the list of forbidden record component names has been duplicated here. The other location is Attr. We can probably find a common place to define it. Probably a new utility class? JavacParser: - fixed the bug that the compiler was not allowing final local records - removed the check for abstract modifiers in records, this code was redundant as Check was already checking this - removed the check for duplicated record component names - added a check to forbid instance initializers in records compiler.properties - I hope I got the error messages right, I tried to reflect all the comments, suggestions, etc. I was proposed to create a `master` message for canonical records and use different `causes`, aka fragments, to be more specific. I decided to follow the same pattern for accessor methods. Regarding the suggestion of placing the caret in the throws clause for the corresponding error message, not possible. We would have to move the check for that error to the parser. New in this iteration: - I have included jdeps related code, I was thinking about putting it in a separate review bucket but, it is small, it kind of fits with the rest of the review - a series of supporting libraries for tests under: test/langtools/lib/combo/tools/javac/combo with also the tests that needed to be modified due to changes in the lib. These changes were created by Brian - a minor change done at ToolBox.java Thanks for all the feedback, Vicente [1] http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.03/ From maurizio.cimadamore at oracle.com Fri Nov 1 12:06:29 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 1 Nov 2019 12:06:29 +0000 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> Message-ID: First, congrats on the work on error messages - it really paid off; the diagnostics now look very consistent and easy to grasp. One minor not on that side is this message: "first statement of this constructor must invoke another constructor" This has two problems, I think: 1) "statement .... must invoke" - a statement does not invoke; maybe rephrase as "first statement ... must be a constructor invocation" 2) we don't have a blessed term to name a non-canonical constructor. Can we just say non-canonical in the diagnostic? E.g. "the first statement in a non-canonical constructor must be an invocation of another constructor" Seems a mouthful. I noted that we have this diagnostic around: # 0: name 230 compiler.err.call.must.be.first.stmt.in.ctor=\ 231 call to {0} must be first statement in constructor Perhaps, inspired by this, we can turn this around and do this: "First statement in non-canonical constructor must be a call to 'this'" ? This seems more compact. More comments inline below: On 01/11/2019 04:11, Vicente Romero wrote: > Hi all, > > Thanks for all the feedback so far. I have published another iteration > at [1]. New in this iteration: > > Flags.java: > > - I have sync the javadoc and the comment on the RECORD flag > - renamed MemberRecordClassFlags -> MemberRecordFlags > > com.sun.tools.javac.code.Kinds.java: > - in order to generate better error messages I have added two new > kinds: RECORD_COMPONENT and RECORD Great - this works very well > > Symbols.java > - moved method isRecord to ClassSymbol for the rest of the symbols > moved back to using the bitwise test > - removed method ::isDynamic from MethodSymbol Good > > Attr.java > - implemented a spec change to relax that constraint that every > non-canonical constructor should call the canonical constructor. Now > the spec forces every non-canonical constructor to invoke a different > constructor as its first statement. This actually implied removing > some code. The new check looks very good - but I think this comment: /* this is it for now we still have to verify that the invocation is actually pointing to +???????????????????? * the canonical constructor as it could be pointing to another constructor, but we need to +???????????????????? * attribute the arguments first in visitApply +???????????????????? */ Is no longer valid? > Check.java > - at method ::duplicateError, there is new code to avoid generating > two errors when the user declares a record with duplicated record > component names. If this happens, then a compiler generated canonical > constructor would have duplicated parameters. This code is preventing > the compiler to generate a second error referring to a method that is > not visible to the user. Another option is to not generate the > canonical constructor at all if there are duplicate record components > - at method ::checkUnique, there is new code to improve the error > message when the user defines a constructor with the same erasure as > the canonical constructor. Still the error message is not perfect > because it shows in both cases the erasure of the methods, so they > seem to be the same. But this is not related to records code, that's a > simplification that happens at the moment of reporting the error. I really don't get why the message shows the erasure of the methods - you are calling: Errors.ConstructorWithSameErasureAsCanonical(other, canonical) That is, you are passing symbols - the symbols contain full type info - why is this being erased? This doesn't seem to happen e.g. in ordinary clash errors, e.g. InheritanceConflict3.java:14:10: compiler.err.name.clash.same.erasure: f(java.lang.Object), f(T) Is it possible, by any chance that we're generating the canonical symbol with an erased type? > > TypeEnter > - removed some commented code > - ::addRecordMembersIfNeeded here I added new code to avoid generating > accessor methods for forbidden record component names. This is to > avoid spurious errors later as any way the compiler will complain > because of the forbidden record component names. The issue with this > solution is that the list of forbidden record component names has been > duplicated here. The other location is Attr. We can probably find a > common place to define it. Probably a new utility class? Looking here http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.03/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java.html I noted that there are several indentation issues around BasicConstructorHelper (e.g. closing braces seem to be off) Also, there are some comments like: 1107 // public String toString() { return ???; } Which should be removed, or tweaked. As for the list of forbidden names, I think it should live in Names. After all, these are all names, so you can easily build a list there, and share it across javac components. > JavacParser: > - fixed the bug that the compiler was not allowing final local records > - removed the check for abstract modifiers in records, this code was > redundant as Check was already checking this > - removed the check for duplicated record component names > - added a check to forbid instance initializers in records > > compiler.properties > - I hope I got the error messages right, I tried to reflect all the > comments, suggestions, etc. I was proposed to create a `master` > message for canonical records and use different `causes`, aka > fragments, to be more specific. I decided to follow the same pattern > for accessor methods. Regarding the suggestion of placing the caret in > the throws clause for the corresponding error message, not possible. > We would have to move the check for that error to the parser. Yep, looks good! Maurizio > > New in this iteration: > - I have included jdeps related code, I was thinking about putting it > in a separate review bucket but, it is small, it kind of fits with the > rest of the review > - a series of supporting libraries for tests under: > test/langtools/lib/combo/tools/javac/combo with also the tests that > needed to be modified due to changes in the lib. These changes were > created by Brian > - a minor change done at ToolBox.java > > Thanks for all the feedback, > Vicente > > > [1] > http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.03/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Fri Nov 1 12:13:34 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 1 Nov 2019 19:13:34 +0700 Subject: Diagnostic.getColumnNumber specification Message-ID: Hello! javax.tools.Diagnostic#getColumnNumber spec currently says [1]: > Returns the column number of the character offset returned by getPosition(). This spec says nothing about handling the tabulation ('\t') character. Current javac implementation increases column to the next number divisible by 8 every time the tabulation character is encountered. Nowadays people use different tab widths, so I would not say that everybody would expect this behavior by default. I suggest improving the specification of this method adding the information about how tabulations are handled. What do you think? Is it a useful change? Also, there's a small typo in the getPosition() method spec [2]: Returns a character offset from the beginning of the source object associated with this diagnostic that indicates the location of the problem. In addition, the following must be true: getStartPostion() <= getPosition() <----- should be getStartPostion ('i' is missing) getPosition() <= getEndPosition() With best regards, Tagir Valeev. [1] https://docs.oracle.com/en/java/javase/13/docs/api/java.compiler/javax/tools/Diagnostic.html#getColumnNumber() [2] https://docs.oracle.com/en/java/javase/13/docs/api/java.compiler/javax/tools/Diagnostic.html#getPosition() From maurizio.cimadamore at oracle.com Fri Nov 1 12:56:31 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 1 Nov 2019 12:56:31 +0000 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> Message-ID: <9f8607fd-9fab-cc7a-9b0b-8913887df893@oracle.com> On 01/11/2019 12:06, Maurizio Cimadamore wrote: > I really don't get why the message shows the erasure of the methods - > you are calling: > > Errors.ConstructorWithSameErasureAsCanonical(other, canonical) > > That is, you are passing symbols - the symbols contain full type info > - why is this being erased? This doesn't seem to happen e.g. in > ordinary clash errors, e.g. > > InheritanceConflict3.java:14:10: compiler.err.name.clash.same.erasure: > f(java.lang.Object), f(T) > > Is it possible, by any chance that we're generating the canonical > symbol with an erased type? Did some more investigation on this. The problem was trivial - and was made clearer by compiling an example like this: import java.util.List; record Foo(List ls) { ??? Foo(List li) { } } This generates: Test.java:4: error: signature clash: constructor Foo(List) and canonical constructor Foo(List) have the same erasure ??? Foo(List li) { } ??? ^ 1 error Where it's clear that there's no erasure at play; the real issue is that the underlying diagnostic is bogus: compiler.err.constructor.with.same.erasure.as.canonical=\ ????????? signature clash: constructor {0} and canonical constructor {0} have the same erasure Note the double reference to {0}. If this is fixed as: # 0: symbol, 1: symbol compiler.err.constructor.with.same.erasure.as.canonical=\ ??? signature clash: constructor {0} and canonical constructor {1} have the same erasure Then the error displayed is correct: # 0: symbol, 1: symbol compiler.err.constructor.with.same.erasure.as.canonical=\ ??? signature clash: constructor {0} and canonical constructor {1} have the same erasure Also, while experimenting, I noted that compiling code like: record Foo(String s) { } Without the --enable-preview flag, causes a spurious parser error, with no clue that I'm using a preview feature: Test.java:1: error: class, interface, or enum expected record Foo(String s) { ^ 1 error Is that expected? I believe the issue is with 'isRecordToken' which always returns 'false' if preview features are disabled. I think something should call checkSourceLevel(Feature.RECORDS), so that preview errors for records will be triggered. And, looking more, I see some issues with parsing inside blocks - for instance, this program no longer compiles (w/o enable-preview): class Foo { ??? void test() { ??????? final record r = null; ??? } } class record {} That's because when we're inside a method body, we always interpret 'final record' as a record declaration. A better solution would be to always check (with lookahead) for "record IDENT '('". That should be more robust. In other words, I think that the parser code should be consolidated so that you have a single routine that checks for the start of a record declaration: record IDENT '(' If the above production is matched (with lookahead), then you call checkSourceLevel(Feature.RECORDS), so that the correct errors are generated. The routine could be something like this: boolean isRecordStart() { ???? if (token.kind == IDENTIFIER && token.name() == names.record && ??????????? (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) || ???????????? peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) { ????????? checkSourceLevel(Feature.RECORDS); ????????? return true; ??? } else { ?????? return false; ?? } } Then you remove isRecordToken, and start to use the above everywhere. I tried with a crude patch (see below), and things seem to work much better. Examples: record foo(int x) {} gives: Test.java:1: error: records are a preview feature and are disabled by default. record foo(int x) {} ^ ? (use --enable-preview to enable records) 1 error And, this: class Foo { ??? void test() { ??????? final record r = null; ??? } } class record {} Gives the following: Test.java:3: warning: 'record' may become a restricted type name in a future release and may be unusable for type declarations or as the element type of an array ??????? final record r = null; ???????????????????? ^ Test.java:7: warning: 'record' may become a restricted type name in a future release and may be unusable for type declarations or as the element type of an array class record {} ????? ^ 2 warnings Which I think it's closer to what we want. Patch below: diff -r 1da4a8addd21 src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.javaThu Oct 31 23:59:56 2019 -0400 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.javaFri Nov 01 12:53:31 2019 +0000 @@ -2558,7 +2558,7 @@ ???????????? if (token.kind == INTERFACE || ???????????????? token.kind == CLASS || ???????????????? token.kind == ENUM || -??????????????? (token.kind == IDENTIFIER && token.name() == names.record) ) { +??????????????? isRecordStart()) { ???????????????? return List.of(classOrRecordOrInterfaceOrEnumDeclaration(mods, dc)); ???????????? } else { ???????????????? JCExpression t = parseType(true); @@ -2625,9 +2625,7 @@ ???????????????? //else intentional fall-through ???????????? } ???????? } -??????? if (isRecordToken() && -??????????? (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) || -???????????? peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) { +??????? if (isRecordStart()) { ???????????? dc = token.comment(CommentStyle.JAVADOC); ???????????? return List.of(recordDeclaration(F.at(pos).Modifiers(0), dc)); ???????? } else { @@ -3661,7 +3659,7 @@ ???? protected JCStatement classOrRecordOrInterfaceOrEnumDeclaration(JCModifiers mods, Comment dc) { ???????? if (token.kind == CLASS) { ???????????? return classDeclaration(mods, dc); -??????? } if (isRecordToken()) { +??????? } if (isRecordStart()) { ???????????? return recordDeclaration(mods, dc); ???????? } else if (token.kind == INTERFACE) { ???????????? return interfaceDeclaration(mods, dc); @@ -4022,7 +4020,7 @@ ???????????? int pos = token.pos; ???????????? JCModifiers mods = modifiersOpt(); ???????????? if (token.kind == CLASS || -??????????????? isRecordToken() || +??????????????? isRecordStart() || ???????????????? token.kind == INTERFACE || ???????????????? token.kind == ENUM) { ???????????????? return List.of(classOrRecordOrInterfaceOrEnumDeclaration(mods, dc)); @@ -4117,9 +4115,16 @@ ???????? } ???? } -??? boolean isRecordToken() { -??????? return allowRecords && token.kind == IDENTIFIER && token.name() == names.record; -??? } +??? boolean isRecordStart() { +???? if (token.kind == IDENTIFIER && token.name() == names.record && +??????????? (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) || +???????????? peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) { +????????? checkSourceLevel(Feature.RECORDS); +????????? return true; +??? } else { +?????? return false; +?? } +} ???? /** MethodDeclaratorRest = ????? *????? FormalParameters BracketsOpt [THROWS TypeList] ( MethodBody | [DEFAULT AnnotationValue] ";") Cheers Maurizio From vicente.romero at oracle.com Fri Nov 1 13:03:56 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 1 Nov 2019 09:03:56 -0400 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> Message-ID: <9c9a551e-0356-98e1-9f08-234fbaeebf2c@oracle.com> Hi Maurizio, On 11/1/19 8:06 AM, Maurizio Cimadamore wrote: > > First, congrats on the work on error messages - it really paid off; > the diagnostics now look very consistent and easy to grasp. > good :) > One minor not on that side is this message: > > "first statement of this constructor must invoke another constructor" > yep I wasn't happy with it either > > This has two problems, I think: > > 1) "statement .... must invoke" - a statement does not invoke; maybe > rephrase as "first statement ... must be a constructor invocation" > > 2) we don't have a blessed term to name a non-canonical constructor. > Can we just say non-canonical in the diagnostic? E.g. > > "the first statement in a non-canonical constructor must be an > invocation of another constructor" > > Seems a mouthful. > > I noted that we have this diagnostic around: > > # 0: name > 230 compiler.err.call.must.be.first.stmt.in.ctor=\ > 231 call to {0} must be first statement in constructor > > Perhaps, inspired by this, we can turn this around and do this: > > "First statement in non-canonical constructor must be a call to 'this'" ? > will do > This seems more compact. > > > More comments inline below: > > > On 01/11/2019 04:11, Vicente Romero wrote: >> Hi all, >> >> Thanks for all the feedback so far. I have published another >> iteration at [1]. New in this iteration: >> >> Flags.java: >> >> - I have sync the javadoc and the comment on the RECORD flag >> - renamed MemberRecordClassFlags -> MemberRecordFlags >> >> com.sun.tools.javac.code.Kinds.java: >> - in order to generate better error messages I have added two new >> kinds: RECORD_COMPONENT and RECORD > Great - this works very well >> >> Symbols.java >> - moved method isRecord to ClassSymbol for the rest of the symbols >> moved back to using the bitwise test >> - removed method ::isDynamic from MethodSymbol > Good >> >> Attr.java >> - implemented a spec change to relax that constraint that every >> non-canonical constructor should call the canonical constructor. Now >> the spec forces every non-canonical constructor to invoke a different >> constructor as its first statement. This actually implied removing >> some code. > > The new check looks very good - but I think this comment: > > /* this is it for now we still have to verify that the invocation is > actually pointing to > +???????????????????? * the canonical constructor as it could be > pointing to another constructor, but we need to > +???????????????????? * attribute the arguments first in visitApply > +???????????????????? */ > > Is no longer valid? > yep, removed > > >> Check.java >> - at method ::duplicateError, there is new code to avoid generating >> two errors when the user declares a record with duplicated record >> component names. If this happens, then a compiler generated canonical >> constructor would have duplicated parameters. This code is preventing >> the compiler to generate a second error referring to a method that is >> not visible to the user. Another option is to not generate the >> canonical constructor at all if there are duplicate record components >> - at method ::checkUnique, there is new code to improve the error >> message when the user defines a constructor with the same erasure as >> the canonical constructor. Still the error message is not perfect >> because it shows in both cases the erasure of the methods, so they >> seem to be the same. But this is not related to records code, that's >> a simplification that happens at the moment of reporting the error. > > I really don't get why the message shows the erasure of the methods - > you are calling: > > Errors.ConstructorWithSameErasureAsCanonical(other, canonical) > > That is, you are passing symbols - the symbols contain full type info > - why is this being erased? This doesn't seem to happen e.g. in > ordinary clash errors, e.g. > > InheritanceConflict3.java:14:10: compiler.err.name.clash.same.erasure: > f(java.lang.Object), f(T) > > Is it possible, by any chance that we're generating the canonical > symbol with an erased type? > >> >> TypeEnter >> - removed some commented code >> - ::addRecordMembersIfNeeded here I added new code to avoid >> generating accessor methods for forbidden record component names. >> This is to avoid spurious errors later as any way the compiler will >> complain because of the forbidden record component names. The issue >> with this solution is that the list of forbidden record component >> names has been duplicated here. The other location is Attr. We can >> probably find a common place to define it. Probably a new utility class? > > Looking here > > http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.03/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java.html > > I noted that there are several indentation issues around > BasicConstructorHelper (e.g. closing braces seem to be off) > > Also, there are some comments like: > > 1107 // public String toString() { return ???; } > > Which should be removed, or tweaked. > done > > As for the list of forbidden names, I think it should live in Names. > After all, these are all names, so you can easily build a list there, > and share it across javac components. > yep you are right that's the natural place > > >> JavacParser: >> - fixed the bug that the compiler was not allowing final local records >> - removed the check for abstract modifiers in records, this code was >> redundant as Check was already checking this >> - removed the check for duplicated record component names >> - added a check to forbid instance initializers in records >> >> compiler.properties >> - I hope I got the error messages right, I tried to reflect all the >> comments, suggestions, etc. I was proposed to create a `master` >> message for canonical records and use different `causes`, aka >> fragments, to be more specific. I decided to follow the same pattern >> for accessor methods. Regarding the suggestion of placing the caret >> in the throws clause for the corresponding error message, not >> possible. We would have to move the check for that error to the parser. > > Yep, looks good! > cool :) > > > Maurizio > Thanks, Vicente > >> >> New in this iteration: >> - I have included jdeps related code, I was thinking about putting it >> in a separate review bucket but, it is small, it kind of fits with >> the rest of the review >> - a series of supporting libraries for tests under: >> test/langtools/lib/combo/tools/javac/combo with also the tests that >> needed to be modified due to changes in the lib. These changes were >> created by Brian >> - a minor change done at ToolBox.java >> >> Thanks for all the feedback, >> Vicente >> >> >> [1] >> http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.03/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri Nov 1 13:12:13 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 1 Nov 2019 14:12:13 +0100 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: <9f8607fd-9fab-cc7a-9b0b-8913887df893@oracle.com> References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> <9f8607fd-9fab-cc7a-9b0b-8913887df893@oracle.com> Message-ID: <7ebb480f-bbcb-2ac0-ce9a-73e5888f5df4@oracle.com> On 01. 11. 19 13:56, Maurizio Cimadamore wrote: > Also, while experimenting, I noted that compiling code like: > > record Foo(String s) { } > > Without the --enable-preview flag, causes a spurious parser error, with > no clue that I'm using a preview feature: > > Test.java:1: error: class, interface, or enum expected > record Foo(String s) { > ^ > 1 error > > Is that expected? I believe the issue is with 'isRecordToken' which > always returns 'false' if preview features are disabled. I think > something should call checkSourceLevel(Feature.RECORDS), so that preview > errors for records will be triggered. I think I was touching that in one of my comments. I am afraid it is probably not so simple - we could do the checks easily for top-level records, but not so easily for nested records. I.e.: --- class X { record R(int i) { return null; } } class record {} --- is valid currently ("R" is a method which returns "record"), but not with the patch: --- $ javac /tmp/R.java /tmp/R.java:2: error: records are a preview feature and are disabled by default. record R(int i) { ^ (use --enable-preview to enable records) /tmp/R.java:3: error: illegal start of type return null; ^ /tmp/R.java:6: warning: 'record' may become a restricted type name in a future release and may be unusable for type declarations or as the element type of an array class record {} ^ 2 errors 1 warning --- I suspect it may be necessary to only add a warning/note for the suspected records, with a possible special-case for top-level records failing with a more appropriate error. Jan > > And, looking more, I see some issues with parsing inside blocks - for > instance, this program no longer compiles (w/o enable-preview): > > class Foo { > ??? void test() { > ??????? final record r = null; > ??? } > } > > class record {} > > That's because when we're inside a method body, we always interpret > 'final record' as a record declaration. > > A better solution would be to always check (with lookahead) for "record > IDENT '('". That should be more robust. > > > In other words, I think that the parser code should be consolidated so > that you have a single routine that checks for the start of a record > declaration: > > record IDENT '(' > > If the above production is matched (with lookahead), then you call > checkSourceLevel(Feature.RECORDS), so that the correct errors are > generated. > > The routine could be something like this: > > boolean isRecordStart() { > ???? if (token.kind == IDENTIFIER && token.name() == names.record && > ??????????? (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) || > ???????????? peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) { > ????????? checkSourceLevel(Feature.RECORDS); > ????????? return true; > ??? } else { > ?????? return false; > ?? } > } > > Then you remove isRecordToken, and start to use the above everywhere. I > tried with a crude patch (see below), and things seem to work much > better. Examples: > > record foo(int x) {} > > gives: > > Test.java:1: error: records are a preview feature and are disabled by > default. > record foo(int x) {} > ^ > ? (use --enable-preview to enable records) > 1 error > > And, this: > > class Foo { > ??? void test() { > ??????? final record r = null; > ??? } > } > > class record {} > > Gives the following: > > Test.java:3: warning: 'record' may become a restricted type name in a > future release and may be unusable for type declarations or as the > element type of an array > ??????? final record r = null; > ???????????????????? ^ > Test.java:7: warning: 'record' may become a restricted type name in a > future release and may be unusable for type declarations or as the > element type of an array > class record {} > ????? ^ > 2 warnings > > > Which I think it's closer to what we want. > > Patch below: > > diff -r 1da4a8addd21 > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.javaThu > Oct 31 23:59:56 2019 -0400 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.javaFri > Nov 01 12:53:31 2019 +0000 > @@ -2558,7 +2558,7 @@ > ???????????? if (token.kind == INTERFACE || > ???????????????? token.kind == CLASS || > ???????????????? token.kind == ENUM || > -??????????????? (token.kind == IDENTIFIER && token.name() == > names.record) ) { > +??????????????? isRecordStart()) { > ???????????????? return > List.of(classOrRecordOrInterfaceOrEnumDeclaration(mods, dc)); > ???????????? } else { > ???????????????? JCExpression t = parseType(true); > @@ -2625,9 +2625,7 @@ > ???????????????? //else intentional fall-through > ???????????? } > ???????? } > -??????? if (isRecordToken() && > -??????????? (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) || > -???????????? peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) { > +??????? if (isRecordStart()) { > ???????????? dc = token.comment(CommentStyle.JAVADOC); > ???????????? return List.of(recordDeclaration(F.at(pos).Modifiers(0), > dc)); > ???????? } else { > @@ -3661,7 +3659,7 @@ > ???? protected JCStatement > classOrRecordOrInterfaceOrEnumDeclaration(JCModifiers mods, Comment dc) { > ???????? if (token.kind == CLASS) { > ???????????? return classDeclaration(mods, dc); > -??????? } if (isRecordToken()) { > +??????? } if (isRecordStart()) { > ???????????? return recordDeclaration(mods, dc); > ???????? } else if (token.kind == INTERFACE) { > ???????????? return interfaceDeclaration(mods, dc); > @@ -4022,7 +4020,7 @@ > ???????????? int pos = token.pos; > ???????????? JCModifiers mods = modifiersOpt(); > ???????????? if (token.kind == CLASS || > -??????????????? isRecordToken() || > +??????????????? isRecordStart() || > ???????????????? token.kind == INTERFACE || > ???????????????? token.kind == ENUM) { > ???????????????? return > List.of(classOrRecordOrInterfaceOrEnumDeclaration(mods, dc)); > @@ -4117,9 +4115,16 @@ > ???????? } > ???? } > > -??? boolean isRecordToken() { > -??????? return allowRecords && token.kind == IDENTIFIER && token.name() > == names.record; > -??? } > +??? boolean isRecordStart() { > +???? if (token.kind == IDENTIFIER && token.name() == names.record && > +??????????? (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) || > +???????????? peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) { > +????????? checkSourceLevel(Feature.RECORDS); > +????????? return true; > +??? } else { > +?????? return false; > +?? } > +} > > ???? /** MethodDeclaratorRest = > ????? *????? FormalParameters BracketsOpt [THROWS TypeList] ( > MethodBody | [DEFAULT AnnotationValue] ";") > > > Cheers > Maurizio > From maurizio.cimadamore at oracle.com Fri Nov 1 13:18:44 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 1 Nov 2019 13:18:44 +0000 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: <7ebb480f-bbcb-2ac0-ce9a-73e5888f5df4@oracle.com> References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> <9f8607fd-9fab-cc7a-9b0b-8913887df893@oracle.com> <7ebb480f-bbcb-2ac0-ce9a-73e5888f5df4@oracle.com> Message-ID: <97d2b883-8df4-dd6e-cad4-e2ad5982a92c@oracle.com> On 01/11/2019 13:12, Jan Lahoda wrote: > On 01. 11. 19 13:56, Maurizio Cimadamore wrote: >> Also, while experimenting, I noted that compiling code like: >> >> record Foo(String s) { } >> >> Without the --enable-preview flag, causes a spurious parser error, >> with no clue that I'm using a preview feature: >> >> Test.java:1: error: class, interface, or enum expected >> record Foo(String s) { >> ^ >> 1 error >> >> Is that expected? I believe the issue is with 'isRecordToken' which >> always returns 'false' if preview features are disabled. I think >> something should call checkSourceLevel(Feature.RECORDS), so that >> preview errors for records will be triggered. > > I think I was touching that in one of my comments. I am afraid it is > probably not so simple - we could do the checks easily for top-level > records, but not so easily for nested records. I.e.: > --- > class X { > ??? record R(int i) { > ??????? return null; > ??? } > } > class record {} > --- > > is valid currently ("R" is a method which returns "record"), but not > with the patch: Good point. So, I think the patch fixes the treatment of toplevel and local records. Where it leaves something to be desired, as you point out, is with member records (e.g. records nested inside a class declaration). Here the grammar is inherently ambiguous with method declarations, so not much we can do (we can probably do something if there's a generic record though). In this cases we should just take the record production or the method one, depending on whether preview features are enabled or not. Maurizio > --- > $ javac /tmp/R.java > /tmp/R.java:2: error: records are a preview feature and are disabled > by default. > record R(int i) { > ^ > ? (use --enable-preview to enable records) > /tmp/R.java:3: error: illegal start of type > return null; > ^ > /tmp/R.java:6: warning: 'record' may become a restricted type name in > a future release and may be unusable for type declarations or as the > element type of an array > class record {} > ????? ^ > 2 errors > 1 warning > --- > > I suspect it may be necessary to only add a warning/note for the > suspected records, with a possible special-case for top-level records > failing with a more appropriate error. > > Jan > >> >> And, looking more, I see some issues with parsing inside blocks - for >> instance, this program no longer compiles (w/o enable-preview): >> >> class Foo { >> ???? void test() { >> ???????? final record r = null; >> ???? } >> } >> >> class record {} >> >> That's because when we're inside a method body, we always interpret >> 'final record' as a record declaration. >> >> A better solution would be to always check (with lookahead) for >> "record IDENT '('". That should be more robust. >> >> >> In other words, I think that the parser code should be consolidated >> so that you have a single routine that checks for the start of a >> record declaration: >> >> record IDENT '(' >> >> If the above production is matched (with lookahead), then you call >> checkSourceLevel(Feature.RECORDS), so that the correct errors are >> generated. >> >> The routine could be something like this: >> >> boolean isRecordStart() { >> ????? if (token.kind == IDENTIFIER && token.name() == names.record && >> ???????????? (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) || >> ????????????? peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) { >> ?????????? checkSourceLevel(Feature.RECORDS); >> ?????????? return true; >> ???? } else { >> ??????? return false; >> ??? } >> } >> >> Then you remove isRecordToken, and start to use the above everywhere. >> I tried with a crude patch (see below), and things seem to work much >> better. Examples: >> >> record foo(int x) {} >> >> gives: >> >> Test.java:1: error: records are a preview feature and are disabled by >> default. >> record foo(int x) {} >> ^ >> ?? (use --enable-preview to enable records) >> 1 error >> >> And, this: >> >> class Foo { >> ???? void test() { >> ???????? final record r = null; >> ???? } >> } >> >> class record {} >> >> Gives the following: >> >> Test.java:3: warning: 'record' may become a restricted type name in a >> future release and may be unusable for type declarations or as the >> element type of an array >> ???????? final record r = null; >> ????????????????????? ^ >> Test.java:7: warning: 'record' may become a restricted type name in a >> future release and may be unusable for type declarations or as the >> element type of an array >> class record {} >> ?????? ^ >> 2 warnings >> >> >> Which I think it's closer to what we want. >> >> Patch below: >> >> diff -r 1da4a8addd21 >> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java >> --- >> a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.javaThu >> Oct 31 23:59:56 2019 -0400 >> +++ >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.javaFri >> Nov 01 12:53:31 2019 +0000 >> @@ -2558,7 +2558,7 @@ >> ????????????? if (token.kind == INTERFACE || >> ????????????????? token.kind == CLASS || >> ????????????????? token.kind == ENUM || >> -??????????????? (token.kind == IDENTIFIER && token.name() == >> names.record) ) { >> +??????????????? isRecordStart()) { >> ????????????????? return >> List.of(classOrRecordOrInterfaceOrEnumDeclaration(mods, dc)); >> ????????????? } else { >> ????????????????? JCExpression t = parseType(true); >> @@ -2625,9 +2625,7 @@ >> ????????????????? //else intentional fall-through >> ????????????? } >> ????????? } >> -??????? if (isRecordToken() && >> -??????????? (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) || >> -???????????? peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) { >> +??????? if (isRecordStart()) { >> ????????????? dc = token.comment(CommentStyle.JAVADOC); >> ????????????? return >> List.of(recordDeclaration(F.at(pos).Modifiers(0), dc)); >> ????????? } else { >> @@ -3661,7 +3659,7 @@ >> ????? protected JCStatement >> classOrRecordOrInterfaceOrEnumDeclaration(JCModifiers mods, Comment >> dc) { >> ????????? if (token.kind == CLASS) { >> ????????????? return classDeclaration(mods, dc); >> -??????? } if (isRecordToken()) { >> +??????? } if (isRecordStart()) { >> ????????????? return recordDeclaration(mods, dc); >> ????????? } else if (token.kind == INTERFACE) { >> ????????????? return interfaceDeclaration(mods, dc); >> @@ -4022,7 +4020,7 @@ >> ????????????? int pos = token.pos; >> ????????????? JCModifiers mods = modifiersOpt(); >> ????????????? if (token.kind == CLASS || >> -??????????????? isRecordToken() || >> +??????????????? isRecordStart() || >> ????????????????? token.kind == INTERFACE || >> ????????????????? token.kind == ENUM) { >> ????????????????? return >> List.of(classOrRecordOrInterfaceOrEnumDeclaration(mods, dc)); >> @@ -4117,9 +4115,16 @@ >> ????????? } >> ????? } >> >> -??? boolean isRecordToken() { >> -??????? return allowRecords && token.kind == IDENTIFIER && >> token.name() == names.record; >> -??? } >> +??? boolean isRecordStart() { >> +???? if (token.kind == IDENTIFIER && token.name() == names.record && >> +??????????? (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) || >> +???????????? peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) { >> +????????? checkSourceLevel(Feature.RECORDS); >> +????????? return true; >> +??? } else { >> +?????? return false; >> +?? } >> +} >> >> ????? /** MethodDeclaratorRest = >> ?????? *????? FormalParameters BracketsOpt [THROWS TypeList] ( >> MethodBody | [DEFAULT AnnotationValue] ";") >> >> >> Cheers >> Maurizio >> From maurizio.cimadamore at oracle.com Fri Nov 1 15:11:24 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 1 Nov 2019 15:11:24 +0000 Subject: RFR: JDK-8230847: Trees.getScope may crash when invoked for statement inside switch. In-Reply-To: References: Message-ID: <7ad99cfb-ac79-79ea-78fe-da76fd786eac@oracle.com> Looks ok. I personally would rename attribIsolated to attribSpeculative (e.g. add another overload) unless it clashes? Maurizio On 12/09/2019 10:30, Jan Lahoda wrote: > Hi, > > There are some cases where the Trees.getScope may misbehave: > -consider code like this: > switch (i) { > ???? case 0: > ???????? String.valueOf(0); //calling getScope on this place > ???????? int i; > ???????? break; > } > > javac will create a copy the tree, attribute it, and stop the > attribution at the specified place by throwing BreakAttr. But in the > case above, Attr.handleSwitch will invoke Attr.addVars (in a finally), > which will try to add the "int i;"'s symbol into a Scope, which fails, > as that variable is not attributed. The proposed solution is to simply > not call addVars if an exception is thrown, by moving the call out of > the current finally block. > > -the attribution when a scope is being computed is not running with a > ArgumentAttr.withLocalCacheContext(), which may lead to the cache > pollution, and trouble for further getScope (or other attribution) > invocations (see the testMemberRefs() test). The proposal is to run > with the withLocalCacheContext(), but as a more general approach, I > tried to reuse as much as possible from the speculative attribution > for Scope computation, as was proposed some time back. > > -there is a corner case, where if the BreakAttr is thrown while > attribution an annotation's type, Annotate.flush() may not finish, and > there may be remaining tasks in the Annotate queues, which may fail on > subsequent flushes (possibly due to subsequent invocations of > getScope()). The proposed solution here is to save and restore the > queues for the isolated/speculative attributions. In the current > patch, this is being done for all speculative attributions, but if > that would be too dangerous, we could move that to getScope > computation only. (See tests testAnnotations() and > testAnnotationsLazy().) > > -there is a corner case, where calling getScope inside an initializer > of a class that depends on itself (i.e. has a cyclic dependency) may > crash, as the initializer is not properly recognized as an > initializer. The proposed solution is to recognize initializers in > erroneous classes as intializers. > > > Proposed webrev: > http://cr.openjdk.java.net/~jlahoda/8230847/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8230847 > > How does this look? > > Thanks, > ??? Jan From alex.buckley at oracle.com Fri Nov 1 17:38:55 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 1 Nov 2019 10:38:55 -0700 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> Message-ID: <6a37a5e8-457f-b9c2-eb68-6e980fa65da8@oracle.com> On 11/1/2019 5:06 AM, Maurizio Cimadamore wrote: > "first statement of this constructor must invoke another constructor" > > This has two problems, I think: > > 1) "statement .... must invoke" - a statement does not invoke; maybe > rephrase as "first statement ... must be a constructor invocation" > > 2) we don't have a blessed term to name a non-canonical constructor. Can > we just say non-canonical in the diagnostic? E.g. > > "the first statement in a non-canonical constructor must be an > invocation of another constructor" > > Seems a mouthful. > > I noted that we have this diagnostic around: > > # 0: name > 230 compiler.err.call.must.be.first.stmt.in.ctor=\ > 231 call to {0} must be first statement in constructor > > Perhaps, inspired by this, we can turn this around and do this: > > "First statement in non-canonical constructor must be a call to 'this'" ? > > This seems more compact. This weird corner of the language (JLS 8.8.7.1, which should be cross-ref'd from the penultimate bullet of 8.10.4) DOES have statements that invoke: ----- Explicit constructor invocation statements are divided into two kinds: - Alternate constructor invocations begin with the keyword `this` ... used to invoke an alternate constructor of the same class. ----- These "invocation statements" are weird: despite the s-word, they are not capital-S "Statements" as defined in chapter 14, and despite the i-word, they are not method invocation expressions as defined in chapter 15. They are so weird that even their most colloquial, snappy description -- "a call to 'this'`" -- is weird. It makes sense if you SAY it to yourself when writing a program, but I think it's hard to READ -- "A call to this what? This constructor? This class?" I therefore recommend the following message, which tiptoes around the ugly term "non-canonical": "error: constructor is not canonical, so its first statement must invoke another constructor" Alex From ksrinifmt at gmail.com Sat Nov 2 15:12:26 2019 From: ksrinifmt at gmail.com (Kumar Srinivasan) Date: Sat, 2 Nov 2019 08:12:26 -0700 Subject: RFR: JEP 359-Records: javadoc code In-Reply-To: References: <914ab35b-ff07-1b9e-472c-9a04f7bc49dc@oracle.com> Message-ID: Hi Jon, Firstly I must commend the javadoc.next project for updating javadoc/doclet to use jx.l.m and other improvements to the doc comments management, this has made it relatively easy for javadoc to implement new language features, such as this. Having said that, the changes are looking great, and the langtools stalwarts have done due diligence. Here are some minor review comments, I don't need to see another revision. Default webrev: src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java Likely search/replace - * Keep track of whether or not this typeElement is an record. + * Keep track of whether or not this typeElement is a record. - // only one canonical constructor; no longer need to keep looking + // only one canonical constructor; no need to keep looking - TypeMirror objectType = utils.elementUtils.getTypeElement("java.lang.Object").asType(); + TypeMirror objectType = utils.getObjectType(); There is a symbol table cache maintained in Utils, for performance improvements. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java Nice simplifications to modifiersToString. With the Element ordering changes (ElementComparator) I thought this might cause failures in TestOrdering, I guess the previous ordering are being preserved, but there are no Records elements in this test ? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/CommentUtils.java + private void add(List contents, String resourceKey) {+ // Special case to allow '{@link ...}' to appear in the string.+ // A less general case would be to detect literal use of Object.equals+ // A more general case would be to allow access to DocCommentParser somehow Yes the church vs. state rule, I don't quite understand the problem we are trying solve with this code. + * name is to be inserted. T+ * @param key the resource key for the description Looks like we have a hanging "T". One last thing, was the doc comparator run ? The reason I ask, there seems to be unrelated improvements ex: Utils::modifiersToString etc, not sure if regressions are lurking in the output. Best, Kumar Srinivasan PS: I will have to go into radio silence for some time. On Wed, Oct 30, 2019 at 4:54 PM Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Please review a moderately small update to the proposed support for > records in javadoc. > > The primary change is to include record components in the signature of a > record displayed near the top of the page. > > In addition, a "combo test" is added into TestRecordTypes.java to verify > the presence or absence of annotations in various places in the > generated page for a record, depending on the `@Target` of the annotations. > > Finally, there are some small cosmetic changes, and the supporting files > for some previously published examples. > > Two webrevs are provided. > > The first is a cumulative webrev of the modified javadoc source and test > files, compared against the default branch of the amber repo (i.e. the > state of the jdk/jdk repo) > http://cr.openjdk.java.net/~jjg/amber-records/webrev.default/ > > The second is a "delta webrev" of the recently modified javadoc source > and test files, compared against the tip of the records branch of the > amber repo. > http://cr.openjdk.java.net/~jjg/amber-records/webrev.tip/ > > Also, the sets of examples are updated, showing examples linked and not > linked to JDK API docs > http://cr.openjdk.java.net/~jjg/amber-records/examples/api-with-link/ > http://cr.openjdk.java.net/~jjg/amber-records/examples/api-no-link/ > > Finally, I note a curiosity, arising from the proposed spec. This is > the first occurrence that I can think of in which an item that is > syntactically necessary in the source code does /not/ show up in the > same place in the generated documentation. In general, in previous > instances where the documented signatures differ from the source code, > the difference has been the addition of default or mandated elements. > Here, the presence of an annotation on the declaration of a record > component in source code may not show up in the corresponding place in > the documented signature, depending on the specified @Target for the > annotation. I'm not saying that's wrong, but it is curious, and may need > explaining to some. > > -- Jon > > JEP 359: https://openjdk.java.net/jeps/359 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Mon Nov 4 05:33:50 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 3 Nov 2019 21:33:50 -0800 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> Message-ID: <1fb0a88c-5d40-475e-984b-570806fd73b4@oracle.com> Hi Vicente, I've taken a pass over the javax.lang.model portions of the change. Elements.recordComponentFor should have an @implSpec tag. I suggest a double-check of the existing visitors/scanners that used to extend one of the "FooVisitor9" types and was updated to extend "FooVisitor14". In prior work, I had to add a new method override for visitRecordComponent to the printing processor to get the proper semantics of that class. For example, PubapiVisitor might need an update. Also, please add the new "FooVisitor14" classes for types. In terms of how the tests are placed, I'd prefer to see tests of, say annotation processing of records, groups with the existing annotation processing tests as opposed to grouped with pure records tests. I think this arrangement provides better test discoverability long term; for example, if someone is updating annotation processing and wants to make sure all the annotation processing tests are run. I recommend the annotation processing tests more consistently subclass JavaTestingAbstractProcessor as opposed to directly subclassing AbstractProcessor. In TestRecord.java, please add newlines to the string arguments to the options method on line 146. Thanks, -Joe On 10/31/2019 9:11 PM, Vicente Romero wrote: > Hi all, > > Thanks for all the feedback so far. I have published another iteration > at [1]. New in this iteration: > > Flags.java: > > - I have sync the javadoc and the comment on the RECORD flag > - renamed MemberRecordClassFlags -> MemberRecordFlags > > com.sun.tools.javac.code.Kinds.java: > - in order to generate better error messages I have added two new > kinds: RECORD_COMPONENT and RECORD > > Symbols.java > - moved method isRecord to ClassSymbol for the rest of the symbols > moved back to using the bitwise test > - removed method ::isDynamic from MethodSymbol > > Attr.java > - implemented a spec change to relax that constraint that every > non-canonical constructor should call the canonical constructor. Now > the spec forces every non-canonical constructor to invoke a different > constructor as its first statement. This actually implied removing > some code. > > Check.java > - at method ::duplicateError, there is new code to avoid generating > two errors when the user declares a record with duplicated record > component names. If this happens, then a compiler generated canonical > constructor would have duplicated parameters. This code is preventing > the compiler to generate a second error referring to a method that is > not visible to the user. Another option is to not generate the > canonical constructor at all if there are duplicate record components > - at method ::checkUnique, there is new code to improve the error > message when the user defines a constructor with the same erasure as > the canonical constructor. Still the error message is not perfect > because it shows in both cases the erasure of the methods, so they > seem to be the same. But this is not related to records code, that's a > simplification that happens at the moment of reporting the error. > > TypeEnter > - removed some commented code > - ::addRecordMembersIfNeeded here I added new code to avoid generating > accessor methods for forbidden record component names. This is to > avoid spurious errors later as any way the compiler will complain > because of the forbidden record component names. The issue with this > solution is that the list of forbidden record component names has been > duplicated here. The other location is Attr. We can probably find a > common place to define it. Probably a new utility class? > > JavacParser: > - fixed the bug that the compiler was not allowing final local records > - removed the check for abstract modifiers in records, this code was > redundant as Check was already checking this > - removed the check for duplicated record component names > - added a check to forbid instance initializers in records > > compiler.properties > - I hope I got the error messages right, I tried to reflect all the > comments, suggestions, etc. I was proposed to create a `master` > message for canonical records and use different `causes`, aka > fragments, to be more specific. I decided to follow the same pattern > for accessor methods. Regarding the suggestion of placing the caret in > the throws clause for the corresponding error message, not possible. > We would have to move the check for that error to the parser. > > New in this iteration: > - I have included jdeps related code, I was thinking about putting it > in a separate review bucket but, it is small, it kind of fits with the > rest of the review > - a series of supporting libraries for tests under: > test/langtools/lib/combo/tools/javac/combo with also the tests that > needed to be modified due to changes in the lib. These changes were > created by Brian > - a minor change done at ToolBox.java > > Thanks for all the feedback, > Vicente > > > [1] > http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.03/ From jan.lahoda at oracle.com Mon Nov 4 10:00:09 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 4 Nov 2019 11:00:09 +0100 Subject: RFR: JDK-8230847: Trees.getScope may crash when invoked for statement inside switch. In-Reply-To: <7ad99cfb-ac79-79ea-78fe-da76fd786eac@oracle.com> References: <7ad99cfb-ac79-79ea-78fe-da76fd786eac@oracle.com> Message-ID: On 01. 11. 19 16:11, Maurizio Cimadamore wrote: > Looks ok. I personally would rename attribIsolated to attribSpeculative > (e.g. add another overload) unless it clashes? Thanks - I've renamed the method, and pushed the patch. Jan > > Maurizio > > On 12/09/2019 10:30, Jan Lahoda wrote: >> Hi, >> >> There are some cases where the Trees.getScope may misbehave: >> -consider code like this: >> switch (i) { >> ???? case 0: >> ???????? String.valueOf(0); //calling getScope on this place >> ???????? int i; >> ???????? break; >> } >> >> javac will create a copy the tree, attribute it, and stop the >> attribution at the specified place by throwing BreakAttr. But in the >> case above, Attr.handleSwitch will invoke Attr.addVars (in a finally), >> which will try to add the "int i;"'s symbol into a Scope, which fails, >> as that variable is not attributed. The proposed solution is to simply >> not call addVars if an exception is thrown, by moving the call out of >> the current finally block. >> >> -the attribution when a scope is being computed is not running with a >> ArgumentAttr.withLocalCacheContext(), which may lead to the cache >> pollution, and trouble for further getScope (or other attribution) >> invocations (see the testMemberRefs() test). The proposal is to run >> with the withLocalCacheContext(), but as a more general approach, I >> tried to reuse as much as possible from the speculative attribution >> for Scope computation, as was proposed some time back. >> >> -there is a corner case, where if the BreakAttr is thrown while >> attribution an annotation's type, Annotate.flush() may not finish, and >> there may be remaining tasks in the Annotate queues, which may fail on >> subsequent flushes (possibly due to subsequent invocations of >> getScope()). The proposed solution here is to save and restore the >> queues for the isolated/speculative attributions. In the current >> patch, this is being done for all speculative attributions, but if >> that would be too dangerous, we could move that to getScope >> computation only. (See tests testAnnotations() and >> testAnnotationsLazy().) >> >> -there is a corner case, where calling getScope inside an initializer >> of a class that depends on itself (i.e. has a cyclic dependency) may >> crash, as the initializer is not properly recognized as an >> initializer. The proposed solution is to recognize initializers in >> erroneous classes as intializers. >> >> >> Proposed webrev: >> http://cr.openjdk.java.net/~jlahoda/8230847/webrev.00/ >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8230847 >> >> How does this look? >> >> Thanks, >> ??? Jan From vicente.romero at oracle.com Mon Nov 4 13:55:27 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 4 Nov 2019 08:55:27 -0500 Subject: Fwd: RFR: CSR for Compiler implementation for records In-Reply-To: References: Message-ID: Forwarding to compiler-dev Vicente -------- Forwarded Message -------- Subject: RFR: CSR for Compiler implementation for records Date: Sun, 3 Nov 2019 12:13:45 -0500 From: Vicente Romero To: Amber dev Hi, Please review the draft of the CSR for Compiler implementation for records at [1] Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8233433 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Nov 4 20:53:09 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 4 Nov 2019 15:53:09 -0500 Subject: RFR: CSR for Compiler implementation for records In-Reply-To: <1c3a6e90-a7fb-97aa-828a-93929d88b442@oracle.com> References: <1c3a6e90-a7fb-97aa-828a-93929d88b442@oracle.com> Message-ID: <43c69224-ff98-afff-df58-c2b416545d60@oracle.com> Hi Alex, Thanks for your comments, I have modified the CSR, does it look better now? Thanks, Vicente On 11/4/19 2:26 PM, Alex Buckley wrote: > Usually, I want a CSR's Solution to break down the new language > feature -- for example, see the original CSR for switch expressions > JDK-8207241, where the Solution sketches the actual changes, not just > "allow switch as an expression kthxbai". However, in the case of > record classes, the Solution is legitimately self-contained -- support > record classes! -- so no need for a break-down. That said, the phrase > "for a fixed set of values" is confusing because it suggests enum-like > behavior (the same phrase in the Summary is not confusing because it > has a qualifier). Also "Add records classes". > > Alex > > On 11/3/2019 9:13 AM, Vicente Romero wrote: >> Hi, >> >> Please review the draft of the CSR for Compiler implementation for >> records at [1] >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8233433 From alex.buckley at oracle.com Mon Nov 4 21:59:46 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 4 Nov 2019 13:59:46 -0800 Subject: RFR: CSR for Compiler implementation for records In-Reply-To: <43c69224-ff98-afff-df58-c2b416545d60@oracle.com> References: <1c3a6e90-a7fb-97aa-828a-93929d88b442@oracle.com> <43c69224-ff98-afff-df58-c2b416545d60@oracle.com> Message-ID: I edited "Add records classes" to say "Add record classes". I also turned a "very low" into just a "low" in the Compatibility Risk Description; more could be written about which aspects of records are most likely to change due to feedback, but there are diminishing returns from spending on this CSR. Added myself as a reviewer. Alex On 11/4/2019 12:53 PM, Vicente Romero wrote: > Hi Alex, > > Thanks for your comments, I have modified the CSR, does it look better now? > > Thanks, > Vicente > > On 11/4/19 2:26 PM, Alex Buckley wrote: >> Usually, I want a CSR's Solution to break down the new language >> feature -- for example, see the original CSR for switch expressions >> JDK-8207241, where the Solution sketches the actual changes, not just >> "allow switch as an expression kthxbai". However, in the case of >> record classes, the Solution is legitimately self-contained -- support >> record classes! -- so no need for a break-down. That said, the phrase >> "for a fixed set of values" is confusing because it suggests enum-like >> behavior (the same phrase in the Summary is not confusing because it >> has a qualifier). Also "Add records classes". >> >> Alex >> >> On 11/3/2019 9:13 AM, Vicente Romero wrote: >>> Hi, >>> >>> Please review the draft of the CSR for Compiler implementation for >>> records at [1] >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8233433 > From jan.lahoda at oracle.com Tue Nov 5 09:50:21 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 5 Nov 2019 10:50:21 +0100 Subject: RFR: JDK-8232684: Make switch expressions final In-Reply-To: References: Message-ID: I've missed updates to some hotspot and jdk tests in the first patch. The problem are unqualified invocations of Thread.yield(), which are no longer allowed (from the spec: JLS 3.9 Keywords: "All invocations of a method called yield must be qualified so as to be distinguished from a yield statement."). Therefore, these invocations need to be changed to qualified invocations (i.e. Thread.yield()). Updates to the hotspot and jdk tests are here: http://cr.openjdk.java.net/~jlahoda/8232684/webrev.delta.00.01/ Full updated webrev, with changes to both javac and the tests, is here: http://cr.openjdk.java.net/~jlahoda/8232684/webrev.01/ How does that look? Thanks, Jan On 21. 10. 19 16:17, Maurizio Cimadamore wrote: > Looks generally good -? went through the test updates one by one and > they look ok, except this: > > http://cr.openjdk.java.net/~jlahoda/8232684/webrev.00/test/langtools/tools/jdeps/listdeps/ListModuleDeps.java.udiff.html > > > Which you explained to me offline (we need to change this code every > time the compiler stops using the @Preview annotation - ugh). Nothing > specific to this webrev, so I approve. > > Maurizio > > On 21/10/2019 14:49, Jan Lahoda wrote: >> Hi, >> >> As part of preparation for proposing JEP 361: Switch Expressions >> (Standard) to target, I would like to ask for a review of the patch to >> make switch expression a non-preview feature in javac: >> http://cr.openjdk.java.net/~jlahoda/8232684/webrev.00/ >> >> The patch basically removes the feature from the list of preview >> features, updates test to this new state (removes --enable-preview >> from associated tests, and adjusts their expected output), and removes >> the @PreviewFeature annotation and associated text from the javadoc of >> the Trees API. >> >> I also would like to ask for a review for the CSR associated with that: >> https://bugs.openjdk.java.net/browse/JDK-8232685 >> >> Reviews/comments on either of these would be very welcome! >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8232684 >> >> Thanks! >> >> Jan From james.laskey at oracle.com Tue Nov 5 13:58:12 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 5 Nov 2019 09:58:12 -0400 Subject: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) Message-ID: Please review the following CSR. Provides for the introduction of two new escape sequences \ and \s. \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for tab. Thank you. Cheers, - Jim CSR: https://bugs.openjdk.java.net/browse/JDK-8233117 From james.laskey at oracle.com Tue Nov 5 15:40:37 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 5 Nov 2019 11:40:37 -0400 Subject: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) In-Reply-To: References: Message-ID: <88096622-1959-4064-A656-76DC3A25729B@oracle.com> I'm withdrawing until it is the correct format. Apologies. > On Nov 5, 2019, at 9:58 AM, Jim Laskey wrote: > > Please review the following CSR. Provides for the introduction of two new escape sequences \ and \s. \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for tab. > > Thank you. > > Cheers, > > - Jim > > CSR: https://bugs.openjdk.java.net/browse/JDK-8233117 > From hannes.wallnoefer at oracle.com Tue Nov 5 16:19:51 2019 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 5 Nov 2019 17:19:51 +0100 Subject: RFR: JEP 359-Records: javadoc code In-Reply-To: References: <914ab35b-ff07-1b9e-472c-9a04f7bc49dc@oracle.com> Message-ID: <4C10CBFA-ACB5-493B-8A52-ABAE363AB7B7@oracle.com> Jon, Both the code and the generated documentation look good to me. A minor issue I noticed with the default branch patch is that it adds quite a few unused imports in TagletWriterImpl, ClassBuilder, and TagletWriter. Hannes > Am 31.10.2019 um 00:50 schrieb Jonathan Gibbons : > > Please review a moderately small update to the proposed support for records in javadoc. > > The primary change is to include record components in the signature of a record displayed near the top of the page. > > In addition, a "combo test" is added into TestRecordTypes.java to verify the presence or absence of annotations in various places in the generated page for a record, depending on the `@Target` of the annotations. > > Finally, there are some small cosmetic changes, and the supporting files for some previously published examples. > > Two webrevs are provided. > > The first is a cumulative webrev of the modified javadoc source and test files, compared against the default branch of the amber repo (i.e. the state of the jdk/jdk repo) > http://cr.openjdk.java.net/~jjg/amber-records/webrev.default/ > > The second is a "delta webrev" of the recently modified javadoc source and test files, compared against the tip of the records branch of the amber repo. > http://cr.openjdk.java.net/~jjg/amber-records/webrev.tip/ > > Also, the sets of examples are updated, showing examples linked and not linked to JDK API docs > http://cr.openjdk.java.net/~jjg/amber-records/examples/api-with-link/ > http://cr.openjdk.java.net/~jjg/amber-records/examples/api-no-link/ > > Finally, I note a curiosity, arising from the proposed spec. This is the first occurrence that I can think of in which an item that is syntactically necessary in the source code does /not/ show up in the same place in the generated documentation. In general, in previous instances where the documented signatures differ from the source code, the difference has been the addition of default or mandated elements. Here, the presence of an annotation on the declaration of a record component in source code may not show up in the corresponding place in the documented signature, depending on the specified @Target for the annotation. I'm not saying that's wrong, but it is curious, and may need explaining to some. > > -- Jon > > JEP 359: https://openjdk.java.net/jeps/359 > From jonathan.gibbons at oracle.com Tue Nov 5 16:26:44 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 5 Nov 2019 08:26:44 -0800 Subject: RFR: JEP 359-Records: javadoc code In-Reply-To: <4C10CBFA-ACB5-493B-8A52-ABAE363AB7B7@oracle.com> References: <914ab35b-ff07-1b9e-472c-9a04f7bc49dc@oracle.com> <4C10CBFA-ACB5-493B-8A52-ABAE363AB7B7@oracle.com> Message-ID: <73e18723-2883-8a75-7ce9-657531091670@oracle.com> Hannes, Thanks, I'll check and fix the imports. -- Jon On 11/5/19 8:19 AM, Hannes Walln?fer wrote: > Jon, > > Both the code and the generated documentation look good to me. > > A minor issue I noticed with the default branch patch is that it adds quite a few unused imports in TagletWriterImpl, ClassBuilder, and TagletWriter. > > Hannes > > >> Am 31.10.2019 um 00:50 schrieb Jonathan Gibbons : >> >> Please review a moderately small update to the proposed support for records in javadoc. >> >> The primary change is to include record components in the signature of a record displayed near the top of the page. >> >> In addition, a "combo test" is added into TestRecordTypes.java to verify the presence or absence of annotations in various places in the generated page for a record, depending on the `@Target` of the annotations. >> >> Finally, there are some small cosmetic changes, and the supporting files for some previously published examples. >> >> Two webrevs are provided. >> >> The first is a cumulative webrev of the modified javadoc source and test files, compared against the default branch of the amber repo (i.e. the state of the jdk/jdk repo) >> http://cr.openjdk.java.net/~jjg/amber-records/webrev.default/ >> >> The second is a "delta webrev" of the recently modified javadoc source and test files, compared against the tip of the records branch of the amber repo. >> http://cr.openjdk.java.net/~jjg/amber-records/webrev.tip/ >> >> Also, the sets of examples are updated, showing examples linked and not linked to JDK API docs >> http://cr.openjdk.java.net/~jjg/amber-records/examples/api-with-link/ >> http://cr.openjdk.java.net/~jjg/amber-records/examples/api-no-link/ >> >> Finally, I note a curiosity, arising from the proposed spec. This is the first occurrence that I can think of in which an item that is syntactically necessary in the source code does /not/ show up in the same place in the generated documentation. In general, in previous instances where the documented signatures differ from the source code, the difference has been the addition of default or mandated elements. Here, the presence of an annotation on the declaration of a record component in source code may not show up in the corresponding place in the documented signature, depending on the specified @Target for the annotation. I'm not saying that's wrong, but it is curious, and may need explaining to some. >> >> -- Jon >> >> JEP 359: https://openjdk.java.net/jeps/359 >> From james.laskey at oracle.com Tue Nov 5 18:00:32 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 5 Nov 2019 14:00:32 -0400 Subject: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) In-Reply-To: <88096622-1959-4064-A656-76DC3A25729B@oracle.com> References: <88096622-1959-4064-A656-76DC3A25729B@oracle.com> Message-ID: <781A9EF0-9117-468E-B102-97CA4338A6EE@oracle.com> Re-proposed. > On Nov 5, 2019, at 11:40 AM, Jim Laskey wrote: > > I'm withdrawing until it is the correct format. Apologies. > > >> On Nov 5, 2019, at 9:58 AM, Jim Laskey wrote: >> >> Please review the following CSR. Provides for the introduction of two new escape sequences \ and \s. \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for tab. >> >> Thank you. >> >> Cheers, >> >> - Jim >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8233117 >> > From forax at univ-mlv.fr Tue Nov 5 18:17:19 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 5 Nov 2019 19:17:19 +0100 (CET) Subject: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) In-Reply-To: <781A9EF0-9117-468E-B102-97CA4338A6EE@oracle.com> References: <88096622-1959-4064-A656-76DC3A25729B@oracle.com> <781A9EF0-9117-468E-B102-97CA4338A6EE@oracle.com> Message-ID: <860162713.1334314.1572977839868.JavaMail.zimbra@u-pem.fr> Hi Jim, the rationale to add \ is well explain but why do you want to introduce \s given we already have \u0020 ? R?mi ----- Mail original ----- > De: "Jim Laskey" > ?: "core-libs-dev" , "compiler-dev" > Envoy?: Mardi 5 Novembre 2019 19:00:32 > Objet: Re: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) > Re-proposed. > >> On Nov 5, 2019, at 11:40 AM, Jim Laskey wrote: >> >> I'm withdrawing until it is the correct format. Apologies. >> >> >>> On Nov 5, 2019, at 9:58 AM, Jim Laskey wrote: >>> >>> Please review the following CSR. Provides for the introduction of two new escape >>> sequences \ and \s. \ allows developers to >>> express unwieldy string literals in a text block as a cluster of short single >>> line segments. The second is to allow developers to express ASCII space, much >>> like \t for tab. >>> >>> Thank you. >>> >>> Cheers, >>> >>> - Jim >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8233117 >>> From alex.buckley at oracle.com Tue Nov 5 18:31:20 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 5 Nov 2019 10:31:20 -0800 Subject: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) In-Reply-To: <860162713.1334314.1572977839868.JavaMail.zimbra@u-pem.fr> References: <88096622-1959-4064-A656-76DC3A25729B@oracle.com> <781A9EF0-9117-468E-B102-97CA4338A6EE@oracle.com> <860162713.1334314.1572977839868.JavaMail.zimbra@u-pem.fr> Message-ID: <56f4901a-c2d8-de86-562f-f9d75aee0b3e@oracle.com> This should be answered in JEP 368, which currently introduces \s with its definition rather than a connecting line back to the final line of the Motivation. JEP 355 had text about the octal escape sequence \040 and now Remi has raised \u0020 -- both should be positioned in 368 as less-clear options for explicit whitespace than a new escape sequence. Syntactic real estate for escape sequences is not in short supply, but there is an element of surprise that we're finally building there. Alex On 11/5/2019 10:17 AM, Remi Forax wrote: > Hi Jim, > the rationale to add \ is well explain but why do you want to introduce \s given we already have \u0020 ? > > R?mi > > ----- Mail original ----- >> De: "Jim Laskey" >> ?: "core-libs-dev" , "compiler-dev" >> Envoy?: Mardi 5 Novembre 2019 19:00:32 >> Objet: Re: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) > >> Re-proposed. >> >>> On Nov 5, 2019, at 11:40 AM, Jim Laskey wrote: >>> >>> I'm withdrawing until it is the correct format. Apologies. >>> >>> >>>> On Nov 5, 2019, at 9:58 AM, Jim Laskey wrote: >>>> >>>> Please review the following CSR. Provides for the introduction of two new escape >>>> sequences \ and \s. \ allows developers to >>>> express unwieldy string literals in a text block as a cluster of short single >>>> line segments. The second is to allow developers to express ASCII space, much >>>> like \t for tab. >>>> >>>> Thank you. >>>> >>>> Cheers, >>>> >>>> - Jim >>>> >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8233117 >>>> From john.r.rose at oracle.com Tue Nov 5 18:35:45 2019 From: john.r.rose at oracle.com (John Rose) Date: Tue, 5 Nov 2019 10:35:45 -0800 Subject: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) In-Reply-To: <860162713.1334314.1572977839868.JavaMail.zimbra@u-pem.fr> References: <88096622-1959-4064-A656-76DC3A25729B@oracle.com> <781A9EF0-9117-468E-B102-97CA4338A6EE@oracle.com> <860162713.1334314.1572977839868.JavaMail.zimbra@u-pem.fr> Message-ID: <504C0B28-C52B-49A3-9604-894EA76F785F@oracle.com> On Nov 5, 2019, at 10:17 AM, Remi Forax wrote: > > the rationale to add \ is well explain but why do you want to introduce \s given we already have \u0020 ? Remi, you are an expert in the field and you got fooled! This is *exactly* why we need \s. The \uXXXX syntax is expanded *before* token scanning, which means that the poor programmer who tries \u0020 will see it stripped by the whitespace stripper. Using \uXXXX where XXXX is an ASCII code point is an anti-pattern! (I think we would help our users if we deprecated it.) You might have said \040, but that too is hard to remember and to read and to use correctly. \s is the answer. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.laskey at oracle.com Tue Nov 5 18:35:39 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 5 Nov 2019 14:35:39 -0400 Subject: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) In-Reply-To: <860162713.1334314.1572977839868.JavaMail.zimbra@u-pem.fr> References: <88096622-1959-4064-A656-76DC3A25729B@oracle.com> <781A9EF0-9117-468E-B102-97CA4338A6EE@oracle.com> <860162713.1334314.1572977839868.JavaMail.zimbra@u-pem.fr> Message-ID: Whereas \u0020 is just another way of expressing space, it also gets consumed by trailing space stripping. Maybe you meant to say we already have \040, which I would reply that you might have the ASCII table memorized but many do not. \s also has brevity on its side. String colors = """ red \040 green \040 blue \040 """; verses String colors = """ red \s green \s blue \s """; Cheers, -- Jim > On Nov 5, 2019, at 2:17 PM, Remi Forax wrote: > > Hi Jim, > the rationale to add \ is well explain but why do you want to introduce \s given we already have \u0020 ? > > R?mi > > ----- Mail original ----- >> De: "Jim Laskey" >> ?: "core-libs-dev" , "compiler-dev" >> Envoy?: Mardi 5 Novembre 2019 19:00:32 >> Objet: Re: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) > >> Re-proposed. >> >>> On Nov 5, 2019, at 11:40 AM, Jim Laskey wrote: >>> >>> I'm withdrawing until it is the correct format. Apologies. >>> >>> >>>> On Nov 5, 2019, at 9:58 AM, Jim Laskey wrote: >>>> >>>> Please review the following CSR. Provides for the introduction of two new escape >>>> sequences \ and \s. \ allows developers to >>>> express unwieldy string literals in a text block as a cluster of short single >>>> line segments. The second is to allow developers to express ASCII space, much >>>> like \t for tab. >>>> >>>> Thank you. >>>> >>>> Cheers, >>>> >>>> - Jim >>>> >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8233117 >>>> From forax at univ-mlv.fr Tue Nov 5 18:48:57 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 5 Nov 2019 19:48:57 +0100 (CET) Subject: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) In-Reply-To: <504C0B28-C52B-49A3-9604-894EA76F785F@oracle.com> References: <88096622-1959-4064-A656-76DC3A25729B@oracle.com> <781A9EF0-9117-468E-B102-97CA4338A6EE@oracle.com> <860162713.1334314.1572977839868.JavaMail.zimbra@u-pem.fr> <504C0B28-C52B-49A3-9604-894EA76F785F@oracle.com> Message-ID: <820257282.1340708.1572979737968.JavaMail.zimbra@u-pem.fr> > De: "John Rose" > ?: "Remi Forax" > Cc: "Jim Laskey" , "compiler-dev" > , "core-libs-dev" > > Envoy?: Mardi 5 Novembre 2019 19:35:45 > Objet: Re: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White > Space (Preview) > On Nov 5, 2019, at 10:17 AM, Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> the rationale to add \ is well explain but why do you want to introduce >> \s given we already have \u0020 ? > Remi, you are an expert in the field and you got fooled! This is *exactly* why > we need \s. > The \uXXXX syntax is expanded *before* token scanning, which means that the poor > programmer > who tries \u0020 will see it stripped by the whitespace stripper. Using \uXXXX > where XXXX is > an ASCII code point is an anti-pattern! (I think we would help our users if we > deprecated it.) I was not thinking of the case where you put a \u0020 inside a text block at the beginning/end of a line :) I still think that i prefer to have a clear delimiter like '|' and a calls to replace('|', ' ') like this private lazy static final String text = """ | this | | is | | fun | """.replace('|', ' '); > You might have said \040, but that too is hard to remember and to read and to > use correctly. > \s is the answer. > ? John R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Tue Nov 5 18:56:20 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 5 Nov 2019 10:56:20 -0800 Subject: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) In-Reply-To: <781A9EF0-9117-468E-B102-97CA4338A6EE@oracle.com> References: <88096622-1959-4064-A656-76DC3A25729B@oracle.com> <781A9EF0-9117-468E-B102-97CA4338A6EE@oracle.com> Message-ID: <002bcba5-4511-83c0-30dc-6001fc0d01d7@oracle.com> I attached text-blocks-jls.html which contains the current unified text blocks + new escape sequences spec. Edited the CSR's Specification section refer specifically to section 3.10.7 of the attachment rather than reproducing some of that section. Made some small edits elsewhere related to having only two bold questions (corresponding to two new escapes) in the Problem. Alex On 11/5/2019 10:00 AM, Jim Laskey wrote: > Re-proposed. > >> On Nov 5, 2019, at 11:40 AM, Jim Laskey wrote: >> >> I'm withdrawing until it is the correct format. Apologies. >> >> >>> On Nov 5, 2019, at 9:58 AM, Jim Laskey wrote: >>> >>> Please review the following CSR. Provides for the introduction of two new escape sequences \ and \s. \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for tab. >>> >>> Thank you. >>> >>> Cheers, >>> >>> - Jim >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8233117 >>> >> > From jonathan.gibbons at oracle.com Tue Nov 5 21:28:52 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 5 Nov 2019 13:28:52 -0800 Subject: RFR: JEP 359-Records: javadoc code In-Reply-To: References: <914ab35b-ff07-1b9e-472c-9a04f7bc49dc@oracle.com> Message-ID: <0571aa0e-7a9b-a231-19f4-c3e91b01c3b6@oracle.com> Hi Kumar, Thanks for the feedback. I'll be posting another webrev shortly. Let me respond here to some of the issues you raise. > + // Special case to allow '{@link ...}' to appear in the string. > + // A less general case would be to detect literal use of Object.equals > + // A more general case would be to allow access to DocCommentParser > somehow > Yes the church vs. state rule, I don't quite understand the problem we > are trying solve with this code. I'm not sure this is the church vs. state rule.? The problem I am solving is that I want the localized generated comment to be able to refer to the program elements like Objects.equals. Without any special handling, using `{@link}` in a resource in the resource file will be treated as literal text and will appear in the generated text exactly as written. The special handling I provided was to explicitly detect `{@link} strings and to replace them in the synthesized DocCommentTree with the appropriate LinkTree node.? As such, it's like a custom micro-parser for `{@link}' in the resource string.? As I mentioned in the comment, the alternatives are to make the code be even more specialized and detect/replace an otherwise plain string of 'Objects.equals` or whatever, or at the other extreme, to create and use a full DocCommentParser on the resource string to create the DocCommentTree. > > With the Element ordering changes (ElementComparator) I thought this > might cause failures > in TestOrdering, I guess the previous ordering are being preserved, > but there are no ?Records > elements in this test ? The change was mostly just a simple/trivial refactoring from using a custom static Map to get the ordering constant, to using a switch statement.? I assumed the existing tests would cover the change. You are right that we could update the existing ordering test to include records. -- Jon On 11/02/2019 08:12 AM, Kumar Srinivasan wrote: > Hi?Jon, > > Firstly I must commend the javadoc.next project for updating > javadoc/doclet to use jx.l.m and > other improvements to the doc comments management, this has made it > relatively easy for javadoc > to implement new language features, such as this. Having said that, > the changes are looking > great, and the langtools stalwarts have done due diligence. > > Here are some minor review comments, I don't need to see another revision. > > Default webrev: > > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java > > Likely search/replace > - * Keep track of whether or not this typeElement is an record. > + * Keep track of whether or not this typeElement is a record. > > - // only one canonical constructor; no longer need to keep looking > + // only one canonical constructor; no need to keep looking > > - TypeMirror objectType = > utils.elementUtils.getTypeElement("java.lang.Object").asType(); > + TypeMirror objectType = utils.getObjectType(); > There is a symbol table cache maintained in Utils, for performance > improvements. > > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java > > Nice simplifications to modifiersToString. > > With the Element ordering changes (ElementComparator) I thought this > might cause failures > in TestOrdering, I guess the previous ordering are being preserved, > but there are no ?Records > elements in this test ? > > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/CommentUtils.java > > + private void add(List contents, String resourceKey) { > + // Special case to allow '{@link ...}' to appear in the string. > + // A less general case would be to detect literal use of Object.equals > + // A more general case would be to allow access to DocCommentParser > somehow > Yes the church vs. state rule, I don't quite understand the problem we > are trying solve with this code. > + * name is to be inserted. T > + * @param key the resource key for the description > Looks like we have a hanging "T". > > One last thing, was the doc comparator run ? The reason I ask, ?there > seems to be unrelated > improvements ex: Utils::modifiersToString etc, not sure if regressions > are lurking in the output. > > Best, > > Kumar Srinivasan > > PS: I will have to go into radio silence for some time. > > On Wed, Oct 30, 2019 at 4:54 PM Jonathan Gibbons > > wrote: > > Please review a moderately small update to the proposed support for > records in javadoc. > > The primary change is to include record components in the > signature of a > record displayed near the top of the page. > > In addition, a "combo test" is added into TestRecordTypes.java to > verify > the presence or absence of annotations in various places in the > generated page for a record, depending on the `@Target` of the > annotations. > > Finally, there are some small cosmetic changes, and the supporting > files > for some previously published examples. > > Two webrevs are provided. > > The first is a cumulative webrev of the modified javadoc source > and test > files, compared against the default branch of the amber repo (i.e. > the > state of the jdk/jdk repo) > http://cr.openjdk.java.net/~jjg/amber-records/webrev.default/ > > > The second is a "delta webrev" of the recently modified javadoc > source > and test files, compared against the tip of the records branch of the > amber repo. > http://cr.openjdk.java.net/~jjg/amber-records/webrev.tip/ > > > Also, the sets of examples are updated, showing examples linked > and not > linked to JDK API docs > http://cr.openjdk.java.net/~jjg/amber-records/examples/api-with-link/ > > http://cr.openjdk.java.net/~jjg/amber-records/examples/api-no-link/ > > > Finally, I note a curiosity, arising from the proposed spec. This is > the first occurrence that I can think of in which an item that is > syntactically necessary in the source code does /not/ show up in the > same place in the generated documentation.? In general, in previous > instances where the documented signatures differ from the source > code, > the difference has been the addition of default or mandated elements. > Here, the presence of an annotation on the declaration of a record > component in source code may not show up in the corresponding > place in > the documented signature, depending on the specified @Target for the > annotation. I'm not saying that's wrong, but it is curious, and > may need > explaining to some. > > -- Jon > > JEP 359: https://openjdk.java.net/jeps/359 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Nov 5 21:35:18 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 5 Nov 2019 13:35:18 -0800 Subject: RFR: JEP 359-Records: javadoc code In-Reply-To: <914ab35b-ff07-1b9e-472c-9a04f7bc49dc@oracle.com> References: <914ab35b-ff07-1b9e-472c-9a04f7bc49dc@oracle.com> Message-ID: I've posted another small webrev, containing review feedback from Hannes and Kumar. In addition, while reading the reviews, I noticed that there were some obsolete references to sealed types in one method. I've removed those references and simplified the code. -- Jon Full webrev against jdk/jdk: http://cr.openjdk.java.net/~jjg/amber-records/webrev.02.default/ Incremental webrev against amber/records:tip: http://cr.openjdk.java.net/~jjg/amber-records/webrev.02.tip/ On 10/17/2019 12:43 PM, Vicente Romero wrote: > Hi, > > Please review the javadoc code for JEP 359 (Records), this webrev > contains only the javadoc code as we have decided to split the new > code in clusters to make the review process easier. > > Thanks in advance for the feedback, > Vicente > > PS, Jon is the author of this code please keep him in the loop > > http://cr.openjdk.java.net/~vromero/records.review/javadoc/webrev.00/ From vicente.romero at oracle.com Tue Nov 5 22:58:00 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 5 Nov 2019 17:58:00 -0500 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: <1fb0a88c-5d40-475e-984b-570806fd73b4@oracle.com> References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> <1fb0a88c-5d40-475e-984b-570806fd73b4@oracle.com> Message-ID: <5a75dd32-2780-4134-d5b5-7615ee494cdb@oracle.com> Hi Joe, Thanks for the review, On 11/4/19 12:33 AM, Joe Darcy wrote: > Hi Vicente, > > I've taken a pass over the javax.lang.model portions of the change. > > Elements.recordComponentFor should have an @implSpec tag. > > I suggest a double-check of the existing visitors/scanners that used > to extend one of the "FooVisitor9" types and was updated to extend > "FooVisitor14". In prior work, I had to add a new method override for > visitRecordComponent to the printing processor to get the proper > semantics of that class. For example, PubapiVisitor might need an update. I have updated the code for all the comments but the one above. I don't understand what you are exactly asking for, > > Also, please add the new "FooVisitor14" classes for types. > > In terms of how the tests are placed, I'd prefer to see tests of, say > annotation processing of records, groups with the existing annotation > processing tests as opposed to grouped with pure records tests. I > think this arrangement provides better test discoverability long term; > for example, if someone is updating annotation processing and wants to > make sure all the annotation processing tests are run. > > I recommend the annotation processing tests more consistently subclass > JavaTestingAbstractProcessor as opposed to directly subclassing > AbstractProcessor. > > > In TestRecord.java, please add newlines to the string arguments to the > options method on line 146. > > Thanks, > > -Joe Thanks, Vicente > > On 10/31/2019 9:11 PM, Vicente Romero wrote: >> Hi all, >> >> Thanks for all the feedback so far. I have published another >> iteration at [1]. New in this iteration: >> >> Flags.java: >> >> - I have sync the javadoc and the comment on the RECORD flag >> - renamed MemberRecordClassFlags -> MemberRecordFlags >> >> com.sun.tools.javac.code.Kinds.java: >> - in order to generate better error messages I have added two new >> kinds: RECORD_COMPONENT and RECORD >> >> Symbols.java >> - moved method isRecord to ClassSymbol for the rest of the symbols >> moved back to using the bitwise test >> - removed method ::isDynamic from MethodSymbol >> >> Attr.java >> - implemented a spec change to relax that constraint that every >> non-canonical constructor should call the canonical constructor. Now >> the spec forces every non-canonical constructor to invoke a different >> constructor as its first statement. This actually implied removing >> some code. >> >> Check.java >> - at method ::duplicateError, there is new code to avoid generating >> two errors when the user declares a record with duplicated record >> component names. If this happens, then a compiler generated canonical >> constructor would have duplicated parameters. This code is preventing >> the compiler to generate a second error referring to a method that is >> not visible to the user. Another option is to not generate the >> canonical constructor at all if there are duplicate record components >> - at method ::checkUnique, there is new code to improve the error >> message when the user defines a constructor with the same erasure as >> the canonical constructor. Still the error message is not perfect >> because it shows in both cases the erasure of the methods, so they >> seem to be the same. But this is not related to records code, that's >> a simplification that happens at the moment of reporting the error. >> >> TypeEnter >> - removed some commented code >> - ::addRecordMembersIfNeeded here I added new code to avoid >> generating accessor methods for forbidden record component names. >> This is to avoid spurious errors later as any way the compiler will >> complain because of the forbidden record component names. The issue >> with this solution is that the list of forbidden record component >> names has been duplicated here. The other location is Attr. We can >> probably find a common place to define it. Probably a new utility class? >> >> JavacParser: >> - fixed the bug that the compiler was not allowing final local records >> - removed the check for abstract modifiers in records, this code was >> redundant as Check was already checking this >> - removed the check for duplicated record component names >> - added a check to forbid instance initializers in records >> >> compiler.properties >> - I hope I got the error messages right, I tried to reflect all the >> comments, suggestions, etc. I was proposed to create a `master` >> message for canonical records and use different `causes`, aka >> fragments, to be more specific. I decided to follow the same pattern >> for accessor methods. Regarding the suggestion of placing the caret >> in the throws clause for the corresponding error message, not >> possible. We would have to move the check for that error to the parser. >> >> New in this iteration: >> - I have included jdeps related code, I was thinking about putting it >> in a separate review bucket but, it is small, it kind of fits with >> the rest of the review >> - a series of supporting libraries for tests under: >> test/langtools/lib/combo/tools/javac/combo with also the tests that >> needed to be modified due to changes in the lib. These changes were >> created by Brian >> - a minor change done at ToolBox.java >> >> Thanks for all the feedback, >> Vicente >> >> >> [1] >> http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.03/ From vicente.romero at oracle.com Tue Nov 5 22:59:18 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 5 Nov 2019 17:59:18 -0500 Subject: RFR: CSR for Compiler implementation for records In-Reply-To: References: <1c3a6e90-a7fb-97aa-828a-93929d88b442@oracle.com> <43c69224-ff98-afff-df58-c2b416545d60@oracle.com> Message-ID: <273bd008-fb58-fa04-d550-068563df57a8@oracle.com> Thanks, Vicente On 11/4/19 4:59 PM, Alex Buckley wrote: > I edited "Add records classes" to say "Add record classes". I also > turned a "very low" into just a "low" in the Compatibility Risk > Description; more could be written about which aspects of records are > most likely to change due to feedback, but there are diminishing > returns from spending on this CSR. Added myself as a reviewer. > > Alex > > On 11/4/2019 12:53 PM, Vicente Romero wrote: >> Hi Alex, >> >> Thanks for your comments, I have modified the CSR, does it look >> better now? >> >> Thanks, >> Vicente >> >> On 11/4/19 2:26 PM, Alex Buckley wrote: >>> Usually, I want a CSR's Solution to break down the new language >>> feature -- for example, see the original CSR for switch expressions >>> JDK-8207241, where the Solution sketches the actual changes, not >>> just "allow switch as an expression kthxbai". However, in the case >>> of record classes, the Solution is legitimately self-contained -- >>> support record classes! -- so no need for a break-down. That said, >>> the phrase "for a fixed set of values" is confusing because it >>> suggests enum-like behavior (the same phrase in the Summary is not >>> confusing because it has a qualifier). Also "Add records classes". >>> >>> Alex >>> >>> On 11/3/2019 9:13 AM, Vicente Romero wrote: >>>> Hi, >>>> >>>> Please review the draft of the CSR for Compiler implementation for >>>> records at [1] >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8233433 >> From jonathan.gibbons at oracle.com Tue Nov 5 23:46:13 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 5 Nov 2019 15:46:13 -0800 Subject: Reducing "exception is never thrown in body of corresponding try statement" Error to a Warning In-Reply-To: References: Message-ID: Mike, Given that you are proposing to change JLS[1], I think? you should get acceptance for the proposal before you embark on creating javac changsets. -- Jon [1] Specifically I am proposing the removal of the following section from JLS 11.2.3 On 11/5/19 3:29 PM, Mike Duigou wrote: > Hello again; > > Hearing no specific objections to my prior suggestion > (https://mail.openjdk.java.net/pipermail/jdk-dev/2019-October/003480.html) > to tweak compilation of checked exceptions by reducing the "exception > is never thrown in body of corresponding try statement" compilation > error to a non-fatal warning I am going to proceed with creating a > JIRA issue and proceeding with proposing a changeset to the > compiler-dev list. > > I do agree with the sentiment that this change is of somewhat limited > value. It is, I believe, useful and incrementally an improvement upon > existing behaviour and worth pursuing in absence of grander proposals. > > Cheers, > > > Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Nov 6 00:13:02 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 5 Nov 2019 16:13:02 -0800 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: <5a75dd32-2780-4134-d5b5-7615ee494cdb@oracle.com> References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> <1fb0a88c-5d40-475e-984b-570806fd73b4@oracle.com> <5a75dd32-2780-4134-d5b5-7615ee494cdb@oracle.com> Message-ID: <96679bcd-38a5-0c67-110e-0e337548b045@oracle.com> Hi Vicente, On 11/5/2019 2:58 PM, Vicente Romero wrote: > Hi Joe, > > Thanks for the review, > > On 11/4/19 12:33 AM, Joe Darcy wrote: >> Hi Vicente, >> >> I've taken a pass over the javax.lang.model portions of the change. >> >> Elements.recordComponentFor should have an @implSpec tag. >> >> I suggest a double-check of the existing visitors/scanners that used >> to extend one of the "FooVisitor9" types and was updated to extend >> "FooVisitor14". In prior work, I had to add a new method override for >> visitRecordComponent to the printing processor to get the proper >> semantics of that class. For example, PubapiVisitor might need an >> update. > > I have updated the code for all the comments but the one above. I > don't understand what you are exactly asking for, > For the printing processor to have the right semantics after record components were modeled with their own top-level element, I had to make the following adjustment: ??? http://hg.openjdk.java.net/amber/amber/rev/6b2b5e4c01a7 In effect, the unmodified processor with its default methods, etc. did not "just" work when the superclass was changed from the old JDK-9 based visitors to the JDK-14 based one. Analogous updates may be needed for other visitors/scanners to contend with records and record components. HTH, -Joe From vicente.romero at oracle.com Wed Nov 6 13:11:26 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 6 Nov 2019 08:11:26 -0500 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: <96679bcd-38a5-0c67-110e-0e337548b045@oracle.com> References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> <1fb0a88c-5d40-475e-984b-570806fd73b4@oracle.com> <5a75dd32-2780-4134-d5b5-7615ee494cdb@oracle.com> <96679bcd-38a5-0c67-110e-0e337548b045@oracle.com> Message-ID: <8e66c37d-d09b-609a-b8f8-4e2495a6a9d3@oracle.com> Hi Joe, I made an experiment: removing the code you added to PrintingProcessor and the tests, TestRecord and family, just work. Thanks, Vicente On 11/5/19 7:13 PM, Joe Darcy wrote: > Hi Vicente, > > On 11/5/2019 2:58 PM, Vicente Romero wrote: >> Hi Joe, >> >> Thanks for the review, >> >> On 11/4/19 12:33 AM, Joe Darcy wrote: >>> Hi Vicente, >>> >>> I've taken a pass over the javax.lang.model portions of the change. >>> >>> Elements.recordComponentFor should have an @implSpec tag. >>> >>> I suggest a double-check of the existing visitors/scanners that used >>> to extend one of the "FooVisitor9" types and was updated to extend >>> "FooVisitor14". In prior work, I had to add a new method override >>> for visitRecordComponent to the printing processor to get the proper >>> semantics of that class. For example, PubapiVisitor might need an >>> update. >> >> I have updated the code for all the comments but the one above. I >> don't understand what you are exactly asking for, >> > For the printing processor to have the right semantics after record > components were modeled with their own top-level element, I had to > make the following adjustment: > > ??? http://hg.openjdk.java.net/amber/amber/rev/6b2b5e4c01a7 > > In effect, the unmodified processor with its default methods, etc. did > not "just" work when the superclass was changed from the old JDK-9 > based visitors to the JDK-14 based one. > > Analogous updates may be needed for other visitors/scanners to contend > with records and record components. > > HTH, > > -Joe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Nov 6 15:43:02 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 6 Nov 2019 07:43:02 -0800 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: <8e66c37d-d09b-609a-b8f8-4e2495a6a9d3@oracle.com> References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> <1fb0a88c-5d40-475e-984b-570806fd73b4@oracle.com> <5a75dd32-2780-4134-d5b5-7615ee494cdb@oracle.com> <96679bcd-38a5-0c67-110e-0e337548b045@oracle.com> <8e66c37d-d09b-609a-b8f8-4e2495a6a9d3@oracle.com> Message-ID: Hi Vicente, On 11/6/2019 5:11 AM, Vicente Romero wrote: > Hi Joe, > > I made an experiment: removing the code you added to PrintingProcessor > and the tests, TestRecord and family, just work. It is true the tests may pass, but unless other changes have been made since I pushed that update, the printing processor doesn't have the right semantics without the change. As a matter of test design, the annotation processing tests intentionally avoid checking the exact output of printing. The visitor in question defines a defaultAction method which prints doc comments and modifiers. When the record components were visited on their own, extra doc comments and modifiers were printed. The record component information was printed in the proper location by during the visitation of the record itself. HTH, -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.laskey at oracle.com Thu Nov 7 14:22:38 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 7 Nov 2019 10:22:38 -0400 Subject: RFR: JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) Message-ID: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com> Please review the following code changes. Provides for the introduction of two new escape sequences \ and \s. \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for tab. The changes are primarily in the compiler, with some small changes in String::translateEscapes. Small changeset overall. Thank you. -- Jim webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8233116 csr: https://bugs.openjdk.java.net/browse/JDK-8233117 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Nov 7 17:34:58 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 7 Nov 2019 09:34:58 -0800 Subject: RFR: JDK-8232684: Make switch expressions final In-Reply-To: References: Message-ID: <0c60f044-4d5b-8fc4-24ca-4da872be6333@oracle.com> HotSpot tests changes (using Thread.yield()) look good. Thanks, Vladimir On 11/5/19 1:50 AM, Jan Lahoda wrote: > I've missed updates to some hotspot and jdk tests in the first patch. The problem are unqualified > invocations of Thread.yield(), which are no longer allowed (from the spec: JLS 3.9 Keywords: "All > invocations of a method called yield must be qualified so as to be distinguished from a yield > statement."). Therefore, these invocations need to be changed to qualified invocations (i.e. > Thread.yield()). Updates to the hotspot and jdk tests are here: > http://cr.openjdk.java.net/~jlahoda/8232684/webrev.delta.00.01/ > > Full updated webrev, with changes to both javac and the tests, is here: > http://cr.openjdk.java.net/~jlahoda/8232684/webrev.01/ > > How does that look? > > Thanks, > ??? Jan > > On 21. 10. 19 16:17, Maurizio Cimadamore wrote: >> Looks generally good -? went through the test updates one by one and they look ok, except this: >> >> http://cr.openjdk.java.net/~jlahoda/8232684/webrev.00/test/langtools/tools/jdeps/listdeps/ListModuleDeps.java.udiff.html >> >> >> Which you explained to me offline (we need to change this code every time the compiler stops using >> the @Preview annotation - ugh). Nothing specific to this webrev, so I approve. >> >> Maurizio >> >> On 21/10/2019 14:49, Jan Lahoda wrote: >>> Hi, >>> >>> As part of preparation for proposing JEP 361: Switch Expressions (Standard) to target, I would >>> like to ask for a review of the patch to make switch expression a non-preview feature in javac: >>> http://cr.openjdk.java.net/~jlahoda/8232684/webrev.00/ >>> >>> The patch basically removes the feature from the list of preview features, updates test to this >>> new state (removes --enable-preview from associated tests, and adjusts their expected output), >>> and removes the @PreviewFeature annotation and associated text from the javadoc of the Trees API. >>> >>> I also would like to ask for a review for the CSR associated with that: >>> https://bugs.openjdk.java.net/browse/JDK-8232685 >>> >>> Reviews/comments on either of these would be very welcome! >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8232684 >>> >>> Thanks! >>> >>> Jan From brent.christian at oracle.com Thu Nov 7 21:23:54 2019 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 7 Nov 2019 13:23:54 -0800 Subject: RFR: JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) In-Reply-To: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com> References: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com> Message-ID: <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com> Should the new escapes be added to the table in the String.translateEscapes() JavaDoc? -Brent On 11/7/19 6:22 AM, Jim Laskey wrote: > Please review the following code changes. Provides for the introduction of two new escape sequences \ and \s. \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for tab. The changes are primarily in the compiler, with some small changes in String::translateEscapes. Small changeset overall. > > Thank you. > > -- Jim > > > webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev/index.html > > jbs: https://bugs.openjdk.java.net/browse/JDK-8233116 > csr: https://bugs.openjdk.java.net/browse/JDK-8233117 > From james.laskey at oracle.com Thu Nov 7 22:11:29 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 7 Nov 2019 18:11:29 -0400 Subject: RFR: JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) In-Reply-To: <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com> References: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com> <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com> Message-ID: Yep. :-) Too much juggling. Thank you. > On Nov 7, 2019, at 5:23 PM, Brent Christian wrote: > > Should the new escapes be added to the table in the String.translateEscapes() JavaDoc? > > -Brent > > On 11/7/19 6:22 AM, Jim Laskey wrote: >> Please review the following code changes. Provides for the introduction of two new escape sequences \ and \s. \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for tab. The changes are primarily in the compiler, with some small changes in String::translateEscapes. Small changeset overall. >> Thank you. >> -- Jim >> webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev/index.html >> jbs: https://bugs.openjdk.java.net/browse/JDK-8233116 >> csr: https://bugs.openjdk.java.net/browse/JDK-8233117 From james.laskey at oracle.com Fri Nov 8 13:15:42 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Fri, 8 Nov 2019 09:15:42 -0400 Subject: RFR: JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) In-Reply-To: <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com> References: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com> <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com> Message-ID: Updated webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev.01/index.html > On Nov 7, 2019, at 5:23 PM, Brent Christian wrote: > > Should the new escapes be added to the table in the String.translateEscapes() JavaDoc? > > -Brent > > On 11/7/19 6:22 AM, Jim Laskey wrote: >> Please review the following code changes. Provides for the introduction of two new escape sequences \ and \s. \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for tab. The changes are primarily in the compiler, with some small changes in String::translateEscapes. Small changeset overall. >> Thank you. >> -- Jim >> webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev/index.html >> jbs: https://bugs.openjdk.java.net/browse/JDK-8233116 >> csr: https://bugs.openjdk.java.net/browse/JDK-8233117 -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Nov 8 16:28:53 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 8 Nov 2019 16:28:53 +0000 Subject: RFR: JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) In-Reply-To: References: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com> <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com> Message-ID: <0aa5b2c5-bb74-d72a-0770-1133001e0f8a@oracle.com> Hi Jim, the tokenizer changes looks good. I was very confused by the dance between: // Indicate that the final string should have escapes translated. ???????????????????? shouldTranslateEscapes = true; This: // Conditionally translate or validate escape sequence and add result to string buffer. ??????????????? scanLitChar(pos, !shouldTranslateEscapes, openCount != 1); And then this: ??? private void scanLitChar(int pos, boolean translate, boolean multiline) { As discussed offline, I think the confusion arises that, in the tokenizer, the 'shouldTranslateEscape' is some kind of a global variable which means "should we translate escapes AFTER reading the string literal", whereas the 'translate' parameter in scanLitChar means "should we translate escapes NOW". The overlapping (but not identical) meaning of the two is confusing. I also wonder, if one is always the negation of the other, can we refer to the global 'shouldTranslateEscapes' from inside scanLitChar - maybe that will help getting rid of some of the indirection. Thanks Maurizio On 08/11/2019 13:15, Jim Laskey wrote: > Updated > > webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev.01/index.html > > >> On Nov 7, 2019, at 5:23 PM, Brent Christian wrote: >> >> Should the new escapes be added to the table in the String.translateEscapes() JavaDoc? >> >> -Brent >> >> On 11/7/19 6:22 AM, Jim Laskey wrote: >>> Please review the following code changes. Provides for the introduction of two new escape sequences \ and \s. \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for tab. The changes are primarily in the compiler, with some small changes in String::translateEscapes. Small changeset overall. >>> Thank you. >>> -- Jim >>> webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev/index.html >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8233116 >>> csr: https://bugs.openjdk.java.net/browse/JDK-8233117 From vicente.romero at oracle.com Fri Nov 8 17:02:29 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 8 Nov 2019 12:02:29 -0500 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: <97d2b883-8df4-dd6e-cad4-e2ad5982a92c@oracle.com> References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> <9f8607fd-9fab-cc7a-9b0b-8913887df893@oracle.com> <7ebb480f-bbcb-2ac0-ce9a-73e5888f5df4@oracle.com> <97d2b883-8df4-dd6e-cad4-e2ad5982a92c@oracle.com> Message-ID: <93449ea7-d486-3f92-8bbf-cf44d386ef1e@oracle.com> Hi all, Please review another iteration of the compiler implementation for records at [1]. New in this iteration: - I added an @implSpec comment to method: javax.lang.model.util.Elements::recordComponentFor - moved the list of forbidden record component names to class Names - added the code proposed by Maurizio to the parser with a small tweak for records declared as members - modified the error message to indicate that any non-canonical constructor should invoke another constructor to: "constructor is not canonical, so its first statement must invoke another constructor" - added method: com.sun.tools.sjavac.comp.PubapiVisitor::visitRecordComponent - added new visitor: javax.lang.model.util.AbstractTypeVisitor14 - moved annotation processing tests for records to common place for other annotation processing tests Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.04 From vicente.romero at oracle.com Sun Nov 10 06:46:29 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Sun, 10 Nov 2019 06:46:29 +0000 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: <93449ea7-d486-3f92-8bbf-cf44d386ef1e@oracle.com> References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> <9f8607fd-9fab-cc7a-9b0b-8913887df893@oracle.com> <7ebb480f-bbcb-2ac0-ce9a-73e5888f5df4@oracle.com> <97d2b883-8df4-dd6e-cad4-e2ad5982a92c@oracle.com> <93449ea7-d486-3f92-8bbf-cf44d386ef1e@oracle.com> Message-ID: <9e9d8874-145b-2f8a-611f-963d137625db@oracle.com> Hi, I have uploaded another iteration to [2]. This one includes some missing type and annotation javax.lang.model visitors, Thanks, Vicente [2] http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.05 On 11/8/19 5:02 PM, Vicente Romero wrote: > Hi all, > > Please review another iteration of the compiler implementation for > records at [1]. New in this iteration: > > - I added an @implSpec comment to method: > javax.lang.model.util.Elements::recordComponentFor > - moved the list of forbidden record component names to class Names > - added the code proposed by Maurizio to the parser with a small tweak > for records declared as members > - modified the error message to indicate that any non-canonical > constructor should invoke another constructor to: "constructor is not > canonical, so its first statement must invoke another constructor" > - added method: > com.sun.tools.sjavac.comp.PubapiVisitor::visitRecordComponent > - added new visitor: javax.lang.model.util.AbstractTypeVisitor14 > - moved annotation processing tests for records to common place for > other annotation processing tests > > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.04 From vicente.romero at oracle.com Sun Nov 10 06:48:08 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Sun, 10 Nov 2019 06:48:08 +0000 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: <93449ea7-d486-3f92-8bbf-cf44d386ef1e@oracle.com> References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> <9f8607fd-9fab-cc7a-9b0b-8913887df893@oracle.com> <7ebb480f-bbcb-2ac0-ce9a-73e5888f5df4@oracle.com> <97d2b883-8df4-dd6e-cad4-e2ad5982a92c@oracle.com> <93449ea7-d486-3f92-8bbf-cf44d386ef1e@oracle.com> Message-ID: <33119ca4-7e11-a7e6-4457-b6a909cfc634@oracle.com> Hi, I have uploaded another iteration to [2]. This one includes some missing type and annotation javax.lang.model visitors, Thanks, Vicente [2] http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.05 On 11/8/19 5:02 PM, Vicente Romero wrote: > Hi all, > > Please review another iteration of the compiler implementation for > records at [1]. New in this iteration: > > - I added an @implSpec comment to method: > javax.lang.model.util.Elements::recordComponentFor > - moved the list of forbidden record component names to class Names > - added the code proposed by Maurizio to the parser with a small tweak > for records declared as members > - modified the error message to indicate that any non-canonical > constructor should invoke another constructor to: "constructor is not > canonical, so its first statement must invoke another constructor" > - added method: > com.sun.tools.sjavac.comp.PubapiVisitor::visitRecordComponent > - added new visitor: javax.lang.model.util.AbstractTypeVisitor14 > - moved annotation processing tests for records to common place for > other annotation processing tests > > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.04 From vicente.romero at oracle.com Tue Nov 12 00:31:22 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 12 Nov 2019 00:31:22 +0000 Subject: RFR: JEP 359-Records: compiler code In-Reply-To: <33119ca4-7e11-a7e6-4457-b6a909cfc634@oracle.com> References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> <9f8607fd-9fab-cc7a-9b0b-8913887df893@oracle.com> <7ebb480f-bbcb-2ac0-ce9a-73e5888f5df4@oracle.com> <97d2b883-8df4-dd6e-cad4-e2ad5982a92c@oracle.com> <93449ea7-d486-3f92-8bbf-cf44d386ef1e@oracle.com> <33119ca4-7e11-a7e6-4457-b6a909cfc634@oracle.com> Message-ID: Hi all, I have uploaded another iteration to [3]. This iteration fixes a regression introduced with one of the fixes that were addressing preview review comments. In short this is the most important change: diff -r 5d6410bfafe0 -r 806e05ae98e3 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java Sun Nov 10 19:41:49 2019 +0000 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java Mon Nov 11 23:42:59 2019 +0000 @@ -1217,8 +1217,11 @@ ???????????????? if (sym.owner.owner.kind == PCK || ???????????????????? (sym.owner.flags_field & STATIC) != 0) ???????????????????? mask |= STATIC; -??????????????? else if ((flags & ENUM) != 0) +??????????????? else if ((flags & ENUM) != 0) { ???????????????????? log.error(pos, Errors.EnumsMustBeStatic); +??????????????? } else if ((flags & RECORD) != 0) { +??????????????????? log.error(pos, Errors.RecordDeclarationNotAllowedInInnerClasses); +??????????????? } ???????????????? // Nested interfaces and enums are always STATIC (Spec ???) ???????????????? if ((flags & (INTERFACE | ENUM | RECORD)) != 0 ) implicit = STATIC; ???????????? } else { The regression introduced was that code like: class Outer { ??? class Inner { ??????? record R() {} ??? } } started being accepted by the compiler. The reason is because the code that checks for static declarations inside inner classes in the compiler, checks for declared modifiers, but records are `implicitly` static as enums are. For this reason I'm now doing the check for records inside inner classes in the same place where a similar check for enums is done at Check::checkFlags. I also introduced a new error message, please see it inserted into the webrev. Thanks, Vicente [3] http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.06 On 11/10/19 6:48 AM, Vicente Romero wrote: > Hi, > > I have uploaded another iteration to [2]. This one includes some > missing type and annotation javax.lang.model visitors, > > Thanks, > Vicente > > [2] http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.05 > > On 11/8/19 5:02 PM, Vicente Romero wrote: >> Hi all, >> >> Please review another iteration of the compiler implementation for >> records at [1]. New in this iteration: >> >> - I added an @implSpec comment to method: >> javax.lang.model.util.Elements::recordComponentFor >> - moved the list of forbidden record component names to class Names >> - added the code proposed by Maurizio to the parser with a small >> tweak for records declared as members >> - modified the error message to indicate that any non-canonical >> constructor should invoke another constructor to: "constructor is not >> canonical, so its first statement must invoke another constructor" >> - added method: >> com.sun.tools.sjavac.comp.PubapiVisitor::visitRecordComponent >> - added new visitor: javax.lang.model.util.AbstractTypeVisitor14 >> - moved annotation processing tests for records to common place for >> other annotation processing tests >> >> >> Thanks, >> Vicente >> >> [1] >> http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.04 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue Nov 12 08:42:33 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 12 Nov 2019 08:42:33 +0000 Subject: RFR: JEP 359-Records: compiler code In-Reply-To: References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> <9f8607fd-9fab-cc7a-9b0b-8913887df893@oracle.com> <7ebb480f-bbcb-2ac0-ce9a-73e5888f5df4@oracle.com> <97d2b883-8df4-dd6e-cad4-e2ad5982a92c@oracle.com> <93449ea7-d486-3f92-8bbf-cf44d386ef1e@oracle.com> <33119ca4-7e11-a7e6-4457-b6a909cfc634@oracle.com> Message-ID: <63f79bf1-8ee9-b1f4-ebeb-10de5b7c2ed5@oracle.com> The compiler changes look good - I still see indentiation issues in TypeEnter, especially in lines 1225-1238. Also, in JavacParser: * in? blockStatements we do this: ?if (isRecordStart() && allowRecords) { 2629???????????? dc = token.comment(CommentStyle.JAVADOC); 2630???????????? return List.of(recordDeclaration(F.at(pos).Modifiers(0), dc)); But isRecordStart() can generate diagnostics - so should it be better to invert the condition, as in: if (allowRecords && isRecordStart()) - to avoid spurious preview warnings on source < 14? * how does this code avoids the problem described well by Jan in a previous email in this thread - reporting below: > I think I was touching that in one of my comments. I am afraid it is > probably not so simple - we could do the checks easily for top-level > records, but not so easily for nested records. I.e.: > --- > class X { > ??? record R(int i) { > ??????? return null; > ??? } > } > class record {} > --- > > is valid currently ("R" is a method which returns "record"), but not > with the patch: > --- > $ javac /tmp/R.java > /tmp/R.java:2: error: records are a preview feature and are disabled > by default. > record R(int i) { > ^ > ? (use --enable-preview to enable records) > /tmp/R.java:3: error: illegal start of type > return null; Seems to me that we are using isRecordStarts in a member position - meaning that a member record would be parsed even if it's just a method returning a 'record' type (which is allowed, with warning). Maybe gate the isRecordStart with allowRecords? Actually, maybe we should add? ' && allowRecords' check inside isRecordStart() all the time, to make sure we don't pick up more records than intended? Maurizio On 12/11/2019 00:31, Vicente Romero wrote: > Hi all, > > I have uploaded another iteration to [3]. This iteration fixes a > regression introduced with one of the fixes that were addressing > preview review comments. In short this is the most important change: > > diff -r 5d6410bfafe0 -r 806e05ae98e3 > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java > Sun Nov 10 19:41:49 2019 +0000 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java > Mon Nov 11 23:42:59 2019 +0000 > @@ -1217,8 +1217,11 @@ > ???????????????? if (sym.owner.owner.kind == PCK || > ???????????????????? (sym.owner.flags_field & STATIC) != 0) > ???????????????????? mask |= STATIC; > -??????????????? else if ((flags & ENUM) != 0) > +??????????????? else if ((flags & ENUM) != 0) { > ???????????????????? log.error(pos, Errors.EnumsMustBeStatic); > +??????????????? } else if ((flags & RECORD) != 0) { > +??????????????????? log.error(pos, > Errors.RecordDeclarationNotAllowedInInnerClasses); > +??????????????? } > ???????????????? // Nested interfaces and enums are always STATIC > (Spec ???) > ???????????????? if ((flags & (INTERFACE | ENUM | RECORD)) != 0 ) > implicit = STATIC; > ???????????? } else { > > The regression introduced was that code like: > > class Outer { > ??? class Inner { > ??????? record R() {} > ??? } > } > > started being accepted by the compiler. The reason is because the code > that checks for static declarations inside inner classes in the > compiler, checks for declared modifiers, but records are `implicitly` > static as enums are. For this reason I'm now doing the check for > records inside inner classes in the same place where a similar check > for enums is done at Check::checkFlags. I also introduced a new error > message, please see it inserted into the webrev. > > Thanks, > Vicente > > [3] http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.06 > > On 11/10/19 6:48 AM, Vicente Romero wrote: >> Hi, >> >> I have uploaded another iteration to [2]. This one includes some >> missing type and annotation javax.lang.model visitors, >> >> Thanks, >> Vicente >> >> [2] >> http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.05 >> >> On 11/8/19 5:02 PM, Vicente Romero wrote: >>> Hi all, >>> >>> Please review another iteration of the compiler implementation for >>> records at [1]. New in this iteration: >>> >>> - I added an @implSpec comment to method: >>> javax.lang.model.util.Elements::recordComponentFor >>> - moved the list of forbidden record component names to class Names >>> - added the code proposed by Maurizio to the parser with a small >>> tweak for records declared as members >>> - modified the error message to indicate that any non-canonical >>> constructor should invoke another constructor to: "constructor is >>> not canonical, so its first statement must invoke another constructor" >>> - added method: >>> com.sun.tools.sjavac.comp.PubapiVisitor::visitRecordComponent >>> - added new visitor: javax.lang.model.util.AbstractTypeVisitor14 >>> - moved annotation processing tests for records to common place for >>> other annotation processing tests >>> >>> >>> Thanks, >>> Vicente >>> >>> [1] >>> http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.04 >> > From maurizio.cimadamore at oracle.com Tue Nov 12 09:00:02 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 12 Nov 2019 09:00:02 +0000 Subject: RFR: JEP 359-Records: compiler code In-Reply-To: <63f79bf1-8ee9-b1f4-ebeb-10de5b7c2ed5@oracle.com> References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> <9f8607fd-9fab-cc7a-9b0b-8913887df893@oracle.com> <7ebb480f-bbcb-2ac0-ce9a-73e5888f5df4@oracle.com> <97d2b883-8df4-dd6e-cad4-e2ad5982a92c@oracle.com> <93449ea7-d486-3f92-8bbf-cf44d386ef1e@oracle.com> <33119ca4-7e11-a7e6-4457-b6a909cfc634@oracle.com> <63f79bf1-8ee9-b1f4-ebeb-10de5b7c2ed5@oracle.com> Message-ID: I also took another look at tests - it seems to me that we're a bit thin in this department, I'll try to explain why. * We need at least a combo test for the parser which tries records with different source levels and in different source positions (top-level, member, local), since we found several complex issues in this part of the parser * I noted that, while we have many diagnostics tests, we have basically zero negative tests to check that the compiler is generating the desired error message _without any additional_ spurious errors. In principle, there should be at least one negative test for each record-related error message. This leads to replication with the diagnostics tests, but we've always done it this way. The diagnostic framework is for diagnostics - per se, it is insufficient to verify good quality of compiler output. * I suggest maybe to group tests in different folders depending on the 'category' they fall in. E.g. I see you have a reflection test and a serialization test, then some annotation processing tests - it would be nice to label these accordingly by putting them in separate folders. * there's no test for checking what happens when javac is fed a 'bad record classfile attribute' (again a combo here is probably the right choice, given the number of ways the attribute can be wrong) * I see no tests for constructor delegation to canonical constructor - again, here we should try different things, with different level of delegation (e.g. C1 -> CANONICAL, C1 -> C2 -> CANONICAL and so forth) to make sure javac is not tripped up by the indirections * Probably DA/DU rules for compact constructor are, again, complex enough that when you start reasoning about 2-3 different record components, the number of different states go up pretty rapidly, and again a combo could be useful (completes normally, completes abruptly, explicitly assigns to x, implicitly assigns to x, ...). * OriginTest seems a bit weak in that it tests _all implicit_ and _all explicit_ and nothing in between; maybe that's part of the test design, but looks odd Maurizio On 12/11/2019 08:42, Maurizio Cimadamore wrote: > The compiler changes look good - I still see indentiation issues in > TypeEnter, especially in lines 1225-1238. > > Also, in JavacParser: > > * in? blockStatements we do this: > > ?if (isRecordStart() && allowRecords) { > 2629???????????? dc = token.comment(CommentStyle.JAVADOC); > 2630???????????? return > List.of(recordDeclaration(F.at(pos).Modifiers(0), dc)); > > But isRecordStart() can generate diagnostics - so should it be better > to invert the condition, as in: > > if (allowRecords && isRecordStart()) - to avoid spurious preview > warnings on source < 14? > > * how does this code avoids the problem described well by Jan in a > previous email in this thread - reporting below: > >> I think I was touching that in one of my comments. I am afraid it is >> probably not so simple - we could do the checks easily for top-level >> records, but not so easily for nested records. I.e.: >> --- >> class X { >> ??? record R(int i) { >> ??????? return null; >> ??? } >> } >> class record {} >> --- >> >> is valid currently ("R" is a method which returns "record"), but not >> with the patch: >> --- >> $ javac /tmp/R.java >> /tmp/R.java:2: error: records are a preview feature and are disabled >> by default. >> record R(int i) { >> ^ >> ? (use --enable-preview to enable records) >> /tmp/R.java:3: error: illegal start of type >> return null; > > Seems to me that we are using isRecordStarts in a member position - > meaning that a member record would be parsed even if it's just a > method returning a 'record' type (which is allowed, with warning). > > Maybe gate the isRecordStart with allowRecords? Actually, maybe we > should add? ' && allowRecords' check inside isRecordStart() all the > time, to make sure we don't pick up more records than intended? > > Maurizio > > > On 12/11/2019 00:31, Vicente Romero wrote: >> Hi all, >> >> I have uploaded another iteration to [3]. This iteration fixes a >> regression introduced with one of the fixes that were addressing >> preview review comments. In short this is the most important change: >> >> diff -r 5d6410bfafe0 -r 806e05ae98e3 >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java >> --- >> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java >> Sun Nov 10 19:41:49 2019 +0000 >> +++ >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java >> Mon Nov 11 23:42:59 2019 +0000 >> @@ -1217,8 +1217,11 @@ >> ???????????????? if (sym.owner.owner.kind == PCK || >> ???????????????????? (sym.owner.flags_field & STATIC) != 0) >> ???????????????????? mask |= STATIC; >> -??????????????? else if ((flags & ENUM) != 0) >> +??????????????? else if ((flags & ENUM) != 0) { >> ???????????????????? log.error(pos, Errors.EnumsMustBeStatic); >> +??????????????? } else if ((flags & RECORD) != 0) { >> +??????????????????? log.error(pos, >> Errors.RecordDeclarationNotAllowedInInnerClasses); >> +??????????????? } >> ???????????????? // Nested interfaces and enums are always STATIC >> (Spec ???) >> ???????????????? if ((flags & (INTERFACE | ENUM | RECORD)) != 0 ) >> implicit = STATIC; >> ???????????? } else { >> >> The regression introduced was that code like: >> >> class Outer { >> ??? class Inner { >> ??????? record R() {} >> ??? } >> } >> >> started being accepted by the compiler. The reason is because the >> code that checks for static declarations inside inner classes in the >> compiler, checks for declared modifiers, but records are `implicitly` >> static as enums are. For this reason I'm now doing the check for >> records inside inner classes in the same place where a similar check >> for enums is done at Check::checkFlags. I also introduced a new error >> message, please see it inserted into the webrev. >> >> Thanks, >> Vicente >> >> [3] >> http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.06 >> >> On 11/10/19 6:48 AM, Vicente Romero wrote: >>> Hi, >>> >>> I have uploaded another iteration to [2]. This one includes some >>> missing type and annotation javax.lang.model visitors, >>> >>> Thanks, >>> Vicente >>> >>> [2] >>> http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.05 >>> >>> On 11/8/19 5:02 PM, Vicente Romero wrote: >>>> Hi all, >>>> >>>> Please review another iteration of the compiler implementation for >>>> records at [1]. New in this iteration: >>>> >>>> - I added an @implSpec comment to method: >>>> javax.lang.model.util.Elements::recordComponentFor >>>> - moved the list of forbidden record component names to class Names >>>> - added the code proposed by Maurizio to the parser with a small >>>> tweak for records declared as members >>>> - modified the error message to indicate that any non-canonical >>>> constructor should invoke another constructor to: "constructor is >>>> not canonical, so its first statement must invoke another constructor" >>>> - added method: >>>> com.sun.tools.sjavac.comp.PubapiVisitor::visitRecordComponent >>>> - added new visitor: javax.lang.model.util.AbstractTypeVisitor14 >>>> - moved annotation processing tests for records to common place for >>>> other annotation processing tests >>>> >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] >>>> http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.04 >>> >> From james.laskey at oracle.com Tue Nov 12 15:15:50 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 12 Nov 2019 11:15:50 -0400 Subject: RFR: JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) In-Reply-To: References: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com> <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com> Message-ID: <00C5C729-D9FF-48E0-8F7F-DD8E7615ACEC@oracle.com> updated webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev.03/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Nov 12 22:51:05 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 12 Nov 2019 14:51:05 -0800 Subject: RFR: JDK-8234025 Elements.getPackageElement(ModuleElement,CharSequence) returns null for unnamed package Message-ID: <23181b25-8674-1566-dbfd-0e50c7bf2fe8@oracle.com> Please review a small fix and corresponding test so that ??? Elements.getPackageElement(ModuleElement mdle, CharSequence name) returns a non-null result, as intended, for an unnamed package. The fault occurs in this code? in JavacElements.nameToSymbol: try { if (sym ==null) sym =javaCompiler.resolveIdent(module, nameStr); if (clazz.isInstance(sym)) { sym.complete(); if (sym.kind !=ERR && sym.exists() && name.equals(sym.getQualifiedName())) { return clazz.cast(sym); } } return null; }catch (CompletionFailure cf) { cf.dcfh.handleAPICompletionFailure(cf); return null; } While a non-null value for sym is found early on, it fails the `.exists()` test and so `null` is returned. The fix is to mark the symbol as existing. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8234025 Webrev: http://cr.openjdk.java.net/~jjg/8234025/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Nov 12 23:37:28 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 12 Nov 2019 15:37:28 -0800 Subject: JDK 14 RFR of JDK-8233096: Update javax.lang.model for switch expressions In-Reply-To: References: <0ba28fbc-6036-2b58-b579-ab3687b939cf@oracle.com> Message-ID: Coming back to this after the switch expression changes were pushed, I've updated the test to give a more informative output message on an error: ??? http://cr.openjdk.java.net/~darcy/8233096.1/ and for completeness, a created an extra small CSR as well: ??? https://bugs.openjdk.java.net/browse/JDK-8234055 Thanks, -Joe On 10/29/2019 11:28 AM, Joe Darcy wrote: > On 10/29/2019 10:09 AM, Jonathan Gibbons wrote: >> >> Although not modified, is this line in the test as intended? >> >> 137 throw new RuntimeException("Unexpected " + message + "-ness of _ on " + version); >> The reference to "_" seems unexpected. > > > Yeah; I noticed that too. It would clearly be more informative to > print out the input causing the failure. Code review feedback could > overcome my activation energy to do the small necessary refactoring ;-) > > -Joe > > >> >> -- Jon >> >> On 10/29/19 9:58 AM, Joe Darcy wrote: >>> Hello, >>> >>> After switch expressions are added as a full non-preview feature >>> (JDK-8232684), portions of javax.lang.model should be updated >>> accordingly, including the description of SourceVersion.RELEASE_14. >>> >>> Please review the changes for this: >>> >>> http://cr.openjdk.java.net/~darcy/8233096.0/ >>> >>> Thanks, >>> >>> -Joe >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Nov 13 01:30:20 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 12 Nov 2019 17:30:20 -0800 Subject: JDK 14 RFR of JDK-8233096: Update javax.lang.model for switch expressions In-Reply-To: References: <0ba28fbc-6036-2b58-b579-ab3687b939cf@oracle.com> Message-ID: <016f03ec-5d0b-1b0e-009f-7ba3acbe135b@oracle.com> I've reviewed the specific proposed update. As a picky comment on the CSR, the line wrapping before the version number seems inconsistently gratuitous. More notably, the general use of "include", as in "Additions in this release include ..." seems lazy and less than definitive. -- Jon On 11/12/19 3:37 PM, Joe Darcy wrote: > > Coming back to this after the switch expression changes were pushed, > I've updated the test to give a more informative output message on an > error: > > http://cr.openjdk.java.net/~darcy/8233096.1/ > > and for completeness, a created an extra small CSR as well: > > https://bugs.openjdk.java.net/browse/JDK-8234055 > > Thanks, > > -Joe > > On 10/29/2019 11:28 AM, Joe Darcy wrote: >> On 10/29/2019 10:09 AM, Jonathan Gibbons wrote: >>> >>> Although not modified, is this line in the test as intended? >>> >>> 137 throw new RuntimeException("Unexpected " + message + "-ness of _ on " + version); >>> The reference to "_" seems unexpected. >> >> >> Yeah; I noticed that too. It would clearly be more informative to >> print out the input causing the failure. Code review feedback could >> overcome my activation energy to do the small necessary refactoring ;-) >> >> -Joe >> >> >>> >>> -- Jon >>> >>> On 10/29/19 9:58 AM, Joe Darcy wrote: >>>> Hello, >>>> >>>> After switch expressions are added as a full non-preview feature >>>> (JDK-8232684), portions of javax.lang.model should be updated >>>> accordingly, including the description of SourceVersion.RELEASE_14. >>>> >>>> Please review the changes for this: >>>> >>>> http://cr.openjdk.java.net/~darcy/8233096.0/ >>>> >>>> Thanks, >>>> >>>> -Joe >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Nov 13 01:43:59 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 12 Nov 2019 17:43:59 -0800 Subject: JDK 14 RFR of JDK-8233096: Update javax.lang.model for switch expressions In-Reply-To: References: <0ba28fbc-6036-2b58-b579-ab3687b939cf@oracle.com> Message-ID: Hi Joe, There seems to be a lot of repeated code in the test, perhaps because it has been slowly growing over the years. It might be worth considering using an enum to encapsulate the properties/predicate/name of "keyword" vs "name". It also seems like the check calls always come in pairs for true/false for the first argument. In conjunction with the previous suggestion, this could maybe be simplified as well. -- Jon On 11/12/19 3:37 PM, Joe Darcy wrote: > > Coming back to this after the switch expression changes were pushed, > I've updated the test to give a more informative output message on an > error: > > http://cr.openjdk.java.net/~darcy/8233096.1/ > From joe.darcy at oracle.com Wed Nov 13 03:50:59 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 12 Nov 2019 19:50:59 -0800 Subject: JDK 14 RFR of JDK-8233096: Update javax.lang.model for switch expressions In-Reply-To: References: <0ba28fbc-6036-2b58-b579-ab3687b939cf@oracle.com> Message-ID: <538f1d3d-613f-d091-6cf9-531fd67a5ac6@oracle.com> Hi Jon, Re-refactored test to cut down on code duplication: ??? http://cr.openjdk.java.net/~darcy/8233096.2/ Cheers, -Joe On 11/12/2019 5:43 PM, Jonathan Gibbons wrote: > Hi Joe, > > There seems to be a lot of repeated code in the test, perhaps because > it has been slowly growing over the years. > > It might be worth considering using an enum to encapsulate the > properties/predicate/name of "keyword" vs "name". > > It also seems like the check calls always come in pairs for true/false > for the first argument. In conjunction with the previous suggestion, > this could maybe be simplified as well. > > -- Jon > > On 11/12/19 3:37 PM, Joe Darcy wrote: >> >> Coming back to this after the switch expression changes were pushed, >> I've updated the test to give a more informative output message on an >> error: >> >> http://cr.openjdk.java.net/~darcy/8233096.1/ >> From joe.darcy at oracle.com Wed Nov 13 04:13:11 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 12 Nov 2019 20:13:11 -0800 Subject: JDK 14 RFR of JDK-8233096: Update javax.lang.model for switch expressions In-Reply-To: <016f03ec-5d0b-1b0e-009f-7ba3acbe135b@oracle.com> References: <0ba28fbc-6036-2b58-b579-ab3687b939cf@oracle.com> <016f03ec-5d0b-1b0e-009f-7ba3acbe135b@oracle.com> Message-ID: <6de1db2c-9aed-d98f-2c69-188febb57f15@oracle.com> Hi Jon, On 11/12/2019 5:30 PM, Jonathan Gibbons wrote: > > I've reviewed the specific proposed update. > > As a picky comment on the CSR, the line wrapping before the version > number seems inconsistently gratuitous. > > More notably, the general use of "include", as in "Additions in this > release include ..." seems lazy and less than definitive. > The wording isn't entirely motivated by laziness ;-) There have been times in the past when the listing in SourceVersion.RELEASE_N was not updated at the same time a new feature went in. The less-precise wording is still truthful in an incomplete state. Also, there have been language changes smaller than the granularity of getting a named feature/JEP. Such changes are conditional on source version and the "additions include" allows for the existence of such changes without risking the false conclusions that there were no other language changes. HTH, -Joe > -- Jon > > > On 11/12/19 3:37 PM, Joe Darcy wrote: >> >> Coming back to this after the switch expression changes were pushed, >> I've updated the test to give a more informative output message on an >> error: >> >> http://cr.openjdk.java.net/~darcy/8233096.1/ >> >> and for completeness, a created an extra small CSR as well: >> >> https://bugs.openjdk.java.net/browse/JDK-8234055 >> >> Thanks, >> >> -Joe >> >> On 10/29/2019 11:28 AM, Joe Darcy wrote: >>> On 10/29/2019 10:09 AM, Jonathan Gibbons wrote: >>>> >>>> Although not modified, is this line in the test as intended? >>>> >>>> 137 throw new RuntimeException("Unexpected " + message + "-ness of _ on " + version); >>>> The reference to "_" seems unexpected. >>> >>> >>> Yeah; I noticed that too. It would clearly be more informative to >>> print out the input causing the failure. Code review feedback could >>> overcome my activation energy to do the small necessary refactoring ;-) >>> >>> -Joe >>> >>> >>>> >>>> -- Jon >>>> >>>> On 10/29/19 9:58 AM, Joe Darcy wrote: >>>>> Hello, >>>>> >>>>> After switch expressions are added as a full non-preview feature >>>>> (JDK-8232684), portions of javax.lang.model should be updated >>>>> accordingly, including the description of SourceVersion.RELEASE_14. >>>>> >>>>> Please review the changes for this: >>>>> >>>>> http://cr.openjdk.java.net/~darcy/8233096.0/ >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Nov 13 13:02:25 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 13 Nov 2019 13:02:25 +0000 Subject: RFR: JDK-8234025 Elements.getPackageElement(ModuleElement,CharSequence) returns null for unnamed package In-Reply-To: <23181b25-8674-1566-dbfd-0e50c7bf2fe8@oracle.com> References: <23181b25-8674-1566-dbfd-0e50c7bf2fe8@oracle.com> Message-ID: <4be87616-b94e-aee8-79dd-9a92f443a80b@oracle.com> Looks reasonable to me. Jan On 12. 11. 19 23:51, Jonathan Gibbons wrote: > Please review a small fix and corresponding test so that > ??? Elements.getPackageElement(ModuleElement mdle, CharSequence name) > returns a non-null result, as intended, for an unnamed package. > > The fault occurs in this code? in JavacElements.nameToSymbol: > > try { > if (sym ==null) > sym =javaCompiler.resolveIdent(module, nameStr); > > if (clazz.isInstance(sym)) { > sym.complete(); > if (sym.kind !=ERR && > sym.exists() && > name.equals(sym.getQualifiedName())) { > return clazz.cast(sym); > } > } > return null; > }catch (CompletionFailure cf) { > cf.dcfh.handleAPICompletionFailure(cf); > return null; > } > > While a non-null value for sym is found early on, it fails the > `.exists()` test and so `null` is returned. > > The fix is to mark the symbol as existing. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8234025 > Webrev: http://cr.openjdk.java.net/~jjg/8234025/webrev.00/ From jan.lahoda at oracle.com Wed Nov 13 14:11:58 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 13 Nov 2019 14:11:58 +0000 Subject: RFR: JDK-8234078: Missing license headers in a few javac files Message-ID: Hi, There is a handful of javac-related files with missing license headers or license headers with typos: -make/langtools/tools/propertiesparser/resources/templates.properties the proposal is to add the license header -src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor7.java typo in the license header -src/jdk.compiler/share/classes/META-INF/services/com.sun.tools.javac.platform.PlatformProvider src/jdk.compiler/share/classes/com/sun/tools/javac/services/javax.tools.JavaCompilerTool These appear unnecessary (their functionality has been moved to module-info, I believe), so the proposal is to remove them. Proposed patch: http://cr.openjdk.java.net/~jlahoda/8234078/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8234078 How does this look? Thanks, Jan From jonathan.gibbons at oracle.com Wed Nov 13 22:40:20 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 13 Nov 2019 14:40:20 -0800 Subject: JDK 14 RFR of JDK-8233096: Update javax.lang.model for switch expressions In-Reply-To: <6de1db2c-9aed-d98f-2c69-188febb57f15@oracle.com> References: <0ba28fbc-6036-2b58-b579-ab3687b939cf@oracle.com> <016f03ec-5d0b-1b0e-009f-7ba3acbe135b@oracle.com> <6de1db2c-9aed-d98f-2c69-188febb57f15@oracle.com> Message-ID: Hi Joe, Understood. While I think there could be some improvement in the wording, I accept such a discussion does not belong in this review thread. -- Jon On 11/12/2019 08:13 PM, Joe Darcy wrote: > > Hi Jon, > > On 11/12/2019 5:30 PM, Jonathan Gibbons wrote: >> >> I've reviewed the specific proposed update. >> >> As a picky comment on the CSR, the line wrapping before the version >> number seems inconsistently gratuitous. >> >> More notably, the general use of "include", as in "Additions in this >> release include ..." seems lazy and less than definitive. >> > The wording isn't entirely motivated by laziness ;-) There have been > times in the past when the listing in SourceVersion.RELEASE_N was not > updated at the same time a new feature went in. The less-precise > wording is still truthful in an incomplete state. Also, there have > been language changes smaller than the granularity of getting a named > feature/JEP. Such changes are conditional on source version and the > "additions include" allows for the existence of such changes without > risking the false conclusions that there were no other language changes. > > HTH, > > -Joe > > >> -- Jon >> >> >> On 11/12/19 3:37 PM, Joe Darcy wrote: >>> >>> Coming back to this after the switch expression changes were pushed, >>> I've updated the test to give a more informative output message on >>> an error: >>> >>> http://cr.openjdk.java.net/~darcy/8233096.1/ >>> >>> and for completeness, a created an extra small CSR as well: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8234055 >>> >>> Thanks, >>> >>> -Joe >>> >>> On 10/29/2019 11:28 AM, Joe Darcy wrote: >>>> On 10/29/2019 10:09 AM, Jonathan Gibbons wrote: >>>>> >>>>> Although not modified, is this line in the test as intended? >>>>> >>>>> 137 throw new RuntimeException("Unexpected " + message + "-ness of _ on " + version); >>>>> The reference to "_" seems unexpected. >>>> >>>> >>>> Yeah; I noticed that too. It would clearly be more informative to >>>> print out the input causing the failure. Code review feedback could >>>> overcome my activation energy to do the small necessary refactoring >>>> ;-) >>>> >>>> -Joe >>>> >>>> >>>>> >>>>> -- Jon >>>>> >>>>> On 10/29/19 9:58 AM, Joe Darcy wrote: >>>>>> Hello, >>>>>> >>>>>> After switch expressions are added as a full non-preview feature >>>>>> (JDK-8232684), portions of javax.lang.model should be updated >>>>>> accordingly, including the description of SourceVersion.RELEASE_14. >>>>>> >>>>>> Please review the changes for this: >>>>>> >>>>>> http://cr.openjdk.java.net/~darcy/8233096.0/ >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Joe >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Nov 13 22:47:49 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 13 Nov 2019 22:47:49 +0000 Subject: JDK 14 RFR of JDK-8233096: Update javax.lang.model for switch expressions In-Reply-To: <538f1d3d-613f-d091-6cf9-531fd67a5ac6@oracle.com> References: <0ba28fbc-6036-2b58-b579-ab3687b939cf@oracle.com> <538f1d3d-613f-d091-6cf9-531fd67a5ac6@oracle.com> Message-ID: Looks good to me. Thanks for taking care of this! Jan On 13. 11. 19 4:50, Joe Darcy wrote: > Hi Jon, > > Re-refactored test to cut down on code duplication: > > ??? http://cr.openjdk.java.net/~darcy/8233096.2/ > > Cheers, > > -Joe > > On 11/12/2019 5:43 PM, Jonathan Gibbons wrote: >> Hi Joe, >> >> There seems to be a lot of repeated code in the test, perhaps because >> it has been slowly growing over the years. >> >> It might be worth considering using an enum to encapsulate the >> properties/predicate/name of "keyword" vs "name". >> >> It also seems like the check calls always come in pairs for true/false >> for the first argument. In conjunction with the previous suggestion, >> this could maybe be simplified as well. >> >> -- Jon >> >> On 11/12/19 3:37 PM, Joe Darcy wrote: >>> >>> Coming back to this after the switch expression changes were pushed, >>> I've updated the test to give a more informative output message on an >>> error: >>> >>> http://cr.openjdk.java.net/~darcy/8233096.1/ >>> From jonathan.gibbons at oracle.com Wed Nov 13 22:49:34 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 13 Nov 2019 14:49:34 -0800 Subject: JDK 14 RFR of JDK-8233096: Update javax.lang.model for switch expressions In-Reply-To: <538f1d3d-613f-d091-6cf9-531fd67a5ac6@oracle.com> References: <0ba28fbc-6036-2b58-b579-ab3687b939cf@oracle.com> <538f1d3d-613f-d091-6cf9-531fd67a5ac6@oracle.com> Message-ID: <489fcce8-9df4-374e-4916-f000e74a5b5a@oracle.com> OK. While there is still some repeated code, most notably with respect to isKeyword and isKeywordVersion, I realize these are the methods being tested, and should not be oversimplified. -- Jon On 11/12/2019 07:50 PM, Joe Darcy wrote: > Hi Jon, > > Re-refactored test to cut down on code duplication: > > ??? http://cr.openjdk.java.net/~darcy/8233096.2/ > > Cheers, > > -Joe > > On 11/12/2019 5:43 PM, Jonathan Gibbons wrote: >> Hi Joe, >> >> There seems to be a lot of repeated code in the test, perhaps because >> it has been slowly growing over the years. >> >> It might be worth considering using an enum to encapsulate the >> properties/predicate/name of "keyword" vs "name". >> >> It also seems like the check calls always come in pairs for >> true/false for the first argument. In conjunction with the previous >> suggestion, this could maybe be simplified as well. >> >> -- Jon >> >> On 11/12/19 3:37 PM, Joe Darcy wrote: >>> >>> Coming back to this after the switch expression changes were pushed, >>> I've updated the test to give a more informative output message on >>> an error: >>> >>> http://cr.openjdk.java.net/~darcy/8233096.1/ >>> From jonathan.gibbons at oracle.com Wed Nov 13 23:19:24 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 13 Nov 2019 15:19:24 -0800 Subject: RFR: JEP 359-Records: javadoc code In-Reply-To: <1401005874.1279819.1572531530885.JavaMail.zimbra@u-pem.fr> References: <914ab35b-ff07-1b9e-472c-9a04f7bc49dc@oracle.com> <143D28AD-946C-4B43-93D7-E88BF1AAD895@oracle.com> <1401005874.1279819.1572531530885.JavaMail.zimbra@u-pem.fr> Message-ID: On 10/31/19 7:18 AM, Remi Forax wrote: >> For nested classes, on the other hand, I?m not quite as sure. The rule about >> ?nested records are implicitly static? is a little more subtle than the one >> about finality. > I will just add that enums have exactly the same rule, an enum is always static when nested in another class, > so whatever we decide, it should be the same for enums. > > R?mi > To pick up on this, there's good news, bad news ;-) Good news: the handling of the static modifier on nested classes is the same for "enum" and "static". Bad news (but should be easy to fix): nested records do not show up in the enclosing class. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Nov 14 00:30:12 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 13 Nov 2019 16:30:12 -0800 Subject: JDK 14 RFR of JDK-8233096: Update javax.lang.model for switch expressions In-Reply-To: <0ba28fbc-6036-2b58-b579-ab3687b939cf@oracle.com> References: <0ba28fbc-6036-2b58-b579-ab3687b939cf@oracle.com> Message-ID: <3e6686df-fae1-68b7-cc45-e2756e0583e9@oracle.com> Just curious does it mean that now it is possible to use "switch expressions" in the libraries of the JDK itself? or we need to wait JDK 15? On 10/29/19 9:58 am, Joe Darcy wrote: > Hello, > > After switch expressions are added as a full non-preview feature (JDK-8232684), portions of javax.lang.model should be updated accordingly, including the description of SourceVersion.RELEASE_14. > > Please review the changes for this: > > ??? http://cr.openjdk.java.net/~darcy/8233096.0/ > > Thanks, > > -Joe > -- Best regards, Sergey. From joe.darcy at oracle.com Thu Nov 14 01:04:18 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 13 Nov 2019 17:04:18 -0800 Subject: JDK 14 RFR of JDK-8233096: Update javax.lang.model for switch expressions In-Reply-To: <3e6686df-fae1-68b7-cc45-e2756e0583e9@oracle.com> References: <0ba28fbc-6036-2b58-b579-ab3687b939cf@oracle.com> <3e6686df-fae1-68b7-cc45-e2756e0583e9@oracle.com> Message-ID: <64b914ff-4706-d29f-5e79-93831c6c5422@oracle.com> Switch expressions can be used except in portions of the platform compiled by the bootstrap compiler, mostly the java.compiler and jdk.compiler modules. HTH, -Joe On 11/13/2019 4:30 PM, Sergey Bylokhov wrote: > Just curious does it mean that now it is possible to use "switch > expressions" > in the libraries of the JDK itself? or we need to wait JDK 15? > > On 10/29/19 9:58 am, Joe Darcy wrote: >> Hello, >> >> After switch expressions are added as a full non-preview feature >> (JDK-8232684), portions of javax.lang.model should be updated >> accordingly, including the description of SourceVersion.RELEASE_14. >> >> Please review the changes for this: >> >> ???? http://cr.openjdk.java.net/~darcy/8233096.0/ >> >> Thanks, >> >> -Joe >> > > From fujie at loongson.cn Thu Nov 14 15:34:58 2019 From: fujie at loongson.cn (Jie Fu) Date: Thu, 14 Nov 2019 23:34:58 +0800 Subject: RFR(trivial): 8234183: [TESTBUG] tools/javac/api/TestModuleUnnamedPackage.java fails to compile Message-ID: <90c02a23-b8e0-1f3a-3413-9a002973156b@loongson.cn> Hi all, May I get reviews for this small fix? JBS:??? https://bugs.openjdk.java.net/browse/JDK-8234183 Webrev: http://cr.openjdk.java.net/~jiefu/8234183/webrev.00/ And I need a sponsor. Thanks a lot. Best regards, Jie From jonathan.gibbons at oracle.com Thu Nov 14 15:57:09 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 14 Nov 2019 07:57:09 -0800 Subject: RFR(trivial): 8234183: [TESTBUG] tools/javac/api/TestModuleUnnamedPackage.java fails to compile In-Reply-To: <90c02a23-b8e0-1f3a-3413-9a002973156b@loongson.cn> References: <90c02a23-b8e0-1f3a-3413-9a002973156b@loongson.cn> Message-ID: <7b971486-afc3-ada6-2e5e-e2c244704dc5@oracle.com> OK, but note it is our standard practice to list the modules one per line. 28 * @modules jdk.compiler/com.sun.tools.javac.api * jdk.compiler/com.sun.tools.javac.main This helps some of our automated checking tools. I'll sponsor this for you. -- Jon On 11/14/19 7:34 AM, Jie Fu wrote: > Hi all, > > May I get reviews for this small fix? > > JBS:??? https://bugs.openjdk.java.net/browse/JDK-8234183 > Webrev: http://cr.openjdk.java.net/~jiefu/8234183/webrev.00/ > > And I need a sponsor. > > Thanks a lot. > Best regards, > Jie > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fujie at loongson.cn Fri Nov 15 00:57:25 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 15 Nov 2019 08:57:25 +0800 Subject: RFR(trivial): 8234183: [TESTBUG] tools/javac/api/TestModuleUnnamedPackage.java fails to compile In-Reply-To: <7b971486-afc3-ada6-2e5e-e2c244704dc5@oracle.com> References: <90c02a23-b8e0-1f3a-3413-9a002973156b@loongson.cn> <7b971486-afc3-ada6-2e5e-e2c244704dc5@oracle.com> Message-ID: Thanks Jon for your review and sponsoring. Best regards, Jie On 2019/11/14 ??11:57, Jonathan Gibbons wrote: > > OK, but note it is our standard practice to list the modules one per line. > > 28 * @modules jdk.compiler/com.sun.tools.javac.api * > jdk.compiler/com.sun.tools.javac.main > This helps some of our automated checking tools. > > I'll sponsor this for you. > > -- Jon > > On 11/14/19 7:34 AM, Jie Fu wrote: >> Hi all, >> >> May I get reviews for this small fix? >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8234183 >> Webrev: http://cr.openjdk.java.net/~jiefu/8234183/webrev.00/ >> >> And I need a sponsor. >> >> Thanks a lot. >> Best regards, >> Jie >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From brent.christian at oracle.com Fri Nov 15 23:47:03 2019 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 15 Nov 2019 15:47:03 -0800 Subject: RFR: JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) In-Reply-To: <00C5C729-D9FF-48E0-8F7F-DD8E7615ACEC@oracle.com> References: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com> <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com> <00C5C729-D9FF-48E0-8F7F-DD8E7615ACEC@oracle.com> Message-ID: <818dcc2d-2d4a-57c7-a4e0-c1c873999c2a@oracle.com> Hi, Jim src/java.base/share/classes/java/lang/String.java These changes look fine. -- test/jdk/java/lang/String/TranslateEscapes.java I'm missing where the new verifyLineTerminator() method gets called. Perhaps that's meant to go here: 83 static void test4() { 84 85 } ? -Brent On 11/12/19 7:15 AM, Jim Laskey wrote: > updated > > webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev.03/index.html > > From brian.goetz at oracle.com Sun Nov 17 21:24:10 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 17 Nov 2019 16:24:10 -0500 Subject: RFR: JEP 359-Records: compiler code In-Reply-To: References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> <9f8607fd-9fab-cc7a-9b0b-8913887df893@oracle.com> <7ebb480f-bbcb-2ac0-ce9a-73e5888f5df4@oracle.com> <97d2b883-8df4-dd6e-cad4-e2ad5982a92c@oracle.com> <93449ea7-d486-3f92-8bbf-cf44d386ef1e@oracle.com> <33119ca4-7e11-a7e6-4457-b6a909cfc634@oracle.com> <63f79bf1-8ee9-b1f4-ebeb-10de5b7c2ed5@oracle.com> Message-ID: <79e9e361-7fab-3fbb-ef28-856f61d683a4@oracle.com> > > * I noted that, while we have many diagnostics tests, we have > basically zero negative tests to check that the compiler is generating > the desired error message _without any additional_ spurious errors. In > principle, there should be at least one negative test for each > record-related error message. This leads to replication with the > diagnostics tests, but we've always done it this way. The diagnostic > framework is for diagnostics - per se, it is insufficient to verify > good quality of compiler output. I propose that we beef up CompilationTestCase to be able to make such assertions (right now we assert that the specified error is there, but we can also assert that others are not.)? Similarly we can beef this up to support correct location testing if desired. > * I suggest maybe to group tests in different folders depending on the > 'category' they fall in. E.g. I see you have a reflection test and a > serialization test, then some annotation processing tests - it would > be nice to label these accordingly by putting them in separate folders. As we discussed last week, perhaps some guidance on what the categories should be -- and the right testing strategy for each category -- would help in uniformity of coverage. From james.laskey at oracle.com Mon Nov 18 14:26:27 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 18 Nov 2019 10:26:27 -0400 Subject: RFR: JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) In-Reply-To: <818dcc2d-2d4a-57c7-a4e0-c1c873999c2a@oracle.com> References: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com> <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com> <00C5C729-D9FF-48E0-8F7F-DD8E7615ACEC@oracle.com> <818dcc2d-2d4a-57c7-a4e0-c1c873999c2a@oracle.com> Message-ID: Editing glitch.Was there but then it was gone. Thanks Brent. http://cr.openjdk.java.net/~jlaskey/8233116/webrev.04/index.html > On Nov 15, 2019, at 7:47 PM, Brent Christian wrote: > > Hi, Jim > > > src/java.base/share/classes/java/lang/String.java > > These changes look fine. > > -- > > test/jdk/java/lang/String/TranslateEscapes.java > > I'm missing where the new verifyLineTerminator() method gets called. Perhaps that's meant to go here: > > 83 static void test4() { > 84 > 85 } > > ? > > -Brent > > On 11/12/19 7:15 AM, Jim Laskey wrote: >> updated >> webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev.03/index.html From per.liden at oracle.com Tue Nov 19 07:32:10 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 19 Nov 2019 08:32:10 +0100 Subject: RFR: 8234382: Test tools/javac/processing/model/testgetallmembers/Main.java using too small heap Message-ID: Hi, Please review this one-liner test fix. The test tools/javac/processing/model/testgetallmembers/Main.java is assuming that a 256M heap is enough to hold its live-set, but this is only true under some conditions. There are a number of JVM flags that, when used, can break this assumption. For example, choice of GC, compressed oop, object alignment, and other options affecting the heap layout or allocation strategy. Under ideal conditions, the test is already fairly close to using the whole heap, so it doesn't take that much to push it over the edge. For example, the following combinations all fail: -XX:+UseSerialGC -XX:-UseCompressedOops -XX:+UseParallelGC -XX:-UseCompressedOops -XX:+UseZGC (always has -XX:-UseCompressedOops) -XX:+UseG1GC -XX:-UseCompressedOops -XX:ObjectAlignmentInBytes=16 I suggest we bump the max heap size to something like 512M, to give the test more headroom and make it less sensitive to exact choice of JVM flags. Bug: https://bugs.openjdk.java.net/browse/JDK-8234382 Webrev: http://cr.openjdk.java.net/~pliden/8234382/webrev.0 /Per From per.liden at oracle.com Tue Nov 19 08:33:17 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 19 Nov 2019 09:33:17 +0100 Subject: RFR: 8234382: Test tools/javac/processing/model/testgetallmembers/Main.java using too small heap In-Reply-To: <8757fad5-88b5-4e28-af8e-01dd457deec9@oracle.com> References: <8757fad5-88b5-4e28-af8e-01dd457deec9@oracle.com> Message-ID: Thanks Erik! /Per On 11/19/19 9:13 AM, Erik ?sterlund wrote: > Hi Per, > > Looks good. > > Thanks, > /Erik > > On 2019-11-19 08:32, Per Liden wrote: >> Hi, >> >> Please review this one-liner test fix. >> >> The test tools/javac/processing/model/testgetallmembers/Main.java is >> assuming that a 256M heap is enough to hold its live-set, but this is >> only true under some conditions. There are a number of JVM flags that, >> when used, can break this assumption. For example, choice of GC, >> compressed oop, object alignment, and other options affecting the heap >> layout or allocation strategy. Under ideal conditions, the test is >> already fairly close to using the whole heap, so it doesn't take that >> much to push it over the edge. For example, the following combinations >> all fail: >> >> -XX:+UseSerialGC -XX:-UseCompressedOops >> -XX:+UseParallelGC -XX:-UseCompressedOops >> -XX:+UseZGC (always has -XX:-UseCompressedOops) >> -XX:+UseG1GC -XX:-UseCompressedOops -XX:ObjectAlignmentInBytes=16 >> >> I suggest we bump the max heap size to something like 512M, to give >> the test more headroom and make it less sensitive to exact choice of >> JVM flags. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8234382 >> Webrev: http://cr.openjdk.java.net/~pliden/8234382/webrev.0 >> >> /Per > From forax at univ-mlv.fr Tue Nov 19 08:40:27 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 19 Nov 2019 09:40:27 +0100 (CET) Subject: JEP 358 (Helpful NPEs) and single source file mode In-Reply-To: References: Message-ID: <1619831852.538078.1574152827976.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Gunnar Morling" > ?: "core-libs-dev" > Envoy?: Mardi 19 Novembre 2019 09:34:41 > Objet: JEP 358 (Helpful NPEs) and single source file mode > Hi, > > I've been exploring the new helpful NPE feature a bit. > > It's a very welcomed improvement, but I noticed one potential usability > issue in conjunction with the single source file mode (JEP 330): as debug > info is missing in that case, e.g. local variables are rendered as > "" in the exception message. Single source file mode also doesn't > let me specify the "-g:vars" option I could use with javac for adding the > debugging info. > > Perhaps single source file mode should add debug information by default to > prevent this issue? yes ! > > Thanks, > > --Gunnar R?mi From per.liden at oracle.com Tue Nov 19 10:02:43 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 19 Nov 2019 11:02:43 +0100 Subject: RFR: 8234382: Test tools/javac/processing/model/testgetallmembers/Main.java using too small heap In-Reply-To: References: Message-ID: Thanks Thomas! /Per On 11/19/19 9:21 AM, Thomas Schatzl wrote: > Hi, > > On 19.11.19 08:32, Per Liden wrote: >> Hi, >> >> Please review this one-liner test fix. >> >> The test tools/javac/processing/model/testgetallmembers/Main.java is[...] >> I suggest we bump the max heap size to something like 512M, to give >> the test more headroom and make it less sensitive to exact choice of >> JVM flags. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8234382 >> Webrev: http://cr.openjdk.java.net/~pliden/8234382/webrev.0 > > ?looks good. > > Thomas From erik.osterlund at oracle.com Tue Nov 19 08:13:38 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 19 Nov 2019 09:13:38 +0100 Subject: RFR: 8234382: Test tools/javac/processing/model/testgetallmembers/Main.java using too small heap In-Reply-To: References: Message-ID: <8757fad5-88b5-4e28-af8e-01dd457deec9@oracle.com> Hi Per, Looks good. Thanks, /Erik On 2019-11-19 08:32, Per Liden wrote: > Hi, > > Please review this one-liner test fix. > > The test tools/javac/processing/model/testgetallmembers/Main.java is > assuming that a 256M heap is enough to hold its live-set, but this is > only true under some conditions. There are a number of JVM flags that, > when used, can break this assumption. For example, choice of GC, > compressed oop, object alignment, and other options affecting the heap > layout or allocation strategy. Under ideal conditions, the test is > already fairly close to using the whole heap, so it doesn't take that > much to push it over the edge. For example, the following combinations > all fail: > > -XX:+UseSerialGC -XX:-UseCompressedOops > -XX:+UseParallelGC -XX:-UseCompressedOops > -XX:+UseZGC (always has -XX:-UseCompressedOops) > -XX:+UseG1GC -XX:-UseCompressedOops -XX:ObjectAlignmentInBytes=16 > > I suggest we bump the max heap size to something like 512M, to give > the test more headroom and make it less sensitive to exact choice of > JVM flags. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8234382 > Webrev: http://cr.openjdk.java.net/~pliden/8234382/webrev.0 > > /Per From jonathan.gibbons at oracle.com Tue Nov 19 18:39:09 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 19 Nov 2019 10:39:09 -0800 Subject: JEP 358 (Helpful NPEs) and single source file mode In-Reply-To: <1619831852.538078.1574152827976.JavaMail.zimbra@u-pem.fr> References: <1619831852.538078.1574152827976.JavaMail.zimbra@u-pem.fr> Message-ID: It's a design constraint that the "single source file mode" does not and should not support javac-specific command-line options beyond those that are also runtime options (for example, --class-path). That being said, since one of the use cases is for beginners learning Java, it seems reasonable to support debugging information in that case. The other use case is for scripts/shebang files, and the debugging information should not be an onerous overhead in that case as well. Therefore, I'm inclined to agree with the suggestion. -- Jon On 11/19/19 12:40 AM, Remi Forax wrote: > ----- Mail original ----- >> De: "Gunnar Morling" >> ?: "core-libs-dev" >> Envoy?: Mardi 19 Novembre 2019 09:34:41 >> Objet: JEP 358 (Helpful NPEs) and single source file mode >> Hi, >> >> I've been exploring the new helpful NPE feature a bit. >> >> It's a very welcomed improvement, but I noticed one potential usability >> issue in conjunction with the single source file mode (JEP 330): as debug >> info is missing in that case, e.g. local variables are rendered as >> "" in the exception message. Single source file mode also doesn't >> let me specify the "-g:vars" option I could use with javac for adding the >> debugging info. >> >> Perhaps single source file mode should add debug information by default to >> prevent this issue? > yes ! > >> Thanks, >> >> --Gunnar > R?mi > From brent.christian at oracle.com Tue Nov 19 19:25:54 2019 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 19 Nov 2019 11:25:54 -0800 Subject: RFR: JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview) In-Reply-To: References: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com> <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com> <00C5C729-D9FF-48E0-8F7F-DD8E7615ACEC@oracle.com> <818dcc2d-2d4a-57c7-a4e0-c1c873999c2a@oracle.com> Message-ID: <0218bbf8-0f0f-6727-91dc-d06184d1b261@oracle.com> On 11/18/19 6:26 AM, Jim Laskey wrote: > > http://cr.openjdk.java.net/~jlaskey/8233116/webrev.04/index.html > OK, thanks. The changes in: src/java.base/share/classes/java/lang/String.java test/jdk/java/lang/String/TranslateEscapes.java look fine. -Brent From vicente.romero at oracle.com Thu Nov 21 16:43:52 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 21 Nov 2019 11:43:52 -0500 Subject: RFR: JDK-8234078: Missing license headers in a few javac files In-Reply-To: References: Message-ID: looks good, Vicente On 11/13/19 9:11 AM, Jan Lahoda wrote: > Hi, > > There is a handful of javac-related files with missing license headers > or license headers with typos: > -make/langtools/tools/propertiesparser/resources/templates.properties > the proposal is to add the license header > -src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor7.java > > typo in the license header > -src/jdk.compiler/share/classes/META-INF/services/com.sun.tools.javac.platform.PlatformProvider > > src/jdk.compiler/share/classes/com/sun/tools/javac/services/javax.tools.JavaCompilerTool > > > These appear unnecessary (their functionality has been moved to > module-info, I believe), so the proposal is to remove them. > > Proposed patch: > http://cr.openjdk.java.net/~jlahoda/8234078/webrev.00/index.html > > JBS: https://bugs.openjdk.java.net/browse/JDK-8234078 > > How does this look? > > Thanks, > ??? Jan From gavin.bierman at oracle.com Thu Nov 21 16:19:08 2019 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Thu, 21 Nov 2019 16:19:08 +0000 Subject: Use of an annotation without @Target meta-annotation on a module declaration Message-ID: <50944B3D-995D-4278-AF41-3A77F635417E@oracle.com> I wanted to alert readers of this list to the fact that JEP 359 (Records) will add a new declaration context for annotations, and hence there will be a new enum constant, RECORD_COMPONENT, of java.lang.annotation.ElementType. http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191121/specs/records-jls.html With regards to the recent discussion on this list, I have followed the agreed suggestion: On 9/19/2019 8:32 PM, Michael Ernst wrote: > * All contexts. > This is the simplest and clearest specification. It is the most > intuitive and easiest to remember, and therefore least likely to lead to > problems. Those qualities make it attractive. > It is a behavior change from the current specification, but a small > one that affects poorly-written programs that have no @Target > meta-annotation. > I propose that we adopt this meaning. In other words, a program with no @Target meta-annotation will be applicable in the new RECORD_COMPONENT context. Gavin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri Nov 22 12:21:28 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 22 Nov 2019 13:21:28 +0100 Subject: RFR: JDK-8231826: Implement javac changes for pattern matching for instanceof In-Reply-To: References: <82fed943-bd28-f0ae-fe9c-645d1f3160c6@oracle.com> <9b6820ff-9a93-31cb-0b51-367d8337fa7f@oracle.com> <8821e763-d28b-8648-c8c9-1f3531fcf3a8@oracle.com> <2f4419d4-f3b5-40d6-9a18-7f8e8537b4f7@oracle.com> Message-ID: A few additional touches to the patch: -improvement to the javadoc for InstanceOfTree.getPattern(), as suggested on the CSR (JDK-8231827) -adding missing @module key in test/langtools/tools/javac/annotations/typeAnnotations/classfile/Patterns.java -enhancing the test/langtools/tools/javac/patterns/ReifiableOld.java test to verify that for the most recent source level and preview features disabled the "instanceof " still works as before (i.e. non-reifiable types disallowed). Delta webrev from last revision: http://cr.openjdk.java.net/~jlahoda/8231826/webrev.delta.03-04/ Full webrev: http://cr.openjdk.java.net/~jlahoda/8231826/webrev.04/ Any objections to this? Thanks, Jan On 22. 10. 19 18:20, Maurizio Cimadamore wrote: > Looks good > > Maurizio > > On 22/10/2019 16:27, Jan Lahoda wrote: >> Hi, >> >> A new draft of the pattern matching for instanceof has been published >> here: >> https://mail.openjdk.java.net/pipermail/amber-dev/2019-October/004962.html >> >> >> A significant change in this draft is that safe(*) reifiable types are >> allowed in instanceof of. And updated version of the pattern matching >> patch for javac which supports this change is here: >> http://cr.openjdk.java.net/~jlahoda/8231826/webrev.03/ >> >> A diff from the previous revision: >> http://cr.openjdk.java.net/~jlahoda/8231826/webrev.delta.02-03/ >> >> (*) reifiable types are allowed if (for "expr instanceof type"), >> "expr" can be cast to "type" without unchecked warnings. >> >> Does this make sense? >> >> Thanks, >> ??? Jan >> >> On 15. 10. 19 15:02, Maurizio Cimadamore wrote: >>> Yep - that would be more helpful (at least to me) >>> >>> Thanks >>> Maurizio >>> >>> On 15/10/2019 13:56, Jan Lahoda wrote: >>>> Would this be better? >>>> >>>> Full patch: >>>> http://cr.openjdk.java.net/~jlahoda/8231826/webrev.02/ >>>> >>>> Diff from previous: >>>> http://cr.openjdk.java.net/~jlahoda/8231826/webrev.delta.01-02/ >>>> >>>> Thanks, >>>> ??? Jan >>>> >>>> On 15. 10. 19 13:59, Maurizio Cimadamore wrote: >>>>> Hi, >>>>> the flow changes look good - I think the TransPattern documentation >>>>> should contain less text and more code snippet examples which show >>>>> what the generated code looks like (as I've tried to do in my >>>>> email, and as you've done for visitTypeTest). In other words, what >>>>> is missing here is "the big picture" which shows what are the main >>>>> ideas behind the translation strategy. >>>>> >>>>> Specific example: decorateExpression: >>>>> >>>>> + //if there are binding variables defined and used only in this >>>>> expression, >>>>> + //which are not confined to a specific sub-expression, >>>>> + //a let expression is created which replaces the statement, and >>>>> + //the binding variables are hoisted into this let expression: >>>>> >>>>> >>>>> This kind of illustrates my point: >>>>> >>>>> * "if there are binding variables defined and used only in this >>>>> expression, which are not confined to a specific sub-expression" is >>>>> very convoluted, and will be almost meaningless when we pick up >>>>> this code again in 6 months >>>>> * "a let expression is created which replaces the statement" - >>>>> statement? Probably cut and paste error >>>>> >>>>> Thanks >>>>> Maurizio >>>>> >>>>> On 15/10/2019 10:46, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> I've updated the patch with the Flow changes and with additional >>>>>> comments in TransPatterns here: >>>>>> http://cr.openjdk.java.net/~jlahoda/8231826/webrev.01/ >>>>>> diff from previous: >>>>>> http://cr.openjdk.java.net/~jlahoda/8231826/webrev.delta.00-01/ >>>>>> >>>>>> An additional patch (that would apply on top of this one) which >>>>>> makes all instanceof instances to be modelled as instanceof >>>>>> : >>>>>> http://cr.openjdk.java.net/~jlahoda/8231826/webrev.01.unify.instanceof/ >>>>>> >>>>>> >>>>>> Some more comment inline. >>>>>> >>>>>> On 10. 10. 19 17:33, Maurizio Cimadamore wrote: >>>>>>> Hi Jan, >>>>>>> the code looks generally very clean, kudos. >>>>>>> >>>>>>> Some general comments: >>>>>>> >>>>>>> * looking at the spec, it seems like both "instanceof T" and >>>>>>> "instanceof T t" are cases of type test patterns. I guess I'm >>>>>>> fine with the implementation doing what it always did in terms of >>>>>>> plain "instanceof T", but I'm worried about the intersection >>>>>>> between this and e.g. the tree API - InstanceofTree::getPattern >>>>>>> returns null in cases like "instanceof T"; now, I know I know >>>>>>> that we're speaking about a JDK specific API, but I think this >>>>>>> issue reveals some modelling issues in the way we treat >>>>>>> instanceof, and I'm worried that some of these issues might pop >>>>>>> up in the future. I'd prefer to either rectify the spec so that >>>>>>> plain 'instanceof T' is not a pattern matching instanceof, or >>>>>>> rectify javac so that these tests are internally also represented >>>>>>> with patterns (at the expense of some extra allocation, perhaps). >>>>>>> >>>>>>> * If I'm not mistaken the only use for the >>>>>>> "MATCH_BINDING_TO_OUTER" flag is to be able to distinguish >>>>>>> between regular 'expression-wide' bindings, and bindings which >>>>>>> 'leaked' outside a statement (e.g. an if statement). And the >>>>>>> reason you need to distinguish between these is that you don't >>>>>>> want Check::checkUnique to flag duplicate errors between regular >>>>>>> 'expression-wide' bindings, which are reported elsewhere >>>>>>> (MatchBindingsComputer). But this is also, more crucially, used >>>>>>> in TransPattern, where the 'isPreserved' flag is used to control >>>>>>> whether a variable decl for the binding variable should be >>>>>>> 'lifted' to the enclosing statement context or not. Is my >>>>>>> understanding correct here? >>>>>> >>>>>> Yes, the primary intent is to mark variables that need to be >>>>>> hoisted to the parent of the current statement. >>>>>> >>>>>>> >>>>>>> * The idea behind TransPatterns seems to be: when we process a >>>>>>> statement, or an expression, we attempt to add all declaration >>>>>>> for the bindings that are used inside the statements/expression >>>>>>> upfront. If we are processing a statement, then we surround the >>>>>>> results in a block; e.g. >>>>>>> >>>>>>> if (obj instanceof Foo f) { >>>>>>> ?? ... >>>>>>> } >>>>>>> >>>>>>> becomes >>>>>>> >>>>>>> { >>>>>>> ??? Foo f$; >>>>>>> ??? if (let Object temp = obj in (obj instanceof Foo && (f$ = >>>>>>> (Foo)temp) == temp) { >>>>>>> ?????? ... >>>>>>> } >>>>>>> >>>>>>> If we are processing an expression, we instead generate a >>>>>>> LetExpr, e.g. >>>>>>> >>>>>>> boolean b = obj instanceof Foo t && t.equals(foo); >>>>>>> >>>>>>> becomes: >>>>>>> >>>>>>> boolean b = let Foo f$ = null in ((let Object temp = obj in (obj >>>>>>> instanceof Foo && (f$ = (Foo)temp) == temp) && f$.equals(foo)) >>>>>>> >>>>>>> So, sometimes the hoisted var is a real var decl in a block, >>>>>>> other times is a var decl inside a let expression. In these cases >>>>>>> we have to generate an initializer, to set the value (which might >>>>>>> be used later). >>>>>> >>>>>> The hoisted vars do not have an initializer (they used to have >>>>>> one, but it is both unnecessary and was masking out bugs, so I >>>>>> have removed it). But I see I've forgot the initializer code >>>>>> commented out in TransPatterns, removed in the updated version to >>>>>> avoid confusion. >>>>>> >>>>>>> On top of that, instanceof generates its own letExpr to cache the >>>>>>> target of the test (to avoid double computation). >>>>>>> >>>>>>> It also seems to me that the code handles cases where the binding >>>>>>> variable is not used, neither hoisted - e.g. >>>>>>> >>>>>>> boolean field = obj instanceof Foo t; >>>>>>> >>>>>>> In this case we generate a plain instanceof w/o the init (because >>>>>>> the 't' variable hasn't been hoisted anywhere). >>>>>>> >>>>>>> Finally, we use the 'isPreserved()' flag to ensure that variables >>>>>>> are hoisted correctly - for instance, if something is to be >>>>>>> preserved (and the enclosing context allows for it) we push >>>>>>> things in the enclosing context instead. >>>>>>> >>>>>>> Am I getting the correct picture here? >>>>>> >>>>>> Yes, I think it is correct. >>>>>> >>>>>>> >>>>>>> It would be nice to have more javadoc spread around to help the >>>>>>> reader understand what's the rationale and show some snippet of >>>>>>> generated code. >>>>>>> >>>>>>> * Flow, I wonder if, like you had created SnippetAliveAnalyzer, >>>>>>> creating a SnippetBreakAnalyzer would help you avoid the >>>>>>> breaksOut[0] trick (that could become a field in the child visitor) >>>>>> >>>>>> I tried to do these two in the updated patch. >>>>>> >>>>>> Thanks for the comments! >>>>>> >>>>>> Jan >>>>>> >>>>>>> >>>>>>> >>>>>>> Other than that, it looks very good. >>>>>>> >>>>>>> Maurizio >>>>>>> >>>>>>> On 10/10/2019 13:12, Jan Lahoda wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> As part of the effort to prepare JEP 305: Pattern Matching for >>>>>>>> instanceof (Preview) for Propose to Target, I would like to ask >>>>>>>> for a code review for the corresponding javac changes. >>>>>>>> >>>>>>>> The webrev is here: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8231826/webrev.00/ >>>>>>>> >>>>>>>> The patch applies on top of: >>>>>>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-October/013727.html >>>>>>>> >>>>>>>> >>>>>>>> The current spec the patch is striving to implements is here: >>>>>>>> http://cr.openjdk.java.net/~gbierman/jep305/jep305-20190918/specs/patterns-instanceof-jls.html >>>>>>>> >>>>>>>> >>>>>>>> As far as I know, there is one (significant) open issue in the >>>>>>>> spec, and that is whether non-reifiable types should be allowed >>>>>>>> in "instanceof ". Currently (AFAIK), the spec >>>>>>>> does not allow non-reifiable types in the type test pattern in >>>>>>>> instanceof, and the javac implementation should be consistent >>>>>>>> with the spec. Should the spec change, the corresponding update >>>>>>>> to the javac code should have a very limited impact. >>>>>>>> >>>>>>>> I'll be preparing a CSR for this change in the coming days. >>>>>>>> >>>>>>>> The JBS issue for this code change is: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8231826 >>>>>>>> >>>>>>>> Any feedback is welcome! >>>>>>>> >>>>>>>> Thanks! >>>>>>>> ??? Jan From maurizio.cimadamore at oracle.com Fri Nov 22 12:31:56 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 22 Nov 2019 12:31:56 +0000 Subject: RFR: JDK-8231826: Implement javac changes for pattern matching for instanceof In-Reply-To: References: <82fed943-bd28-f0ae-fe9c-645d1f3160c6@oracle.com> <9b6820ff-9a93-31cb-0b51-367d8337fa7f@oracle.com> <8821e763-d28b-8648-c8c9-1f3531fcf3a8@oracle.com> <2f4419d4-f3b5-40d6-9a18-7f8e8537b4f7@oracle.com> Message-ID: Looks good Maurizio On 22/11/2019 12:21, Jan Lahoda wrote: > A few additional touches to the patch: > -improvement to the javadoc for InstanceOfTree.getPattern(), as > suggested on the CSR (JDK-8231827) > -adding missing @module key in > test/langtools/tools/javac/annotations/typeAnnotations/classfile/Patterns.java > -enhancing the test/langtools/tools/javac/patterns/ReifiableOld.java > test to verify that for the most recent source level and preview > features disabled the "instanceof " still works as > before (i.e. non-reifiable types disallowed). > > Delta webrev from last revision: > http://cr.openjdk.java.net/~jlahoda/8231826/webrev.delta.03-04/ > > Full webrev: > http://cr.openjdk.java.net/~jlahoda/8231826/webrev.04/ > > Any objections to this? > > Thanks, > ??? Jan > > On 22. 10. 19 18:20, Maurizio Cimadamore wrote: >> Looks good >> >> Maurizio >> >> On 22/10/2019 16:27, Jan Lahoda wrote: >>> Hi, >>> >>> A new draft of the pattern matching for instanceof has been >>> published here: >>> https://mail.openjdk.java.net/pipermail/amber-dev/2019-October/004962.html >>> >>> >>> A significant change in this draft is that safe(*) reifiable types >>> are allowed in instanceof of. And updated version of the pattern >>> matching patch for javac which supports this change is here: >>> http://cr.openjdk.java.net/~jlahoda/8231826/webrev.03/ >>> >>> A diff from the previous revision: >>> http://cr.openjdk.java.net/~jlahoda/8231826/webrev.delta.02-03/ >>> >>> (*) reifiable types are allowed if (for "expr instanceof type"), >>> "expr" can be cast to "type" without unchecked warnings. >>> >>> Does this make sense? >>> >>> Thanks, >>> ??? Jan >>> >>> On 15. 10. 19 15:02, Maurizio Cimadamore wrote: >>>> Yep - that would be more helpful (at least to me) >>>> >>>> Thanks >>>> Maurizio >>>> >>>> On 15/10/2019 13:56, Jan Lahoda wrote: >>>>> Would this be better? >>>>> >>>>> Full patch: >>>>> http://cr.openjdk.java.net/~jlahoda/8231826/webrev.02/ >>>>> >>>>> Diff from previous: >>>>> http://cr.openjdk.java.net/~jlahoda/8231826/webrev.delta.01-02/ >>>>> >>>>> Thanks, >>>>> ??? Jan >>>>> >>>>> On 15. 10. 19 13:59, Maurizio Cimadamore wrote: >>>>>> Hi, >>>>>> the flow changes look good - I think the TransPattern >>>>>> documentation should contain less text and more code snippet >>>>>> examples which show what the generated code looks like (as I've >>>>>> tried to do in my email, and as you've done for visitTypeTest). >>>>>> In other words, what is missing here is "the big picture" which >>>>>> shows what are the main ideas behind the translation strategy. >>>>>> >>>>>> Specific example: decorateExpression: >>>>>> >>>>>> + //if there are binding variables defined and used only in this >>>>>> expression, >>>>>> + //which are not confined to a specific sub-expression, >>>>>> + //a let expression is created which replaces the statement, and >>>>>> + //the binding variables are hoisted into this let expression: >>>>>> >>>>>> >>>>>> This kind of illustrates my point: >>>>>> >>>>>> * "if there are binding variables defined and used only in this >>>>>> expression, which are not confined to a specific sub-expression" >>>>>> is very convoluted, and will be almost meaningless when we pick >>>>>> up this code again in 6 months >>>>>> * "a let expression is created which replaces the statement" - >>>>>> statement? Probably cut and paste error >>>>>> >>>>>> Thanks >>>>>> Maurizio >>>>>> >>>>>> On 15/10/2019 10:46, Jan Lahoda wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I've updated the patch with the Flow changes and with additional >>>>>>> comments in TransPatterns here: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8231826/webrev.01/ >>>>>>> diff from previous: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8231826/webrev.delta.00-01/ >>>>>>> >>>>>>> An additional patch (that would apply on top of this one) which >>>>>>> makes all instanceof instances to be modelled as instanceof >>>>>>> : >>>>>>> http://cr.openjdk.java.net/~jlahoda/8231826/webrev.01.unify.instanceof/ >>>>>>> >>>>>>> >>>>>>> Some more comment inline. >>>>>>> >>>>>>> On 10. 10. 19 17:33, Maurizio Cimadamore wrote: >>>>>>>> Hi Jan, >>>>>>>> the code looks generally very clean, kudos. >>>>>>>> >>>>>>>> Some general comments: >>>>>>>> >>>>>>>> * looking at the spec, it seems like both "instanceof T" and >>>>>>>> "instanceof T t" are cases of type test patterns. I guess I'm >>>>>>>> fine with the implementation doing what it always did in terms >>>>>>>> of plain "instanceof T", but I'm worried about the intersection >>>>>>>> between this and e.g. the tree API - InstanceofTree::getPattern >>>>>>>> returns null in cases like "instanceof T"; now, I know I know >>>>>>>> that we're speaking about a JDK specific API, but I think this >>>>>>>> issue reveals some modelling issues in the way we treat >>>>>>>> instanceof, and I'm worried that some of these issues might pop >>>>>>>> up in the future. I'd prefer to either rectify the spec so that >>>>>>>> plain 'instanceof T' is not a pattern matching instanceof, or >>>>>>>> rectify javac so that these tests are internally also >>>>>>>> represented with patterns (at the expense of some extra >>>>>>>> allocation, perhaps). >>>>>>>> >>>>>>>> * If I'm not mistaken the only use for the >>>>>>>> "MATCH_BINDING_TO_OUTER" flag is to be able to distinguish >>>>>>>> between regular 'expression-wide' bindings, and bindings which >>>>>>>> 'leaked' outside a statement (e.g. an if statement). And the >>>>>>>> reason you need to distinguish between these is that you don't >>>>>>>> want Check::checkUnique to flag duplicate errors between >>>>>>>> regular 'expression-wide' bindings, which are reported >>>>>>>> elsewhere (MatchBindingsComputer). But this is also, more >>>>>>>> crucially, used in TransPattern, where the 'isPreserved' flag >>>>>>>> is used to control whether a variable decl for the binding >>>>>>>> variable should be 'lifted' to the enclosing statement context >>>>>>>> or not. Is my understanding correct here? >>>>>>> >>>>>>> Yes, the primary intent is to mark variables that need to be >>>>>>> hoisted to the parent of the current statement. >>>>>>> >>>>>>>> >>>>>>>> * The idea behind TransPatterns seems to be: when we process a >>>>>>>> statement, or an expression, we attempt to add all declaration >>>>>>>> for the bindings that are used inside the statements/expression >>>>>>>> upfront. If we are processing a statement, then we surround the >>>>>>>> results in a block; e.g. >>>>>>>> >>>>>>>> if (obj instanceof Foo f) { >>>>>>>> ?? ... >>>>>>>> } >>>>>>>> >>>>>>>> becomes >>>>>>>> >>>>>>>> { >>>>>>>> ??? Foo f$; >>>>>>>> ??? if (let Object temp = obj in (obj instanceof Foo && (f$ = >>>>>>>> (Foo)temp) == temp) { >>>>>>>> ?????? ... >>>>>>>> } >>>>>>>> >>>>>>>> If we are processing an expression, we instead generate a >>>>>>>> LetExpr, e.g. >>>>>>>> >>>>>>>> boolean b = obj instanceof Foo t && t.equals(foo); >>>>>>>> >>>>>>>> becomes: >>>>>>>> >>>>>>>> boolean b = let Foo f$ = null in ((let Object temp = obj in >>>>>>>> (obj instanceof Foo && (f$ = (Foo)temp) == temp) && >>>>>>>> f$.equals(foo)) >>>>>>>> >>>>>>>> So, sometimes the hoisted var is a real var decl in a block, >>>>>>>> other times is a var decl inside a let expression. In these >>>>>>>> cases we have to generate an initializer, to set the value >>>>>>>> (which might be used later). >>>>>>> >>>>>>> The hoisted vars do not have an initializer (they used to have >>>>>>> one, but it is both unnecessary and was masking out bugs, so I >>>>>>> have removed it). But I see I've forgot the initializer code >>>>>>> commented out in TransPatterns, removed in the updated version >>>>>>> to avoid confusion. >>>>>>> >>>>>>>> On top of that, instanceof generates its own letExpr to cache >>>>>>>> the target of the test (to avoid double computation). >>>>>>>> >>>>>>>> It also seems to me that the code handles cases where the >>>>>>>> binding variable is not used, neither hoisted - e.g. >>>>>>>> >>>>>>>> boolean field = obj instanceof Foo t; >>>>>>>> >>>>>>>> In this case we generate a plain instanceof w/o the init >>>>>>>> (because the 't' variable hasn't been hoisted anywhere). >>>>>>>> >>>>>>>> Finally, we use the 'isPreserved()' flag to ensure that >>>>>>>> variables are hoisted correctly - for instance, if something is >>>>>>>> to be preserved (and the enclosing context allows for it) we >>>>>>>> push things in the enclosing context instead. >>>>>>>> >>>>>>>> Am I getting the correct picture here? >>>>>>> >>>>>>> Yes, I think it is correct. >>>>>>> >>>>>>>> >>>>>>>> It would be nice to have more javadoc spread around to help the >>>>>>>> reader understand what's the rationale and show some snippet of >>>>>>>> generated code. >>>>>>>> >>>>>>>> * Flow, I wonder if, like you had created SnippetAliveAnalyzer, >>>>>>>> creating a SnippetBreakAnalyzer would help you avoid the >>>>>>>> breaksOut[0] trick (that could become a field in the child >>>>>>>> visitor) >>>>>>> >>>>>>> I tried to do these two in the updated patch. >>>>>>> >>>>>>> Thanks for the comments! >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Other than that, it looks very good. >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> On 10/10/2019 13:12, Jan Lahoda wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> As part of the effort to prepare JEP 305: Pattern Matching for >>>>>>>>> instanceof (Preview) for Propose to Target, I would like to >>>>>>>>> ask for a code review for the corresponding javac changes. >>>>>>>>> >>>>>>>>> The webrev is here: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8231826/webrev.00/ >>>>>>>>> >>>>>>>>> The patch applies on top of: >>>>>>>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-October/013727.html >>>>>>>>> >>>>>>>>> >>>>>>>>> The current spec the patch is striving to implements is here: >>>>>>>>> http://cr.openjdk.java.net/~gbierman/jep305/jep305-20190918/specs/patterns-instanceof-jls.html >>>>>>>>> >>>>>>>>> >>>>>>>>> As far as I know, there is one (significant) open issue in the >>>>>>>>> spec, and that is whether non-reifiable types should be >>>>>>>>> allowed in "instanceof ". Currently >>>>>>>>> (AFAIK), the spec does not allow non-reifiable types in the >>>>>>>>> type test pattern in instanceof, and the javac implementation >>>>>>>>> should be consistent with the spec. Should the spec change, >>>>>>>>> the corresponding update to the javac code should have a very >>>>>>>>> limited impact. >>>>>>>>> >>>>>>>>> I'll be preparing a CSR for this change in the coming days. >>>>>>>>> >>>>>>>>> The JBS issue for this code change is: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8231826 >>>>>>>>> >>>>>>>>> Any feedback is welcome! >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> ??? Jan From leonid.kuskov at oracle.com Fri Nov 22 19:22:36 2019 From: leonid.kuskov at oracle.com (Leonid Kuskov) Date: Fri, 22 Nov 2019 11:22:36 -0800 Subject: Spec: ACC_MANDATED Message-ID: <46eda485-91bb-4c5d-9d52-f15307b80b3e@oracle.com> Hi all, The draft JVM spec for JEP 359(Records)* states in chapter 4.7.8 that: "The|Synthetic|attribute is a fixed-length attribute in the|attributes|table of a|ClassFile|,|field_info|, or|method_info|structure (4.1 ,4.5 ,4.6 ). A class member that does not appear in the source code must be marked using a|Synthetic|attribute, or else it must have its|ACC_SYNTHETIC|flag set. The only exceptions to this requirement are compiler-generated methods which are not considered implementation artifacts, namely the instance initialization method representing a default constructor of the Java programming language (2.9.1 ), the class or interface initialization method (2.9.2 ), andthe|Enum.values()|and|Enum.valueOf()|methods*mandated members of enums and records*." So specification allows RI? to mark final fields associated with components and some methods by ACC_MANDATED flag (0x8000). The latest JVMS specification (https://docs.oracle.com/javase/specs/jvms/se13/html/index.html) permits this flag only for 2 attributes: MethodParameters_attribute, Module_attribute . The flag is not mentioned in both tables: Table 4.5-A. "Field access and property flags", Table 4.6-A. "Method access and property flags". From my point of view, usage of this flag with methods/fields contradicts the assertions: >> All bits of the access_flags item not assigned in Table 4.5-A are reserved for future use. *They should be* *set to zero* in generated class files and should be ignored by Java Virtual Machine implementations. >> All bits of the access_flags item not assigned in Table 4.6-A are reserved for future use. They should be set to zero in generated class files and should be ignored by Java Virtual Machine implementations. Does it make sense to add a definition of ACC_MANDATED to the tables? And: Earlier the spec stated that the Enum.values() and Enum.valueOf() are exceptions to the requirement that a class member that does not appear in the source code must be marked using a Synthetic attribute, or have its ACC_SYNTHETIC flag set. Now names of methods are removed and the more loose statement "mandated members of enums and records" is used. Does it mean that spec won't enumerate "mandated" methods anymore? And the setting of this flag will be implementation-specific? From my point of view, it might break the unambiguity of the signature tests. Should the JCK signature test take into account the ACC_MANDATED flag? Thanks, Leonid *) http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191031/specs/records-jvms.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Fri Nov 22 20:02:23 2019 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 22 Nov 2019 13:02:23 -0700 Subject: Spec: ACC_MANDATED In-Reply-To: <46eda485-91bb-4c5d-9d52-f15307b80b3e@oracle.com> References: <46eda485-91bb-4c5d-9d52-f15307b80b3e@oracle.com> Message-ID: <3507F393-49FC-4FF0-ADAA-343E5277682E@oracle.com> > On Nov 22, 2019, at 12:22 PM, Leonid Kuskov wrote: > > So specification allows RI to mark final fields associated with components and some methods by ACC_MANDATED flag (0x8000). The latest JVMS specification (https://docs.oracle.com/javase/specs/jvms/se13/html/index.html) permits this flag only for 2 attributes: MethodParameters_attribute, Module_attribute . The flag is not mentioned in both tables: Table 4.5-A. "Field access and property flags", Table 4.6-A. "Method access and property flags". > Does it make sense to add a definition of ACC_MANDATED to the tables? To clarify: are you saying javac is using the 0x8000 flags on fields and methods, despite this flag being undefined in these contexts? Or are you saying that you think we should *start* using the flag on fields and methods, with supporting changes to the spec? (The first would be a bug, the second would be a minor new feature.) > Now names of methods are removed and the more loose statement "mandated members of enums and records" is used. Does it mean that spec won't enumerate "mandated" methods anymore? And the setting of this flag will be implementation-specific? From my point of view, it might break the unambiguity of the signature tests. I don't like putting highly specific compilation details in the JVMS description of an attribute. I don't think it's the appropriate place for those kinds of rules. I *do* think we have a reasonable definition of "mandated" based on the specification of the flag, combined with what the JLS has to say about implicit declarations (see, for example, JLS 8.9.3). (JLS doesn't use that particular term, so depending on the answer to your first question, maybe it makes sense to rephrase this rule to talk about "implicit" members rather than "mandated" members.) From leonid.kuskov at oracle.com Fri Nov 22 21:57:20 2019 From: leonid.kuskov at oracle.com (Leonid Kuskov) Date: Fri, 22 Nov 2019 13:57:20 -0800 Subject: Spec: ACC_MANDATED In-Reply-To: <3507F393-49FC-4FF0-ADAA-343E5277682E@oracle.com> References: <46eda485-91bb-4c5d-9d52-f15307b80b3e@oracle.com> <3507F393-49FC-4FF0-ADAA-343E5277682E@oracle.com> Message-ID: On 11/22/19 12:02, Dan Smith wrote: >> On Nov 22, 2019, at 12:22 PM, Leonid Kuskov wrote: >> >> So specification allows RI to mark final fields associated with components and some methods by ACC_MANDATED flag (0x8000). The latest JVMS specification (https://docs.oracle.com/javase/specs/jvms/se13/html/index.html) permits this flag only for 2 attributes: MethodParameters_attribute, Module_attribute . The flag is not mentioned in both tables: Table 4.5-A. "Field access and property flags", Table 4.6-A. "Method access and property flags". >> Does it make sense to add a definition of ACC_MANDATED to the tables? > To clarify: are you saying javac is using the 0x8000 flags on fields and methods, despite this flag being undefined in these contexts? Or are you saying that you think we should *start* using the flag on fields and methods, with supporting changes to the spec? I'm saying javac is using the ACC_MANDATED flag on fields and methods and VM doesn't throw an exception although the spec does not permit this. Please see the example below. > > (The first would be a bug, the second would be a minor new feature.) > >> Now names of methods are removed and the more loose statement "mandated members of enums and records" is used. Does it mean that spec won't enumerate "mandated" methods anymore? And the setting of this flag will be implementation-specific? From my point of view, it might break the unambiguity of the signature tests. > I don't like putting highly specific compilation details in the JVMS description of an attribute. I don't think it's the appropriate place for those kinds of rules. I don't like this too. It is a good idea to define "mandated" members in JVMS through implicitly declared members stated in the JLS. But JVMS doesn't interact with JLS in a definition of any members at all. Could it be clarified in the VM spec? > > I *do* think we have a reasonable definition of "mandated" based on the specification of the flag, combined with what the JLS has to say about implicit declarations (see, for example, JLS 8.9.3). > > (JLS doesn't use that particular term, so depending on the answer to your first question, maybe it makes sense to rephrase this rule to talk about "implicit" members rather than "mandated" members.) I agree. BTW, JLS for Records* (chapter 13.1 Binary compatibility) states For reference, the following constructs are declared implicitly in source code, but are not marked as mandated because only formal parameters can be so marked in a|class|file (JVMS ?4.7.24): * Default constructors of classes and enum types (8.8.9 ,8.9.2 ) * *Canonical constructors of record types (8.10.4 )* * Anonymous constructors (15.9.5.1 ) * The|values|and|valueOf|methods of enum types (8.9.3 ) * Certain|public|fields of enum types (8.9.3 ) * *Certain|private|fields and|public|methods of record types (8.10.3 )* * Certain|public|methods of interfaces (9.2 ) * Container annotations (9.7.5 ) It is an extra place where implicit members don't match "mandated" members from the JVMS point of view. It would be good to be able to identify a list of implicit/mandated methods for each class/interface. For example, the record: public record Complex(double re, double im) { ? @Override ? public String toString() { ... } } is compiled to : super public final class Complex extends java/lang/Record version 58:65535 { private final mandated Field re:D; private final mandated Field im:D; public Method "":"(DD)V" ??? stack 3 locals 5 ??? 0: #{re mandated} ??? 1: #{im mandated} {} public Method toString:"()Ljava/lang/String;"{} public final mandated Method hashCode:"()I" {} public final mandated Method equals:"(Ljava/lang/Object;)Z" {} public mandated Method re:"()D" public mandated Method im:"()D" Record ?re:D, ?im:D; } Thanks, Leonid *) http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191031/specs/records-jls.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Nov 22 23:24:05 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 22 Nov 2019 15:24:05 -0800 Subject: RFR: JDK-8234687: change javap reporting on unknown attributes Message-ID: <380f3880-b70d-28f4-a7bd-9ba6787fd488@oracle.com> Please review a small change to javap, to avoid reporting an unknown or custom attribute as an "error". The following is an example of the javap output, before and after the change: Before: Error: unknown attribute ? CustomAttr: length = 0x2 ?? 00 0E After: ? CustomAttr: length = 0x2 (unknown attribute) ?? 00 0E The test is a modified copy of an existing test, despite appearing in the webrev to be a modified renamed test.? It shares enough in common with the other test to be worth sharing its genesis. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8234687 Webrev: http://cr.openjdk.java.net/~jjg/8234687/webrev.00/ From mandy.chung at oracle.com Fri Nov 22 23:39:38 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 22 Nov 2019 15:39:38 -0800 Subject: RFR: JDK-8234687: change javap reporting on unknown attributes In-Reply-To: <380f3880-b70d-28f4-a7bd-9ba6787fd488@oracle.com> References: <380f3880-b70d-28f4-a7bd-9ba6787fd488@oracle.com> Message-ID: On 11/22/19 3:24 PM, Jonathan Gibbons wrote: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8234687 > Webrev: http://cr.openjdk.java.net/~jjg/8234687/webrev.00/ > Looks okay to me.? About the test: 26 * @bug 8234687 Is it intentional to remove 8047072? Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Sat Nov 23 00:01:36 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 22 Nov 2019 16:01:36 -0800 Subject: RFR: JDK-8234687: change javap reporting on unknown attributes In-Reply-To: References: <380f3880-b70d-28f4-a7bd-9ba6787fd488@oracle.com> Message-ID: <2a686e52-0558-a629-4fa2-e329636c99ea@oracle.com> On 11/22/19 3:39 PM, Mandy Chung wrote: > > > On 11/22/19 3:24 PM, Jonathan Gibbons wrote: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8234687 >> Webrev: http://cr.openjdk.java.net/~jjg/8234687/webrev.00/ >> > Looks okay to me.? About the test: > > 26 * @bug 8234687 Is it intentional to remove 8047072? > > Mandy Yes, this is a new test for this specific fix;? it's just that it was based on an earlier test.? Since it does not test the issue in 8047072, it does not seem appropriate to list that bug number. The old test (for BadAttributeLength) still exists without modification. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Sat Nov 23 00:09:22 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 22 Nov 2019 16:09:22 -0800 Subject: RFR: JDK-8234687: change javap reporting on unknown attributes In-Reply-To: <2a686e52-0558-a629-4fa2-e329636c99ea@oracle.com> References: <380f3880-b70d-28f4-a7bd-9ba6787fd488@oracle.com> <2a686e52-0558-a629-4fa2-e329636c99ea@oracle.com> Message-ID: <7d3a9ceb-5c40-a12a-f02e-2a1c4d15e02f@oracle.com> On 11/22/19 4:01 PM, Jonathan Gibbons wrote: > > > On 11/22/19 3:39 PM, Mandy Chung wrote: >> >> >> On 11/22/19 3:24 PM, Jonathan Gibbons wrote: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234687 >>> Webrev: http://cr.openjdk.java.net/~jjg/8234687/webrev.00/ >>> >> Looks okay to me.? About the test: >> >> 26 * @bug 8234687 Is it intentional to remove 8047072? >> >> Mandy > > Yes, this is a new test for this specific fix;? it's just that it was > based on an earlier test.? Since it does not test the issue in > 8047072, it does not seem appropriate to list that bug number. > > The old test (for BadAttributeLength) still exists without modification. > Looks good to me. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Sat Nov 23 00:08:57 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 22 Nov 2019 16:08:57 -0800 Subject: RFR: JDK-8234687: change javap reporting on unknown attributes In-Reply-To: <7d3a9ceb-5c40-a12a-f02e-2a1c4d15e02f@oracle.com> References: <380f3880-b70d-28f4-a7bd-9ba6787fd488@oracle.com> <2a686e52-0558-a629-4fa2-e329636c99ea@oracle.com> <7d3a9ceb-5c40-a12a-f02e-2a1c4d15e02f@oracle.com> Message-ID: <0425c35c-05b6-5edf-961f-dca9e1ae9202@oracle.com> On 11/22/2019 04:09 PM, Mandy Chung wrote: > > > On 11/22/19 4:01 PM, Jonathan Gibbons wrote: >> >> >> On 11/22/19 3:39 PM, Mandy Chung wrote: >>> >>> >>> On 11/22/19 3:24 PM, Jonathan Gibbons wrote: >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234687 >>>> Webrev: http://cr.openjdk.java.net/~jjg/8234687/webrev.00/ >>>> >>> Looks okay to me.? About the test: >>> >>> 26 * @bug 8234687 Is it intentional to remove 8047072? >>> >>> Mandy >> >> Yes, this is a new test for this specific fix;? it's just that it was >> based on an earlier test.? Since it does not test the issue in >> 8047072, it does not seem appropriate to list that bug number. >> >> The old test (for BadAttributeLength) still exists without modification. >> > > Looks good to me. > > Mandy Thanks -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.kelemen85 at gmail.com Sat Nov 23 18:42:02 2019 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Sat, 23 Nov 2019 19:42:02 +0100 Subject: JEP 305 - Pattern Matching for instanceof (Preview) Message-ID: Hi, I have a couple of questions on the syntax of the upcoming "instanceof" enhancement: 1. Can I write `obj instanceof String obj` and shadow the original `obj` variable with the new one? It would be nice if I could, because one of my main concern with the lack of "auto-cast", is that I have to give another name to the same thing, which usually leads to lame things like `o` and `other`. 2. Is the newly declared variable final? I personally would prefer if it would be final, because then that is one less thing to worry about. 3. Is it legal to do this kind of declaration even if the effective scope of that variable is nothing? For example, `if (obj instanceof String s || myCondition)`. As both path is reachable without `obj` being an instance of `String`. 4. What is the limit for the compiler to figure out the scope of the variable? I was mildly surpised to see that `if (!(obj instanceof String s))` works on the else path. But this begs the question: What is the limit of the ability to deduce the scope. If the previously mentioned expression works, then I would naively expect that javac would evaluate it this way: if the "instanceof expression" is false and the complete condition might evaluate to true with any combination of true/false for the other parts of the boolean expression, then then the newly declared variable is not in scope for the true path (similarly for the else path). If my above guess is true, then I would expect `if (!(!(obj instanceof String s) || myCondition))` to give me the `s` for the true path. Thanks, Attila Kelemen From brian.goetz at oracle.com Sat Nov 23 19:43:19 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 23 Nov 2019 14:43:19 -0500 Subject: JEP 305 - Pattern Matching for instanceof (Preview) In-Reply-To: References: Message-ID: <54a84da8-74e3-292f-2c58-93328a18dc63@oracle.com> > 1. Can I write `obj instanceof String obj` and shadow the original > `obj` variable with the new one? > > It would be nice if I could, because one of my main concern > with the lack of "auto-cast", is that I have to give another name > to the same thing, which usually leads to lame things like > `o` and `other`. No.? It has been discussed, but so far, we are sticking with the original rules about shadowing.? We might consider relaxing it in the future, but have ruled out doing so for now. While I understand the attraction of flow typing, flow typing is in fact a weaker mechanism than pattern matching (though that's not obvious because we're starting with the weakest form of patterns, type patterns).? Bundling a tiny amount of flow typing with pattern matching is not likely to make the flow-typers happy, and will also serve to confuse people about what pattern matching is.? But when we get farther down the road with pattern matching, we may review this decision. > 2. Is the newly declared variable final? > > I personally would prefer if it would be final, because then > that is one less thing to worry about. Pattern variables are final, yes. > 3. Is it legal to do this kind of declaration even if the effective > scope of that variable is nothing? > > For example, `if (obj instanceof String s || myCondition)`. > As both path is reachable without `obj` being an instance of `String`. Yes, just as it is legal to write: ??? void m() { ??????? String s = ""; ??? } We don't go out of our way to forbid declare-and-then-don't-use. Note that there are still places where you might want to use `s` in the above: ??? if ((obj instanceof String s && s.length() > 3) || myCondition) { ... } even if you don't use it in the body of the if. > 4. What is the limit for the compiler to figure out the scope of the variable? > > I was mildly surpised to see that `if (!(obj instanceof String s))` > works on the else path. The intuitive rule is "the binding is in scope wherever it would be definitely assigned, and not in scope otherwise."? (We call this "flow scoping.")? The formal rules are sketched out here: http://cr.openjdk.java.net/~briangoetz/amber/pattern-semantics.html (and, big surprise, they bear a significant resemblance to the "definite assignment" rules.) > But this begs the question: What is the limit of the ability to > deduce the scope. If the previously mentioned expression works, > then I would naively expect that javac would evaluate it this way: > if the "instanceof expression" is false and the complete condition > might evaluate to true with any combination of true/false for the > other parts of the boolean expression, then then the newly declared > variable is not in scope for the true path (similarly for the else path). > > If my above guess is true, then I would expect > `if (!(!(obj instanceof String s) || myCondition))` > to give me the `s` for the true path. > The rules are well defined and compositional, so it doesn't really matter how complex the expression you give the compiler; it will apply them and determine the scope of your bindings (which might not be a contiguous scope.)? So the "limit" is more likely to be in your own head than in the language. From attila.kelemen85 at gmail.com Sat Nov 23 20:59:21 2019 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Sat, 23 Nov 2019 21:59:21 +0100 Subject: JEP 305 - Pattern Matching for instanceof (Preview) In-Reply-To: <54a84da8-74e3-292f-2c58-93328a18dc63@oracle.com> References: <54a84da8-74e3-292f-2c58-93328a18dc63@oracle.com> Message-ID: Thanks, I don't know how I could miss the very first link in the JEP ... but it actually even clears up another question I forgot to ask (i.e., generic types). I guess my whole confusion came from brain failure to realize that the match of Scala (not that I know Scala that much) naturally generalize to `instanceof`. It looks a lot more sensible with the linked document (I'm especially intrigued by the "pattern merging" concept). I'm still a little sad that `x instanceof String x` is not a thing. Despite that it is kinda flow typing, it was not my hidden way to advocate for real flow typing; though my reasons against it might be different: it would probably either break backward compatibility due to overloading / shadowing, or introduce obscure rules for them. Anyway, I'm hoping to see the pattern matching in its full glory with records. Then my only wish would be to be able to create large immutable data objects in a non-awkward manner. Just kidding, I would bash Java for something else like error handling :) Attila Brian Goetz ezt ?rta (id?pont: 2019. nov. 23., Szo, 20:43): > > > > > 1. Can I write `obj instanceof String obj` and shadow the original > > `obj` variable with the new one? > > > > It would be nice if I could, because one of my main concern > > with the lack of "auto-cast", is that I have to give another name > > to the same thing, which usually leads to lame things like > > `o` and `other`. > > No. It has been discussed, but so far, we are sticking with the > original rules about shadowing. We might consider relaxing it in the > future, but have ruled out doing so for now. > > While I understand the attraction of flow typing, flow typing is in fact > a weaker mechanism than pattern matching (though that's not obvious > because we're starting with the weakest form of patterns, type > patterns). Bundling a tiny amount of flow typing with pattern matching > is not likely to make the flow-typers happy, and will also serve to > confuse people about what pattern matching is. But when we get farther > down the road with pattern matching, we may review this decision. > > > 2. Is the newly declared variable final? > > > > I personally would prefer if it would be final, because then > > that is one less thing to worry about. > > Pattern variables are final, yes. > > > 3. Is it legal to do this kind of declaration even if the effective > > scope of that variable is nothing? > > > > For example, `if (obj instanceof String s || myCondition)`. > > As both path is reachable without `obj` being an instance of `String`. > > Yes, just as it is legal to write: > > void m() { > String s = ""; > } > > We don't go out of our way to forbid declare-and-then-don't-use. Note > that there are still places where you might want to use `s` in the above: > > if ((obj instanceof String s && s.length() > 3) || myCondition) { ... } > > even if you don't use it in the body of the if. > > > 4. What is the limit for the compiler to figure out the scope of the variable? > > > > I was mildly surpised to see that `if (!(obj instanceof String s))` > > works on the else path. > > The intuitive rule is "the binding is in scope wherever it would be > definitely assigned, and not in scope otherwise." (We call this "flow > scoping.") The formal rules are sketched out here: > > http://cr.openjdk.java.net/~briangoetz/amber/pattern-semantics.html > > (and, big surprise, they bear a significant resemblance to the "definite > assignment" rules.) > > > But this begs the question: What is the limit of the ability to > > deduce the scope. If the previously mentioned expression works, > > then I would naively expect that javac would evaluate it this way: > > if the "instanceof expression" is false and the complete condition > > might evaluate to true with any combination of true/false for the > > other parts of the boolean expression, then then the newly declared > > variable is not in scope for the true path (similarly for the else path). > > > > If my above guess is true, then I would expect > > `if (!(!(obj instanceof String s) || myCondition))` > > to give me the `s` for the true path. > > > > The rules are well defined and compositional, so it doesn't really > matter how complex the expression you give the compiler; it will apply > them and determine the scope of your bindings (which might not be a > contiguous scope.) So the "limit" is more likely to be in your own head > than in the language. > > > > From attila.kelemen85 at gmail.com Sat Nov 23 23:44:14 2019 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Sun, 24 Nov 2019 00:44:14 +0100 Subject: JEP 305 - Pattern Matching for instanceof (Preview) In-Reply-To: References: <54a84da8-74e3-292f-2c58-93328a18dc63@oracle.com> Message-ID: One little comment on the "flow scoping" rules: As I can see `x = y` empties the binding sets (for both T and F). Is there a reason not to apply the same for them as if they were written as `(x && y) || (!x && !y)`. That is, the following: T: intersect(union(x.T, y.T), union(x.F, y.F)) F: union(intersect(x.F, y.F), intersect(x.T, y.T)) Obviously, this would apply for boolean x and y only, and the reverse for `x != y` Attila Kelemen ezt ?rta (id?pont: 2019. nov. 23., Szo, 21:59): > > Thanks, I don't know how I could miss the very first link in the JEP ... > but it actually even clears up another question I forgot to ask (i.e., > generic types). > > I guess my whole confusion came from brain failure to realize that the > match of Scala > (not that I know Scala that much) naturally generalize to > `instanceof`. It looks a lot more > sensible with the linked document (I'm especially intrigued by the > "pattern merging" concept). > I'm still a little sad that `x instanceof String x` is not a thing. > Despite that it is kinda flow typing, > it was not my hidden way to advocate for real flow typing; though my > reasons against it > might be different: it would probably either break backward compatibility due to > overloading / shadowing, or introduce obscure rules for them. > > Anyway, I'm hoping to see the pattern matching in its full glory with records. > Then my only wish would be to be able to create large immutable data objects in > a non-awkward manner. Just kidding, I would bash Java for something > else like error handling :) > > Attila > > > Brian Goetz ezt ?rta (id?pont: 2019. nov. > 23., Szo, 20:43): > > > > > > > > > 1. Can I write `obj instanceof String obj` and shadow the original > > > `obj` variable with the new one? > > > > > > It would be nice if I could, because one of my main concern > > > with the lack of "auto-cast", is that I have to give another name > > > to the same thing, which usually leads to lame things like > > > `o` and `other`. > > > > No. It has been discussed, but so far, we are sticking with the > > original rules about shadowing. We might consider relaxing it in the > > future, but have ruled out doing so for now. > > > > While I understand the attraction of flow typing, flow typing is in fact > > a weaker mechanism than pattern matching (though that's not obvious > > because we're starting with the weakest form of patterns, type > > patterns). Bundling a tiny amount of flow typing with pattern matching > > is not likely to make the flow-typers happy, and will also serve to > > confuse people about what pattern matching is. But when we get farther > > down the road with pattern matching, we may review this decision. > > > > > 2. Is the newly declared variable final? > > > > > > I personally would prefer if it would be final, because then > > > that is one less thing to worry about. > > > > Pattern variables are final, yes. > > > > > 3. Is it legal to do this kind of declaration even if the effective > > > scope of that variable is nothing? > > > > > > For example, `if (obj instanceof String s || myCondition)`. > > > As both path is reachable without `obj` being an instance of `String`. > > > > Yes, just as it is legal to write: > > > > void m() { > > String s = ""; > > } > > > > We don't go out of our way to forbid declare-and-then-don't-use. Note > > that there are still places where you might want to use `s` in the above: > > > > if ((obj instanceof String s && s.length() > 3) || myCondition) { ... } > > > > even if you don't use it in the body of the if. > > > > > 4. What is the limit for the compiler to figure out the scope of the variable? > > > > > > I was mildly surpised to see that `if (!(obj instanceof String s))` > > > works on the else path. > > > > The intuitive rule is "the binding is in scope wherever it would be > > definitely assigned, and not in scope otherwise." (We call this "flow > > scoping.") The formal rules are sketched out here: > > > > http://cr.openjdk.java.net/~briangoetz/amber/pattern-semantics.html > > > > (and, big surprise, they bear a significant resemblance to the "definite > > assignment" rules.) > > > > > But this begs the question: What is the limit of the ability to > > > deduce the scope. If the previously mentioned expression works, > > > then I would naively expect that javac would evaluate it this way: > > > if the "instanceof expression" is false and the complete condition > > > might evaluate to true with any combination of true/false for the > > > other parts of the boolean expression, then then the newly declared > > > variable is not in scope for the true path (similarly for the else path). > > > > > > If my above guess is true, then I would expect > > > `if (!(!(obj instanceof String s) || myCondition))` > > > to give me the `s` for the true path. > > > > > > > The rules are well defined and compositional, so it doesn't really > > matter how complex the expression you give the compiler; it will apply > > them and determine the scope of your bindings (which might not be a > > contiguous scope.) So the "limit" is more likely to be in your own head > > than in the language. > > > > > > > > From brian.goetz at oracle.com Sun Nov 24 18:01:47 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 24 Nov 2019 13:01:47 -0500 Subject: JEP 305 - Pattern Matching for instanceof (Preview) In-Reply-To: References: <54a84da8-74e3-292f-2c58-93328a18dc63@oracle.com> Message-ID: > Anyway, I'm hoping to see the pattern matching in its full glory with records. Me too, but this isn't even the full glory!? There's a far richer story even than that waiting in the wings.? This is just the next "obvious" installment.? Stay tuned! From srikanth.adayapalam at oracle.com Mon Nov 25 11:09:19 2019 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Mon, 25 Nov 2019 16:39:19 +0530 Subject: RFR: JDK-8234729: Javac should eagerly change code generation for method references to avert IllegalAccessError in future. Message-ID: <279f405f-03f4-910c-4b7a-9a0ae8e92683@oracle.com> JBS ticket: https://bugs.openjdk.java.net/browse/JDK-8234729 Webrev link: http://cr.openjdk.java.net/~sadayapalam/JDK-8234729/webrev.00/jdk.patch [1] Hidden Classes JEP: http://openjdk.java.net/jeps/8220607 [2] Corresponding JBS ticket: https://bugs.openjdk.java.net/browse/JDK-8220607 [3] Nestmates branch specific fix: https://bugs.openjdk.java.net/browse/JDK-8227415 Scenario: Javac's code generation for method references that target a protected method declared in a superclass in a different package. Problem: When Hidden Classes JEP [1] eventually makes its way into mainline via [2], due to stricter enforcement of access control, code compiled using earlier compilers that uses method references that target a protected method of a super class in a different package may trigger an IllegalAccessError. This was discovered in the nestmates work in Valhalla and was fixed locally there via [3]. The present task JDK-8234729 is to bring forward the fix in JDK-8227415 [3] to jdk/jdk ahead of time, so as to minimize compatibility risks. If [2] and [3] were released together, then any code compiled using older compilers that involves the scenario may trigger an IAE and will have to recompiled. More detailed description in https://bugs.openjdk.java.net/browse/JDK-8234729 The proposed fix passes all langtools tests and JCK tests. Thanks Srikanth. From srikanth.adayapalam at oracle.com Mon Nov 25 12:00:18 2019 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Mon, 25 Nov 2019 17:30:18 +0530 Subject: RFR: JDK-8234729: Javac should eagerly change code generation for method references to avert IllegalAccessError in future. In-Reply-To: <279f405f-03f4-910c-4b7a-9a0ae8e92683@oracle.com> References: <279f405f-03f4-910c-4b7a-9a0ae8e92683@oracle.com> Message-ID: Just as a curiosity/academic exercise, I instrumented javac to gather statistics on how many method references are encountered in a clean build of OpenJDK mainline tip and how many of those would trigger the problem scenario: Total method references encountered: 1715 Ones that would trigger the problem scenario: 0 FWIW/FYI Thanks Srikanth On 25/11/19 4:39 PM, Srikanth wrote: > > JBS ticket: https://bugs.openjdk.java.net/browse/JDK-8234729 > Webrev link: > http://cr.openjdk.java.net/~sadayapalam/JDK-8234729/webrev.00/jdk.patch > > [1] Hidden Classes JEP: http://openjdk.java.net/jeps/8220607 > [2] Corresponding JBS ticket: > https://bugs.openjdk.java.net/browse/JDK-8220607 > [3] Nestmates branch specific fix: > https://bugs.openjdk.java.net/browse/JDK-8227415 > > Scenario: Javac's code generation for method references that target a > protected method declared in a superclass in a different package. > > Problem: > > When Hidden Classes JEP [1] eventually makes its way into mainline via > [2], due to stricter enforcement of access control, code compiled > using earlier compilers that uses method references that target a > protected method of a super class in a different package may trigger > an IllegalAccessError. > > This was discovered in the nestmates work in Valhalla and was fixed > locally there via [3]. > > The present task JDK-8234729 is to bring forward the fix in > JDK-8227415 [3] to jdk/jdk ahead of time, so as to minimize > compatibility risks. If [2] and [3] were released together, then any > code compiled using older compilers that involves the scenario may > trigger an IAE and will have to recompiled. > > More detailed description in > https://bugs.openjdk.java.net/browse/JDK-8234729 > > The proposed fix passes all langtools tests and JCK tests. > > Thanks > Srikanth. From maurizio.cimadamore at oracle.com Mon Nov 25 12:53:02 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 25 Nov 2019 12:53:02 +0000 Subject: RFR: JDK-8234729: Javac should eagerly change code generation for method references to avert IllegalAccessError in future. In-Reply-To: References: <279f405f-03f4-910c-4b7a-9a0ae8e92683@oracle.com> Message-ID: Hi Srikanth, the patch looks good, and I see no reasons as to why we shouldn't move forward with it. The real issue will be, of course, upgrading the runtime support to use hidden classes (instead of Unsafe.dAC) - at which point we might start see issues for code that has not been recompiled with your patch; but given that (a) the condition seems rare (as your number show) and (b) the workaround is easy (recompile!), we should probably not worry too much about this. Cheers Maurizio On 25/11/2019 12:00, Srikanth wrote: > > Just as a curiosity/academic exercise, I instrumented javac to gather > statistics on how many method references are encountered in a clean > build of OpenJDK mainline tip and how many of those would trigger the > problem scenario: > > Total method references encountered: 1715 > Ones that would trigger the problem scenario: 0 > > FWIW/FYI > Thanks > Srikanth > > On 25/11/19 4:39 PM, Srikanth wrote: >> >> JBS ticket: https://bugs.openjdk.java.net/browse/JDK-8234729 >> Webrev link: >> http://cr.openjdk.java.net/~sadayapalam/JDK-8234729/webrev.00/jdk.patch >> >> [1] Hidden Classes JEP: http://openjdk.java.net/jeps/8220607 >> [2] Corresponding JBS ticket: >> https://bugs.openjdk.java.net/browse/JDK-8220607 >> [3] Nestmates branch specific fix: >> https://bugs.openjdk.java.net/browse/JDK-8227415 >> >> Scenario: Javac's code generation for method references that target a >> protected method declared in a superclass in a different package. >> >> Problem: >> >> When Hidden Classes JEP [1] eventually makes its way into mainline >> via [2], due to stricter enforcement of access control, code compiled >> using earlier compilers that uses method references that target a >> protected method of a super class in a different package may trigger >> an IllegalAccessError. >> >> This was discovered in the nestmates work in Valhalla and was fixed >> locally there via [3]. >> >> The present task JDK-8234729 is to bring forward the fix in >> JDK-8227415 [3] to jdk/jdk ahead of time, so as to minimize >> compatibility risks. If [2] and [3] were released together, then any >> code compiled using older compilers that involves the scenario may >> trigger an IAE and will have to recompiled. >> >> More detailed description in >> https://bugs.openjdk.java.net/browse/JDK-8234729 >> >> The proposed fix passes all langtools tests and JCK tests. >> >> Thanks >> Srikanth. > From srikanth.adayapalam at oracle.com Tue Nov 26 06:09:20 2019 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Tue, 26 Nov 2019 11:39:20 +0530 Subject: RFR: JDK-8234729: Javac should eagerly change code generation for method references to avert IllegalAccessError in future. In-Reply-To: References: <279f405f-03f4-910c-4b7a-9a0ae8e92683@oracle.com> Message-ID: <843ec1dc-0dd4-b5d5-52df-9375401ecd58@oracle.com> On 25/11/19 6:23 PM, Maurizio Cimadamore wrote: > Hi Srikanth, > the patch looks good, and I see no reasons as to why we shouldn't move > forward with it. The real issue will be, of course, upgrading the > runtime support to use hidden classes (instead of Unsafe.dAC) - at > which point we might start see issues for code that has not been > recompiled with your patch; but given that (a) the condition seems > rare (as your number show) and (b) the workaround is easy > (recompile!), we should probably not worry too much about this. Thanks Maurizio! Fix and tests pushed here: http://hg.openjdk.java.net/jdk/jdk/rev/d9a3bddcffcc Srikanth From gavin.bierman at oracle.com Wed Nov 27 13:26:03 2019 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Wed, 27 Nov 2019 13:26:03 +0000 Subject: JEP 305 - Pattern Matching for instanceof (Preview) Message-ID: <30E04BEF-AC44-4095-8C8A-01AF4CF12AF0@oracle.com> Hi Attila: > One little comment on the "flow scoping" rules: > As I can see `x = y` empties the binding sets (for both T and F). > Is there a reason not to apply the same for them as if they were > written as `(x && y) || (!x && !y)`. That is, the following: > > T: intersect(union(x.T, y.T), union(x.F, y.F)) > F: union(intersect(x.F, y.F), intersect(x.T, y.T)) > > Obviously, this would apply for boolean x and y only, > and the reverse for `x != y` I appreciate the suggestion, thank you. Unfortunately, there are a couple of problems. First, it is important to note that flow scoping applies only to pattern variables. So your suggestion as written doesn?t really apply. Even if it could, your observation also kills it - it would only ?..apply for boolean x and y?. Scoping of variables happens way before typing - indeed, you can?t define typing without knowing scoping. We can construct a similar example to consider though; for example: (e instanceof T x) == (f instanceof S y) You define the True set as: T: intersect(union(x.T, y.T), union(x.F, y.F)) So, in this case it?s: intersect(union({x}, {y}), union({},{})) = intersect({x,y}, {}) = {} Similarly for the False set. In fact, I think this will always be the case. I would be very interested to hear any feedback you may have of using pattern matching in anger in the next few months. We really want to hear what works and, please!, what is awkward - that?s the purpose of ?preview? features. Best wishes, Gavin From attila.kelemen85 at gmail.com Wed Nov 27 18:47:00 2019 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Wed, 27 Nov 2019 19:47:00 +0100 Subject: JEP 305 - Pattern Matching for instanceof (Preview) In-Reply-To: <30E04BEF-AC44-4095-8C8A-01AF4CF12AF0@oracle.com> References: <30E04BEF-AC44-4095-8C8A-01AF4CF12AF0@oracle.com> Message-ID: Hi Gavin, Originally I was thinking xor, though I forgot my original thought and just wrote `!=` and `==`, and merely for the sake of completeness of the binary operators. To be honest - without the record pattern matching, and switch - I can realistically imagine using `if (a instance C x)` constructs only, and nothing more complicated (mostly as a deliberate decision to avoid too complex expressions). So, I don't feel too bad not having rule for xor and such. That said, you can create non-empty T/F sets, by writing this: (!(a instanceof String x) == (b instanceof String x)) or the same with xor !(!(a instanceof String x) ^ (b instanceof String x)) This when evaluates to true imply that exactly one of them can be cast to `String` (and is consistent with my rules). While the false path creates an empty binding set. But as I wrote, this is all for the sake of completeness, I don't have any realistic use-case where I would want to use it. Attila > > Hi Attila: > > > One little comment on the "flow scoping" rules: > > As I can see `x = y` empties the binding sets (for both T and F). > > Is there a reason not to apply the same for them as if they were > > written as `(x && y) || (!x && !y)`. That is, the following: > > > > T: intersect(union(x.T, y.T), union(x.F, y.F)) > > F: union(intersect(x.F, y.F), intersect(x.T, y.T)) > > > > Obviously, this would apply for boolean x and y only, > > and the reverse for `x != y` > > I appreciate the suggestion, thank you. > > Unfortunately, there are a couple of problems. First, it is important to note that flow scoping applies only to pattern variables. So your suggestion as written doesn?t really apply. Even if it could, your observation also kills it - it would only ?..apply for boolean x and y?. Scoping of variables happens way before typing - indeed, you can?t define typing without knowing scoping. > > We can construct a similar example to consider though; for example: > > (e instanceof T x) == (f instanceof S y) > > You define the True set as: > > T: intersect(union(x.T, y.T), union(x.F, y.F)) > > So, in this case it?s: > > intersect(union({x}, {y}), union({},{})) > = intersect({x,y}, {}) > = {} > > Similarly for the False set. In fact, I think this will always be the case. > > I would be very interested to hear any feedback you may have of using pattern matching in anger in the next few months. We really want to hear what works and, please!, what is awkward - that?s the purpose of ?preview? features. > > Best wishes, > Gavin > > > > > > From vicente.romero at oracle.com Thu Nov 28 04:37:21 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 27 Nov 2019 23:37:21 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) Message-ID: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Hi, Please review the code for the records feature at [1]. This webrev includes all: APIs, runtime, compiler, serialization, javadoc, and more! Must of the code has been reviewed but there have been some changes since reviewers saw it. Also this is the first time an integral webrev is sent out for review. Last changes on top of my mind since last review iterations: On the compiler implementation: - it has been adapted to the last version of the language spec [2], as a reference the JVM spec is at [3]. This implied some changes in determining if a user defined constructor is the canonical or not. Now if a constructor is override-equivalent to a signature derived from the record components, then it is considered the canonical constructor. And any canonical constructor should satisfy a set of restrictions, see section 8.10.4 Record Constructor Declarations of the specification. - It was also added a check to make sure that accessors are not generic. - And that the canonical constructor, if user defined, is not explicitly invoking any other constructor. - The list of forbidden record component names has also been updated. - new error messages have been added APIs: - there have been some API editing in java.lang.Record, java.lang.runtime.ObjectMethods and java.lang.reflect.RecordComponent, java.io.ObjectInputStream, javax.lang.model (some visitors were added) On the JVM implementation: - some logging capabilities have been added to classFileParser.cpp to provide the reason for which the Record attribute has been ignored Reflection: - there are several new changes to the implementation of java.lang.reflect.RecordComponent apart from the spec changes mentioned before. bug fixes in - compiler - serialization, - JVM, etc As a reference the last iteration of the previous reviews can be found at [4] under folders: compiler, hotspot_runtime, javadoc, reflection and serialization, TIA, Vicente [1] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ [2] http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html [3] http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html [4] http://cr.openjdk.java.net/~vromero/records.review/ From jan.lahoda at oracle.com Thu Nov 28 15:11:18 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 28 Nov 2019 16:11:18 +0100 Subject: RFR: JDK-8234922: No compilation error reported not reported for a binding variable when loop broken with label Message-ID: Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8234922 The problem described there is basically: --- public class PatternTest { public static void test(Object o) { A: do { break A; } while (!(o instanceof String v)); System.out.println("Got: " + v); } } --- This should not compile, as "v" should not be in scope for the System.out.println, but javac fails to detect the break, as the break breaks to a labeled statement, not to the loop. The proposed patch solves not only this, but also break to any statement that is not inside the given loop. Webrev: http://cr.openjdk.java.net/~jlahoda/8234922/webrev.00/ How does this look? Thanks, Jan From vicente.romero at oracle.com Thu Nov 28 16:05:52 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 28 Nov 2019 11:05:52 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> Hi again, Sorry but I realized that I forgot to remove some code on the compiler side. The code removed is small, before we were issuing an error if some serialization methods were declared as record members. That section was removed from the spec. I have prepared another iteration with this change at [1] Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ On 11/27/19 11:37 PM, Vicente Romero wrote: > Hi, > > Please review the code for the records feature at [1]. This webrev > includes all: APIs, runtime, compiler, serialization, javadoc, and > more! Must of the code has been reviewed but there have been some > changes since reviewers saw it. Also this is the first time an > integral webrev is sent out for review. Last changes on top of my mind > since last review iterations: > > On the compiler implementation: > - it has been adapted to the last version of the language spec [2], as > a reference the JVM spec is at [3]. This implied some changes in > determining if a user defined constructor is the canonical or not. Now > if a constructor is override-equivalent to a signature derived from > the record components, then it is considered the canonical > constructor. And any canonical constructor should satisfy a set of > restrictions, see section 8.10.4 Record Constructor Declarations of > the specification. > - It was also added a check to make sure that accessors are not generic. > - And that the canonical constructor, if user defined, is not > explicitly invoking any other constructor. > - The list of forbidden record component names has also been updated. > - new error messages have been added > > APIs: > - there have been some API editing in java.lang.Record, > java.lang.runtime.ObjectMethods and java.lang.reflect.RecordComponent, > java.io.ObjectInputStream, javax.lang.model (some visitors were added) > > On the JVM implementation: > - some logging capabilities have been added to classFileParser.cpp to > provide the reason for which the Record attribute has been ignored > > Reflection: > - there are several new changes to the implementation of > java.lang.reflect.RecordComponent apart from the spec changes > mentioned before. > > bug fixes in > - compiler > - serialization, > - JVM, etc > > As a reference the last iteration of the previous reviews can be found > at [4] under folders: compiler, hotspot_runtime, javadoc, reflection > and serialization, > > TIA, > Vicente > > [1] > http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ > [2] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html > [3] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html > [4] http://cr.openjdk.java.net/~vromero/records.review/ > From jan.lahoda at oracle.com Thu Nov 28 16:43:58 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 28 Nov 2019 17:43:58 +0100 Subject: RFR: JDK-8233524: Wrong module name for "package P is declared in the unnamed module, but module M does not read it" Message-ID: Hi, There is a small mistake (with bad consequences) in compiler.properties: --- # {0} - package in which the invisible class is declared # {1} - current module # 0: symbol, 1: symbol compiler.misc.not.def.access.does.not.read.unnamed=\ package {0} is declared in the unnamed module, but module {0} does not read it --- Note the use of {0} after module - but based on the comment above (and the code that uses this error message), the module is in {1}. The proposal is to simply fix this as: --- # {0} - package in which the invisible class is declared # {1} - current module # 0: symbol, 1: symbol compiler.misc.not.def.access.does.not.read.unnamed=\ package {0} is declared in the unnamed module, but module {1} does not read it --- Webrev: http://cr.openjdk.java.net/~jlahoda/8233524/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8233524 How does this look? Thanks, Jan From maurizio.cimadamore at oracle.com Thu Nov 28 18:35:26 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Nov 2019 18:35:26 +0000 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> Message-ID: Hi Vicente, generally looks good - few comments below; I tried to focus on areas where the compiler code seemed to diverge from the spec, as well on pieces of code which look a leftover from previous spec rounds. * canonical constructors *can* have return statements - compact constructors cant; the spec went a bit back and forth on this, but now it has settled. Since compact constructors are turned into ordinary canonical ones by the parser, I think you need to add an extra check for COMPACT_RECORD_CONSTRUCTOR; in other words, this is ok: record Foo() { ?? Foo() { return; } //canonical } this isn't record Foo() { ?? Foo { return; } //compact } but the compiler rejects both. This probably means tweaking the diagnostic a bit to say "a compact constructor must not contain |return| statements" * in general, all diagnostics speak about 'canonical constructor' regardless of whether the constructor is canonical of compact; while I understand the reason behind what we get now, some of the error messages can be confusing, especially if you look at the spec, where canonical constructor and compact constructor are two different concepts. This should be fixed (even if not immediately, in which case I'd recommend to file a JBS issue to track that) * static accessors are allowed - this means that I can do this: record Foo(int x) { public static int x() {return 0; } public static void main(String[] args) { ?? System.err.println(new Foo(42).x()); } } This will compile and print 0. The classfile will contain the following members: final class Foo extends java.lang.Record { ? public Foo(int); ? public static int x(); ? public static void main(java.lang.String[]); ? public java.lang.String toString(); ? public final int hashCode(); ? public final boolean equals(java.lang.Object); } I believe this is an issue in the compiler, but also in the latest spec draft, if I'm not mistaken. * [optional - style] the env.info.isSerializableLambda could become an enum { NONE, LAMBDA, SERIALIZABLE_LAMBDA } instead of two boolean parameters * this code is still rejected with --enable-preview _disabled_: class X { ??? record R(int i) { ??????? return null; ??? } } class record {} This gives the error: Error: |? records are a preview feature and are disabled by default. |??? (use --enable-preview to enable records) |? record R(int i) { return null } } |? ^ |? Error: |? illegal start of type |? record R(int i) { return null } } |??????????????????? ^ In other words, the parsing logic for members is too aggressive - we shouldn't call isRecordStart() in there. If this is not fixed in this round, we should keep track with a JBS issue. * Are the changes in Tokens really needed? * Check::checkUnique doesn't seem to use the added 'env' parameter - changes should be reverted * Names.jave - the logic for having forbiddenRecordComponentNames could use some refresh - in the latest spec we basically have to ban components that have same name as j.l.Object members - so I think we can implement the check more directly (e.g. w/o having a set of names). Also, the serialization names are not needed (although I guess they will come back at some point). And, not sure what "get" and "set" are needed for? Maurizio On 28/11/2019 16:05, Vicente Romero wrote: > Hi again, > > Sorry but I realized that I forgot to remove some code on the compiler > side. The code removed is small, before we were issuing an error if > some serialization methods were declared as record members. That > section was removed from the spec. I have prepared another iteration > with this change at [1] > > Thanks, > Vicente > > [1] > http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ > > On 11/27/19 11:37 PM, Vicente Romero wrote: >> Hi, >> >> Please review the code for the records feature at [1]. This webrev >> includes all: APIs, runtime, compiler, serialization, javadoc, and >> more! Must of the code has been reviewed but there have been some >> changes since reviewers saw it. Also this is the first time an >> integral webrev is sent out for review. Last changes on top of my >> mind since last review iterations: >> >> On the compiler implementation: >> - it has been adapted to the last version of the language spec [2], >> as a reference the JVM spec is at [3]. This implied some changes in >> determining if a user defined constructor is the canonical or not. >> Now if a constructor is override-equivalent to a signature derived >> from the record components, then it is considered the canonical >> constructor. And any canonical constructor should satisfy a set of >> restrictions, see section 8.10.4 Record Constructor Declarations of >> the specification. >> - It was also added a check to make sure that accessors are not generic. >> - And that the canonical constructor, if user defined, is not >> explicitly invoking any other constructor. >> - The list of forbidden record component names has also been updated. >> - new error messages have been added >> >> APIs: >> - there have been some API editing in java.lang.Record, >> java.lang.runtime.ObjectMethods and >> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >> javax.lang.model (some visitors were added) >> >> On the JVM implementation: >> - some logging capabilities have been added to classFileParser.cpp to >> provide the reason for which the Record attribute has been ignored >> >> Reflection: >> - there are several new changes to the implementation of >> java.lang.reflect.RecordComponent apart from the spec changes >> mentioned before. >> >> bug fixes in >> - compiler >> - serialization, >> - JVM, etc >> >> As a reference the last iteration of the previous reviews can be >> found at [4] under folders: compiler, hotspot_runtime, javadoc, >> reflection and serialization, >> >> TIA, >> Vicente >> >> [1] >> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >> [2] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >> [3] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >> [4] http://cr.openjdk.java.net/~vromero/records.review/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Nov 28 18:43:27 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Nov 2019 18:43:27 +0000 Subject: RFR: JDK-8234922: No compilation error reported not reported for a binding variable when loop broken with label In-Reply-To: References: Message-ID: <35d29b86-42fa-01ea-8581-c7d6fa0e0fa7@oracle.com> Looks good - I wonder if we really need to store all trees from the outer loop down to the break statement. Shouldn't we just add trees that could potentially be targets of a break? (e.g. labels, switch and other loops) Maurizio On 28/11/2019 15:11, Jan Lahoda wrote: > Hi, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8234922 > > The problem described there is basically: > --- > public class PatternTest { > ??? public static void test(Object o) { > ??????? A: > ??????? do { > ??????????? break A; > ??????? } while (!(o instanceof String v)); > ??????? System.out.println("Got: " + v); > ??? } > } > --- > > This should not compile, as "v" should not be in scope for the > System.out.println, but javac fails to detect the break, as the break > breaks to a labeled statement, not to the loop. The proposed patch > solves not only this, but also break to any statement that is not > inside the given loop. > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8234922/webrev.00/ > > How does this look? > > Thanks, > ??? Jan From jan.lahoda at oracle.com Fri Nov 29 11:25:47 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 29 Nov 2019 12:25:47 +0100 Subject: RFR: JDK-8234922: No compilation error reported not reported for a binding variable when loop broken with label In-Reply-To: <35d29b86-42fa-01ea-8581-c7d6fa0e0fa7@oracle.com> References: <35d29b86-42fa-01ea-8581-c7d6fa0e0fa7@oracle.com> Message-ID: <2aa88b22-a77a-60b6-d2e7-5d22ca6b326e@oracle.com> On 28. 11. 19 19:43, Maurizio Cimadamore wrote: > Looks good - I wonder if we really need to store all trees from the > outer loop down to the break statement. Thanks. > > Shouldn't we just add trees that could potentially be targets of a > break? (e.g. labels, switch and other loops) We can - updated patch: http://cr.openjdk.java.net/~jlahoda/8234922/webrev.01/ Thanks, Jan > > Maurizio > > On 28/11/2019 15:11, Jan Lahoda wrote: >> Hi, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8234922 >> >> The problem described there is basically: >> --- >> public class PatternTest { >> ??? public static void test(Object o) { >> ??????? A: >> ??????? do { >> ??????????? break A; >> ??????? } while (!(o instanceof String v)); >> ??????? System.out.println("Got: " + v); >> ??? } >> } >> --- >> >> This should not compile, as "v" should not be in scope for the >> System.out.println, but javac fails to detect the break, as the break >> breaks to a labeled statement, not to the loop. The proposed patch >> solves not only this, but also break to any statement that is not >> inside the given loop. >> >> Webrev: >> http://cr.openjdk.java.net/~jlahoda/8234922/webrev.00/ >> >> How does this look? >> >> Thanks, >> ??? Jan From joe.darcy at oracle.com Fri Nov 29 14:59:00 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 29 Nov 2019 06:59:00 -0800 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> Message-ID: <04ab170a-72a3-81e0-c38b-79b9a2533cd1@oracle.com> Hi Vicente, Please change all uses of ??? @compile --enable-preview -source 14 in jtreg tags to to ??? @compile --enable-preview -source ${jdk.version} The former structure will spuriously fail when the JDK 14 -> 15 transition occurs. Also, publishing delta-webrevs between iterations in additional to full webrev would help track the incremental changes. Thanks, -Joe On 11/28/2019 8:05 AM, Vicente Romero wrote: > Hi again, > > Sorry but I realized that I forgot to remove some code on the compiler > side. The code removed is small, before we were issuing an error if > some serialization methods were declared as record members. That > section was removed from the spec. I have prepared another iteration > with this change at [1] > > Thanks, > Vicente > > [1] > http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ > > On 11/27/19 11:37 PM, Vicente Romero wrote: >> Hi, >> >> Please review the code for the records feature at [1]. This webrev >> includes all: APIs, runtime, compiler, serialization, javadoc, and >> more! Must of the code has been reviewed but there have been some >> changes since reviewers saw it. Also this is the first time an >> integral webrev is sent out for review. Last changes on top of my >> mind since last review iterations: >> >> On the compiler implementation: >> - it has been adapted to the last version of the language spec [2], >> as a reference the JVM spec is at [3]. This implied some changes in >> determining if a user defined constructor is the canonical or not. >> Now if a constructor is override-equivalent to a signature derived >> from the record components, then it is considered the canonical >> constructor. And any canonical constructor should satisfy a set of >> restrictions, see section 8.10.4 Record Constructor Declarations of >> the specification. >> - It was also added a check to make sure that accessors are not generic. >> - And that the canonical constructor, if user defined, is not >> explicitly invoking any other constructor. >> - The list of forbidden record component names has also been updated. >> - new error messages have been added >> >> APIs: >> - there have been some API editing in java.lang.Record, >> java.lang.runtime.ObjectMethods and >> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >> javax.lang.model (some visitors were added) >> >> On the JVM implementation: >> - some logging capabilities have been added to classFileParser.cpp to >> provide the reason for which the Record attribute has been ignored >> >> Reflection: >> - there are several new changes to the implementation of >> java.lang.reflect.RecordComponent apart from the spec changes >> mentioned before. >> >> bug fixes in >> - compiler >> - serialization, >> - JVM, etc >> >> As a reference the last iteration of the previous reviews can be >> found at [4] under folders: compiler, hotspot_runtime, javadoc, >> reflection and serialization, >> >> TIA, >> Vicente >> >> [1] >> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >> [2] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >> [3] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >> [4] http://cr.openjdk.java.net/~vromero/records.review/ >> > From jan.lahoda at oracle.com Fri Nov 29 16:30:57 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 29 Nov 2019 17:30:57 +0100 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: Hi Vcente, Overall, looks fine I think. A few comments on the javac implementation: -in TypeEnter, I believe this: memberEnter.memberEnter(tree.defs.diff(List.convert(JCTree.class, defsBeforeAddingNewMembers)), env); is unnecessary (and fairly slow). defsBeforeAddingNewMembers is initialized to tree.defs a few lines above, and I don't think tree.defs is modified between the point defsBeforeAddingNewMembers and this line. I.e. the diff will be empty, but very slow to compute (basically n^2, unless I am mistaken). Not having this line would also help in not changing: test/langtools/tools/javac/importscope/T8193717.java (If the tree.defs would be changed, I would suggest to keep track of which members were added, and avoid the List.diff - tree.defs can contain a lot of elements, and the diff is fairly slow.) -in test/langtools/tools/javac/expswitch/ExpSwitchNestingTest.java, the --enable-preview should no longer be needed -Flags.COMPACT_RECORD_CONSTRUCTOR says it is only for MethodSymbols, but is also for VarSymbols. Either the comment should be adjusted, or (possibly better), there could be a different/new flag for the fields. (That new flag can reuse the same bit position as COMPACT_RECORD_CONSTRUCTOR, of course.) -nits: --Lower.generateMandatedAccessors: could be rewritten using filter() to avoid having an if in the forEach, or changed even more by using filter-map-collect (and avoid having a manual ListBuffer). For your consideration --AttrContext.java: no need to move the isLambda initialization, correct? (i.e. the actual change is adding isSerializableLambda, but the diff says isLambda is removed and added on a different place). --in src/jdk.compiler/share/classes/com/sun/source/doctree/DocTree.java and src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java, there are no changes except for a change in the copyright years - these could be presumably stripped. --there is a TODO in: src/java.compiler/share/classes/javax/lang/model/SourceVersion.java presumably, this could be resolved based on the current spec? Jan On 28. 11. 19 5:37, Vicente Romero wrote: > Hi, > > Please review the code for the records feature at [1]. This webrev > includes all: APIs, runtime, compiler, serialization, javadoc, and more! > Must of the code has been reviewed but there have been some changes > since reviewers saw it. Also this is the first time an integral webrev > is sent out for review. Last changes on top of my mind since last review > iterations: > > On the compiler implementation: > - it has been adapted to the last version of the language spec [2], as a > reference the JVM spec is at [3]. This implied some changes in > determining if a user defined constructor is the canonical or not. Now > if a constructor is override-equivalent to a signature derived from the > record components, then it is considered the canonical constructor. And > any canonical constructor should satisfy a set of restrictions, see > section 8.10.4 Record Constructor Declarations of the specification. > - It was also added a check to make sure that accessors are not generic. > - And that the canonical constructor, if user defined, is not explicitly > invoking any other constructor. > - The list of forbidden record component names has also been updated. > - new error messages have been added > > APIs: > - there have been some API editing in java.lang.Record, > java.lang.runtime.ObjectMethods and java.lang.reflect.RecordComponent, > java.io.ObjectInputStream, javax.lang.model (some visitors were added) > > On the JVM implementation: > - some logging capabilities have been added to classFileParser.cpp to > provide the reason for which the Record attribute has been ignored > > Reflection: > - there are several new changes to the implementation of > java.lang.reflect.RecordComponent apart from the spec changes mentioned > before. > > bug fixes in > - compiler > - serialization, > - JVM, etc > > As a reference the last iteration of the previous reviews can be found > at [4] under folders: compiler, hotspot_runtime, javadoc, reflection and > serialization, > > TIA, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ > [2] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html > > [3] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html > > [4] http://cr.openjdk.java.net/~vromero/records.review/ > From vicente.romero at oracle.com Fri Nov 29 23:12:30 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 29 Nov 2019 18:12:30 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <04ab170a-72a3-81e0-c38b-79b9a2533cd1@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> <04ab170a-72a3-81e0-c38b-79b9a2533cd1@oracle.com> Message-ID: <3805c12d-d476-0f09-3344-a0f7e215c34b@oracle.com> Hi Joe, All the tests that have an explicit -source 14 are that way because of, I think to remember, a bug in jtreg that doesn't expand the ${some.property} macro for those tests. I don't remember the details though Thanks, Vicente On 11/29/19 9:59 AM, Joe Darcy wrote: > Hi Vicente, > > Please change all uses of > > ??? @compile --enable-preview -source 14 > > in jtreg tags to to > > ??? @compile --enable-preview -source ${jdk.version} > > The former structure will spuriously fail when the JDK 14 -> 15 > transition occurs. > > Also, publishing delta-webrevs between iterations in additional to > full webrev would help track the incremental changes. > > Thanks, > > -Joe > > On 11/28/2019 8:05 AM, Vicente Romero wrote: >> Hi again, >> >> Sorry but I realized that I forgot to remove some code on the >> compiler side. The code removed is small, before we were issuing an >> error if some serialization methods were declared as record members. >> That section was removed from the spec. I have prepared another >> iteration with this change at [1] >> >> Thanks, >> Vicente >> >> [1] >> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ >> >> On 11/27/19 11:37 PM, Vicente Romero wrote: >>> Hi, >>> >>> Please review the code for the records feature at [1]. This webrev >>> includes all: APIs, runtime, compiler, serialization, javadoc, and >>> more! Must of the code has been reviewed but there have been some >>> changes since reviewers saw it. Also this is the first time an >>> integral webrev is sent out for review. Last changes on top of my >>> mind since last review iterations: >>> >>> On the compiler implementation: >>> - it has been adapted to the last version of the language spec [2], >>> as a reference the JVM spec is at [3]. This implied some changes in >>> determining if a user defined constructor is the canonical or not. >>> Now if a constructor is override-equivalent to a signature derived >>> from the record components, then it is considered the canonical >>> constructor. And any canonical constructor should satisfy a set of >>> restrictions, see section 8.10.4 Record Constructor Declarations of >>> the specification. >>> - It was also added a check to make sure that accessors are not >>> generic. >>> - And that the canonical constructor, if user defined, is not >>> explicitly invoking any other constructor. >>> - The list of forbidden record component names has also been updated. >>> - new error messages have been added >>> >>> APIs: >>> - there have been some API editing in java.lang.Record, >>> java.lang.runtime.ObjectMethods and >>> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >>> javax.lang.model (some visitors were added) >>> >>> On the JVM implementation: >>> - some logging capabilities have been added to classFileParser.cpp >>> to provide the reason for which the Record attribute has been ignored >>> >>> Reflection: >>> - there are several new changes to the implementation of >>> java.lang.reflect.RecordComponent apart from the spec changes >>> mentioned before. >>> >>> bug fixes in >>> - compiler >>> - serialization, >>> - JVM, etc >>> >>> As a reference the last iteration of the previous reviews can be >>> found at [4] under folders: compiler, hotspot_runtime, javadoc, >>> reflection and serialization, >>> >>> TIA, >>> Vicente >>> >>> [1] >>> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >>> [2] >>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >>> [3] >>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >>> [4] http://cr.openjdk.java.net/~vromero/records.review/ >>> >> From vicente.romero at oracle.com Sat Nov 30 18:29:23 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Sat, 30 Nov 2019 13:29:23 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> Message-ID: <5cc9da98-3dae-b6c6-7acb-c9a4c3484a3b@oracle.com> Hi, I have created another iteration at [1], this is just a delta from last iteration [2]. Some comments below [1] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01_delta.01/ [2] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01 On 11/28/19 1:35 PM, Maurizio Cimadamore wrote: > > Hi Vicente, > generally looks good - few comments below; I tried to focus on areas > where the compiler code seemed to diverge from the spec, as well on > pieces of code which look a leftover from previous spec rounds. > > * canonical constructors *can* have return statements - compact > constructors cant; the spec went a bit back and forth on this, but now > it has settled. Since compact constructors are turned into ordinary > canonical ones by the parser, I think you need to add an extra check > for COMPACT_RECORD_CONSTRUCTOR; in other words, this is ok: > > record Foo() { > ?? Foo() { return; } //canonical > } > > this isn't > > record Foo() { > ?? Foo { return; } //compact > } > > but the compiler rejects both. This probably means tweaking the > diagnostic a bit to say "a compact constructor must not contain > |return| statements" > yes I have modified the code so that the error messages can show "canonical" or "compact" depending on the case > * in general, all diagnostics speak about 'canonical constructor' > regardless of whether the constructor is canonical of compact; while I > understand the reason behind what we get now, some of the error > messages can be confusing, especially if you look at the spec, where > canonical constructor and compact constructor are two different > concepts. This should be fixed (even if not immediately, in which case > I'd recommend to file a JBS issue to track that) > > * static accessors are allowed - this means that I can do this: > > record Foo(int x) { > public static int x() {return 0; } > > public static void main(String[] args) { > ?? System.err.println(new Foo(42).x()); > } > } > > This will compile and print 0. The classfile will contain the > following members: > > final class Foo extends java.lang.Record { > ? public Foo(int); > ? public static int x(); > ? public static void main(java.lang.String[]); > ? public java.lang.String toString(); > ? public final int hashCode(); > ? public final boolean equals(java.lang.Object); > } > > I believe this is an issue in the compiler, but also in the latest > spec draft, if I'm not mistaken. > yes this is a bug, we are considering updating both the spec and the compiler. I will submit another iteration as soon as this change is reflected in both > * [optional - style] the env.info.isSerializableLambda could become an > enum { NONE, LAMBDA, SERIALIZABLE_LAMBDA } instead of two boolean > parameters > will do that later, I remember that there were some interactions between these flags, they are not exclusive > > * this code is still rejected with --enable-preview _disabled_: > > class X { > ??? record R(int i) { > ??????? return null; > ??? } > } > class record {} > > This gives the error: > > Error: > |? records are a preview feature and are disabled by default. > |??? (use --enable-preview to enable records) > |? record R(int i) { return null } } > |? ^ > |? Error: > |? illegal start of type > |? record R(int i) { return null } } > |??????????????????? ^ > > In other words, the parsing logic for members is too aggressive - we > shouldn't call isRecordStart() in there. If this is not fixed in this > round, we should keep track with a JBS issue. > I have created a follow up issue: https://bugs.openjdk.java.net/browse/JDK-8235149 > * Are the changes in Tokens really needed? > no removed > > * Check::checkUnique doesn't seem to use the added 'env' parameter - > changes should be reverted > yep done > > * Names.jave - the logic for having forbiddenRecordComponentNames > could use some refresh - in the latest spec we basically have to ban > components that have same name as j.l.Object members - so I think we > can implement the check more directly (e.g. w/o having a set of names). > right done, I have created a method that check if a record component name matches with a parameterless method in Object > Also, the serialization names are not needed (although I guess they > will come back at some point). > yes they will, I can remove them now but I guess we will need them once we implement a lint warning > And, not sure what "get" and "set" are needed for? > removed > > > Maurizio > thanks, Vicente > > On 28/11/2019 16:05, Vicente Romero wrote: >> Hi again, >> >> Sorry but I realized that I forgot to remove some code on the >> compiler side. The code removed is small, before we were issuing an >> error if some serialization methods were declared as record members. >> That section was removed from the spec. I have prepared another >> iteration with this change at [1] >> >> Thanks, >> Vicente >> >> [1] >> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ >> >> On 11/27/19 11:37 PM, Vicente Romero wrote: >>> Hi, >>> >>> Please review the code for the records feature at [1]. This webrev >>> includes all: APIs, runtime, compiler, serialization, javadoc, and >>> more! Must of the code has been reviewed but there have been some >>> changes since reviewers saw it. Also this is the first time an >>> integral webrev is sent out for review. Last changes on top of my >>> mind since last review iterations: >>> >>> On the compiler implementation: >>> - it has been adapted to the last version of the language spec [2], >>> as a reference the JVM spec is at [3]. This implied some changes in >>> determining if a user defined constructor is the canonical or not. >>> Now if a constructor is override-equivalent to a signature derived >>> from the record components, then it is considered the canonical >>> constructor. And any canonical constructor should satisfy a set of >>> restrictions, see section 8.10.4 Record Constructor Declarations of >>> the specification. >>> - It was also added a check to make sure that accessors are not >>> generic. >>> - And that the canonical constructor, if user defined, is not >>> explicitly invoking any other constructor. >>> - The list of forbidden record component names has also been updated. >>> - new error messages have been added >>> >>> APIs: >>> - there have been some API editing in java.lang.Record, >>> java.lang.runtime.ObjectMethods and >>> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >>> javax.lang.model (some visitors were added) >>> >>> On the JVM implementation: >>> - some logging capabilities have been added to classFileParser.cpp >>> to provide the reason for which the Record attribute has been ignored >>> >>> Reflection: >>> - there are several new changes to the implementation of >>> java.lang.reflect.RecordComponent apart from the spec changes >>> mentioned before. >>> >>> bug fixes in >>> - compiler >>> - serialization, >>> - JVM, etc >>> >>> As a reference the last iteration of the previous reviews can be >>> found at [4] under folders: compiler, hotspot_runtime, javadoc, >>> reflection and serialization, >>> >>> TIA, >>> Vicente >>> >>> [1] >>> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >>> [2] >>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >>> [3] >>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >>> [4] http://cr.openjdk.java.net/~vromero/records.review/ >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Sat Nov 30 18:31:57 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Sat, 30 Nov 2019 13:31:57 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: Hi Jan, I have addressed your comments on delta iteration [1] [1] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01_delta.01/ some comments below. On 11/29/19 11:30 AM, Jan Lahoda wrote: > Hi Vcente, > > Overall, looks fine I think. A few comments on the javac implementation: > -in TypeEnter, I believe this: > memberEnter.memberEnter(tree.defs.diff(List.convert(JCTree.class, > defsBeforeAddingNewMembers)), env); > is unnecessary yep removed > (and fairly slow). defsBeforeAddingNewMembers is initialized to > tree.defs a few lines above, and I don't think tree.defs is modified > between the point defsBeforeAddingNewMembers and this line. I.e. the > diff will be empty, but very slow to compute (basically n^2, unless I > am mistaken). Not having this line would also help in not changing: > test/langtools/tools/javac/importscope/T8193717.java > (If the tree.defs would be changed, I would suggest to keep track of > which members were added, and avoid the List.diff - tree.defs can > contain a lot of elements, and the diff is fairly slow.) > > -in test/langtools/tools/javac/expswitch/ExpSwitchNestingTest.java, > the --enable-preview should no longer be needed done > > -Flags.COMPACT_RECORD_CONSTRUCTOR says it is only for MethodSymbols, > but is also for VarSymbols. Either the comment should be adjusted, or > (possibly better), there could be a different/new flag for the fields. > (That new flag can reuse the same bit position as > COMPACT_RECORD_CONSTRUCTOR, of course.) done > > -nits: > --Lower.generateMandatedAccessors: could be rewritten using filter() > to avoid having an if in the forEach, or changed even more by using > filter-map-collect (and avoid having a manual ListBuffer). For your > consideration yep done > --AttrContext.java: no need to move the isLambda initialization, > correct? (i.e. the actual change is adding isSerializableLambda, but > the diff says isLambda is removed and added on a different place). done > --in > src/jdk.compiler/share/classes/com/sun/source/doctree/DocTree.java and > src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java, > there are no changes except for a change in the copyright years - > these could be presumably stripped. yep done > --there is a TODO in: > src/java.compiler/share/classes/javax/lang/model/SourceVersion.java > presumably, this could be resolved based on the current spec? I think that this comment doesn't apply as there is no need for any additional change. I have removed it > > Jan Thanks, Vicente > > On 28. 11. 19 5:37, Vicente Romero wrote: >> Hi, >> >> Please review the code for the records feature at [1]. This webrev >> includes all: APIs, runtime, compiler, serialization, javadoc, and >> more! Must of the code has been reviewed but there have been some >> changes since reviewers saw it. Also this is the first time an >> integral webrev is sent out for review. Last changes on top of my >> mind since last review iterations: >> >> On the compiler implementation: >> - it has been adapted to the last version of the language spec [2], >> as a reference the JVM spec is at [3]. This implied some changes in >> determining if a user defined constructor is the canonical or not. >> Now if a constructor is override-equivalent to a signature derived >> from the record components, then it is considered the canonical >> constructor. And any canonical constructor should satisfy a set of >> restrictions, see section 8.10.4 Record Constructor Declarations of >> the specification. >> - It was also added a check to make sure that accessors are not generic. >> - And that the canonical constructor, if user defined, is not >> explicitly invoking any other constructor. >> - The list of forbidden record component names has also been updated. >> - new error messages have been added >> >> APIs: >> - there have been some API editing in java.lang.Record, >> java.lang.runtime.ObjectMethods and >> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >> javax.lang.model (some visitors were added) >> >> On the JVM implementation: >> - some logging capabilities have been added to classFileParser.cpp to >> provide the reason for which the Record attribute has been ignored >> >> Reflection: >> - there are several new changes to the implementation of >> java.lang.reflect.RecordComponent apart from the spec changes >> mentioned before. >> >> bug fixes in >> - compiler >> - serialization, >> - JVM, etc >> >> As a reference the last iteration of the previous reviews can be >> found at [4] under folders: compiler, hotspot_runtime, javadoc, >> reflection and serialization, >> >> TIA, >> Vicente >> >> [1] >> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >> [2] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >> >> [3] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >> >> [4] http://cr.openjdk.java.net/~vromero/records.review/ >> From maurizio.cimadamore at oracle.com Sat Nov 30 22:51:25 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sat, 30 Nov 2019 22:51:25 +0000 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <5cc9da98-3dae-b6c6-7acb-c9a4c3484a3b@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> <5cc9da98-3dae-b6c6-7acb-c9a4c3484a3b@oracle.com> Message-ID: <1c81d93e-4fcc-68b5-7e1b-a6b8880a2964@oracle.com> Looks good - but you need diagnostic fragments for the "canonical", "compact" diagnostic bits (no need for re-review). Maurizio On 30/11/2019 18:29, Vicente Romero wrote: > Hi, > > I have created another iteration at [1], this is just a delta from > last iteration [2]. Some comments below > > [1] > http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01_delta.01/ > [2] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01 > > On 11/28/19 1:35 PM, Maurizio Cimadamore wrote: >> >> Hi Vicente, >> generally looks good - few comments below; I tried to focus on areas >> where the compiler code seemed to diverge from the spec, as well on >> pieces of code which look a leftover from previous spec rounds. >> >> * canonical constructors *can* have return statements - compact >> constructors cant; the spec went a bit back and forth on this, but >> now it has settled. Since compact constructors are turned into >> ordinary canonical ones by the parser, I think you need to add an >> extra check for COMPACT_RECORD_CONSTRUCTOR; in other words, this is ok: >> >> record Foo() { >> ?? Foo() { return; } //canonical >> } >> >> this isn't >> >> record Foo() { >> ?? Foo { return; } //compact >> } >> >> but the compiler rejects both. This probably means tweaking the >> diagnostic a bit to say "a compact constructor must not contain >> |return| statements" >> > > yes I have modified the code so that the error messages can show > "canonical" or "compact" depending on the case > >> * in general, all diagnostics speak about 'canonical constructor' >> regardless of whether the constructor is canonical of compact; while >> I understand the reason behind what we get now, some of the error >> messages can be confusing, especially if you look at the spec, where >> canonical constructor and compact constructor are two different >> concepts. This should be fixed (even if not immediately, in which >> case I'd recommend to file a JBS issue to track that) >> >> * static accessors are allowed - this means that I can do this: >> >> record Foo(int x) { >> public static int x() {return 0; } >> >> public static void main(String[] args) { >> ?? System.err.println(new Foo(42).x()); >> } >> } >> >> This will compile and print 0. The classfile will contain the >> following members: >> >> final class Foo extends java.lang.Record { >> ? public Foo(int); >> ? public static int x(); >> ? public static void main(java.lang.String[]); >> ? public java.lang.String toString(); >> ? public final int hashCode(); >> ? public final boolean equals(java.lang.Object); >> } >> >> I believe this is an issue in the compiler, but also in the latest >> spec draft, if I'm not mistaken. >> > > yes this is a bug, we are considering updating both the spec and the > compiler. I will submit another iteration as soon as this change is > reflected in both > >> * [optional - style] the env.info.isSerializableLambda could become >> an enum { NONE, LAMBDA, SERIALIZABLE_LAMBDA } instead of two boolean >> parameters >> > > will do that later, I remember that there were some interactions > between these flags, they are not exclusive >> >> * this code is still rejected with --enable-preview _disabled_: >> >> class X { >> ??? record R(int i) { >> ??????? return null; >> ??? } >> } >> class record {} >> >> This gives the error: >> >> Error: >> |? records are a preview feature and are disabled by default. >> |??? (use --enable-preview to enable records) >> |? record R(int i) { return null } } >> |? ^ >> |? Error: >> |? illegal start of type >> |? record R(int i) { return null } } >> |??????????????????? ^ >> >> In other words, the parsing logic for members is too aggressive - we >> shouldn't call isRecordStart() in there. If this is not fixed in this >> round, we should keep track with a JBS issue. >> > > I have created a follow up issue: > https://bugs.openjdk.java.net/browse/JDK-8235149 > >> * Are the changes in Tokens really needed? >> > no removed >> >> * Check::checkUnique doesn't seem to use the added 'env' parameter - >> changes should be reverted >> > yep done >> >> * Names.jave - the logic for having forbiddenRecordComponentNames >> could use some refresh - in the latest spec we basically have to ban >> components that have same name as j.l.Object members - so I think we >> can implement the check more directly (e.g. w/o having a set of names). >> > > right done, I have created a method that check if a record component > name matches with a parameterless method in Object > >> Also, the serialization names are not needed (although I guess they >> will come back at some point). >> > > yes they will, I can remove them now but I guess we will need them > once we implement a lint warning > >> And, not sure what "get" and "set" are needed for? >> > > removed >> >> >> Maurizio >> > > thanks, > Vicente >> >> On 28/11/2019 16:05, Vicente Romero wrote: >>> Hi again, >>> >>> Sorry but I realized that I forgot to remove some code on the >>> compiler side. The code removed is small, before we were issuing an >>> error if some serialization methods were declared as record members. >>> That section was removed from the spec. I have prepared another >>> iteration with this change at [1] >>> >>> Thanks, >>> Vicente >>> >>> [1] >>> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ >>> >>> On 11/27/19 11:37 PM, Vicente Romero wrote: >>>> Hi, >>>> >>>> Please review the code for the records feature at [1]. This webrev >>>> includes all: APIs, runtime, compiler, serialization, javadoc, and >>>> more! Must of the code has been reviewed but there have been some >>>> changes since reviewers saw it. Also this is the first time an >>>> integral webrev is sent out for review. Last changes on top of my >>>> mind since last review iterations: >>>> >>>> On the compiler implementation: >>>> - it has been adapted to the last version of the language spec [2], >>>> as a reference the JVM spec is at [3]. This implied some changes in >>>> determining if a user defined constructor is the canonical or not. >>>> Now if a constructor is override-equivalent to a signature derived >>>> from the record components, then it is considered the canonical >>>> constructor. And any canonical constructor should satisfy a set of >>>> restrictions, see section 8.10.4 Record Constructor Declarations of >>>> the specification. >>>> - It was also added a check to make sure that accessors are not >>>> generic. >>>> - And that the canonical constructor, if user defined, is not >>>> explicitly invoking any other constructor. >>>> - The list of forbidden record component names has also been updated. >>>> - new error messages have been added >>>> >>>> APIs: >>>> - there have been some API editing in java.lang.Record, >>>> java.lang.runtime.ObjectMethods and >>>> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >>>> javax.lang.model (some visitors were added) >>>> >>>> On the JVM implementation: >>>> - some logging capabilities have been added to classFileParser.cpp >>>> to provide the reason for which the Record attribute has been ignored >>>> >>>> Reflection: >>>> - there are several new changes to the implementation of >>>> java.lang.reflect.RecordComponent apart from the spec changes >>>> mentioned before. >>>> >>>> bug fixes in >>>> - compiler >>>> - serialization, >>>> - JVM, etc >>>> >>>> As a reference the last iteration of the previous reviews can be >>>> found at [4] under folders: compiler, hotspot_runtime, javadoc, >>>> reflection and serialization, >>>> >>>> TIA, >>>> Vicente >>>> >>>> [1] >>>> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >>>> [2] >>>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >>>> [3] >>>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >>>> [4] http://cr.openjdk.java.net/~vromero/records.review/ >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: