From jan.lahoda at oracle.com Mon Jul 1 07:33:42 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 1 Jul 2019 09:33:42 +0200 Subject: RFR: JDK-8226522: No compilation error reported when yield is used in incorrect context In-Reply-To: <024dff63-f1d0-b5fb-6ba6-85ebc0560a72@oracle.com> References: <8272c0f6-2a79-1b74-6ffc-35f9af814a8c@oracle.com> <024dff63-f1d0-b5fb-6ba6-85ebc0560a72@oracle.com> Message-ID: On 29. 06. 19 23:04, Maurizio Cimadamore wrote: > The fix looks good - but I suggest a refactoring of the condition which, > as is, is quite difficult to parse (for the human eyes). > > Maybe factor away: > > Name restrictedTypeName = restrictedTypeName(result, !allowVar) > > > ? Thanks! Updated webrev: http://cr.openjdk.java.net/~jlahoda/8226522/webrev.01/ Does this look better? Thanks, Jan > > Maurizio > > On 28/06/2019 13:33, Jan Lahoda wrote: >> Hi, >> >> For code like: >> I i = (yield a) -> {}; >> >> interface I { public void test(String a); } >> >> javac will compile the code, as if the "yield" was "var". This is >> because of a mistake in restricted types handling in this case. >> >> Proposed fix is to ensure we are seeing "var" as the lambda parameter >> type, not yield. >> >> Webrev: http://cr.openjdk.java.net/~jlahoda/8226522/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8226522 >> >> How does this look? >> >> Thanks, >> ??? Jan From maurizio.cimadamore at oracle.com Mon Jul 1 09:06:26 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 1 Jul 2019 10:06:26 +0100 Subject: RFR: JDK-8226522: No compilation error reported when yield is used in incorrect context In-Reply-To: References: <8272c0f6-2a79-1b74-6ffc-35f9af814a8c@oracle.com> <024dff63-f1d0-b5fb-6ba6-85ebc0560a72@oracle.com> Message-ID: <9548ca6a-21ca-cea1-180a-9d86bdfa85a1@oracle.com> Better thanks! Maurizio On 01/07/2019 08:33, Jan Lahoda wrote: > On 29. 06. 19 23:04, Maurizio Cimadamore wrote: >> The fix looks good - but I suggest a refactoring of the condition >> which, as is, is quite difficult to parse (for the human eyes). >> >> Maybe factor away: >> >> Name restrictedTypeName = restrictedTypeName(result, !allowVar) >> >> >> ? > > Thanks! Updated webrev: > http://cr.openjdk.java.net/~jlahoda/8226522/webrev.01/ > > Does this look better? > > Thanks, > ??? Jan > >> >> Maurizio >> >> On 28/06/2019 13:33, Jan Lahoda wrote: >>> Hi, >>> >>> For code like: >>> I i = (yield a) -> {}; >>> >>> interface I { public void test(String a); } >>> >>> javac will compile the code, as if the "yield" was "var". This is >>> because of a mistake in restricted types handling in this case. >>> >>> Proposed fix is to ensure we are seeing "var" as the lambda >>> parameter type, not yield. >>> >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8226522/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8226522 >>> >>> How does this look? >>> >>> Thanks, >>> ??? Jan From jan.lahoda at oracle.com Mon Jul 1 15:24:09 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 1 Jul 2019 17:24:09 +0200 Subject: RFR(14): JDK-8227010: Error recovery after local variable redeclaration can be improved Message-ID: Hi, Consider code like this: --- public class T { { String v = ""; Integer v = 0; System.err.println(v.byteValue()); } } --- This produces errors like this: --- $ javac T.java T.java:4: error: variable v is already defined in instance initializer of class T Integer v = 0; ^ T.java:5: error: cannot find symbol System.err.println(v.byteValue()); ^ symbol: method byteValue() location: variable v of type String 2 errors --- The second error feels superfluous, as the last declaration for "v" declares it as "Integer". The reason is that non-unique (local) variables are not added into the Scope, and hence will never be looked up. The proposed patch is to add non-unique local variables (but not other Symbols) to the Scope, which should hide the previous declaration. The first error will remain untouched. JBS: https://bugs.openjdk.java.net/browse/JDK-8227010 Webrev: http://cr.openjdk.java.net/~jlahoda/8227010/webrev.00/ How does this look? Thanks, Jan From maurizio.cimadamore at oracle.com Tue Jul 2 13:19:01 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 2 Jul 2019 14:19:01 +0100 Subject: RFR(14): JDK-8227010: Error recovery after local variable redeclaration can be improved In-Reply-To: References: Message-ID: Looks good! Maurizio On 01/07/2019 16:24, Jan Lahoda wrote: > Hi, > > Consider code like this: > --- > public class T { > ??? { > ???????? String v = ""; > ???????? Integer v = 0; > ???????? System.err.println(v.byteValue()); > ??? } > } > --- > > This produces errors like this: > --- > $ javac T.java > T.java:4: error: variable v is already defined in instance initializer > of class T > ???????? Integer v = 0; > ???????????????? ^ > T.java:5: error: cannot find symbol > ???????? System.err.println(v.byteValue()); > ???????????????????????????? ^ > ? symbol: method byteValue() > ? location: variable v of type String > 2 errors > --- > > The second error feels superfluous, as the last declaration for "v" > declares it as "Integer". The reason is that non-unique (local) > variables are not added into the Scope, and hence will never be looked > up. The proposed patch is to add non-unique local variables (but not > other Symbols) to the Scope, which should hide the previous > declaration. The first error will remain untouched. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8227010 > Webrev: http://cr.openjdk.java.net/~jlahoda/8227010/webrev.00/ > > How does this look? > > Thanks, > ??? Jan From maurizio.cimadamore at oracle.com Tue Jul 2 17:02:28 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 2 Jul 2019 18:02:28 +0100 Subject: RFR: JDK-8223443: Calling Trees.getScope early changes names of local/anonymous classes In-Reply-To: <932af897-4fa3-d983-1a0f-d6cbdea7415d@oracle.com> References: <932af897-4fa3-d983-1a0f-d6cbdea7415d@oracle.com> Message-ID: <9634b711-92b7-bb44-1682-87421ac76a9a@oracle.com> Hi Jan, the fix in itself is fine. And I'm ok going ahead with it modulo few nits: * there seem to be commented lines in TestGetScopeBinaryNames * I'm not a big fan of names like "tree2FlatName", "new2Old", "prepareTree2FlatName" - but I can understand that's subjective * some extra doc would be helpful, especially in the visitClassDef inside fixLocalClassNames - e.g. it would be helpful if the comments called out the cases that you can encounter explicitly (e.g. we have seen an unattributed tree, so we have to make up a new name, vs. we have seen an already attributed tree, so we copy the name over, etc.) More generally, I think that leaning on the deferred attribution machinery is the right move here, and in fact I wonder if we couldn't leverage that machinery more. For instance, if I look at JavacTrees::getAttrContext I can't help but thinking that that method is a poor man version of speculative attribution - so, rather than using that method and fix up the results so that they 'match' what javac would otherwise produce during Attr, wouldn't it be better to use javac's Attr directly (e.g. speculative re-attributing the entire class, and stopping at a given tree, them returning the speculative env?). Maybe the approach I suggest is too complex, or it would lead to a poor performance model, but I just wanted to share this thought as it came up when looking at the JavacTrees code. Cheers Maurizio On 09/05/2019 16:39, Jan Lahoda wrote: > Hi, > > In the Trees API, there is the (com.sun.source.util.)Trees.getScope > method. It works by cloning the body of the enclosing method and > attributing the clone, capturing the appropriate Env. > > There are a few issues with this method: > 1. if getScope is called on an unattributed (but already entered) AST, > while attributing the copy of the enclosing method, (some of) the > names of the local/anonymous classes are assigned to the copy, and > then not reused when actually attributing the real AST and generating > classfiles. So calling getScope "early" may lead to generating > different classfiles with different names for the local/anonymous > classes. This can be fixed by un-entering the classes (which is > already done in DeferredAttr). > 2. the binary names of the TypeElements for local/anonymous classes in > the returned Scope do not match those from the real AST. This can be > fixed by assigning the correct flat/binary names to the returned > ClassSymbols. > 3. if there are (compile-time) errors in the enclosing method, these > may be reported during this attribution for getScope. This can be > fixed by ignoring errors reported from the attribution for getScope. > > The proposed fix for these is here: > http://cr.openjdk.java.net/~jlahoda/8223443/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223443 > > How does this look? > > Thanks, > ??? Jan From joe.darcy at oracle.com Wed Jul 3 00:33:35 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 2 Jul 2019 17:33:35 -0700 Subject: Aligning compiler messages for using preview API with preview language features? Message-ID: Hello, As a follow-up to some recent work ("Improving compiler messages for preview API " [1]), I wanted to get some feedback on a possible variation of the work to align the messages for using preview API elements and using preview language features. Assuming some mechanism to implement a predicate identifying a preview API (presence of an annotation, side table in the compiler, etc.), the messages for preview APIs could be routed through the same previewHandler used to process preview language features. The summary message ??? Note: Test.java uses preview language features. ??? Note: Recompile with -Xlint:preview for details. could then be replaced with something like ??? Note: Test.java uses preview language features and/or preview API elements. ??? Note: Recompile with -Xlint:preview for details. or more specialize variants for the particular combinations of a least one flavor of preview functionality being used. Comments? Thanks, -Joe [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html From james.laskey at oracle.com Wed Jul 3 12:48:19 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 3 Jul 2019 09:48:19 -0300 Subject: Aligning compiler messages for using preview API with preview language features? In-Reply-To: References: Message-ID: Clarity always helps. > On Jul 2, 2019, at 9:33 PM, Joe Darcy wrote: > > Hello, > > As a follow-up to some recent work ("Improving compiler messages for preview API " [1]), I wanted to get some feedback on a possible variation of the work to align the messages for using preview API elements and using preview language features. > > Assuming some mechanism to implement a predicate identifying a preview API (presence of an annotation, side table in the compiler, etc.), the messages for preview APIs could be routed through the same previewHandler used to process preview language features. > > The summary message > > Note: Test.java uses preview language features. > Note: Recompile with -Xlint:preview for details. > > could then be replaced with something like > > Note: Test.java uses preview language features and/or preview API elements. > Note: Recompile with -Xlint:preview for details. > > or more specialize variants for the particular combinations of a least one flavor of preview functionality being used. > > Comments? > > Thanks, > > -Joe > > [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html > From jan.lahoda at oracle.com Thu Jul 4 15:34:52 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 4 Jul 2019 17:34:52 +0200 Subject: RFR: JDK-8223443: Calling Trees.getScope early changes names of local/anonymous classes In-Reply-To: <9634b711-92b7-bb44-1682-87421ac76a9a@oracle.com> References: <932af897-4fa3-d983-1a0f-d6cbdea7415d@oracle.com> <9634b711-92b7-bb44-1682-87421ac76a9a@oracle.com> Message-ID: Hi Maurizio, Thanks for comments, please see responses inline: On 02. 07. 19 19:02, Maurizio Cimadamore wrote: > Hi Jan, > the fix in itself is fine. And I'm ok going ahead with it modulo few nits: > > * there seem to be commented lines in TestGetScopeBinaryNames > * I'm not a big fan of names like "tree2FlatName", "new2Old", > "prepareTree2FlatName" - but I can understand that's subjective > * some extra doc would be helpful, especially in the visitClassDef > inside fixLocalClassNames - e.g. it would be helpful if the comments > called out the cases that you can encounter explicitly (e.g. we have > seen an unattributed tree, so we have to make up a new name, vs. we have > seen an already attributed tree, so we copy the name over, etc.) I've tried to improve the patch based on these comments, updated patch: http://cr.openjdk.java.net/~jlahoda/8223443/webrev.01/ And a delta between the last version and this one: http://cr.openjdk.java.net/~jlahoda/8223443/webrev.delta.00.01/ > > > More generally, I think that leaning on the deferred attribution > machinery is the right move here, and in fact I wonder if we couldn't > leverage that machinery more. For instance, if I look at > JavacTrees::getAttrContext I can't help but thinking that that method is > a poor man version of speculative attribution - so, rather than using > that method and fix up the results so that they 'match' what javac would > otherwise produce during Attr, wouldn't it be better to use javac's Attr > directly (e.g. speculative re-attributing the entire class, and stopping > at a given tree, them returning the speculative env?). Speculatively attributing the whole tree (or the whole top-level class) is I think troublesome for two reasons. One is performance (as attributing whole class takes more time than attributing a single method). The other is that we cannot re-enter or attribute again (top-level or nested) classes. JavacTrees.getAttrContext is finding the first part of the AST we can reattribute. I tried to tweak the attribStatToTree in JavacTrees so that it would delegate to attribSpeculative, but so far without too much success. Thanks, Jan > > Maybe the approach I suggest is too complex, or it would lead to a poor > performance model, but I just wanted to share this thought as it came up > when looking at the JavacTrees code. > > Cheers > Maurizio > > On 09/05/2019 16:39, Jan Lahoda wrote: >> Hi, >> >> In the Trees API, there is the (com.sun.source.util.)Trees.getScope >> method. It works by cloning the body of the enclosing method and >> attributing the clone, capturing the appropriate Env. >> >> There are a few issues with this method: >> 1. if getScope is called on an unattributed (but already entered) AST, >> while attributing the copy of the enclosing method, (some of) the >> names of the local/anonymous classes are assigned to the copy, and >> then not reused when actually attributing the real AST and generating >> classfiles. So calling getScope "early" may lead to generating >> different classfiles with different names for the local/anonymous >> classes. This can be fixed by un-entering the classes (which is >> already done in DeferredAttr). >> 2. the binary names of the TypeElements for local/anonymous classes in >> the returned Scope do not match those from the real AST. This can be >> fixed by assigning the correct flat/binary names to the returned >> ClassSymbols. >> 3. if there are (compile-time) errors in the enclosing method, these >> may be reported during this attribution for getScope. This can be >> fixed by ignoring errors reported from the attribution for getScope. >> >> The proposed fix for these is here: >> http://cr.openjdk.java.net/~jlahoda/8223443/webrev.00/ >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8223443 >> >> How does this look? >> >> Thanks, >> ??? Jan From maurizio.cimadamore at oracle.com Thu Jul 4 16:23:31 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 4 Jul 2019 17:23:31 +0100 Subject: RFR: JDK-8223443: Calling Trees.getScope early changes names of local/anonymous classes In-Reply-To: References: <932af897-4fa3-d983-1a0f-d6cbdea7415d@oracle.com> <9634b711-92b7-bb44-1682-87421ac76a9a@oracle.com> Message-ID: <4fc57d9b-7ad7-8450-d869-cb25476f4639@oracle.com> On 04/07/2019 16:34, Jan Lahoda wrote: > > I've tried to improve the patch based on these comments, updated patch: > http://cr.openjdk.java.net/~jlahoda/8223443/webrev.01/ > > And a delta between the last version and this one: > http://cr.openjdk.java.net/~jlahoda/8223443/webrev.delta.00.01/ Looks much better - thanks! Maurizio From matthias.baesken at sap.com Thu Jul 4 09:45:51 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 4 Jul 2019 09:45:51 +0000 Subject: RFR [XS] : 8227247: tools/sjavac/IdleShutdown.java fails with AssertionError: Error too big on windows Message-ID: Hello, please review this small change to tools/sjavac/IdleShutdown.java . It allows higher timeout differences and gives a better error output . On Windows (especially on slower virtualized machines) the langtools test tools/sjavac/IdleShutdown.java shows sporadic failures. The error we see is : IdleShutdown.java: java.lang.AssertionError: Error too big Reason is that the "timeout error" is larger than the allowed error of 300 ms ( 3000 ms *0.1) : if (error > TIMEOUT_MS * .1) throw new AssertionError("Error too big"); We see sometimes errors in the range of 300-900 ms . For example : After 16166 ms: Timeout error: 609 ms Idea is to increase the allowed timeout error to make the test more stable. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8227247 http://cr.openjdk.java.net/~mbaesken/webrevs/8227247.0/webrev/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Fri Jul 5 16:09:21 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 5 Jul 2019 18:09:21 +0200 Subject: RFR [XS] : 8227247: tools/sjavac/IdleShutdown.java fails with AssertionError: Error too big on windows In-Reply-To: References: Message-ID: Hi Matthias, seems reasonable. Change looks good. Cheers, Thomas On Fri, Jul 5, 2019 at 5:58 PM Baesken, Matthias wrote: > Hello, > > please review this small change to tools/sjavac/IdleShutdown.java . > > It allows higher timeout differences and gives a better error output . > > > > > > On Windows (especially on slower virtualized machines) the langtools test > tools/sjavac/IdleShutdown.java shows sporadic failures. > The error we see is : > IdleShutdown.java: java.lang.AssertionError: Error too big > > Reason is that the "timeout error" is larger than the allowed error of 300 > ms ( 3000 ms *0.1) : > > if (error > TIMEOUT_MS * .1) > throw new AssertionError("Error too big"); > > We see sometimes errors in the range of 300-900 ms . > For example : > > After 16166 ms: Timeout error: 609 ms > > Idea is to increase the allowed timeout error to make the test more stable. > > > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8227247 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8227247.0/webrev/ > > > > > > Thanks, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Mon Jul 8 07:07:00 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 8 Jul 2019 07:07:00 +0000 Subject: RFR [XS] : 8227247: tools/sjavac/IdleShutdown.java fails with AssertionError: Error too big on windows In-Reply-To: References: Message-ID: Thanks Thomas for looking into it ! Any (other) opinions on this from the compiler (sjavac?) developers ? Best regards, Matthias From: Thomas St?fe Sent: Freitag, 5. Juli 2019 18:09 To: Baesken, Matthias Cc: compiler-dev at openjdk.java.net Subject: Re: RFR [XS] : 8227247: tools/sjavac/IdleShutdown.java fails with AssertionError: Error too big on windows Hi Matthias, seems reasonable. Change looks good. Cheers, Thomas On Fri, Jul 5, 2019 at 5:58 PM Baesken, Matthias > wrote: Hello, please review this small change to tools/sjavac/IdleShutdown.java . It allows higher timeout differences and gives a better error output . On Windows (especially on slower virtualized machines) the langtools test tools/sjavac/IdleShutdown.java shows sporadic failures. The error we see is : IdleShutdown.java: java.lang.AssertionError: Error too big Reason is that the "timeout error" is larger than the allowed error of 300 ms ( 3000 ms *0.1) : if (error > TIMEOUT_MS * .1) throw new AssertionError("Error too big"); We see sometimes errors in the range of 300-900 ms . For example : After 16166 ms: Timeout error: 609 ms Idea is to increase the allowed timeout error to make the test more stable. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8227247 http://cr.openjdk.java.net/~mbaesken/webrevs/8227247.0/webrev/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Mon Jul 8 21:56:14 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 8 Jul 2019 14:56:14 -0700 Subject: RFR [XS] : 8227247: tools/sjavac/IdleShutdown.java fails with AssertionError: Error too big on windows In-Reply-To: References: Message-ID: <0de04a12-e7d1-988f-008c-57dbef16cb2c@oracle.com> Generally, the typical way to handle timeouts on slow machines is to use the jtreg "timeout factor" mechanism, which is a multiplicative factor that can be set from the command line.? This allows timeouts to be increased on slow machines without unduly increasing timeouts for all platforms. Within the test, the value is available in the `test.timeout.factor` system property. https://openjdk.java.net/jtreg/tag-spec.html#testvars -- Jon On 7/8/19 12:07 AM, Baesken, Matthias wrote: > > Thanks Thomas for looking into it ! > > Any (other) opinions on this from the compiler (sjavac?) developers ? > > Best regards, Matthias > > *From:*Thomas St?fe > *Sent:* Freitag, 5. Juli 2019 18:09 > *To:* Baesken, Matthias > *Cc:* compiler-dev at openjdk.java.net > *Subject:* Re: RFR [XS] : 8227247: tools/sjavac/IdleShutdown.java > fails with AssertionError: Error too big on windows > > Hi Matthias, > > seems reasonable. Change looks good. > > Cheers, Thomas > > On Fri, Jul 5, 2019 at 5:58 PM Baesken, Matthias > > wrote: > > Hello, > > ???please review this small change to? > tools/sjavac/IdleShutdown.java? . > > It? allows higher timeout differences and gives a better error > output . > > On Windows (especially on slower virtualized machines) the > langtools test tools/sjavac/IdleShutdown.java shows sporadic > failures. > The error we see is : > IdleShutdown.java: java.lang.AssertionError: Error too big > > Reason is that the "timeout error" is larger than the allowed > error of 300 ms ???( 3000 ms *0.1)? : > > ????????if (error > TIMEOUT_MS * .1) > ????????????throw new AssertionError("Error too big"); > > We see sometimes errors in the range of 300-900 ms . > For example : > > After 16166 ms: Timeout error: 609 ms > > Idea is to increase the allowed timeout error to make the test > more stable. > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8227247 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8227247.0/webrev/ > > Thanks, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janis at schoeck-netz.de Tue Jul 9 13:08:12 2019 From: janis at schoeck-netz.de (=?UTF-8?Q?Janis_Sch=c3=b6ck?=) Date: Tue, 9 Jul 2019 15:08:12 +0200 Subject: Null-safe navigation operator (and elvis operator) Message-ID: Hello compiler-dev List, I am trying to assert, whether my idea (which is not actually original it appears) is valuable for Java. Apparently kotlin already features the following (null safe navigation operator): // returns null if... // - foo() returns null, // - or if foo() is non-null, but bar() returns null, // - or if foo() and bar() are non-null, but baz() returns null. // vice versa, return value is non-null if and only if foo(), bar() and baz() are non-null foo()?.bar()?.baz() In that same context, if an expression would evaluate to null, but a primitive type is required, kotlin can fall back on a default, or evaluate an alternate expression. val name: String = maybe ?: "stranger" Independently of kotlin, I think null safe accessing seems to be a valuable language feature. Since I did not know kotlin had this when I started, I put it into a JEP/JSR format to collect feedback on. Since I am new to this list, maybe the primary question: Do I just write up the entire JEP-plain text here, or will this just bother people, as it is a lot of text, and probably will mess up bulked mails? Secondary question: Is this the correct list to write to, or is this better addressed at the amber-project list? Thank you in advance, Janis Sch?ck -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Tue Jul 9 14:54:25 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 9 Jul 2019 16:54:25 +0200 Subject: RFR: JDK-8220041: NullPointerException at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0 Message-ID: <87f9bef7-02c6-e7f4-2d6a-2eaf07126dc3@oracle.com> Hi, Consider code like: --- I lambdaCapture1(int i) { I r = switch (i) { default -> { String k = "D"; yield () -> k; //need to capture k here } }; return r; } interface I { public T t(); } --- "k" needs to be captured, but LambdaToMethod fails to recognize that, as the enclosing Frame is for a variable declaration, which does not check the definitions under the variable decl (since before switch expressions, this could not happen). This then eventually leads either to a compiler crash, or a failure at runtime. The proposed solution is to check local variables in the variables frame, to see if they should be captured or not. JBS: https://bugs.openjdk.java.net/browse/JDK-8220041 Webrev: http://cr.openjdk.java.net/~jlahoda/8220041/webrev.00/ How does this look? Thanks, Jan From maurizio.cimadamore at oracle.com Tue Jul 9 15:39:48 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Jul 2019 16:39:48 +0100 Subject: RFR: JDK-8220041: NullPointerException at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0 In-Reply-To: <87f9bef7-02c6-e7f4-2d6a-2eaf07126dc3@oracle.com> References: <87f9bef7-02c6-e7f4-2d6a-2eaf07126dc3@oracle.com> Message-ID: <4633b6a4-f813-bdc5-74f5-ed7004e3fc08@oracle.com> Looks good Maurizio On 09/07/2019 15:54, Jan Lahoda wrote: > Hi, > > Consider code like: > --- > ??? I lambdaCapture1(int i) { > ??????? I r = switch (i) { > ??????????? default -> { > ??????????????? String k = "D"; > ??????????????? yield () -> k; //need to capture k here > ??????????? } > ??????? }; > > ??????? return r; > ??? } > > ??? interface I { > ??????? public T t(); > ??? } > --- > > "k" needs to be captured, but LambdaToMethod fails to recognize that, > as the enclosing Frame is for a variable declaration, which does not > check the definitions under the variable decl (since before switch > expressions, this could not happen). This then eventually leads either > to a compiler crash, or a failure at runtime. The proposed solution is > to check local variables in the variables frame, to see if they should > be captured or not. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8220041 > Webrev: http://cr.openjdk.java.net/~jlahoda/8220041/webrev.00/ > > How does this look? > > Thanks, > ??? Jan From vicente.romero at oracle.com Tue Jul 9 16:06:01 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 9 Jul 2019 12:06:01 -0400 Subject: RFR: JDK-8220041: NullPointerException at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0 In-Reply-To: <87f9bef7-02c6-e7f4-2d6a-2eaf07126dc3@oracle.com> References: <87f9bef7-02c6-e7f4-2d6a-2eaf07126dc3@oracle.com> Message-ID: looks good, Vicente On 7/9/19 10:54 AM, Jan Lahoda wrote: > Hi, > > Consider code like: > --- > ??? I lambdaCapture1(int i) { > ??????? I r = switch (i) { > ??????????? default -> { > ??????????????? String k = "D"; > ??????????????? yield () -> k; //need to capture k here > ??????????? } > ??????? }; > > ??????? return r; > ??? } > > ??? interface I { > ??????? public T t(); > ??? } > --- > > "k" needs to be captured, but LambdaToMethod fails to recognize that, > as the enclosing Frame is for a variable declaration, which does not > check the definitions under the variable decl (since before switch > expressions, this could not happen). This then eventually leads either > to a compiler crash, or a failure at runtime. The proposed solution is > to check local variables in the variables frame, to see if they should > be captured or not. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8220041 > Webrev: http://cr.openjdk.java.net/~jlahoda/8220041/webrev.00/ > > How does this look? > > Thanks, > ??? Jan From joe.darcy at oracle.com Tue Jul 9 21:41:59 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 9 Jul 2019 14:41:59 -0700 Subject: Null-safe navigation operator (and elvis operator) In-Reply-To: References: Message-ID: <5556e1b1-6610-36b7-0e42-c826aebcc9cf@oracle.com> Hello Janis, We've been aware of the null safe navigator operator, sometimes referred to as the Elvis operator, no later than the Project Coin call for proposals back in February 2009: https://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000047.html To date, we have chosen not to pursue this change. Cheers, -Joe On 7/9/2019 6:08 AM, Janis Sch?ck wrote: > > Hello compiler-dev List, > > I am trying to assert, whether my idea (which is not actually original > it appears) is valuable for Java. > Apparently kotlin already features the following (null safe navigation > operator): > > // returns null if... > // - foo() returns null, > // - or if foo() is non-null, but bar() returns null, > // - or if foo() and bar() are non-null, but baz() returns null. > // vice versa, return value is non-null if and only if foo(), bar() > and baz() are non-null > foo()?.bar()?.baz() > > In that same context, if an expression would evaluate to null, but a > primitive type is required, kotlin can > fall back on a default, or evaluate an alternate expression. > > val name: String = maybe ?: "stranger" > > Independently of kotlin, I think null safe accessing seems to be a > valuable language feature. Since I did not > know kotlin had this when I started, I put it into a JEP/JSR format to > collect feedback on. Since I am new to > this list, maybe the primary question: Do I just write up the entire > JEP-plain text here, or will this just bother > people, as it is a lot of text, and probably will mess up bulked mails? > > Secondary question: Is this the correct list to write to, or is this > better addressed at the amber-project list? > > Thank you in advance, > Janis Sch?ck > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Wed Jul 10 12:19:55 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 10 Jul 2019 14:19:55 +0200 (CEST) Subject: Null-safe navigation operator (and elvis operator) In-Reply-To: <5556e1b1-6610-36b7-0e42-c826aebcc9cf@oracle.com> References: <5556e1b1-6610-36b7-0e42-c826aebcc9cf@oracle.com> Message-ID: <576857240.1016870.1562761195234.JavaMail.zimbra@u-pem.fr> To complement what Joe said, Java has chosen to provides a library solution, java.util.Optional, instead of a new language construct. so if each of foo(), bar() and baz returns an Optional, you can write: foo().flatMap(Main::bar).flatMap(Main::baz) The elvis operator works great in a language that tracks nullability like in Kotlin, because if you fail to take care of the possible null, the compiler emits an error. The Java type system doesn't track null, introducing the elvis operator will only creates more NPE because the compiler will not fail if you don't use the elvis operator when needed. That why we have chosen Optional, because it forces you to deal with the fact that the result may not exist. The major drawback of Optional is that people are using it not only as a return type but as a type of a field or in a List, a Map, etc, where it makes no sense but that's another story :) regards, R?mi > De: "joe darcy" > ?: "Janis Sch?ck" , "compiler-dev" > > Envoy?: Mardi 9 Juillet 2019 23:41:59 > Objet: Re: Null-safe navigation operator (and elvis operator) > Hello Janis, > We've been aware of the null safe navigator operator, sometimes referred to as > the Elvis operator, no later than the Project Coin call for proposals back in > February 2009: > [ https://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000047.html | > https://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000047.html ] > To date, we have chosen not to pursue this change. > Cheers, > -Joe > On 7/9/2019 6:08 AM, Janis Sch?ck wrote: >> Hello compiler-dev List, >> I am trying to assert, whether my idea (which is not actually original it >> appears) is valuable for Java. >> Apparently kotlin already features the following (null safe navigation >> operator): >> // returns null if... // - foo() returns null, // - or if foo() is non-null, but >> bar() returns null, // - or if foo() and bar() are non-null, but baz() returns >> null. // vice versa, return value is non-null if and only if foo(), bar() and >> baz() are non-null foo () ?. bar () ?. baz () >> In that same context, if an expression would evaluate to null, but a primitive >> type is required, kotlin can >> fall back on a default, or evaluate an alternate expression. >> val name : String = maybe ?: "stranger" >> Independently of kotlin, I think null safe accessing seems to be a valuable >> language feature. Since I did not >> know kotlin had this when I started, I put it into a JEP/JSR format to collect >> feedback on. Since I am new to >> this list, maybe the primary question: Do I just write up the entire JEP-plain >> text here, or will this just bother >> people, as it is a lot of text, and probably will mess up bulked mails? >> Secondary question: Is this the correct list to write to, or is this better >> addressed at the amber-project list? >> Thank you in advance, >> Janis Sch?ck -------------- next part -------------- An HTML attachment was scrubbed... URL: From akarnokd at gmail.com Fri Jul 12 08:30:26 2019 From: akarnokd at gmail.com (=?UTF-8?Q?D=C3=A1vid_Karnok?=) Date: Fri, 12 Jul 2019 10:30:26 +0200 Subject: Switch statement in source results in type$1.class being generated? Message-ID: Hi. As part of the outreach program, I'm testing the various JDK early access builds with the library RxJava. Now that I can test JDK 13 and JDK 14 by setting a version target in my IDE, I've come across a strange compiler output not encountered with JDK 12 and prior versions. Note that RxJava's source code uses Java 6 constructs only. One of the rules for RxJava development is that there should be no anonymous inner classes used as it makes analyzing stacktraces with all those $12.class difficult. When the project is compiled, we check for the existence of such type$x.class output and fail the build if found. This worked well up until JDK 12, but now JDK 13 and JDK 14 early accesses generate a couple of such $1.class files. As far as I can tell, they are due to switch statements, for example: https://github.com/akarnokd/RxJava3_BuildMatrix/blob/master/src/main/java/io/reactivex/Observable.java#L14379 switch (strategy) { case DROP: return f.onBackpressureDrop(); case LATEST: return f.onBackpressureLatest(); case MISSING: return f; case ERROR: return RxJavaPlugins.onAssembly(new FlowableOnBackpressureError(f)); default: return f.onBackpressureBuffer(); } Creates Observable$1.class: javap Observable$1.class Compiled from "Observable.java" class io.reactivex.Observable$1 { static final int[] $SwitchMap$io$reactivex$BackpressureStrategy; static {}; } Is this some kind of expected new artifact? -- Best regards, David Karnok -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Jul 12 14:26:03 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 12 Jul 2019 15:26:03 +0100 Subject: Switch statement in source results in type$1.class being generated? In-Reply-To: References: Message-ID: <9481ecc2-789d-c609-defb-71fe537db4ff@oracle.com> Hi David, javac has been generating 'switchmap' classes for enum switched since JDK 5, I believe. This example: enum Foo { A, B; } class TestSwitch { ?? int m(Foo foo) { ????? switch (foo) { ???????? case A: return 1; ???????? case B: return 2; ???????? default: return -1; ????? } ?? } } Generates the following classes: Foo.class TestSwitch.class TestSwitch$1.class Where TestSwitch$1.class is similar to the one you have shown. I can see this even on JDK 8. So, I think you might have found a real issue - but I'm not sure that this specific synthetic class is the root cause of your problem, as this class has been there for a long time. Maurizio On 12/07/2019 09:30, D?vid Karnok wrote: > Hi. > > As part of the outreach program, I'm testing the various JDK early > access builds with the library RxJava. Now that I can test JDK 13 and > JDK 14 by setting a version target in my IDE, I've come across a > strange compiler output not encountered with JDK 12 and prior > versions. Note that RxJava's source code uses Java 6 constructs only. > > One of the rules for RxJava development is that there should be no > anonymous inner classes used as it makes analyzing stacktraces with > all those $12.class difficult. When the project is compiled, we check > for the existence of such type$x.class output and fail the build if > found. This worked well up until JDK 12, but now JDK 13 and JDK 14 > early accesses generate a couple of such $1.class files. As far as I > can tell, they are due to switch statements, for example: > > https://github.com/akarnokd/RxJava3_BuildMatrix/blob/master/src/main/java/io/reactivex/Observable.java#L14379 > > > ? ? switch (strategy) { > ? ? ? case DROP: > ? ? ? ? return f.onBackpressureDrop(); > ??? ??case LATEST: > ? ??? ??return f.onBackpressureLatest(); > ??? ??case MISSING: > ? ??? ??return f; > ??? ??case ERROR: > ? ?? ???return RxJavaPlugins.onAssembly(new > FlowableOnBackpressureError(f)); > ??? ??default: > ? ??? ??return f.onBackpressureBuffer(); > ? ? } > > Creates Observable$1.class: > > ? ? javap Observable$1.class > > ? ? Compiled from "Observable.java" > ? ??? class io.reactivex.Observable$1 { > ??? ??static final int[] $SwitchMap$io$reactivex$BackpressureStrategy; > ??? ??static {}; > ? ? } > > Is this some kind of expected new artifact? > > -- > Best regards, > David Karnok -------------- next part -------------- An HTML attachment was scrubbed... URL: From akarnokd at gmail.com Fri Jul 12 17:17:01 2019 From: akarnokd at gmail.com (=?UTF-8?Q?D=C3=A1vid_Karnok?=) Date: Fri, 12 Jul 2019 19:17:01 +0200 Subject: Switch statement in source results in type$1.class being generated? In-Reply-To: <9481ecc2-789d-c609-defb-71fe537db4ff@oracle.com> References: <9481ecc2-789d-c609-defb-71fe537db4ff@oracle.com> Message-ID: Hi Maurizio! Thanks for the clarification. I think I have some explanation why this happened. By default, I develop RxJava in Eclipse and eclipsec does not generate this file, hence the test was never tripped. I've been verifying JDKs with IntelliJ and up until 2019.1.3, the test wasn't tripped either because the compiled test classes go into separate directory than the main classes and the file was naturally not there. With 2019.2, something changed with the compilation and/or output settings and now the test could see this $1.class and failed. In other words, a bug in the test met with a glitch/bug in the IDE made the test work as intended. Maurizio Cimadamore ezt ?rta (id?pont: 2019. j?l. 12., P, 16:26): > Hi David, > javac has been generating 'switchmap' classes for enum switched since JDK > 5, I believe. > > This example: > > enum Foo { A, B; } > > class TestSwitch { > int m(Foo foo) { > switch (foo) { > case A: return 1; > case B: return 2; > default: return -1; > } > } > } > > Generates the following classes: > > Foo.class > TestSwitch.class > TestSwitch$1.class > > Where TestSwitch$1.class is similar to the one you have shown. I can see > this even on JDK 8. > > So, I think you might have found a real issue - but I'm not sure that this > specific synthetic class is the root cause of your problem, as this class > has been there for a long time. > > Maurizio > On 12/07/2019 09:30, D?vid Karnok wrote: > > Hi. > > As part of the outreach program, I'm testing the various JDK early access > builds with the library RxJava. Now that I can test JDK 13 and JDK 14 by > setting a version target in my IDE, I've come across a strange compiler > output not encountered with JDK 12 and prior versions. Note that RxJava's > source code uses Java 6 constructs only. > > One of the rules for RxJava development is that there should be no > anonymous inner classes used as it makes analyzing stacktraces with all > those $12.class difficult. When the project is compiled, we check for the > existence of such type$x.class output and fail the build if found. This > worked well up until JDK 12, but now JDK 13 and JDK 14 early accesses > generate a couple of such $1.class files. As far as I can tell, they are > due to switch statements, for example: > > > https://github.com/akarnokd/RxJava3_BuildMatrix/blob/master/src/main/java/io/reactivex/Observable.java#L14379 > > > switch (strategy) { > case DROP: > return f.onBackpressureDrop(); > case LATEST: > return f.onBackpressureLatest(); > case MISSING: > return f; > case ERROR: > return RxJavaPlugins.onAssembly(new > FlowableOnBackpressureError(f)); > default: > return f.onBackpressureBuffer(); > } > > Creates Observable$1.class: > > javap Observable$1.class > > Compiled from "Observable.java" > class io.reactivex.Observable$1 { > static final int[] $SwitchMap$io$reactivex$BackpressureStrategy; > static {}; > } > > Is this some kind of expected new artifact? > > -- > Best regards, > David Karnok > > -- Best regards, David Karnok -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Jul 12 17:23:44 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 12 Jul 2019 18:23:44 +0100 Subject: Switch statement in source results in type$1.class being generated? In-Reply-To: References: <9481ecc2-789d-c609-defb-71fe537db4ff@oracle.com> Message-ID: <8fca33d8-3691-527f-fe70-de2ba279eb1b@oracle.com> On 12/07/2019 18:17, D?vid Karnok wrote: > Hi Maurizio! > > Thanks for the clarification. I think I have some explanation why this > happened. By default, I develop RxJava in Eclipse and eclipsec does > not generate this file, hence the test was never tripped. I've been > verifying JDKs with IntelliJ and up until 2019.1.3, the test wasn't > tripped either because the compiled test classes go into separate > directory than the main classes and the file was naturally not there. > With 2019.2, something changed with the compilation and/or output > settings and now the test could see this $1.class and failed. > Btw - these classes have the ACC_SYNTHETHIC? flag set - so I guess it should be possible for your build system to be made more robust and skip those? After all, if I understand correctly, you want to catch cases where the library itself is using anon inner classes - and you probably want to skip whatever helper class compiler XYZ will have generated, right? Maurizio > In other words, a bug in the test met with a glitch/bug in the IDE > made the test work as intended. > > Maurizio Cimadamore > ezt ?rta (id?pont: 2019. j?l. > 12., P, 16:26): > > Hi David, > javac has been generating 'switchmap' classes for enum switched > since JDK 5, I believe. > > This example: > > enum Foo { A, B; } > > class TestSwitch { > ?? int m(Foo foo) { > ????? switch (foo) { > ???????? case A: return 1; > ???????? case B: return 2; > ???????? default: return -1; > ????? } > ?? } > } > > Generates the following classes: > > Foo.class > TestSwitch.class > TestSwitch$1.class > > Where TestSwitch$1.class is similar to the one you have shown. I > can see this even on JDK 8. > > So, I think you might have found a real issue - but I'm not sure > that this specific synthetic class is the root cause of your > problem, as this class has been there for a long time. > > Maurizio > > On 12/07/2019 09:30, D?vid Karnok wrote: >> Hi. >> >> As part of the outreach program, I'm testing the various JDK >> early access builds with the library RxJava. Now that I can test >> JDK 13 and JDK 14 by setting a version target in my IDE, I've >> come across a strange compiler output not encountered with JDK 12 >> and prior versions. Note that RxJava's source code uses Java 6 >> constructs only. >> >> One of the rules for RxJava development is that there should be >> no anonymous inner classes used as it makes analyzing stacktraces >> with all those $12.class difficult. When the project is compiled, >> we check for the existence of such type$x.class output and fail >> the build if found. This worked well up until JDK 12, but now JDK >> 13 and JDK 14 early accesses generate a couple of such $1.class >> files. As far as I can tell, they are due to switch statements, >> for example: >> >> https://github.com/akarnokd/RxJava3_BuildMatrix/blob/master/src/main/java/io/reactivex/Observable.java#L14379 >> >> >> ? ? switch (strategy) { >> ? ? ? case DROP: >> ? ? ? ? return f.onBackpressureDrop(); >> ??? ??case LATEST: >> ? ??? ??return f.onBackpressureLatest(); >> ??? ??case MISSING: >> ? ??? ??return f; >> ??? ??case ERROR: >> ? ?? ???return RxJavaPlugins.onAssembly(new >> FlowableOnBackpressureError(f)); >> ??? ??default: >> ? ??? ??return f.onBackpressureBuffer(); >> ? ? } >> >> Creates Observable$1.class: >> >> ? ? javap Observable$1.class >> >> ? ? Compiled from "Observable.java" >> ? ??? class io.reactivex.Observable$1 { >> ??? ??static final int[] >> $SwitchMap$io$reactivex$BackpressureStrategy; >> ??? ??static {}; >> ? ? } >> >> Is this some kind of expected new artifact? >> >> -- >> Best regards, >> David Karnok > > > > -- > Best regards, > David Karnok -------------- next part -------------- An HTML attachment was scrubbed... URL: From akarnokd at gmail.com Fri Jul 12 17:37:56 2019 From: akarnokd at gmail.com (=?UTF-8?Q?D=C3=A1vid_Karnok?=) Date: Fri, 12 Jul 2019 19:37:56 +0200 Subject: Switch statement in source results in type$1.class being generated? In-Reply-To: <8fca33d8-3691-527f-fe70-de2ba279eb1b@oracle.com> References: <9481ecc2-789d-c609-defb-71fe537db4ff@oracle.com> <8fca33d8-3691-527f-fe70-de2ba279eb1b@oracle.com> Message-ID: Yes, that would be great. However, I seems to me I have to parse the class file and skip the constant pool to get to the access flags, right? Some upcoming JDK changes are planning to change that pool around, don't they? My current workaround is to simply scan the file for $SwitchMap$ and double check there is no $1$1.class, assuming such switchmap classes don't have more synthetic helper classes themselves. Maurizio Cimadamore ezt ?rta (id?pont: 2019. j?l. 12., P, 19:23): > > On 12/07/2019 18:17, D?vid Karnok wrote: > > Hi Maurizio! > > Thanks for the clarification. I think I have some explanation why this > happened. By default, I develop RxJava in Eclipse and eclipsec does not > generate this file, hence the test was never tripped. I've been verifying > JDKs with IntelliJ and up until 2019.1.3, the test wasn't tripped either > because the compiled test classes go into separate directory than the main > classes and the file was naturally not there. With 2019.2, something > changed with the compilation and/or output settings and now the test could > see this $1.class and failed. > > Btw - these classes have the ACC_SYNTHETHIC flag set - so I guess it > should be possible for your build system to be made more robust and skip > those? After all, if I understand correctly, you want to catch cases where > the library itself is using anon inner classes - and you probably want to > skip whatever helper class compiler XYZ will have generated, right? > > Maurizio > > In other words, a bug in the test met with a glitch/bug in the IDE made > the test work as intended. > > Maurizio Cimadamore ezt ?rta (id?pont: > 2019. j?l. 12., P, 16:26): > >> Hi David, >> javac has been generating 'switchmap' classes for enum switched since JDK >> 5, I believe. >> >> This example: >> >> enum Foo { A, B; } >> >> class TestSwitch { >> int m(Foo foo) { >> switch (foo) { >> case A: return 1; >> case B: return 2; >> default: return -1; >> } >> } >> } >> >> Generates the following classes: >> >> Foo.class >> TestSwitch.class >> TestSwitch$1.class >> >> Where TestSwitch$1.class is similar to the one you have shown. I can see >> this even on JDK 8. >> >> So, I think you might have found a real issue - but I'm not sure that >> this specific synthetic class is the root cause of your problem, as this >> class has been there for a long time. >> >> Maurizio >> On 12/07/2019 09:30, D?vid Karnok wrote: >> >> Hi. >> >> As part of the outreach program, I'm testing the various JDK early access >> builds with the library RxJava. Now that I can test JDK 13 and JDK 14 by >> setting a version target in my IDE, I've come across a strange compiler >> output not encountered with JDK 12 and prior versions. Note that RxJava's >> source code uses Java 6 constructs only. >> >> One of the rules for RxJava development is that there should be no >> anonymous inner classes used as it makes analyzing stacktraces with all >> those $12.class difficult. When the project is compiled, we check for the >> existence of such type$x.class output and fail the build if found. This >> worked well up until JDK 12, but now JDK 13 and JDK 14 early accesses >> generate a couple of such $1.class files. As far as I can tell, they are >> due to switch statements, for example: >> >> >> https://github.com/akarnokd/RxJava3_BuildMatrix/blob/master/src/main/java/io/reactivex/Observable.java#L14379 >> >> >> switch (strategy) { >> case DROP: >> return f.onBackpressureDrop(); >> case LATEST: >> return f.onBackpressureLatest(); >> case MISSING: >> return f; >> case ERROR: >> return RxJavaPlugins.onAssembly(new >> FlowableOnBackpressureError(f)); >> default: >> return f.onBackpressureBuffer(); >> } >> >> Creates Observable$1.class: >> >> javap Observable$1.class >> >> Compiled from "Observable.java" >> class io.reactivex.Observable$1 { >> static final int[] $SwitchMap$io$reactivex$BackpressureStrategy; >> static {}; >> } >> >> Is this some kind of expected new artifact? >> >> -- >> Best regards, >> David Karnok >> >> > > -- > Best regards, > David Karnok > > -- Best regards, David Karnok -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Jul 12 17:50:20 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 12 Jul 2019 18:50:20 +0100 Subject: Switch statement in source results in type$1.class being generated? In-Reply-To: References: <9481ecc2-789d-c609-defb-71fe537db4ff@oracle.com> <8fca33d8-3691-527f-fe70-de2ba279eb1b@oracle.com> Message-ID: <268509c9-a6a5-e54c-7e50-5e4430d251f6@oracle.com> Yes, the flags are after the constant pool. Project Valhalla will likely add some new pool entries, but that doesn't really matter, as the classfile has the pool size, so you can just skip past the entire thing. That is: skip 4 bytes (magic) skip 2 bytes (minor version) skip 2 bytes (major version) u2 count = skip count u2 flags = This should be fairly straightforward to implement, and it's stable unless we throw the current classfile format out of the window - which I frankly don't see happening :-) Note that javac generates these anon class for various reasons, not just for enum constants, so if you hardwire some $SwitchMap$ detection, be prepared for the code to fail in other places - also we are planning some revamp to the switch translation strategy (in preparation for pattern matching) so these names are really not going to be stable for much longer. Maurizio On 12/07/2019 18:37, D?vid Karnok wrote: > Yes, that would be great.?However, I seems to me I have to parse the > class file and skip the constant pool to get to the access flags, > right? Some upcoming JDK changes are planning to change that pool > around, don't they? My current workaround is to simply scan the file > for $SwitchMap$ and double check there is no $1$1.class, assuming such > switchmap classes don't have more synthetic helper classes themselves. > > Maurizio Cimadamore > ezt ?rta (id?pont: 2019. j?l. > 12., P, 19:23): > > > On 12/07/2019 18:17, D?vid Karnok wrote: >> Hi Maurizio! >> >> Thanks for the clarification. I think I have some explanation why >> this happened. By default, I develop RxJava in Eclipse and >> eclipsec does not generate this file, hence the test was never >> tripped. I've been verifying JDKs with IntelliJ and up until >> 2019.1.3, the test wasn't tripped either because the compiled >> test classes go into separate directory than the main classes and >> the file was naturally not there. With 2019.2, something changed >> with the compilation and/or output settings and now the test >> could see this $1.class and failed. >> > Btw - these classes have the ACC_SYNTHETHIC? flag set - so I guess > it should be possible for your build system to be made more robust > and skip those? After all, if I understand correctly, you want to > catch cases where the library itself is using anon inner classes - > and you probably want to skip whatever helper class compiler XYZ > will have generated, right? > > Maurizio > >> In other words, a bug in the test met with a glitch/bug in the >> IDE made the test work as intended. >> >> Maurizio Cimadamore > > ezt ?rta (id?pont: 2019. >> j?l. 12., P, 16:26): >> >> Hi David, >> javac has been generating 'switchmap' classes for enum >> switched since JDK 5, I believe. >> >> This example: >> >> enum Foo { A, B; } >> >> class TestSwitch { >> ?? int m(Foo foo) { >> ????? switch (foo) { >> ???????? case A: return 1; >> ???????? case B: return 2; >> ???????? default: return -1; >> ????? } >> ?? } >> } >> >> Generates the following classes: >> >> Foo.class >> TestSwitch.class >> TestSwitch$1.class >> >> Where TestSwitch$1.class is similar to the one you have >> shown. I can see this even on JDK 8. >> >> So, I think you might have found a real issue - but I'm not >> sure that this specific synthetic class is the root cause of >> your problem, as this class has been there for a long time. >> >> Maurizio >> >> On 12/07/2019 09:30, D?vid Karnok wrote: >>> Hi. >>> >>> As part of the outreach program, I'm testing the various JDK >>> early access builds with the library RxJava. Now that I can >>> test JDK 13 and JDK 14 by setting a version target in my >>> IDE, I've come across a strange compiler output not >>> encountered with JDK 12 and prior versions. Note that >>> RxJava's source code uses Java 6 constructs only. >>> >>> One of the rules for RxJava development is that there should >>> be no anonymous inner classes used as it makes analyzing >>> stacktraces with all those $12.class difficult. When the >>> project is compiled, we check for the existence of such >>> type$x.class output and fail the build if found. This worked >>> well up until JDK 12, but now JDK 13 and JDK 14 early >>> accesses generate a couple of such $1.class files. As far as >>> I can tell, they are due to switch statements, for example: >>> >>> https://github.com/akarnokd/RxJava3_BuildMatrix/blob/master/src/main/java/io/reactivex/Observable.java#L14379 >>> >>> >>> ? ? switch (strategy) { >>> ? ? ? case DROP: >>> ? ? ? ? return f.onBackpressureDrop(); >>> ??? ??case LATEST: >>> ? ??? ??return f.onBackpressureLatest(); >>> ??? ??case MISSING: >>> ? ??? ??return f; >>> ??? ??case ERROR: >>> ? ?? ???return RxJavaPlugins.onAssembly(new >>> FlowableOnBackpressureError(f)); >>> ??? ??default: >>> ? ??? ??return f.onBackpressureBuffer(); >>> ? ? } >>> >>> Creates Observable$1.class: >>> >>> ? ? javap Observable$1.class >>> >>> ? ? Compiled from "Observable.java" >>> ? ??? class io.reactivex.Observable$1 { >>> ??? ??static final int[] >>> $SwitchMap$io$reactivex$BackpressureStrategy; >>> ??? ??static {}; >>> ? ? } >>> >>> Is this some kind of expected new artifact? >>> >>> -- >>> Best regards, >>> David Karnok >> >> >> >> -- >> Best regards, >> David Karnok > > > > -- > Best regards, > David Karnok -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Fri Jul 12 17:52:04 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 12 Jul 2019 19:52:04 +0200 (CEST) Subject: Switch statement in source results in type$1.class being generated? In-Reply-To: References: <9481ecc2-789d-c609-defb-71fe537db4ff@oracle.com> <8fca33d8-3691-527f-fe70-de2ba279eb1b@oracle.com> Message-ID: <809861893.2072156.1562953924314.JavaMail.zimbra@u-pem.fr> Hi Davis, > De: "D?vid Karnok" > ?: "Maurizio Cimadamore" > Cc: "compiler-dev" > Envoy?: Vendredi 12 Juillet 2019 19:37:56 > Objet: Re: Switch statement in source results in type$1.class being generated? > Yes, that would be great. However, I seems to me I have to parse the class file > and skip the constant pool to get to the access flags, right? yes ! > Some upcoming JDK changes are planning to change that pool around, don't they? no change is planned yet, the last change, the constant dynamic feature, was introduced by Java 11. The introduction of better generics as part of valhalla requires such changes but we are several years from that happens. > My current workaround is to simply scan the file for $SwitchMap$ and double > check there is no $1$1.class, assuming such switchmap classes don't have more > synthetic helper classes themselves. why not using ASM [1] instead of rolling your own code ? R?mi [1] https://asm.ow2.io/ > Maurizio Cimadamore < [ mailto:maurizio.cimadamore at oracle.com | > maurizio.cimadamore at oracle.com ] > ezt ?rta (id?pont: 2019. j?l. 12., P, > 19:23): >> On 12/07/2019 18:17, D?vid Karnok wrote: >>> Hi Maurizio! >>> Thanks for the clarification. I think I have some explanation why this happened. >>> By default, I develop RxJava in Eclipse and eclipsec does not generate this >>> file, hence the test was never tripped. I've been verifying JDKs with IntelliJ >>> and up until 2019.1.3, the test wasn't tripped either because the compiled test >>> classes go into separate directory than the main classes and the file was >>> naturally not there. With 2019.2, something changed with the compilation and/or >>> output settings and now the test could see this $1.class and failed. >> Btw - these classes have the ACC_SYNTHETHIC flag set - so I guess it should be >> possible for your build system to be made more robust and skip those? After >> all, if I understand correctly, you want to catch cases where the library >> itself is using anon inner classes - and you probably want to skip whatever >> helper class compiler XYZ will have generated, right? >> Maurizio >>> In other words, a bug in the test met with a glitch/bug in the IDE made the test >>> work as intended. >>> Maurizio Cimadamore < [ mailto:maurizio.cimadamore at oracle.com | >>> maurizio.cimadamore at oracle.com ] > ezt ?rta (id?pont: 2019. j?l. 12., P, >>> 16:26): >>>> Hi David, >>>> javac has been generating 'switchmap' classes for enum switched since JDK 5, I >>>> believe. >>>> This example: >>>> enum Foo { A, B; } >>>> class TestSwitch { >>>> int m(Foo foo) { >>>> switch (foo) { >>>> case A: return 1; >>>> case B: return 2; >>>> default: return -1; >>>> } >>>> } >>>> } >>>> Generates the following classes: >>>> Foo.class >>>> TestSwitch.class >>>> TestSwitch$1.class >>>> Where TestSwitch$1.class is similar to the one you have shown. I can see this >>>> even on JDK 8. >>>> So, I think you might have found a real issue - but I'm not sure that this >>>> specific synthetic class is the root cause of your problem, as this class has >>>> been there for a long time. >>>> Maurizio >>>> On 12/07/2019 09:30, D?vid Karnok wrote: >>>>> Hi. >>>>> As part of the outreach program, I'm testing the various JDK early access builds >>>>> with the library RxJava. Now that I can test JDK 13 and JDK 14 by setting a >>>>> version target in my IDE, I've come across a strange compiler output not >>>>> encountered with JDK 12 and prior versions. Note that RxJava's source code uses >>>>> Java 6 constructs only. >>>>> One of the rules for RxJava development is that there should be no anonymous >>>>> inner classes used as it makes analyzing stacktraces with all those $12.class >>>>> difficult. When the project is compiled, we check for the existence of such >>>>> type$x.class output and fail the build if found. This worked well up until JDK >>>>> 12, but now JDK 13 and JDK 14 early accesses generate a couple of such $1.class >>>>> files. As far as I can tell, they are due to switch statements, for example: >>>>> [ >>>>> https://github.com/akarnokd/RxJava3_BuildMatrix/blob/master/src/main/java/io/reactivex/Observable.java#L14379 >>>>> | >>>>> https://github.com/akarnokd/RxJava3_BuildMatrix/blob/master/src/main/java/io/reactivex/Observable.java#L14379 >>>>> ] >>>>> switch (strategy) { >>>>> case DROP: >>>>> return f.onBackpressureDrop(); >>>>> case LATEST: >>>>> return f.onBackpressureLatest(); >>>>> case MISSING: >>>>> return f; >>>>> case ERROR: >>>>> return RxJavaPlugins.onAssembly(new FlowableOnBackpressureError(f)); >>>>> default: >>>>> return f.onBackpressureBuffer(); >>>>> } >>>>> Creates Observable$1.class: >>>>> javap Observable$1.class >>>>> Compiled from "Observable.java" >>>>> class io.reactivex.Observable$1 { >>>>> static final int[] $SwitchMap$io$reactivex$BackpressureStrategy; >>>>> static {}; >>>>> } >>>>> Is this some kind of expected new artifact? >>>>> -- >>>>> Best regards, >>>>> David Karnok >>> -- >>> Best regards, >>> David Karnok > -- > Best regards, > David Karnok -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Jul 12 17:54:51 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 12 Jul 2019 18:54:51 +0100 Subject: Switch statement in source results in type$1.class being generated? In-Reply-To: <809861893.2072156.1562953924314.JavaMail.zimbra@u-pem.fr> References: <9481ecc2-789d-c609-defb-71fe537db4ff@oracle.com> <8fca33d8-3691-527f-fe70-de2ba279eb1b@oracle.com> <809861893.2072156.1562953924314.JavaMail.zimbra@u-pem.fr> Message-ID: <36ee0a70-bd1b-c9a7-3bb5-18da60653149@oracle.com> On 12/07/2019 18:52, Remi Forax wrote: > why not using ASM [1] instead of rolling your own code ? This is also a fine alternative. Another alternative would be to try to load the class with Class.forName and check the flags there. Maurizio From forax at univ-mlv.fr Fri Jul 12 18:02:14 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 12 Jul 2019 20:02:14 +0200 (CEST) Subject: Switch statement in source results in type$1.class being generated? In-Reply-To: <36ee0a70-bd1b-c9a7-3bb5-18da60653149@oracle.com> References: <9481ecc2-789d-c609-defb-71fe537db4ff@oracle.com> <8fca33d8-3691-527f-fe70-de2ba279eb1b@oracle.com> <809861893.2072156.1562953924314.JavaMail.zimbra@u-pem.fr> <36ee0a70-bd1b-c9a7-3bb5-18da60653149@oracle.com> Message-ID: <694708382.2072965.1562954534533.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Maurizio Cimadamore" > ?: "Remi Forax" , "D?vid Karnok" > Cc: "compiler-dev" > Envoy?: Vendredi 12 Juillet 2019 19:54:51 > Objet: Re: Switch statement in source results in type$1.class being generated? > On 12/07/2019 18:52, Remi Forax wrote: >> why not using ASM [1] instead of rolling your own code ? > > This is also a fine alternative. > > Another alternative would be to try to load the class with Class.forName > and check the flags there. using the Class.forName with 3 arguments to avoid nasty side effects due to the class being initialized. > > Maurizio R?mi From Pengfei.Li at arm.com Mon Jul 15 01:38:33 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Mon, 15 Jul 2019 01:38:33 +0000 Subject: RFR(trivial): 8227512: [TESTBUG] Fix JTReg javac test failures with Graal In-Reply-To: References: Message-ID: CC compiler-dev -- Thanks, Pengfei > Hi, > > Please help review this small fix. > JBS: https://bugs.openjdk.java.net/browse/JDK-8227512 > Webrev: http://cr.openjdk.java.net/~pli/rfr/8227512/ > > JTReg javac tests > * langtools/tools/javac/modules/InheritRuntimeEnvironmentTest.java > * langtools/tools/javac/file/LimitedImage.java > failed when Graal is used as JVMCI compiler. > > These cases test javac behavior with the condition that observable modules > are limited. But Graal is unable to be found in the limited module scope. This > fixes these two tests by adding "jdk.internal.vm.compiler" into the limited > modules. > > -- > Thanks, > Pengfei From Michael.Rasmussen at roguewave.com Mon Jul 15 12:56:42 2019 From: Michael.Rasmussen at roguewave.com (Michael Rasmussen) Date: Mon, 15 Jul 2019 12:56:42 +0000 Subject: Switch statement in source results in type$1.class being generated? In-Reply-To: References: <9481ecc2-789d-c609-defb-71fe537db4ff@oracle.com> <8fca33d8-3691-527f-fe70-de2ba279eb1b@oracle.com>, Message-ID: Just an FYI. the Eclipse Java compiler also created SwitchMap classes, but they are slightly different, and use a different naming pattern, they use $SWITCH_TABLE$ instead. /Michael ________________________________ From: compiler-dev on behalf of D?vid Karnok Sent: 12 July 2019 20:37:56 To: Maurizio Cimadamore Cc: compiler-dev at openjdk.java.net Subject: Re: Switch statement in source results in type$1.class being generated? Yes, that would be great. However, I seems to me I have to parse the class file and skip the constant pool to get to the access flags, right? Some upcoming JDK changes are planning to change that pool around, don't they? My current workaround is to simply scan the file for $SwitchMap$ and double check there is no $1$1.class, assuming such switchmap classes don't have more synthetic helper classes themselves. Maurizio Cimadamore > ezt ?rta (id?pont: 2019. j?l. 12., P, 19:23): On 12/07/2019 18:17, D?vid Karnok wrote: Hi Maurizio! Thanks for the clarification. I think I have some explanation why this happened. By default, I develop RxJava in Eclipse and eclipsec does not generate this file, hence the test was never tripped. I've been verifying JDKs with IntelliJ and up until 2019.1.3, the test wasn't tripped either because the compiled test classes go into separate directory than the main classes and the file was naturally not there. With 2019.2, something changed with the compilation and/or output settings and now the test could see this $1.class and failed. Btw - these classes have the ACC_SYNTHETHIC flag set - so I guess it should be possible for your build system to be made more robust and skip those? After all, if I understand correctly, you want to catch cases where the library itself is using anon inner classes - and you probably want to skip whatever helper class compiler XYZ will have generated, right? Maurizio In other words, a bug in the test met with a glitch/bug in the IDE made the test work as intended. Maurizio Cimadamore > ezt ?rta (id?pont: 2019. j?l. 12., P, 16:26): Hi David, javac has been generating 'switchmap' classes for enum switched since JDK 5, I believe. This example: enum Foo { A, B; } class TestSwitch { int m(Foo foo) { switch (foo) { case A: return 1; case B: return 2; default: return -1; } } } Generates the following classes: Foo.class TestSwitch.class TestSwitch$1.class Where TestSwitch$1.class is similar to the one you have shown. I can see this even on JDK 8. So, I think you might have found a real issue - but I'm not sure that this specific synthetic class is the root cause of your problem, as this class has been there for a long time. Maurizio On 12/07/2019 09:30, D?vid Karnok wrote: Hi. As part of the outreach program, I'm testing the various JDK early access builds with the library RxJava. Now that I can test JDK 13 and JDK 14 by setting a version target in my IDE, I've come across a strange compiler output not encountered with JDK 12 and prior versions. Note that RxJava's source code uses Java 6 constructs only. One of the rules for RxJava development is that there should be no anonymous inner classes used as it makes analyzing stacktraces with all those $12.class difficult. When the project is compiled, we check for the existence of such type$x.class output and fail the build if found. This worked well up until JDK 12, but now JDK 13 and JDK 14 early accesses generate a couple of such $1.class files. As far as I can tell, they are due to switch statements, for example: https://github.com/akarnokd/RxJava3_BuildMatrix/blob/master/src/main/java/io/reactivex/Observable.java#L14379 switch (strategy) { case DROP: return f.onBackpressureDrop(); case LATEST: return f.onBackpressureLatest(); case MISSING: return f; case ERROR: return RxJavaPlugins.onAssembly(new FlowableOnBackpressureError(f)); default: return f.onBackpressureBuffer(); } Creates Observable$1.class: javap Observable$1.class Compiled from "Observable.java" class io.reactivex.Observable$1 { static final int[] $SwitchMap$io$reactivex$BackpressureStrategy; static {}; } Is this some kind of expected new artifact? -- Best regards, David Karnok -- Best regards, David Karnok -- Best regards, David Karnok -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Jul 15 15:25:43 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 15 Jul 2019 16:25:43 +0100 Subject: RFR(trivial): 8227512: [TESTBUG] Fix JTReg javac test failures with Graal In-Reply-To: References: Message-ID: <808dfddf-1a5f-be51-4078-fccfac3f19f8@oracle.com> Looks good! Thanks Maurizio On 15/07/2019 02:38, Pengfei Li (Arm Technology China) wrote: > CC compiler-dev > > -- > Thanks, > Pengfei > >> Hi, >> >> Please help review this small fix. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8227512 >> Webrev: http://cr.openjdk.java.net/~pli/rfr/8227512/ >> >> JTReg javac tests >> * langtools/tools/javac/modules/InheritRuntimeEnvironmentTest.java >> * langtools/tools/javac/file/LimitedImage.java >> failed when Graal is used as JVMCI compiler. >> >> These cases test javac behavior with the condition that observable modules >> are limited. But Graal is unable to be found in the limited module scope. This >> fixes these two tests by adding "jdk.internal.vm.compiler" into the limited >> modules. >> >> -- >> Thanks, >> Pengfei From jan.lahoda at oracle.com Mon Jul 15 16:05:16 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 15 Jul 2019 18:05:16 +0200 Subject: RFR: JDK-8227640: javac crashes on text blocks with invalid escapes. Message-ID: <73ed5a36-285a-a3e3-426f-2a537d1c4688@oracle.com> Hi, When a text block contains an invalid escape sequence, there is an internal IllegalArgumentException thrown from String.translateEscapes invoked from javac. While this is concealed by javac, there are still ways to see the effects of the exception. So, I'd like to propose avoid calling String.translateEscapes when there are invalid escape sequences (errors for these invalid sequences are already reported). JBS: https://bugs.openjdk.java.net/browse/JDK-8227640 Webrev: http://cr.openjdk.java.net/~jlahoda/8227640/webrev.00/ How does this look? Thanks, Jan From james.laskey at oracle.com Mon Jul 15 16:26:45 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 15 Jul 2019 13:26:45 -0300 Subject: RFR: JDK-8227640: javac crashes on text blocks with invalid escapes. In-Reply-To: <73ed5a36-285a-a3e3-426f-2a537d1c4688@oracle.com> References: <73ed5a36-285a-a3e3-426f-2a537d1c4688@oracle.com> Message-ID: <61366EC6-A126-4521-87B6-6F318E20943F@oracle.com> +1 Upped to P2. Likely too late for 13. > On Jul 15, 2019, at 1:05 PM, Jan Lahoda wrote: > > Hi, > > When a text block contains an invalid escape sequence, there is an internal IllegalArgumentException thrown from String.translateEscapes invoked from javac. While this is concealed by javac, there are still ways to see the effects of the exception. So, I'd like to propose avoid calling String.translateEscapes when there are invalid escape sequences (errors for these invalid sequences are already reported). > > JBS: https://bugs.openjdk.java.net/browse/JDK-8227640 > Webrev: http://cr.openjdk.java.net/~jlahoda/8227640/webrev.00/ > > How does this look? > > Thanks, > Jan From james.laskey at oracle.com Mon Jul 15 16:29:03 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 15 Jul 2019 13:29:03 -0300 Subject: RFR: JDK-8227640: javac crashes on text blocks with invalid escapes. In-Reply-To: <73ed5a36-285a-a3e3-426f-2a537d1c4688@oracle.com> References: <73ed5a36-285a-a3e3-426f-2a537d1c4688@oracle.com> Message-ID: Actually, one problem, should break from the token loop when the error is encountered, otherwise it's a change in behaviour. > On Jul 15, 2019, at 1:05 PM, Jan Lahoda wrote: > > Hi, > > When a text block contains an invalid escape sequence, there is an internal IllegalArgumentException thrown from String.translateEscapes invoked from javac. While this is concealed by javac, there are still ways to see the effects of the exception. So, I'd like to propose avoid calling String.translateEscapes when there are invalid escape sequences (errors for these invalid sequences are already reported). > > JBS: https://bugs.openjdk.java.net/browse/JDK-8227640 > Webrev: http://cr.openjdk.java.net/~jlahoda/8227640/webrev.00/ > > How does this look? > > Thanks, > Jan From jan.lahoda at oracle.com Mon Jul 15 19:00:06 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 15 Jul 2019 21:00:06 +0200 Subject: RFR: JDK-8227640: javac crashes on text blocks with invalid escapes. In-Reply-To: References: <73ed5a36-285a-a3e3-426f-2a537d1c4688@oracle.com> Message-ID: <0ef7987a-56d7-f328-b4b0-1b17a8a8bc62@oracle.com> On 15. 07. 19 18:29, Jim Laskey wrote: > Actually, one problem, should break from the token loop when the error is encountered, otherwise it's a change in behaviour. Sorry, I am not sure I follow - if there are multiple illegal escapes in the literal, javac used to produce an error for each of them: (JDK 8): --- $ javac IllegalEscapes.java IllegalEscapes.java:2: error: illegal escape character private static final String s1 = "\!\!\!"; ^ IllegalEscapes.java:2: error: illegal escape character private static final String s1 = "\!\!\!"; ^ IllegalEscapes.java:2: error: illegal escape character private static final String s1 = "\!\!\!"; ^ 3 errors --- With this patch, it does the same: --- $ javac IllegalEscapes.java IllegalEscapes.java:2: error: illegal escape character private static final String s1 = "\!\!\!"; ^ IllegalEscapes.java:2: error: illegal escape character private static final String s1 = "\!\!\!"; ^ IllegalEscapes.java:2: error: illegal escape character private static final String s1 = "\!\!\!"; ^ 3 errors --- This is because the conversion is happening after the literal is fully scanned. Thanks, Jan IllegalEscapes.java: --- public class IllegalEscapes { private static final String s1 = "\!\!\!"; } --- > > >> On Jul 15, 2019, at 1:05 PM, Jan Lahoda wrote: >> >> Hi, >> >> When a text block contains an invalid escape sequence, there is an internal IllegalArgumentException thrown from String.translateEscapes invoked from javac. While this is concealed by javac, there are still ways to see the effects of the exception. So, I'd like to propose avoid calling String.translateEscapes when there are invalid escape sequences (errors for these invalid sequences are already reported). >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8227640 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8227640/webrev.00/ >> >> How does this look? >> >> Thanks, >> Jan > From james.laskey at oracle.com Mon Jul 15 19:07:03 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 15 Jul 2019 16:07:03 -0300 Subject: RFR: JDK-8227640: javac crashes on text blocks with invalid escapes. In-Reply-To: <0ef7987a-56d7-f328-b4b0-1b17a8a8bc62@oracle.com> References: <73ed5a36-285a-a3e3-426f-2a537d1c4688@oracle.com> <0ef7987a-56d7-f328-b4b0-1b17a8a8bc62@oracle.com> Message-ID: Okay, I mis-remembered. Thank you. +1. > On Jul 15, 2019, at 4:00 PM, Jan Lahoda wrote: > > On 15. 07. 19 18:29, Jim Laskey wrote: >> Actually, one problem, should break from the token loop when the error is encountered, otherwise it's a change in behaviour. > > Sorry, I am not sure I follow - if there are multiple illegal escapes in the literal, javac used to produce an error for each of them: > (JDK 8): > --- > $ javac IllegalEscapes.java > IllegalEscapes.java:2: error: illegal escape character > private static final String s1 = "\!\!\!"; > ^ > IllegalEscapes.java:2: error: illegal escape character > private static final String s1 = "\!\!\!"; > ^ > IllegalEscapes.java:2: error: illegal escape character > private static final String s1 = "\!\!\!"; > ^ > 3 errors > --- > > With this patch, it does the same: > --- > $ javac IllegalEscapes.java > IllegalEscapes.java:2: error: illegal escape character > private static final String s1 = "\!\!\!"; > ^ > IllegalEscapes.java:2: error: illegal escape character > private static final String s1 = "\!\!\!"; > ^ > IllegalEscapes.java:2: error: illegal escape character > private static final String s1 = "\!\!\!"; > ^ > 3 errors > --- > > This is because the conversion is happening after the literal is fully scanned. > > Thanks, > Jan > > IllegalEscapes.java: > --- > public class IllegalEscapes { > private static final String s1 = "\!\!\!"; > } > --- > >>> On Jul 15, 2019, at 1:05 PM, Jan Lahoda wrote: >>> >>> Hi, >>> >>> When a text block contains an invalid escape sequence, there is an internal IllegalArgumentException thrown from String.translateEscapes invoked from javac. While this is concealed by javac, there are still ways to see the effects of the exception. So, I'd like to propose avoid calling String.translateEscapes when there are invalid escape sequences (errors for these invalid sequences are already reported). >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8227640 >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8227640/webrev.00/ >>> >>> How does this look? >>> >>> Thanks, >>> Jan From alex.buckley at oracle.com Tue Jul 16 23:14:15 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 16 Jul 2019 16:14:15 -0700 Subject: Aligning compiler messages for using preview API with preview language features? In-Reply-To: References: Message-ID: <5D2E5A47.1090405@oracle.com> On 7/2/2019 5:33 PM, Joe Darcy wrote: > Assuming some mechanism to implement a predicate identifying a preview > API (presence of an annotation, side table in the compiler, etc.), the > messages for preview APIs could be routed through the same > previewHandler used to process preview language features. > > The summary message > > Note: Test.java uses preview language features. > Note: Recompile with -Xlint:preview for details. > > could then be replaced with something like > > Note: Test.java uses preview language features and/or preview API > elements. > Note: Recompile with -Xlint:preview for details. > > or more specialize variants for the particular combinations of a least > one flavor of preview functionality being used. If this is strictly about the wording of the summary message, then I would prefer to stay away from the term "preview API" until such time as there is a java.lang.Preview annotation type which supercedes terminal-deprecation-at-birth. Perhaps: Note: Test.java uses preview language features and/or APIs connected with preview language features. Note: Recompile ... And if you compile with --enable-preview but (say) you don't use text blocks, you just call String::stripIndent directly: Note: Test.java uses APIs connected with preview language features. Note: Recompile ... Alex From joe.darcy at oracle.com Wed Jul 17 01:02:00 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 16 Jul 2019 18:02:00 -0700 Subject: FYI, JSR 269 maintenance review (MR) for changes in Java SE 13 Message-ID: <9530b70b-718d-0243-e6d7-a96621ca7e64@oracle.com> Hello, FYI, the JCP review of the proposed changes for JSR 269 (javax.lang.model and javax.annotation.processing) for Java SE 13 is underway: http://jcp.org/aboutJava/communityprocess/maintenance/jsr269/index6.html Cheers, -Joe From matthias.baesken at sap.com Wed Jul 10 09:40:28 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 10 Jul 2019 09:40:28 +0000 Subject: RFR [XS] : 8227247: tools/sjavac/IdleShutdown.java fails with AssertionError: Error too big on windows In-Reply-To: References: Message-ID: Hi Jon, I switched to the proposed test.timeout.factor property : http://cr.openjdk.java.net/~mbaesken/webrevs/8227247.1/ Best regards, Matthias https://mail.openjdk.java.net/pipermail/compiler-dev/2019-July/013525.html Generally, the typical way to handle timeouts on slow machines is to use the jtreg "timeout factor" mechanism, which is a multiplicative factor that can be set from the command line. This allows timeouts to be increased on slow machines without unduly increasing timeouts for all platforms. Within the test, the value is available in the `test.timeout.factor` system property. https://openjdk.java.net/jtreg/tag-spec.html#testvars -- Jon On Fri, Jul 5, 2019 at 5:58 PM Baesken, Matthias > wrote: Hello, please review this small change to tools/sjavac/IdleShutdown.java . It allows higher timeout differences and gives a better error output . On Windows (especially on slower virtualized machines) the langtools test tools/sjavac/IdleShutdown.java shows sporadic failures. The error we see is : IdleShutdown.java: java.lang.AssertionError: Error too big Reason is that the "timeout error" is larger than the allowed error of 300 ms ( 3000 ms *0.1) : if (error > TIMEOUT_MS * .1) throw new AssertionError("Error too big"); We see sometimes errors in the range of 300-900 ms . For example : After 16166 ms: Timeout error: 609 ms Idea is to increase the allowed timeout error to make the test more stable. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8227247 http://cr.openjdk.java.net/~mbaesken/webrevs/8227247.0/webrev/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Wed Jul 17 07:25:47 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 17 Jul 2019 07:25:47 +0000 Subject: RFR [XS] : 8227247: tools/sjavac/IdleShutdown.java fails with AssertionError: Error too big on windows References: Message-ID: Hi Jon / Thomas , are you fine with the updated revision ? Best regards, Matthias From: Baesken, Matthias Sent: Mittwoch, 10. Juli 2019 11:40 To: compiler-dev at openjdk.java.net Cc: Zeller, Arno Subject: RE: RFR [XS] : 8227247: tools/sjavac/IdleShutdown.java fails with AssertionError: Error too big on windows Hi Jon, I switched to the proposed test.timeout.factor property : http://cr.openjdk.java.net/~mbaesken/webrevs/8227247.1/ Best regards, Matthias https://mail.openjdk.java.net/pipermail/compiler-dev/2019-July/013525.html Generally, the typical way to handle timeouts on slow machines is to use the jtreg "timeout factor" mechanism, which is a multiplicative factor that can be set from the command line. This allows timeouts to be increased on slow machines without unduly increasing timeouts for all platforms. Within the test, the value is available in the `test.timeout.factor` system property. https://openjdk.java.net/jtreg/tag-spec.html#testvars -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Jul 17 15:10:30 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 17 Jul 2019 08:10:30 -0700 Subject: RFR [XS] : 8227247: tools/sjavac/IdleShutdown.java fails with AssertionError: Error too big on windows In-Reply-To: References: Message-ID: <90b470ef-474e-8588-7fa5-227b9c4a9f5d@oracle.com> Matthias, Looks better, -- Jon On 7/10/19 2:40 AM, Baesken, Matthias wrote: > Hi Jon,?? I switched to? the? proposed?? test.timeout.factor?? property : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8227247.1/ > > Best regards, Matthias > > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-July/013525.html > > Generally, the typical way to handle timeouts on slow machines is to use > > the jtreg "timeout factor" mechanism, which is a multiplicative factor > > that can be set from the command line.? This allows timeouts to be > > increased on slow machines without unduly increasing timeouts for all > > platforms. > > Within the test, the value is available in the `test.timeout.factor` > > system property. > > https://openjdk.java.net/jtreg/tag-spec.html#testvars > > -- Jon > > On Fri, Jul 5, 2019 at 5:58 PM Baesken, Matthias > > wrote: > > Hello, > > ???please review this small change to? > tools/sjavac/IdleShutdown.java? . > > It? allows higher timeout differences and gives a better error > output . > > On Windows (especially on slower virtualized machines) the > langtools test tools/sjavac/IdleShutdown.java shows sporadic > failures. > The error we see is : > IdleShutdown.java: java.lang.AssertionError: Error too big > > Reason is that the "timeout error" is larger than the allowed > error of 300 ms ???( 3000 ms *0.1)? : > > ????????if (error > TIMEOUT_MS * .1) > ????????????throw new AssertionError("Error too big"); > > We see sometimes errors in the range of 300-900 ms . > For example : > > After 16166 ms: Timeout error: 609 ms > > Idea is to increase the allowed timeout error to make the test > more stable. > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8227247 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8227247.0/webrev/ > > Thanks, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Jul 18 06:27:10 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Jul 2019 07:27:10 +0100 Subject: RFR(trivial): 8227512: [TESTBUG] Fix JTReg javac test failures with Graal In-Reply-To: References: Message-ID: On 12/07/2019 04:27, Pengfei Li (Arm Technology China) wrote: > Hi, > > Please help review this small fix. > JBS: https://bugs.openjdk.java.net/browse/JDK-8227512 > Webrev: http://cr.openjdk.java.net/~pli/rfr/8227512/ > > JTReg javac tests > * langtools/tools/javac/modules/InheritRuntimeEnvironmentTest.java > * langtools/tools/javac/file/LimitedImage.java > failed when Graal is used as JVMCI compiler. > > These cases test javac behavior with the condition that observable modules are limited. But Graal is unable to be found in the limited module scope. This fixes these two tests by adding "jdk.internal.vm.compiler" into the limited modules. > I see this has been pushed but it looks like it is missing `@modules jdk.internal.vm.compiler` as the test now requires this module to be in the run-time image under test. As the test is not interesting when testing with the Graal compiler then maybe an alternative is to add `@requires !vm.graal.enabled` so that the test is not selected when exercising Graal - we've done this in a few other tests that run with `--limit-modules`. -Alan. From christoph.langer at sap.com Thu Jul 18 08:25:00 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 18 Jul 2019 08:25:00 +0000 Subject: RFR [XS] : 8227247: tools/sjavac/IdleShutdown.java fails with AssertionError: Error too big on windows In-Reply-To: <90b470ef-474e-8588-7fa5-227b9c4a9f5d@oracle.com> References: <90b470ef-474e-8588-7fa5-227b9c4a9f5d@oracle.com> Message-ID: Hi Matthias, thanks for fixing this. Too bad you pushed it to jdk/jdk and not to jdk13, though, because we see the issue there as well. And also in jdk11u. So I?ll push it to JDK13, too and take care of a backport to 11u ?? Cheers Christoph From: compiler-dev On Behalf Of Jonathan Gibbons Sent: Mittwoch, 17. Juli 2019 17:11 To: Baesken, Matthias ; compiler-dev at openjdk.java.net Cc: Zeller, Arno Subject: Re: RFR [XS] : 8227247: tools/sjavac/IdleShutdown.java fails with AssertionError: Error too big on windows Matthias, Looks better, -- Jon On 7/10/19 2:40 AM, Baesken, Matthias wrote: Hi Jon, I switched to the proposed test.timeout.factor property : http://cr.openjdk.java.net/~mbaesken/webrevs/8227247.1/ Best regards, Matthias https://mail.openjdk.java.net/pipermail/compiler-dev/2019-July/013525.html Generally, the typical way to handle timeouts on slow machines is to use the jtreg "timeout factor" mechanism, which is a multiplicative factor that can be set from the command line. This allows timeouts to be increased on slow machines without unduly increasing timeouts for all platforms. Within the test, the value is available in the `test.timeout.factor` system property. https://openjdk.java.net/jtreg/tag-spec.html#testvars -- Jon On Fri, Jul 5, 2019 at 5:58 PM Baesken, Matthias > wrote: Hello, please review this small change to tools/sjavac/IdleShutdown.java . It allows higher timeout differences and gives a better error output . On Windows (especially on slower virtualized machines) the langtools test tools/sjavac/IdleShutdown.java shows sporadic failures. The error we see is : IdleShutdown.java: java.lang.AssertionError: Error too big Reason is that the "timeout error" is larger than the allowed error of 300 ms ( 3000 ms *0.1) : if (error > TIMEOUT_MS * .1) throw new AssertionError("Error too big"); We see sometimes errors in the range of 300-900 ms . For example : After 16166 ms: Timeout error: 609 ms Idea is to increase the allowed timeout error to make the test more stable. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8227247 http://cr.openjdk.java.net/~mbaesken/webrevs/8227247.0/webrev/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Jul 18 08:57:48 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 18 Jul 2019 08:57:48 +0000 Subject: RFR(trivial): 8227512: [TESTBUG] Fix JTReg javac test failures with Graal In-Reply-To: References: Message-ID: Hi, we observe this issue on some of our platforms (ppc64, ppc64le) where graal/jdk.internal.vm.compiler is not available. So a good fix would either be to have `@requires !vm.graal.enabled` or, if jtreg supports it, we'd need two sets of @modules directives and VM Options (--limit-modules) to cover both cases, with or without aot. Does anybody know if this is possible? Thanks Christoph > -----Original Message----- > From: hotspot-dev On Behalf Of > Pengfei Li (Arm Technology China) > Sent: Donnerstag, 18. Juli 2019 08:52 > To: Alan Bateman > Cc: nd ; compiler-dev at openjdk.java.net; hotspot- > dev at openjdk.java.net > Subject: RE: RFR(trivial): 8227512: [TESTBUG] Fix JTReg javac test failures with > Graal > > Hi Alan, > > > I see this has been pushed but it looks like it is missing `@modules > > jdk.internal.vm.compiler` as the test now requires this module to be in the > > run-time image under test. As the test is not interesting when testing with > the > > Graal compiler then maybe an alternative is to add > > `@requires !vm.graal.enabled` so that the test is not selected when > > exercising Graal - we've done this in a few other tests that run with `--limit- > > modules`. > > Thanks for reply. I've used this alternative approach before when I tried to > clean up other false failures in Graal jtreg (see > http://hg.openjdk.java.net/jdk/jdk/rev/206afa6372ae). This time I choose to > add the missing module because I thought the javac test would be > interesting when Graal is used since javac is also written in Java. This change > is already pushed, but it's fine to me if you would like to submit another > patch to disable this two cases with Graal. > > -- > Thanks, > Pengfei From jan.lahoda at oracle.com Thu Jul 18 13:28:46 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 18 Jul 2019 15:28:46 +0200 Subject: RFR: JDK-8227922: DocTreeScanner does not dive into AttributeTree.getValue() and LiteralTree.getBody() Message-ID: <68e6541c-ec82-ea6b-ca53-74512e319435@oracle.com> Hi, com.sun.source.util.DocTreeScanner#visitAttribute is not scanning over the children of AttributeNode (i.e. AttributeNode#getValue()), and DocTreeScanner#visitLiteral is not scanning over the children of LiteralNode (i.e. LiteralNode#getBody()). The proposal here is to fix DocTreeScanner to scan over the children of these two node types. Webrev: http://cr.openjdk.java.net/~jlahoda/8227922/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8227922 As this change may cause new nodes to be encountered by subclasses of DocTreeScanner, with possibly undesirable effects (like in DocLint's Checker) and also affects the javadoc for the two methods, CSR appears to be needed as well, so I'd like to ask for a review of that as well: CSR: https://bugs.openjdk.java.net/browse/JDK-8228371 How does this look? Thanks, Jan From jan.lahoda at oracle.com Thu Jul 18 15:53:31 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 18 Jul 2019 17:53:31 +0200 Subject: RFR: JDK-8227923: End position of EndElementTree is -1 Message-ID: <58618f27-fa7f-3120-8602-44e814ab2422@oracle.com> Hi, The end position of some DocTrees (namely EndElementTree, EntityTree and CommentTree) is reported as -1 from DocTrees.getEndPosition(CompilationUnitTree, DocCommentTree, DocTree) For EntityTree and CommentTree, the end position can be currently computed easily. For EndElementTree, the proposal is to record the end position during parsing, as is done for the corresponding StartElementTree. Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8227923/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8227923 How does this look? Thanks, Jan From vladimir.kozlov at oracle.com Thu Jul 18 16:34:44 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 18 Jul 2019 09:34:44 -0700 Subject: RFR(trivial): 8227512: [TESTBUG] Fix JTReg javac test failures with Graal In-Reply-To: References: Message-ID: <35bf9c4b-75ad-7a19-a802-12a279cbc286@oracle.com> Yes, I think it is possible. You need 2 @test blocks. Something like next: http://hg.openjdk.java.net/jdk/jdk/file/aeb124322000/test/hotspot/jtreg/compiler/floatingpoint/TestFloatJNIArgs.java Vladimir On 7/18/19 1:57 AM, Langer, Christoph wrote: > Hi, > > we observe this issue on some of our platforms (ppc64, ppc64le) where graal/jdk.internal.vm.compiler is not available. So a good fix would either be to have `@requires !vm.graal.enabled` or, if jtreg supports it, we'd need two sets of @modules directives and VM Options (--limit-modules) to cover both cases, with or without aot. Does anybody know if this is possible? > > Thanks > Christoph > >> -----Original Message----- >> From: hotspot-dev On Behalf Of >> Pengfei Li (Arm Technology China) >> Sent: Donnerstag, 18. Juli 2019 08:52 >> To: Alan Bateman >> Cc: nd ; compiler-dev at openjdk.java.net; hotspot- >> dev at openjdk.java.net >> Subject: RE: RFR(trivial): 8227512: [TESTBUG] Fix JTReg javac test failures with >> Graal >> >> Hi Alan, >> >>> I see this has been pushed but it looks like it is missing `@modules >>> jdk.internal.vm.compiler` as the test now requires this module to be in the >>> run-time image under test. As the test is not interesting when testing with >> the >>> Graal compiler then maybe an alternative is to add >>> `@requires !vm.graal.enabled` so that the test is not selected when >>> exercising Graal - we've done this in a few other tests that run with `--limit- >>> modules`. >> >> Thanks for reply. I've used this alternative approach before when I tried to >> clean up other false failures in Graal jtreg (see >> http://hg.openjdk.java.net/jdk/jdk/rev/206afa6372ae). This time I choose to >> add the missing module because I thought the javac test would be >> interesting when Graal is used since javac is also written in Java. This change >> is already pushed, but it's fine to me if you would like to submit another >> patch to disable this two cases with Graal. >> >> -- >> Thanks, >> Pengfei > From jonathan.gibbons at oracle.com Thu Jul 18 18:44:25 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 18 Jul 2019 11:44:25 -0700 Subject: RFR: JDK-8227923: End position of EndElementTree is -1 In-Reply-To: <58618f27-fa7f-3120-8602-44e814ab2422@oracle.com> References: <58618f27-fa7f-3120-8602-44e814ab2422@oracle.com> Message-ID: The patch looks OK for the problem it is addressing, but it shows up a probably-unrelated bug in DocCommentParser. Look at these lines in http://cr.openjdk.java.net/~jlahoda/8227923/webrev.00/test/langtools/tools/javac/doctree/positions/TestPosition.out.sdiff.html: 94 TEXT: 95 * 96 *!trailing-whitespace! This seems to indicate that leading were not being skipped as they should be.? This needs to be looked at, but can be done separately from this fix. -- Jon On 07/18/2019 08:53 AM, Jan Lahoda wrote: > Hi, > > The end position of some DocTrees (namely EndElementTree, EntityTree > and CommentTree) is reported as -1 from > DocTrees.getEndPosition(CompilationUnitTree, DocCommentTree, DocTree) > > For EntityTree and CommentTree, the end position can be currently > computed easily. For EndElementTree, the proposal is to record the end > position during parsing, as is done for the corresponding > StartElementTree. > > Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8227923/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8227923 > > How does this look? > > Thanks, > ??? Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri Jul 19 14:28:07 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 19 Jul 2019 16:28:07 +0200 Subject: RFR: JDK-8227923: End position of EndElementTree is -1 In-Reply-To: References: <58618f27-fa7f-3120-8602-44e814ab2422@oracle.com> Message-ID: <230a2529-514c-4cf0-c990-678bf87db85e@oracle.com> On 18. 07. 19 20:44, Jonathan Gibbons wrote: > The patch looks OK for the problem it is addressing, but it shows up a > probably-unrelated bug in DocCommentParser. > > Look at these lines in > http://cr.openjdk.java.net/~jlahoda/8227923/webrev.00/test/langtools/tools/javac/doctree/positions/TestPosition.out.sdiff.html: > > 94 TEXT: > 95 * > 96 *!trailing-whitespace! > > This seems to indicate that leading were not being > skipped as they should be.? This needs to be looked at, but can be done > separately from this fix. One thing to note is that the code snippets in the golden output are not DocTree.toString() (which don't contain the ), but the part of the original code between the starting and ending position. Which for trees that span multiple lines may include the . Jan > > -- Jon > > On 07/18/2019 08:53 AM, Jan Lahoda wrote: >> Hi, >> >> The end position of some DocTrees (namely EndElementTree, EntityTree >> and CommentTree) is reported as -1 from >> DocTrees.getEndPosition(CompilationUnitTree, DocCommentTree, DocTree) >> >> For EntityTree and CommentTree, the end position can be currently >> computed easily. For EndElementTree, the proposal is to record the end >> position during parsing, as is done for the corresponding >> StartElementTree. >> >> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8227923/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8227923 >> >> How does this look? >> >> Thanks, >> ??? Jan > From jonathan.gibbons at oracle.com Fri Jul 19 14:38:48 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 19 Jul 2019 07:38:48 -0700 Subject: RFR: JDK-8227923: End position of EndElementTree is -1 In-Reply-To: <230a2529-514c-4cf0-c990-678bf87db85e@oracle.com> References: <58618f27-fa7f-3120-8602-44e814ab2422@oracle.com> <230a2529-514c-4cf0-c990-678bf87db85e@oracle.com> Message-ID: Inline On 7/19/19 7:28 AM, Jan Lahoda wrote: > On 18. 07. 19 20:44, Jonathan Gibbons wrote: >> The patch looks OK for the problem it is addressing, but it shows up >> a probably-unrelated bug in DocCommentParser. >> >> Look at these lines in >> http://cr.openjdk.java.net/~jlahoda/8227923/webrev.00/test/langtools/tools/javac/doctree/positions/TestPosition.out.sdiff.html: >> >> 94 TEXT: >> 95 * >> 96 *!trailing-whitespace! >> >> This seems to indicate that leading were not being >> skipped as they should be.? This needs to be looked at, but can be >> done separately from this fix. > > One thing to note is that the code snippets in the golden output are > not DocTree.toString() (which don't contain the ), > but the part of the original code between the starting and ending > position. Which for trees that span multiple lines may include the > . Ah OK, thanks; I'd forgotten that! > > Jan > >> >> -- Jon >> >> On 07/18/2019 08:53 AM, Jan Lahoda wrote: >>> Hi, >>> >>> The end position of some DocTrees (namely EndElementTree, EntityTree >>> and CommentTree) is reported as -1 from >>> DocTrees.getEndPosition(CompilationUnitTree, DocCommentTree, DocTree) >>> >>> For EntityTree and CommentTree, the end position can be currently >>> computed easily. For EndElementTree, the proposal is to record the >>> end position during parsing, as is done for the corresponding >>> StartElementTree. >>> >>> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8227923/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8227923 >>> >>> How does this look? >>> >>> Thanks, >>> ??? Jan >> From ronshapiro at google.com Fri Jul 19 20:09:20 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Fri, 19 Jul 2019 16:09:20 -0400 Subject: AbstractMessager Message-ID: In a number of processors that I've implemented, I've wanted to wrap a Messager instance to track if I've printed a diagnostic with an ERROR kind so I can know to abort any generation if the inputs are invalid. There are a number of ways to do this, but what always feels like would be most natural is to be able to create a ForwardingMessager of some sort. I think the easiest way to do this is if there were already an AbstractMessager class, so I wanted to propose adding it to the JSR 269 APIs. The implementation would be rather simple, just telescoping the calls with `null` arguments, just like JavacMessager works. @Override public void printMessage(Diagnostic.Kind kind, CharSequence msg) { printMessage(kind, msg, null); } @Override public void printMessage(Diagnostic.Kind kind, CharSequence msg, Element e) { printMessage(kind, msg, e, null); } // etc Alternatively, the methods could become default methods, which is probably the easiest change and doesn't introduce a new type. Does something like this make sense? -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Mon Jul 22 04:10:05 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 21 Jul 2019 21:10:05 -0700 Subject: Aligning compiler messages for using preview API with preview language features? In-Reply-To: <5D2E5A47.1090405@oracle.com> References: <5D2E5A47.1090405@oracle.com> Message-ID: <9228ac87-4cf1-34bd-7a97-3e279d9e57ac@oracle.com> Hello, On 7/16/2019 4:14 PM, Alex Buckley wrote: > On 7/2/2019 5:33 PM, Joe Darcy wrote: >> Assuming some mechanism to implement a predicate identifying a preview >> API (presence of an annotation, side table in the compiler, etc.), the >> messages for preview APIs could be routed through the same >> previewHandler used to process preview language features. >> >> The summary message >> >> ???? Note: Test.java uses preview language features. >> ???? Note: Recompile with -Xlint:preview for details. >> >> could then be replaced with something like >> >> ???? Note: Test.java uses preview language features and/or preview API >> elements. >> ???? Note: Recompile with -Xlint:preview for details. >> >> or more specialize variants for the particular combinations of a least >> one flavor of preview functionality being used. > > If this is strictly about the wording of the summary message, then I > would prefer to stay away from the term "preview API" until such time > as there is a java.lang.Preview annotation type which supercedes > terminal-deprecation-at-birth. Perhaps: > > ? Note: Test.java uses preview language features and/or > ??????? APIs connected with preview language features. > ? Note: Recompile ... > > And if you compile with --enable-preview but (say) you don't use text > blocks, you just call String::stripIndent directly: > > ? Note: Test.java uses APIs connected with preview language features. > ? Note: Recompile ... Yes; getting the compiler messages to distinguish between just "preivew API" usage (modulo wording above), preview language features, or both should be simple enough using distinct methods to record the preview-related usages of different kinds. There are at least two possible versions of Preview annotation type: 1) One that supplements @Deprecated(forRemoval=true) and only suppresses the deprecation warning if --enable-preview is used. 2) One that replaces @Deprecated(forRemoval=true) for preview-related APIs and generates differentiated messages based on the status of --enable-preview. If the distinct annotation type is added, I'd prefer the latter; although it would (presumably) require some JLS spec work. I think the former option would still be an improvement over the current warning generation situation. Cheers, -Joe From vicente.romero at oracle.com Mon Jul 22 16:55:49 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 22 Jul 2019 12:55:49 -0400 Subject: RFR: JDK-8227922: DocTreeScanner does not dive into AttributeTree.getValue() and LiteralTree.getBody() In-Reply-To: <68e6541c-ec82-ea6b-ca53-74512e319435@oracle.com> References: <68e6541c-ec82-ea6b-ca53-74512e319435@oracle.com> Message-ID: looks good, the only nit is that probably the text in the CSR section: "Compatibility Risk" could be improved with a rephrasing. At least it is not clear to me that if a class doesn't override, for example, visitLiteral, how that method will be invoked at all? I think that you mean that a visitLiteral implementation in a subclass will be invoked with, possible, more literals than before? Thanks, Vicente On 7/18/19 9:28 AM, Jan Lahoda wrote: > Hi, > > com.sun.source.util.DocTreeScanner#visitAttribute is not scanning over > the children of AttributeNode (i.e. AttributeNode#getValue()), and > DocTreeScanner#visitLiteral is not scanning over the children of > LiteralNode (i.e. LiteralNode#getBody()). The proposal here is to fix > DocTreeScanner to scan over the children of these two node types. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8227922/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8227922 > > As this change may cause new nodes to be encountered by subclasses of > DocTreeScanner, with possibly undesirable effects (like in DocLint's > Checker) and also affects the javadoc for the two methods, CSR appears > to be needed as well, so I'd like to ask for a review of that as well: > > CSR: https://bugs.openjdk.java.net/browse/JDK-8228371 > > How does this look? > > Thanks, > ??? Jan From joe.darcy at oracle.com Mon Jul 22 23:37:54 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 22 Jul 2019 16:37:54 -0700 Subject: AbstractMessager In-Reply-To: References: Message-ID: <9ecd9f42-61ec-dcd1-01c3-8d26de3a58d5@oracle.com> Hi Ron, I take it you aren't finding ??? RoundEnvironment.errorRaised() https://docs.oracle.com/en/java/javase/12/docs/api/java.compiler/javax/annotation/processing/RoundEnvironment.html#errorRaised() to be sufficient? This will indicate an error has been raised started at the *next* round of annotation processing. I would be more tempted to add some default methods like ?* warn/printWarn(CharSequence msg) ?* warn/printWarn(CharSequence msg, Element e) ?* error/printError(CharSequence msg) ?* error/printError(CharSequence msg, Element e) Cheers, -Joe On 7/19/2019 1:09 PM, Ron Shapiro wrote: > In a number of processors that I've implemented, I've wanted to wrap a > Messager instance to track if I've printed a diagnostic with an ERROR > kind so I can know to abort any generation if the inputs are invalid. > > There are a number of ways to do this, but what always feels like > would be most natural is to be able to create a ForwardingMessager of > some sort. I think the easiest way to do this is if there were already > an AbstractMessager class, so I wanted to propose adding it to the JSR > 269 APIs. > > The implementation would be rather simple, just telescoping the calls > with `null` arguments, just like JavacMessager works. > > @Override > public void printMessage(Diagnostic.Kind kind, CharSequence msg) { > ? ? printMessage(kind, msg, null); > } > > @Override > public void printMessage(Diagnostic.Kind kind, CharSequence msg, > Element e) { > ? ? printMessage(kind, msg, e, null); > } > > // etc > > Alternatively, the methods could become default methods, which is > probably the easiest change and doesn't introduce a new type. > > Does something like this make sense? From ronshapiro at google.com Tue Jul 23 13:25:07 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Tue, 23 Jul 2019 09:25:07 -0400 Subject: AbstractMessager In-Reply-To: <9ecd9f42-61ec-dcd1-01c3-8d26de3a58d5@oracle.com> References: <9ecd9f42-61ec-dcd1-01c3-8d26de3a58d5@oracle.com> Message-ID: Correct. I often need to know whether the same round should do more processing. Typically we run many different validations and only want to generate code if all of those have passed. These validations span different methods and classes, so keeping track of the state can often get ugly. Adding those default methods may be a helpful calling convenience, but it wouldn't assist in determining whether an error has been printed in one of the methods that already exists. ?????? ??? ??, 22 ????? 2019, 19:37, ??? Joe Darcy ?: > Hi Ron, > > I take it you aren't finding > > RoundEnvironment.errorRaised() > > https://docs.oracle.com/en/java/javase/12/docs/api/java.compiler/javax/annotation/processing/RoundEnvironment.html#errorRaised() > > to be sufficient? This will indicate an error has been raised started at > the *next* round of annotation processing. > > I would be more tempted to add some default methods like > > * warn/printWarn(CharSequence msg) > * warn/printWarn(CharSequence msg, Element e) > * error/printError(CharSequence msg) > * error/printError(CharSequence msg, Element e) > > Cheers, > > -Joe > > On 7/19/2019 1:09 PM, Ron Shapiro wrote: > > In a number of processors that I've implemented, I've wanted to wrap a > > Messager instance to track if I've printed a diagnostic with an ERROR > > kind so I can know to abort any generation if the inputs are invalid. > > > > There are a number of ways to do this, but what always feels like > > would be most natural is to be able to create a ForwardingMessager of > > some sort. I think the easiest way to do this is if there were already > > an AbstractMessager class, so I wanted to propose adding it to the JSR > > 269 APIs. > > > > The implementation would be rather simple, just telescoping the calls > > with `null` arguments, just like JavacMessager works. > > > > @Override > > public void printMessage(Diagnostic.Kind kind, CharSequence msg) { > > printMessage(kind, msg, null); > > } > > > > @Override > > public void printMessage(Diagnostic.Kind kind, CharSequence msg, > > Element e) { > > printMessage(kind, msg, e, null); > > } > > > > // etc > > > > Alternatively, the methods could become default methods, which is > > probably the easiest change and doesn't introduce a new type. > > > > Does something like this make sense? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Jul 24 08:08:43 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Jul 2019 08:08:43 +0000 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 Message-ID: Hi, Please review a fix for two tests that fail on non-aot builds/platforms after JDK-8227512: langtools/tools/javac/modules/InheritRuntimeEnvironmentTest.java langtools/tools/javac/file/LimitedImage.java Bug: https://bugs.openjdk.java.net/browse/JDK-8227512 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8228571.0/ I would fix it by setting up two test run configurations, one with graal and the other without. Therefore I need to add some configuration to langtools/TEST.ROOT to be able to use "@requires vm.graal.enabled". Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Jul 24 08:12:59 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Jul 2019 08:12:59 +0000 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 Message-ID: Sorry, wrong bug URL. The correct one is: https://bugs.openjdk.java.net/browse/JDK-8228571 From: Langer, Christoph Sent: Mittwoch, 24. Juli 2019 10:09 To: compiler-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Cc: Alan Bateman ; 'Vladimir Kozlov' ; 'Pengfei Li (Arm Technology China)' ; 'daniel.daugherty at oracle.com' ; David Holmes Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 Hi, Please review a fix for two tests that fail on non-aot builds/platforms after JDK-8227512: langtools/tools/javac/modules/InheritRuntimeEnvironmentTest.java langtools/tools/javac/file/LimitedImage.java Bug: https://bugs.openjdk.java.net/browse/JDK-8227512 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8228571.0/ I would fix it by setting up two test run configurations, one with graal and the other without. Therefore I need to add some configuration to langtools/TEST.ROOT to be able to use "@requires vm.graal.enabled". Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Jul 24 08:34:54 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Jul 2019 09:34:54 +0100 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 In-Reply-To: References: Message-ID: <6f8ac3de-b0fd-626f-09bb-865a56f969b0@oracle.com> On 24/07/2019 09:08, Langer, Christoph wrote: > > Hi, > > Please review a fix for two tests that fail on non-aot > builds/platforms after JDK-8227512: > > langtools/tools/javac/modules/InheritRuntimeEnvironmentTest.java > > langtools/tools/javac/file/LimitedImage.java > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227512 > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8228571.0/ > > > I would fix it by setting up two test run configurations, one with > graal and the other without. Therefore I need to add some > configuration to langtools/TEST.ROOT to be able to use ?@requires > vm.graal.enabled?. > > The update requires.extraPropDefns.bootlibs TEST.ROOT should probably include Container.java so that it's consistent with the jdk tests. I realize it's unlikely that langtools tests will run docker commands but I'm sure the inconsistency will be noticed. Shouldn't vm.graal.enabled tests include jdk.internal.vm.compiler in the @modules list? I agree with Aleksey about inverting the default for the parameter. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Jul 24 09:44:05 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Jul 2019 09:44:05 +0000 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 In-Reply-To: <6f8ac3de-b0fd-626f-09bb-865a56f969b0@oracle.com> References: <6f8ac3de-b0fd-626f-09bb-865a56f969b0@oracle.com> Message-ID: Hi Alan, Aleksey, thanks for the reviews. Here is an update which incorporates all suggestions: http://cr.openjdk.java.net/~clanger/webrevs/8228571.1/ > The update requires.extraPropDefns.bootlibs TEST.ROOT should probably > include Container.java so that it's consistent with the jdk tests. I realize it's > unlikely that langtools tests will run docker commands but I'm sure the > inconsistency will be noticed. Agreed. I copied that part from an older version of jdk's TEST.ROOT. > Shouldn't vm.graal.enabled tests include jdk.internal.vm.compiler in the > @modules list? It's probably better. I added it. > I agree with Aleksey about inverting the default for the parameter. You are right. Please look at my new webrev whether you find it better there. I tested with both, graal and non-graal configurations and see the relevant test configuration is executed and succeeds. I'll run the fix through our nightlies, too. Best regards Christoph From Alan.Bateman at oracle.com Wed Jul 24 10:31:45 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Jul 2019 11:31:45 +0100 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 In-Reply-To: References: <6f8ac3de-b0fd-626f-09bb-865a56f969b0@oracle.com> Message-ID: <22f18391-0a4d-8c39-9f78-7d49124be825@oracle.com> On 24/07/2019 10:44, Langer, Christoph wrote: > Hi Alan, Aleksey, > > thanks for the reviews. > > Here is an update which incorporates all suggestions: http://cr.openjdk.java.net/~clanger/webrevs/8228571.1/ > This looks okay to me but probably best to have someone on compiler-dev okay to change too as that is where the javac tests are maintained. There is an argument that it would be simpler to just have these tests be skipped when testing with Graal. -Alan From christoph.langer at sap.com Wed Jul 24 12:27:41 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Jul 2019 12:27:41 +0000 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 In-Reply-To: <22f18391-0a4d-8c39-9f78-7d49124be825@oracle.com> References: <6f8ac3de-b0fd-626f-09bb-865a56f969b0@oracle.com> <22f18391-0a4d-8c39-9f78-7d49124be825@oracle.com> Message-ID: > > Here is an update which incorporates all suggestions: > http://cr.openjdk.java.net/~clanger/webrevs/8228571.1/ > > > This looks okay to me but probably best to have someone on compiler-dev > okay to change too as that is where the javac tests are maintained. > There is an argument that it would be simpler to just have these tests > be skipped when testing with Graal. Thanks Alan. I agree, somebody from compiler-dev should approve this. Alternatives would be to skip the test in graal configurations via @requires !vm.graal.enabled or to restore the test in the state it was pre JDK-8227512 and exclude via graal specific problem list (which does not yet exist for langtools). /Christoph From shade at redhat.com Wed Jul 24 08:13:37 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 24 Jul 2019 10:13:37 +0200 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 In-Reply-To: References: Message-ID: <4a608de3-ae96-bb93-d46a-6461875cdef7@redhat.com> On 7/24/19 10:08 AM, Langer, Christoph wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8227512 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8228571.0/ This inversion is dodgy: 47 * @run main InheritRuntimeEnvironmentTest graal ...then: 74 if (args.length > 0) { 75 hasGraal = false; 76 } How about supplying "graal" turn hasGraal=true instead? Maybe even check that first argument is "graal" indeed. Otherwise looks okay. -- Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From shade at redhat.com Wed Jul 24 09:46:26 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 24 Jul 2019 11:46:26 +0200 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 In-Reply-To: References: <6f8ac3de-b0fd-626f-09bb-865a56f969b0@oracle.com> Message-ID: <87ef29bb-e651-664e-938b-a98893d50841@redhat.com> On 7/24/19 11:44 AM, Langer, Christoph wrote: > Here is an update which incorporates all suggestions: http://cr.openjdk.java.net/~clanger/webrevs/8228571.1/ Looks okay to me. -- Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From matthias.baesken at sap.com Thu Jul 18 06:35:43 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 18 Jul 2019 06:35:43 +0000 Subject: RFR [XS] : 8227247: tools/sjavac/IdleShutdown.java fails with AssertionError: Error too big on windows In-Reply-To: <90b470ef-474e-8588-7fa5-227b9c4a9f5d@oracle.com> References: <90b470ef-474e-8588-7fa5-227b9c4a9f5d@oracle.com> Message-ID: Hi Jon + Thomas , thanks for the reviews ! Best regards, Matthias From: Jonathan Gibbons Sent: Mittwoch, 17. Juli 2019 17:11 To: Baesken, Matthias ; compiler-dev at openjdk.java.net Cc: Zeller, Arno Subject: Re: RFR [XS] : 8227247: tools/sjavac/IdleShutdown.java fails with AssertionError: Error too big on windows Matthias, Looks better, -- Jon On 7/10/19 2:40 AM, Baesken, Matthias wrote: Hi Jon, I switched to the proposed test.timeout.factor property : http://cr.openjdk.java.net/~mbaesken/webrevs/8227247.1/ Best regards, Matthias https://mail.openjdk.java.net/pipermail/compiler-dev/2019-July/013525.html Generally, the typical way to handle timeouts on slow machines is to use the jtreg "timeout factor" mechanism, which is a multiplicative factor that can be set from the command line. This allows timeouts to be increased on slow machines without unduly increasing timeouts for all platforms. Within the test, the value is available in the `test.timeout.factor` system property. https://openjdk.java.net/jtreg/tag-spec.html#testvars -- Jon On Fri, Jul 5, 2019 at 5:58 PM Baesken, Matthias > wrote: Hello, please review this small change to tools/sjavac/IdleShutdown.java . It allows higher timeout differences and gives a better error output . On Windows (especially on slower virtualized machines) the langtools test tools/sjavac/IdleShutdown.java shows sporadic failures. The error we see is : IdleShutdown.java: java.lang.AssertionError: Error too big Reason is that the "timeout error" is larger than the allowed error of 300 ms ( 3000 ms *0.1) : if (error > TIMEOUT_MS * .1) throw new AssertionError("Error too big"); We see sometimes errors in the range of 300-900 ms . For example : After 16166 ms: Timeout error: 609 ms Idea is to increase the allowed timeout error to make the test more stable. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8227247 http://cr.openjdk.java.net/~mbaesken/webrevs/8227247.0/webrev/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From Pengfei.Li at arm.com Thu Jul 18 06:51:35 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Thu, 18 Jul 2019 06:51:35 +0000 Subject: RFR(trivial): 8227512: [TESTBUG] Fix JTReg javac test failures with Graal In-Reply-To: References: Message-ID: Hi Alan, > I see this has been pushed but it looks like it is missing `@modules > jdk.internal.vm.compiler` as the test now requires this module to be in the > run-time image under test. As the test is not interesting when testing with the > Graal compiler then maybe an alternative is to add > `@requires !vm.graal.enabled` so that the test is not selected when > exercising Graal - we've done this in a few other tests that run with `--limit- > modules`. Thanks for reply. I've used this alternative approach before when I tried to clean up other false failures in Graal jtreg (see http://hg.openjdk.java.net/jdk/jdk/rev/206afa6372ae). This time I choose to add the missing module because I thought the javac test would be interesting when Graal is used since javac is also written in Java. This change is already pushed, but it's fine to me if you would like to submit another patch to disable this two cases with Graal. -- Thanks, Pengfei From jonathan.gibbons at oracle.com Wed Jul 24 16:40:17 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 24 Jul 2019 09:40:17 -0700 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 In-Reply-To: <22f18391-0a4d-8c39-9f78-7d49124be825@oracle.com> References: <6f8ac3de-b0fd-626f-09bb-865a56f969b0@oracle.com> <22f18391-0a4d-8c39-9f78-7d49124be825@oracle.com> Message-ID: <797cc38b-9ab0-9c18-3012-38dfaabdf18b@oracle.com> On 7/24/19 3:31 AM, Alan Bateman wrote: > On 24/07/2019 10:44, Langer, Christoph wrote: >> Hi Alan, Aleksey, >> >> thanks for the reviews. >> >> Here is an update which incorporates all suggestions: >> http://cr.openjdk.java.net/~clanger/webrevs/8228571.1/ >> > This looks okay to me but probably best to have someone on > compiler-dev okay to change too as that is where the javac tests are > maintained. There is an argument that it would be simpler to just have > these tests be skipped when testing with Graal. > > -Alan This seems wrong/misguided/over the top. On the one hand, javac is a relatively simple Java program that should not need to depend on VM internals like this. Conversely, if a Java program does need to depend on VM "internals" like this, perhaps they should be exposed more publicly and not be "internal". -- Jon From jonathan.gibbons at oracle.com Wed Jul 24 20:12:06 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 24 Jul 2019 13:12:06 -0700 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 In-Reply-To: <797cc38b-9ab0-9c18-3012-38dfaabdf18b@oracle.com> References: <6f8ac3de-b0fd-626f-09bb-865a56f969b0@oracle.com> <22f18391-0a4d-8c39-9f78-7d49124be825@oracle.com> <797cc38b-9ab0-9c18-3012-38dfaabdf18b@oracle.com> Message-ID: On 07/24/2019 09:40 AM, Jonathan Gibbons wrote: > > On 7/24/19 3:31 AM, Alan Bateman wrote: >> On 24/07/2019 10:44, Langer, Christoph wrote: >>> Hi Alan, Aleksey, >>> >>> thanks for the reviews. >>> >>> Here is an update which incorporates all suggestions: >>> http://cr.openjdk.java.net/~clanger/webrevs/8228571.1/ >>> >> This looks okay to me but probably best to have someone on >> compiler-dev okay to change too as that is where the javac tests are >> maintained. There is an argument that it would be simpler to just >> have these tests be skipped when testing with Graal. >> >> -Alan > > > This seems wrong/misguided/over the top. > > On the one hand, javac is a relatively simple Java program that should > not need to depend on VM internals like this. Conversely, if a Java > program does need to depend on VM "internals" like this, perhaps they > should be exposed more publicly and not be "internal". > > -- Jon > I think this fix, and the one that preceded it, are both wrong, and that JDK-8227512 should be backed out until we have a better solution. 1. I think it is a significant functional regression if a previously valid, unrelated test starts to fail when Graal is enabled.? If this were a white-box test about testing JVMs, then changing the test code may be seen as reasonable. But the two tests in question are high-level tests of unrelated features.? The test failures should be seen as underlying problems to be addressed, and not swept under the carpet with a workaround. 2. Even detecting whether or not Graal is enabled requires access to internal API, mediated through VMProps.java in the jtreg extraPropDefns mechanism, which calls down onto `sun.hotspot.code.Compiler.isGraalEnabled`. Even if you're prepared to swallow #1 and have clients change their code when Graal is enabled, telling them how to detect if Graal is enabled is pretty dire. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From Pengfei.Li at arm.com Thu Jul 25 02:12:26 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Thu, 25 Jul 2019 02:12:26 +0000 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 In-Reply-To: References: <6f8ac3de-b0fd-626f-09bb-865a56f969b0@oracle.com> <22f18391-0a4d-8c39-9f78-7d49124be825@oracle.com> <797cc38b-9ab0-9c18-3012-38dfaabdf18b@oracle.com> Message-ID: Hi Jonathan, > 1. I think it is a significant functional regression if a previously > valid, unrelated test starts to fail when Graal is enabled. If this > were a white-box test about testing JVMs, then changing the test code > may be seen as reasonable. But the two tests in question are high-level > tests of unrelated features. The test failures should be seen as > underlying problems to be addressed, and not swept under the carpet with > a workaround. > > 2. Even detecting whether or not Graal is enabled requires access to > internal API, mediated through VMProps.java in the jtreg extraPropDefns > mechanism, which calls down onto > `sun.hotspot.code.Compiler.isGraalEnabled`. Even if you're prepared to > swallow #1 and have clients change their code when Graal is enabled, > telling them how to detect if Graal is enabled is pretty dire. Thanks for comments. But from your point, I don't see any better solution before Graal is moved out from the jdk.internal.* modules. Is it ok to problem-list these two cases? There's no ProblemList-graal.txt in langtools. Does the ProblemList-graal mechanism access VM internals as well? -- Thanks, Pengfei From Alan.Bateman at oracle.com Thu Jul 25 09:03:45 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 25 Jul 2019 10:03:45 +0100 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 In-Reply-To: References: <6f8ac3de-b0fd-626f-09bb-865a56f969b0@oracle.com> <22f18391-0a4d-8c39-9f78-7d49124be825@oracle.com> <797cc38b-9ab0-9c18-3012-38dfaabdf18b@oracle.com> Message-ID: <70d2def2-a5ba-66bb-44c7-c86025552b7c@oracle.com> On 24/07/2019 21:12, Jonathan Gibbons wrote: > > : > > I think this fix, and the one that preceded it, are both wrong, and > that JDK-8227512 > should be backed out until we have a better solution. > > 1. I think it is a significant functional regression if a previously > valid, unrelated test starts to fail when Graal is enabled.? If this > were a white-box test about testing JVMs, then changing the test code > may be seen as reasonable. But the two tests in question are > high-level tests of unrelated features.? The test failures should be > seen as underlying problems to be addressed, and not swept under the > carpet with a workaround. Most tests don't care if they are being tested with Graal or not. The challenge for tests using --limit-modules is the set of observable modules needs to expanded to include the Graal modules when testing Graal. This can lead to two test descriptions or more invasive changes when the test forks additional VMs and computes the value to specify to --limit-modules in the test code. In test/jdk, where we looked the other way when the TEST.ROOT changes and VMProps helper were added, it means we can add `@requires !vm.graal.enabled` to the tests using --limit-modules so they are skipped when testing Graal. This avoids duplicate test descriptions and changing test code and seems the least invasive approach. To do the same for the javac tests in test/langtools would mean bringing in the TEST.ROOT changes to run VMProps. If that isn't going to happen then it might mean a Graal specific exclude list (like test/jdk/ProblemList-graal.txt). I assume any other solutions would starting a new discussion on how to test with Graal enabled. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Jul 25 13:28:44 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 25 Jul 2019 13:28:44 +0000 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 In-Reply-To: References: <6f8ac3de-b0fd-626f-09bb-865a56f969b0@oracle.com> <22f18391-0a4d-8c39-9f78-7d49124be825@oracle.com> <797cc38b-9ab0-9c18-3012-38dfaabdf18b@oracle.com> <5809c7fb-16bd-b9d8-7b50-1af74b84d847@oracle.com> <84E6E19F-131B-40F9-AE9C-432D4919944A@oracle.com> Message-ID: Hi, after catching up with this discussion, I agree that the most pragmatic fix for now would be to backout JDK-8227512 and add graal specific exclusions. That's what I do here: http://cr.openjdk.java.net/~clanger/webrevs/8228571.2/ If you all agree, I'll create another JBS Bug about the underlying issues regarding this test with limiting modules to jdk.compiler on a graal enabled VM and add that to the problem list entries. I also think that it's not the time now to introduce the machinery behind `@requires !vm.graal.enabled` to langtools testing. Please let me know what you think. Cheers Christoph > -----Original Message----- > From: Pengfei Li (Arm Technology China) > Sent: Donnerstag, 25. Juli 2019 06:06 > To: Igor Ignatyev ; Jonathan Gibbons > > Cc: Alan Bateman ; Langer, Christoph > ; compiler-dev at openjdk.java.net; hotspot- > compiler-dev at openjdk.java.net; Aleksey Shipilev ; > Vladimir Kozlov ; David Holmes > ; nd ; > daniel.daugherty at oracle.com; Maurizio Cimadamore > > Subject: RE: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms > after JDK-8227512 > > > ProblemList-graal.txt files don't use any magic at all, neither do they > depend > > VMProps, special jtreg or VM technology. these are just extra problem list > > files, which you are supposed to add into your command lines whenever > you > > are using Graal . > > Thanks Igor and Jon for your explanation. > > Christoph, would you like to add a ProblemList-graal.txt file and remove my > added modules in your JDK-8228571? I see this is also your alternative fix. > > -- > Thanks, > Pengfei From jonathan.gibbons at oracle.com Thu Jul 25 02:52:25 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 24 Jul 2019 19:52:25 -0700 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 In-Reply-To: References: <6f8ac3de-b0fd-626f-09bb-865a56f969b0@oracle.com> <22f18391-0a4d-8c39-9f78-7d49124be825@oracle.com> <797cc38b-9ab0-9c18-3012-38dfaabdf18b@oracle.com> Message-ID: <5809c7fb-16bd-b9d8-7b50-1af74b84d847@oracle.com> On 7/24/19 7:12 PM, Pengfei Li (Arm Technology China) wrote: > Hi Jonathan, > >> 1. I think it is a significant functional regression if a previously >> valid, unrelated test starts to fail when Graal is enabled. If this >> were a white-box test about testing JVMs, then changing the test code >> may be seen as reasonable. But the two tests in question are high-level >> tests of unrelated features. The test failures should be seen as >> underlying problems to be addressed, and not swept under the carpet with >> a workaround. >> >> 2. Even detecting whether or not Graal is enabled requires access to >> internal API, mediated through VMProps.java in the jtreg extraPropDefns >> mechanism, which calls down onto >> `sun.hotspot.code.Compiler.isGraalEnabled`. Even if you're prepared to >> swallow #1 and have clients change their code when Graal is enabled, >> telling them how to detect if Graal is enabled is pretty dire. > Thanks for comments. But from your point, I don't see any better solution before Graal is moved out from the jdk.internal.* modules. > > Is it ok to problem-list these two cases? There's no ProblemList-graal.txt in langtools. Does the ProblemList-graal mechanism access VM internals as well? > > -- > Thanks, > Pengfei > It would be OK to ProblemList these tests. I can't speak to how ProblemList-graal.txt works, but I'm guessing it uses Makefile magic and does not depend on any special jtreg or VM technology. If you can create the problemlist file in test/langtools, with no other changes to test/langtools, that would be a preferable solution to the changeset that is being proposed. I'm not sure what you mean by "any better solution before Graal is moved out from the jdk.internal.* modules." It seems to me the problem is a missing module dependency and not by any side effect of being an "internal module". I'm not familiar with anything beyond the superficial details of how Graal works in OpenJDK, but it seems to be the problem starts when the special -XX options are provided on the command line .... those switches seem to implicitly change the need for the extra module to be present, thus causing existing, working code to fail. In other words, the switches are not enough when a VM with limited modules is used. From an oustsider "layman" position, maybe the code underlying those switches should ensure that the module is made available, even in the face of a --limit-modules option.? One step short of that would be to detect the module is not available and to give a friendly helpful message instead of a crash and stack trace.? (And, again, I'm not an expert in this area, so apologies if this has been asked/discussed/answered elsewhere.) -- Jon From david.holmes at oracle.com Thu Jul 25 05:09:09 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jul 2019 15:09:09 +1000 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 In-Reply-To: <5809c7fb-16bd-b9d8-7b50-1af74b84d847@oracle.com> References: <6f8ac3de-b0fd-626f-09bb-865a56f969b0@oracle.com> <22f18391-0a4d-8c39-9f78-7d49124be825@oracle.com> <797cc38b-9ab0-9c18-3012-38dfaabdf18b@oracle.com> <5809c7fb-16bd-b9d8-7b50-1af74b84d847@oracle.com> Message-ID: Hi Jon, On 25/07/2019 12:52 pm, Jonathan Gibbons wrote: > > On 7/24/19 7:12 PM, Pengfei Li (Arm Technology China) wrote: >> Hi Jonathan, >> >>> 1. I think it is a significant functional regression if a previously >>> valid, unrelated test starts to fail when Graal is enabled.? If this >>> were a white-box test about testing JVMs, then changing the test code >>> may be seen as reasonable. But the two tests in question are high-level >>> tests of unrelated features.? The test failures should be seen as >>> underlying problems to be addressed, and not swept under the carpet with >>> a workaround. >>> >>> 2. Even detecting whether or not Graal is enabled requires access to >>> internal API, mediated through VMProps.java in the jtreg extraPropDefns >>> mechanism, which calls down onto >>> `sun.hotspot.code.Compiler.isGraalEnabled`. Even if you're prepared to >>> swallow #1 and have clients change their code when Graal is enabled, >>> telling them how to detect if Graal is enabled is pretty dire. >> Thanks for comments. But from your point, I don't see any better >> solution before Graal is moved out from the jdk.internal.* modules. >> >> Is it ok to problem-list these two cases? There's no >> ProblemList-graal.txt in langtools. Does the ProblemList-graal >> mechanism access VM internals as well? >> >> -- >> Thanks, >> Pengfei >> > > It would be OK to ProblemList these tests. I can't speak to how > ProblemList-graal.txt works, but I'm guessing it uses Makefile magic and > does not depend on any special jtreg or VM technology. If you can create > the problemlist file in test/langtools, with no other changes to > test/langtools, that would be a preferable solution to the changeset > that is being proposed. > > I'm not sure what you mean by "any better solution before Graal is moved > out from the jdk.internal.* modules." It seems to me the problem is a > missing module dependency and not by any side effect of being an > "internal module". > > I'm not familiar with anything beyond the superficial details of how > Graal works in OpenJDK, but it seems to be the problem starts when the > special -XX options are provided on the command line .... those switches > seem to implicitly change the need for the extra module to be present, > thus causing existing, working code to fail. In other words, the > switches are not enough when a VM with limited modules is used. From an > oustsider "layman" position, maybe the code underlying those switches > should ensure that the module is made available, even in the face of a > --limit-modules option. I agree that when the test configuration logic enables Graal it should add whatever flags are needed to enable Graal to work. However I don't know if that can be arbitrarily combined with test specific settings like --limit-modules. The module system folk would have to tell us how exactly --limit-modules works and whether there is another flag that would add the necessary access to the graal module without needing to augment the @modules section of the test. David ----- >? One step short of that would be to detect the > module is not available and to give a friendly helpful message instead > of a crash and stack trace.? (And, again, I'm not an expert in this > area, so apologies if this has been asked/discussed/answered elsewhere.) > > -- Jon > > From igor.ignatyev at oracle.com Thu Jul 25 03:13:04 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 24 Jul 2019 20:13:04 -0700 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 In-Reply-To: <5809c7fb-16bd-b9d8-7b50-1af74b84d847@oracle.com> References: <6f8ac3de-b0fd-626f-09bb-865a56f969b0@oracle.com> <22f18391-0a4d-8c39-9f78-7d49124be825@oracle.com> <797cc38b-9ab0-9c18-3012-38dfaabdf18b@oracle.com> <5809c7fb-16bd-b9d8-7b50-1af74b84d847@oracle.com> Message-ID: <84E6E19F-131B-40F9-AE9C-432D4919944A@oracle.com> Hi Pengfei, Jon, ProblemList-graal.txt files don't use any magic at all, neither do they depend VMProps, special jtreg or VM technology. these are just extra problem list files, which you are supposed to add into your command lines whenever you are using Graal . the way we (Oracle) use them is by simply adding 'JTREG_EXTRA_PROBLEM_LISTS=ProblemList-graal.txt' (or 'JTREG=EXTRA_PROBLEM_LISTS=ProblemList-graal.txt') to our 'make test' commands, makefiles take care of checking if the file exists and adding an extra '-exclude:' to jtreg command line. in other words, you can create ProblemList-graal.txt in 'test/langtools/' directory and it will be used in the same way as ProblemList-graal.txt files from other test suites. HTH, -- Igor > On Jul 24, 2019, at 7:52 PM, Jonathan Gibbons wrote: > > > On 7/24/19 7:12 PM, Pengfei Li (Arm Technology China) wrote: >> Hi Jonathan, >> >>> 1. I think it is a significant functional regression if a previously >>> valid, unrelated test starts to fail when Graal is enabled. If this >>> were a white-box test about testing JVMs, then changing the test code >>> may be seen as reasonable. But the two tests in question are high-level >>> tests of unrelated features. The test failures should be seen as >>> underlying problems to be addressed, and not swept under the carpet with >>> a workaround. >>> >>> 2. Even detecting whether or not Graal is enabled requires access to >>> internal API, mediated through VMProps.java in the jtreg extraPropDefns >>> mechanism, which calls down onto >>> `sun.hotspot.code.Compiler.isGraalEnabled`. Even if you're prepared to >>> swallow #1 and have clients change their code when Graal is enabled, >>> telling them how to detect if Graal is enabled is pretty dire. >> Thanks for comments. But from your point, I don't see any better solution before Graal is moved out from the jdk.internal.* modules. >> >> Is it ok to problem-list these two cases? There's no ProblemList-graal.txt in langtools. Does the ProblemList-graal mechanism access VM internals as well? >> >> -- >> Thanks, >> Pengfei >> > > It would be OK to ProblemList these tests. I can't speak to how ProblemList-graal.txt works, but I'm guessing it uses Makefile magic and does not depend on any special jtreg or VM technology. If you can create the problemlist file in test/langtools, with no other changes to test/langtools, that would be a preferable solution to the changeset that is being proposed. > > I'm not sure what you mean by "any better solution before Graal is moved out from the jdk.internal.* modules." It seems to me the problem is a missing module dependency and not by any side effect of being an "internal module". > > I'm not familiar with anything beyond the superficial details of how Graal works in OpenJDK, but it seems to be the problem starts when the special -XX options are provided on the command line .... those switches seem to implicitly change the need for the extra module to be present, thus causing existing, working code to fail. In other words, the switches are not enough when a VM with limited modules is used. From an oustsider "layman" position, maybe the code underlying those switches should ensure that the module is made available, even in the face of a --limit-modules option. One step short of that would be to detect the module is not available and to give a friendly helpful message instead of a crash and stack trace. (And, again, I'm not an expert in this area, so apologies if this has been asked/discussed/answered elsewhere.) > > -- Jon > > From Pengfei.Li at arm.com Thu Jul 25 04:06:06 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Thu, 25 Jul 2019 04:06:06 +0000 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 In-Reply-To: <84E6E19F-131B-40F9-AE9C-432D4919944A@oracle.com> References: <6f8ac3de-b0fd-626f-09bb-865a56f969b0@oracle.com> <22f18391-0a4d-8c39-9f78-7d49124be825@oracle.com> <797cc38b-9ab0-9c18-3012-38dfaabdf18b@oracle.com> <5809c7fb-16bd-b9d8-7b50-1af74b84d847@oracle.com> <84E6E19F-131B-40F9-AE9C-432D4919944A@oracle.com> Message-ID: > ProblemList-graal.txt files don't use any magic at all, neither do they depend > VMProps, special jtreg or VM technology. these are just extra problem list > files, which you are supposed to add into your command lines whenever you > are using Graal . Thanks Igor and Jon for your explanation. Christoph, would you like to add a ProblemList-graal.txt file and remove my added modules in your JDK-8228571? I see this is also your alternative fix. -- Thanks, Pengfei From christoph.langer at sap.com Thu Jul 25 12:08:28 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 25 Jul 2019 12:08:28 +0000 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 In-Reply-To: References: <6f8ac3de-b0fd-626f-09bb-865a56f969b0@oracle.com> <22f18391-0a4d-8c39-9f78-7d49124be825@oracle.com> <797cc38b-9ab0-9c18-3012-38dfaabdf18b@oracle.com> <5809c7fb-16bd-b9d8-7b50-1af74b84d847@oracle.com> <84E6E19F-131B-40F9-AE9C-432D4919944A@oracle.com> Message-ID: Hi, after catching up with this discussion, I agree that the most pragmatic fix for now would be to backout JDK-8227512 and add graal specific exclusions. That's what I do here: http://cr.openjdk.java.net/~clanger/webrevs/8228571.2/ If you all agree, I'll create another JBS Bug about the underlying issues regarding this test with limiting modules to jdk.compiler on a graal enabled VM and add that to the problem list entries. I also think that it's not the time now to introduce the machinery behind `@requires !vm.graal.enabled` to langtools testing. Please let me know what you think. Cheers Christoph > -----Original Message----- > From: Pengfei Li (Arm Technology China) > Sent: Donnerstag, 25. Juli 2019 06:06 > To: Igor Ignatyev ; Jonathan Gibbons > > Cc: Alan Bateman ; Langer, Christoph > ; compiler-dev at openjdk.java.net; hotspot- > compiler-dev at openjdk.java.net; Aleksey Shipilev ; > Vladimir Kozlov ; David Holmes > ; nd ; > daniel.daugherty at oracle.com; Maurizio Cimadamore > > Subject: RE: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms > after JDK-8227512 > > > ProblemList-graal.txt files don't use any magic at all, neither do they > depend > > VMProps, special jtreg or VM technology. these are just extra problem list > > files, which you are supposed to add into your command lines whenever > you > > are using Graal . > > Thanks Igor and Jon for your explanation. > > Christoph, would you like to add a ProblemList-graal.txt file and remove my > added modules in your JDK-8228571? I see this is also your alternative fix. > > -- > Thanks, > Pengfei From igor.ignatyev at oracle.com Thu Jul 25 14:14:56 2019 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Thu, 25 Jul 2019 07:14:56 -0700 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 Message-ID: Hi Christoph, LGTM ? Igor > On Jul 25, 2019, at 5:08 AM, Langer, Christoph wrote: > > Hi, > > after catching up with this discussion, I agree that the most pragmatic fix for now would be to backout JDK-8227512 and add graal specific exclusions. > > That's what I do here: http://cr.openjdk.java.net/~clanger/webrevs/8228571.2/ > > If you all agree, I'll create another JBS Bug about the underlying issues regarding this test with limiting modules to jdk.compiler on a graal enabled VM and add that to the problem list entries. > > I also think that it's not the time now to introduce the machinery behind `@requires !vm.graal.enabled` to langtools testing. > > Please let me know what you think. > > Cheers > Christoph > > >> -----Original Message----- >> From: Pengfei Li (Arm Technology China) >> Sent: Donnerstag, 25. Juli 2019 06:06 >> To: Igor Ignatyev ; Jonathan Gibbons >> >> Cc: Alan Bateman ; Langer, Christoph >> ; compiler-dev at openjdk.java.net; hotspot- >> compiler-dev at openjdk.java.net; Aleksey Shipilev ; >> Vladimir Kozlov ; David Holmes >> ; nd ; >> daniel.daugherty at oracle.com; Maurizio Cimadamore >> >> Subject: RE: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms >> after JDK-8227512 >> >>> ProblemList-graal.txt files don't use any magic at all, neither do they >> depend >>> VMProps, special jtreg or VM technology. these are just extra problem list >>> files, which you are supposed to add into your command lines whenever >> you >>> are using Graal . >> >> Thanks Igor and Jon for your explanation. >> >> Christoph, would you like to add a ProblemList-graal.txt file and remove my >> added modules in your JDK-8228571? I see this is also your alternative fix. >> >> -- >> Thanks, >> Pengfei > From jonathan.gibbons at oracle.com Thu Jul 25 14:44:20 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 25 Jul 2019 07:44:20 -0700 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 In-Reply-To: References: <6f8ac3de-b0fd-626f-09bb-865a56f969b0@oracle.com> <22f18391-0a4d-8c39-9f78-7d49124be825@oracle.com> <797cc38b-9ab0-9c18-3012-38dfaabdf18b@oracle.com> <5809c7fb-16bd-b9d8-7b50-1af74b84d847@oracle.com> <84E6E19F-131B-40F9-AE9C-432D4919944A@oracle.com> Message-ID: <34c5e276-fdb3-b50c-079b-424dee137b11@oracle.com> +1 -- Jon On 7/25/19 6:28 AM, Langer, Christoph wrote: > Hi, > > after catching up with this discussion, I agree that the most pragmatic fix for now would be to backout JDK-8227512 and add graal specific exclusions. > > That's what I do here: http://cr.openjdk.java.net/~clanger/webrevs/8228571.2/ > > If you all agree, I'll create another JBS Bug about the underlying issues regarding this test with limiting modules to jdk.compiler on a graal enabled VM and add that to the problem list entries. > > I also think that it's not the time now to introduce the machinery behind `@requires !vm.graal.enabled` to langtools testing. > > Please let me know what you think. > > Cheers > Christoph > >> -----Original Message----- >> From: Pengfei Li (Arm Technology China) >> Sent: Donnerstag, 25. Juli 2019 06:06 >> To: Igor Ignatyev ; Jonathan Gibbons >> >> Cc: Alan Bateman ; Langer, Christoph >> ; compiler-dev at openjdk.java.net; hotspot- >> compiler-dev at openjdk.java.net; Aleksey Shipilev ; >> Vladimir Kozlov ; David Holmes >> ; nd ; >> daniel.daugherty at oracle.com; Maurizio Cimadamore >> >> Subject: RE: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms >> after JDK-8227512 >> >>> ProblemList-graal.txt files don't use any magic at all, neither do they >> depend >>> VMProps, special jtreg or VM technology. these are just extra problem list >>> files, which you are supposed to add into your command lines whenever >> you >>> are using Graal . >> Thanks Igor and Jon for your explanation. >> >> Christoph, would you like to add a ProblemList-graal.txt file and remove my >> added modules in your JDK-8228571? I see this is also your alternative fix. >> >> -- >> Thanks, >> Pengfei From vicente.romero at oracle.com Thu Jul 25 16:23:03 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 25 Jul 2019 12:23:03 -0400 Subject: RFR: JDK-8226561: javac throws NullPointerException in Check.checkClassOverrideEqualsAndHash Message-ID: <534f0484-0c9e-73e9-7770-397473cf4b3a@oracle.com> Please review the fix for [1] at [2]. This patch fixes a NPE produced at a lint warning checking that a class overriding ::equals should override ::hashCode too. The thing is that if the class is an inexistent symbol then the method symbol returned by Types::implementation is null. The fix is checking for this null case, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8226561 [2] http://cr.openjdk.java.net/~vromero/8226561/webrev.00/ From christoph.langer at sap.com Fri Jul 26 07:30:48 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 26 Jul 2019 07:30:48 +0000 Subject: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms after JDK-8227512 In-Reply-To: <34c5e276-fdb3-b50c-079b-424dee137b11@oracle.com> References: <6f8ac3de-b0fd-626f-09bb-865a56f969b0@oracle.com> <22f18391-0a4d-8c39-9f78-7d49124be825@oracle.com> <797cc38b-9ab0-9c18-3012-38dfaabdf18b@oracle.com> <5809c7fb-16bd-b9d8-7b50-1af74b84d847@oracle.com> <84E6E19F-131B-40F9-AE9C-432D4919944A@oracle.com> <34c5e276-fdb3-b50c-079b-424dee137b11@oracle.com> Message-ID: I pushed this, creating https://bugs.openjdk.java.net/browse/JDK-8228642 to track resolving the root cause issue with --limit-modules and graal. Thanks for reviewing. /Christoph > -----Original Message----- > From: Jonathan Gibbons > Sent: Donnerstag, 25. Juli 2019 16:44 > To: Langer, Christoph ; Pengfei Li (Arm > Technology China) > Cc: Alan Bateman ; compiler- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; David > Holmes > Subject: Re: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot platforms > after JDK-8227512 > > +1 > > -- Jon > > On 7/25/19 6:28 AM, Langer, Christoph wrote: > > Hi, > > > > after catching up with this discussion, I agree that the most pragmatic fix for > now would be to backout JDK-8227512 and add graal specific exclusions. > > > > That's what I do here: > http://cr.openjdk.java.net/~clanger/webrevs/8228571.2/ > > > > If you all agree, I'll create another JBS Bug about the underlying issues > regarding this test with limiting modules to jdk.compiler on a graal enabled > VM and add that to the problem list entries. > > > > I also think that it's not the time now to introduce the machinery behind > `@requires !vm.graal.enabled` to langtools testing. > > > > Please let me know what you think. > > > > Cheers > > Christoph > > > >> -----Original Message----- > >> From: Pengfei Li (Arm Technology China) > >> Sent: Donnerstag, 25. Juli 2019 06:06 > >> To: Igor Ignatyev ; Jonathan Gibbons > >> > >> Cc: Alan Bateman ; Langer, Christoph > >> ; compiler-dev at openjdk.java.net; hotspot- > >> compiler-dev at openjdk.java.net; Aleksey Shipilev ; > >> Vladimir Kozlov ; David Holmes > >> ; nd ; > >> daniel.daugherty at oracle.com; Maurizio Cimadamore > >> > >> Subject: RE: RFR: 8228571: [TESTBUG] Fix tests failing on non-aot > platforms > >> after JDK-8227512 > >> > >>> ProblemList-graal.txt files don't use any magic at all, neither do they > >> depend > >>> VMProps, special jtreg or VM technology. these are just extra problem > list > >>> files, which you are supposed to add into your command lines whenever > >> you > >>> are using Graal . > >> Thanks Igor and Jon for your explanation. > >> > >> Christoph, would you like to add a ProblemList-graal.txt file and remove > my > >> added modules in your JDK-8228571? I see this is also your alternative fix. > >> > >> -- > >> Thanks, > >> Pengfei From jan.lahoda at oracle.com Fri Jul 26 13:05:02 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 26 Jul 2019 15:05:02 +0200 Subject: RFR: JDK-8227922: DocTreeScanner does not dive into AttributeTree.getValue() and LiteralTree.getBody() In-Reply-To: References: <68e6541c-ec82-ea6b-ca53-74512e319435@oracle.com> Message-ID: <27ead1d4-6b3d-5922-01d3-0594d837539c@oracle.com> On 22. 07. 19 18:55, Vicente Romero wrote: > looks good, the only nit is that probably the text in the CSR section: > "Compatibility Risk" could be improved with a rephrasing. At least it is > not clear to me that if a class doesn't override, for example, > visitLiteral, how that method will be invoked at all? I think that you > mean that a visitLiteral implementation in a subclass will be invoked > with, possible, more literals than before? Thanks Vicente. I tried to phrase it better in the CSR. It issue is that when there is e.g. "{@code something}" in the javadoc comment, using the DocTreeScanner before this patch didn't invoke the visitText method for "something", but after this patch, it will be called for that TextNode. Jan > > Thanks, > Vicente > > On 7/18/19 9:28 AM, Jan Lahoda wrote: >> Hi, >> >> com.sun.source.util.DocTreeScanner#visitAttribute is not scanning over >> the children of AttributeNode (i.e. AttributeNode#getValue()), and >> DocTreeScanner#visitLiteral is not scanning over the children of >> LiteralNode (i.e. LiteralNode#getBody()). The proposal here is to fix >> DocTreeScanner to scan over the children of these two node types. >> >> Webrev: http://cr.openjdk.java.net/~jlahoda/8227922/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8227922 >> >> As this change may cause new nodes to be encountered by subclasses of >> DocTreeScanner, with possibly undesirable effects (like in DocLint's >> Checker) and also affects the javadoc for the two methods, CSR appears >> to be needed as well, so I'd like to ask for a review of that as well: >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8228371 >> >> How does this look? >> >> Thanks, >> ??? Jan > From vicente.romero at oracle.com Fri Jul 26 14:49:49 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 26 Jul 2019 10:49:49 -0400 Subject: RFR: JDK-8227922: DocTreeScanner does not dive into AttributeTree.getValue() and LiteralTree.getBody() In-Reply-To: <27ead1d4-6b3d-5922-01d3-0594d837539c@oracle.com> References: <68e6541c-ec82-ea6b-ca53-74512e319435@oracle.com> <27ead1d4-6b3d-5922-01d3-0594d837539c@oracle.com> Message-ID: <698c17f4-2c59-7172-590c-69162270c1ff@oracle.com> I see, thanks it is clearer to me now. I'm OK with the last version Vicente On 7/26/19 9:05 AM, Jan Lahoda wrote: > On 22. 07. 19 18:55, Vicente Romero wrote: >> looks good, the only nit is that probably the text in the CSR >> section: "Compatibility Risk" could be improved with a rephrasing. At >> least it is not clear to me that if a class doesn't override, for >> example, visitLiteral, how that method will be invoked at all? I >> think that you mean that a visitLiteral implementation in a subclass >> will be invoked with, possible, more literals than before? > > Thanks Vicente. I tried to phrase it better in the CSR. It issue is > that when there is e.g. "{@code something}" in the javadoc comment, > using the DocTreeScanner before this patch didn't invoke the visitText > method for "something", but after this patch, it will be called for > that TextNode. > > Jan > >> >> Thanks, >> Vicente >> >> On 7/18/19 9:28 AM, Jan Lahoda wrote: >>> Hi, >>> >>> com.sun.source.util.DocTreeScanner#visitAttribute is not scanning >>> over the children of AttributeNode (i.e. AttributeNode#getValue()), >>> and DocTreeScanner#visitLiteral is not scanning over the children of >>> LiteralNode (i.e. LiteralNode#getBody()). The proposal here is to >>> fix DocTreeScanner to scan over the children of these two node types. >>> >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8227922/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8227922 >>> >>> As this change may cause new nodes to be encountered by subclasses >>> of DocTreeScanner, with possibly undesirable effects (like in >>> DocLint's Checker) and also affects the javadoc for the two methods, >>> CSR appears to be needed as well, so I'd like to ask for a review of >>> that as well: >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8228371 >>> >>> How does this look? >>> >>> Thanks, >>> ??? Jan >> From jan.lahoda at oracle.com Fri Jul 26 15:25:54 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 26 Jul 2019 17:25:54 +0200 Subject: RFR: JDK-8228451: NPE in Attr.java when -XDshould-stop.ifError=FLOW Message-ID: <07f2249d-36a3-022e-2c37-5badf7157d66@oracle.com> Hi, Consider code like this: --- public class T { v + v n; } --- javac's parser will parse this as a variable of type "v" without a name, and another variable of type "v" with a name "n", skipping the "+". But if the code is: --- public class T { v += v n; } --- (note the change of '+' to compound assignment '+='), javac will parse it as a variable with name "n" and type "v += v" and allows the compilation to continue to Attr, where it eventually fails with: --- java.lang.AssertionError: Unexpected tree: v += v with kind: PLUS_ASSIGNMENT within: v += v with kind: PLUS_ASSIGNMENT at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162) at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.validateAnnotatedType(Attr.java:5154) at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitVarDef(Attr.java:5000) ... --- It seems the reason for this difference is incorrect reliance on operator priorities in JavacParser.term(). The proposed fix is to ignore compound operators in type mode in term(), and hence treat += similarly to +, parsing "v += v n;" as two variables, skipping '+='. Part of the problem in the original testcase is insufficient error recovery for parsing broken enums, I've split that into a separate bug - JDK-8228647. JBS: https://bugs.openjdk.java.net/browse/JDK-8228451 Webrev: http://cr.openjdk.java.net/~jlahoda/8228451/webrev.00/ How does this look? Thanks, Jan From ronshapiro at google.com Fri Jul 26 21:05:02 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Fri, 26 Jul 2019 17:05:02 -0400 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation Message-ID: Hi, Please review this change to speed up Resolve.findMethod for large classes that have large numbers of (super)interfaces webrev: http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8228675 Thanks, Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Mon Jul 29 11:31:21 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 29 Jul 2019 13:31:21 +0200 Subject: RFR: JDK-8228647: Broken enum produce inconvenient errors and AST Message-ID: <1edb1a8f-fe84-818e-09a5-5d4364b5249f@oracle.com> Hi, The javac's parser does not recover well from enums that have missing ',' between the enum constants, or are missing the ';' between constants and other members. For example, consider: --- $ cat E.java public enum E { A B, C; public void t1() {} public void t2() {} } $ javac E.java E.java:3: error: ',', '}', or ';' expected B, ^ E.java:3: error: '}' expected B, ^ E.java:5: error: class, interface, or enum expected public void t1() {} ^ E.java:6: error: class, interface, or enum expected public void t2() {} ^ 4 errors --- The reason for this is that the parser stops looking for enum constants if there is no ',' after a constant, and does not try to parse other members if there is no ';' after the constants block. I.e. in the example above, it will stop looking for enum constants after "A" (no comma), and won't look for further members because there is no semicolon, after which the parser is somewhat lost. The patch proposed herein is trying to improve the situation by parsing member until the closing semicolon, estimating whether the upcoming member is an enum constant, other member, or "unknown". Unknown members are parsed either as enum constants or ordinary members, depending on whether they are before or after ';' that separates enum constants and members. One limitation of this estimate are members which start with an annotation - these will be currently categorized as "unknown", and parsed based on their position. If needed, we could improve the behavior by estimating the category only after annotations are parsed. This is a spin off from JDK-8228451. JBS: https://bugs.openjdk.java.net/browse/JDK-8228647 Webrev: http://cr.openjdk.java.net/~jlahoda/8228647/webrev.00/index.html How does this look? Thanks, Jan From jan.lahoda at oracle.com Mon Jul 29 15:23:53 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 29 Jul 2019 17:23:53 +0200 Subject: RFR: JDK-8228502: javac crashed on a broken classfile with ConstantValue attribute on a field of type Object Message-ID: <1da20af5-ae6c-06d2-b1dc-b4608f517521@oracle.com> Hi, Consider a classfile that has a field with the ConstantValue attribute (pointing to a constant value of type String), but the type of the field is j.l.Object. This crashes javac (see the JBS entry to a stacktrace). The proposed solution is to throw a BadClassFile exception when this situation is detected, which is then handled using the existing mechanisms. JBS: https://bugs.openjdk.java.net/browse/JDK-8228502 Webrev: http://cr.openjdk.java.net/~jlahoda/8228502/webrev.00/ How does this look? Thanks, Jan From vicente.romero at oracle.com Tue Jul 30 14:28:19 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 30 Jul 2019 10:28:19 -0400 Subject: RFR: JDK-8228502: javac crashed on a broken classfile with ConstantValue attribute on a field of type Object In-Reply-To: <1da20af5-ae6c-06d2-b1dc-b4608f517521@oracle.com> References: <1da20af5-ae6c-06d2-b1dc-b4608f517521@oracle.com> Message-ID: <322faa92-f1ec-0b43-66bf-da2483ac9ccd@oracle.com> looks good, Vicente On 7/29/19 11:23 AM, Jan Lahoda wrote: > Hi, > > Consider a classfile that has a field with the ConstantValue attribute > (pointing to a constant value of type String), but the type of the > field is j.l.Object. This crashes javac (see the JBS entry to a > stacktrace). The proposed solution is to throw a BadClassFile > exception when this situation is detected, which is then handled using > the existing mechanisms. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8228502 > Webrev: http://cr.openjdk.java.net/~jlahoda/8228502/webrev.00/ > > How does this look? > > Thanks, > ??? Jan From vicente.romero at oracle.com Tue Jul 30 15:07:20 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 30 Jul 2019 11:07:20 -0400 Subject: RFR: JDK-8228647: Broken enum produce inconvenient errors and AST In-Reply-To: <1edb1a8f-fe84-818e-09a5-5d4364b5249f@oracle.com> References: <1edb1a8f-fe84-818e-09a5-5d4364b5249f@oracle.com> Message-ID: <9e03f69b-cdd3-89d8-7c35-899fffa1626a@oracle.com> looks good, Vicente On 7/29/19 7:31 AM, Jan Lahoda wrote: > Hi, > > The javac's parser does not recover well from enums that have missing > ',' between the enum constants, or are missing the ';' between > constants and other members. For example, consider: > --- > $ cat E.java > public enum E { > ??? A > ??? B, > ??? C; > ??? public void t1() {} > ??? public void t2() {} > } > $ javac E.java > E.java:3: error: ',', '}', or ';' expected > ??? B, > ??? ^ > E.java:3: error: '}' expected > ??? B, > ???? ^ > E.java:5: error: class, interface, or enum expected > ??? public void t1() {} > ?????????? ^ > E.java:6: error: class, interface, or enum expected > ??? public void t2() {} > ?????????? ^ > 4 errors > --- > > The reason for this is that the parser stops looking for enum > constants if there is no ',' after a constant, and does not try to > parse other members if there is no ';' after the constants block. I.e. > in the example above, it will stop looking for enum constants after > "A" (no comma), and won't look for further members because there is no > semicolon, after which the parser is somewhat lost. > > The patch proposed herein is trying to improve the situation by > parsing member until the closing semicolon, estimating whether the > upcoming member is an enum constant, other member, or "unknown". > Unknown members are parsed either as enum constants or ordinary > members, depending on whether they are before or after ';' that > separates enum constants and members. One limitation of this estimate > are members which start with an annotation - these will be currently > categorized as "unknown", and parsed based on their position. If > needed, we could improve the behavior by estimating the category only > after annotations are parsed. > > This is a spin off from JDK-8228451. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8228647 > Webrev: http://cr.openjdk.java.net/~jlahoda/8228647/webrev.00/index.html > > How does this look? > > Thanks, > ??? Jan