From cushon at google.com Wed Apr 1 00:58:32 2020 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 31 Mar 2020 17:58:32 -0700 Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: References: <240132e3-a88e-ef49-54e2-c9ac5309bb19@oracle.com> <1ba99b6e-3635-5962-7ab6-c1fb883df0bc@oracle.com> Message-ID: Deferring the code golf approach makes sense to me, thanks. It might be an interesting option for code generators that are running into this limit, and that are willing to generate bytecode directly instead of source. I did some benchmarking of the original patch, and found that the difference is within measurement error and that the assembly appears to be identical, as expected. The benchmark is just looking at steady-state calls to values(), I'm not sure what the best way to measure the effect of the additional method call in the clinit would be. The code is here: http://cr.openjdk.java.net/~cushon/benchmark/JDK-8241798/ Remy, you pointed out that this could make it harder for AOT compilers to find the value of the constants without executing the clinit. Do you have suggestions for quantifying that risk? I tried running a demo through GraalVM/native-image for fun and it didn't seem to cause any problems. Also, I fixed up the unnecessary `final` modifier in the synthetic values methods, and uploaded a new webrev: http://cr.openjdk.java.net/~cushon/8241798/webrev.01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Wed Apr 1 10:13:16 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 1 Apr 2020 12:13:16 +0200 (CEST) Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: References: <240132e3-a88e-ef49-54e2-c9ac5309bb19@oracle.com> <1ba99b6e-3635-5962-7ab6-c1fb883df0bc@oracle.com> Message-ID: <447867370.1743633.1585735996671.JavaMail.zimbra@u-pem.fr> > De: "Liam Miller-Cushon" > ?: "Brian Goetz" > Cc: "Maurizio Cimadamore" , "compiler-dev" > , "Remi Forax" > Envoy?: Mercredi 1 Avril 2020 02:58:32 > Objet: Re: RFR: JDK-8241798: Allow enums to have more constants > Deferring the code golf approach makes sense to me, thanks. It might be an > interesting option for code generators that are running into this limit, and > that are willing to generate bytecode directly instead of source. > I did some benchmarking of the original patch, and found that the difference is > within measurement error and that the assembly appears to be identical, as > expected. The benchmark is just looking at steady-state calls to values(), I'm > not sure what the best way to measure the effect of the additional method call > in the clinit would be. The code is here: [ > http://cr.openjdk.java.net/~cushon/benchmark/JDK-8241798/ | > http://cr.openjdk.java.net/~cushon/benchmark/JDK-8241798/ ] > Remy, you pointed out that this could make it harder for AOT compilers to find > the value of the constants without executing the clinit. Do you have > suggestions for quantifying that risk? I tried running a demo through > GraalVM/native-image for fun and it didn't seem to cause any problems. I was talking about the code proposed by Brian (create the array first and then initialize the enum constants later), I don't think this is an issue with your proposed patch (delegate the creation of the array to an helper method). Also playing with native image (for something else), i've found it very smart, at least smarter than the other AOT system i've used previously. I think native-image works too well to fairly represent the different other existing AOT systems that consume bytecodes. > Also, I fixed up the unnecessary `final` modifier in the synthetic values > methods, and uploaded a new webrev: [ > http://cr.openjdk.java.net/~cushon/8241798/webrev.01/ | > http://cr.openjdk.java.net/~cushon/8241798/webrev.01/ ] Thank you for that, You have forgotten to update the corresponding comment // private static final synthetic T[] #values() { return new T[] { a, b, c }; } Otherwise, patch looks good to me. cheers, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Wed Apr 1 12:34:18 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Wed, 1 Apr 2020 14:34:18 +0200 Subject: RFR: JDK-8239544 : Javac does not respect should-stop.ifNoError policy to stop after CompileState PARSE, ENTER and PROCESS In-Reply-To: References: <5E286896-78B2-4680-B56D-6E937366A6F7@oracle.com> Message-ID: <4FD5FA94-B819-4AED-B689-87C1BE983896@oracle.com> Hi, Jan showed me a case where previous fix potentially hides deferred enter errors and also proposed even less intrusive fix. new webrev: http://cr.openjdk.java.net/~asotona/8239544/webrev.02/ Mach5 build passes all Tier1, Tier2 and Tier3 tests Thank you for the review, Adam > On 26 Mar 2020, at 15:45, Adam Sotona wrote: > > Hi, > I've returned back to the issue and found the patch is affecting annotation processing negatively for cases of "recoverable" errors. > Here is slightly modified fix that does not cause premature stop before annotation processing in such specific situations. > Also the T823954.java test had to be written a bit more complex way to correctly test annotation processing stopping. > > new webrev: http://cr.openjdk.java.net/~asotona/8239544/webrev.01/ > > Mach5 build passed Tier1, Tier2 and Tier3 tests (except for java/net/httpclient/FilePublisher/FilePublisherPermsTest.java, which seems to be unrelated). > > Thanks for your review, > Adam > >> On 24 Mar 2020, at 13:04, Jim Laskey > wrote: >> >> No problem. Just get one other reviewer. >> >>> On Mar 23, 2020, at 12:44 PM, Adam Sotona > wrote: >>> >>> Hi, >>> I would like to ask you for review of the JavaCompiler patch fixing its response to should-stop.ifNoError= option for PARSE, ENTER and PROCESS compiler states. >>> The patch also includes new T8239544.java matrix regression test validating the compiler really stops at the requested states even under various compiler policies. >>> The most critical part of the fix was to do not affect existing (golden-file) tests expecting exact compiler errors and also do not affect MultiTaskListener expected behavior (and related tests). >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8239544 >>> webrev: http://cr.openjdk.java.net/~asotona/8239544/webrev.00/ >>> >>> Mach5 build passed Tier1, Tier2 and Tier3 tests >>> >>> Thank you, >>> Adam >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Wed Apr 1 18:32:42 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 1 Apr 2020 20:32:42 +0200 Subject: Enhancing expressions with mutability? In-Reply-To: <6a4113cb-5e51-4406-cf26-d24d8474f257@oracle.com> References: <9238fa7d-3035-6f10-7334-3772df712584@oracle.com> <3C71B207-24D0-429F-80A9-EB9C6E2AC381@oracle.com> <6a4113cb-5e51-4406-cf26-d24d8474f257@oracle.com> Message-ID: On Mon, 23 Mar 2020 at 20:33, Maurizio Cimadamore wrote: > > > I'm planning to employ experimentally to solve some > > tricky performance issues in javac's type inference solving system, > > see [3]. > > With respect to implement type inference using these algorithms, I feel > less sanguine. So, here is a concrete experiment: https://bugs.openjdk.java.net/secure/attachment/87565/learning.patch Quoting from my comment on JBS, it uses a parallel genetic algorithm to solve all contextual inference variables at once requiring only a small subset of propagation steps which reduces JDK-8152289 example's compilation time to a couple of seconds! Note that this heuristic is dedicated to similar examples and the usual inference algorithm is still used if the former doesn't converge rapidly enough. The current design is absolutely not affected as this implementation additionally uses very expressive mutable expressions like "Term gene = (`able).link(`adn, `undetvars.get(i), `type());" employing the quotation operator `. It simply requires a boot JDK (14) including the patch minus inference changes in Attr, Infer & InferenceContext. Still not convinced? Ciao, Bernard From maurizio.cimadamore at oracle.com Wed Apr 1 20:59:30 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 1 Apr 2020 21:59:30 +0100 Subject: Enhancing expressions with mutability? In-Reply-To: References: <9238fa7d-3035-6f10-7334-3772df712584@oracle.com> <3C71B207-24D0-429F-80A9-EB9C6E2AC381@oracle.com> <6a4113cb-5e51-4406-cf26-d24d8474f257@oracle.com> Message-ID: <069958fe-9d79-3482-d771-58a319eb5e4f@oracle.com> On 01/04/2020 19:32, B. Blaser wrote: > On Mon, 23 Mar 2020 at 20:33, Maurizio Cimadamore > wrote: >>> I'm planning to employ experimentally to solve some >>> tricky performance issues in javac's type inference solving system, >>> see [3]. >> With respect to implement type inference using these algorithms, I feel >> less sanguine. > So, here is a concrete experiment: > > https://bugs.openjdk.java.net/secure/attachment/87565/learning.patch > > Quoting from my comment on JBS, it uses a parallel genetic algorithm > to solve all contextual inference variables at once requiring only a > small subset of propagation steps which reduces JDK-8152289 example's > compilation time to a couple of seconds! Note that this heuristic is > dedicated to similar examples and the usual inference algorithm is > still used if the former doesn't converge rapidly enough. > > The current design is absolutely not affected as this implementation > additionally uses very expressive mutable expressions like "Term gene > = (`able).link(`adn, `undetvars.get(i), `type());" employing the > quotation operator `. It simply requires a boot JDK (14) including the > patch minus inference changes in Attr, Infer & InferenceContext. > > Still not convinced? Sadly yes :-) I mentioned a number of issues, performances aside, in my previous email; error recovery seems particularly nasty with an approach such as this, but more generally, having two inference engines opens up a whole new can of worms, where now you have two implementations to maintain and keep in sync, and there are many more things that can go wrong - and testing becomes similarly much harder. What if the two algorithms don't agree? Might we end up in situations where, depending on how much time one engine takes to converge, we get an error or a failure because a different solver is used? This is the kind of problems that worry me. In my eyes, 8152289 is "just" a performance bug, and one that we know how to solve (*), but we did not get enough time to work on it. Also, as far as I know, the pathological cases described in that bug are the only thing left for us to solve performance-wise (e.g. when speaking about programs which keep running through inference for minutes). Coming up with a new inference engine to solve these classes of problem is, in my opinion, the wrong way to go about things. It might have been a nice validation for your mutable expression experiment, but we can't consider that as a candidate fix for JDK-8152289, sorry. Maurizio (*) The crux of the issue in that bug is detecting that many inference variables are just "duplicates" of each other, so they are going to get exactly same bounds, and be resolved in exactly the same way. Vicente, Dan and I have brainstormed months ago about ways to take an inference context, minimize it aggressively, solve the minimized context, the project resolutions back to the original context. We already applied a similar techniques in cases like a(b(c(d .... ) And that worked really well. But the logic we have implemented has some limitations and, currently, it doesn't scale to cases where hundreds of tvars are added to the _same_ inference context. But this is fixable, with some work. Maurizio > > Ciao, > Bernard From jan.lahoda at oracle.com Thu Apr 2 11:48:07 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 2 Apr 2020 13:48:07 +0200 Subject: RFR: JDK-8239544 : Javac does not respect should-stop.ifNoError policy to stop after CompileState PARSE, ENTER and PROCESS In-Reply-To: <4FD5FA94-B819-4AED-B689-87C1BE983896@oracle.com> References: <5E286896-78B2-4680-B56D-6E937366A6F7@oracle.com> <4FD5FA94-B819-4AED-B689-87C1BE983896@oracle.com> Message-ID: Looks Ok to me. Jan On 01. 04. 20 14:34, Adam Sotona wrote: > Hi, > Jan showed me a case where previous fix potentially hides deferred enter > errors and also proposed even less intrusive fix. > new webrev: http://cr.openjdk.java.net/~asotona/8239544/webrev.02/ > > Mach5 build passes all Tier1, Tier2 and Tier3 tests > > Thank you for the review, > Adam > >> On 26 Mar 2020, at 15:45, Adam Sotona > > wrote: >> >> Hi, >> I've returned back to the issue and found the patch is affecting >> annotation processing negatively for cases of "recoverable" errors. >> Here is slightly modified fix that does not cause premature stop >> before annotation processing in such specific situations. >> Also the T823954.java test had to be written a bit more complex way to >> correctly test annotation processing stopping. >> >> new webrev: http://cr.openjdk.java.net/~asotona/8239544/webrev.01/ >> >> Mach5 build passed Tier1, Tier2 and Tier3 tests (except for >> java/net/httpclient/FilePublisher/FilePublisherPermsTest.java, which >> seems to be unrelated). >> >> Thanks for your review, >> Adam >> >>> On 24 Mar 2020, at 13:04, Jim Laskey >> > wrote: >>> >>> No problem. Just get one other reviewer. >>> >>>> On Mar 23, 2020, at 12:44 PM, Adam Sotona >>> > wrote: >>>> >>>> Hi, >>>> I would like to ask you for review of the JavaCompiler patch fixing >>>> its response to should-stop.ifNoError= option for PARSE, ENTER and >>>> PROCESS compiler states. >>>> The patch also includes new?T8239544.java?matrix regression test >>>> validating the compiler really stops at the requested states even >>>> under various compiler policies. >>>> The most critical part of the fix was to do not affect existing >>>> (golden-file) tests expecting exact compiler errors and also do not >>>> affect MultiTaskListener expected behavior (and related?tests). >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8239544 >>>> webrev: http://cr.openjdk.java.net/~asotona/8239544/webrev.00/ >>>> >>>> Mach5 build passed Tier1, Tier2 and Tier3 tests >>>> >>>> Thank you, >>>> Adam >>>> >>> >> > From bsrbnd at gmail.com Sun Apr 5 18:25:25 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Sun, 5 Apr 2020 20:25:25 +0200 Subject: Enhancing expressions with mutability? In-Reply-To: <069958fe-9d79-3482-d771-58a319eb5e4f@oracle.com> References: <9238fa7d-3035-6f10-7334-3772df712584@oracle.com> <3C71B207-24D0-429F-80A9-EB9C6E2AC381@oracle.com> <6a4113cb-5e51-4406-cf26-d24d8474f257@oracle.com> <069958fe-9d79-3482-d771-58a319eb5e4f@oracle.com> Message-ID: On Wed, 1 Apr 2020 at 22:59, Maurizio Cimadamore wrote: > > On 01/04/2020 19:32, B. Blaser wrote: > > So, here is a concrete experiment: > > > > https://bugs.openjdk.java.net/secure/attachment/87565/learning.patch > > > > Quoting from my comment on JBS, it uses a parallel genetic algorithm > > to solve all contextual inference variables at once requiring only a > > small subset of propagation steps which reduces JDK-8152289 example's > > compilation time to a couple of seconds! Note that this heuristic is > > dedicated to similar examples and the usual inference algorithm is > > still used if the former doesn't converge rapidly enough. > > > > The current design is absolutely not affected as this implementation > > additionally uses very expressive mutable expressions like "Term gene > > = (`able).link(`adn, `undetvars.get(i), `type());" employing the > > quotation operator `. It simply requires a boot JDK (14) including the > > patch minus inference changes in Attr, Infer & InferenceContext. > > > > Still not convinced? > > Sadly yes :-) Paradoxically, I agree with you, a few questions still remain... > I mentioned a number of issues, performances aside, in my previous > email; error recovery seems particularly nasty with an approach such as > this, Yes, this is the most problematic issue but I'm rather confident that if a solution exists the genetic algorithm will converge rapidly enough (less than 10 generations) otherwise we can consider that an error occurred. Of course, this would have to be confirmed with many measures but as far as I know, * either the context has few inference variables (1 to 4) and a clever choice of the initial population might simply perform an exhaustive combinatorial search using multiple threads, * or the context has potentially many variables which are most of the time exact copies of themselves resulting in very low liberty-degrees and thus a very fast convergence too. Of course, you might argue that this genetic engine might fail to infer valid expressions but I believe this is inherent to inference algorithms in general. Recall JDK-8219318, you said yourself that the current engine might be "out of gas" in some situations, and if I remember well, this unresolved issue comes from a weakness in propagation rules which seems not so trivial to be solved... and although the current genetic prototype isn't evolved enough to resolve it yet, I'm rather confident that it might do that intrinsically with some more maturation! > but more generally, having two inference engines opens up a whole > new can of worms, where now you have two implementations to maintain and > keep in sync, and there are many more things that can go wrong - and > testing becomes similarly much harder. What if the two algorithms don't > agree? Might we end up in situations where, depending on how much time > one engine takes to converge, we get an error or a failure because a > different solver is used? This is the kind of problems that worry me. That's right, we cannot live with two different engines. The current prototype is only a first partial attempt, but the goal of this experiment would be to finish with a complete genetic inference engine to be compared with the existing more formal one. > In my eyes, 8152289 is "just" a performance bug, and one that we know > how to solve (*), but we did not get enough time to work on it. Also, as > far as I know, the pathological cases described in that bug are the only > thing left for us to solve performance-wise (e.g. when speaking about > programs which keep running through inference for minutes). Coming up > with a new inference engine to solve these classes of problem is, in my > opinion, the wrong way to go about things. It might have been a nice > validation for your mutable expression experiment, Sure, it is ;-) > but we can't consider > that as a candidate fix for JDK-8152289, sorry. Not as is, of course, as discussed above. Bernard > Maurizio From maurizio.cimadamore at oracle.com Mon Apr 6 10:33:49 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 6 Apr 2020 11:33:49 +0100 Subject: Enhancing expressions with mutability? In-Reply-To: References: <9238fa7d-3035-6f10-7334-3772df712584@oracle.com> <3C71B207-24D0-429F-80A9-EB9C6E2AC381@oracle.com> <6a4113cb-5e51-4406-cf26-d24d8474f257@oracle.com> <069958fe-9d79-3482-d771-58a319eb5e4f@oracle.com> Message-ID: On 05/04/2020 19:25, B. Blaser wrote: > On Wed, 1 Apr 2020 at 22:59, Maurizio Cimadamore > wrote: >> On 01/04/2020 19:32, B. Blaser wrote: >>> So, here is a concrete experiment: >>> >>> https://bugs.openjdk.java.net/secure/attachment/87565/learning.patch >>> >>> Quoting from my comment on JBS, it uses a parallel genetic algorithm >>> to solve all contextual inference variables at once requiring only a >>> small subset of propagation steps which reduces JDK-8152289 example's >>> compilation time to a couple of seconds! Note that this heuristic is >>> dedicated to similar examples and the usual inference algorithm is >>> still used if the former doesn't converge rapidly enough. >>> >>> The current design is absolutely not affected as this implementation >>> additionally uses very expressive mutable expressions like "Term gene >>> = (`able).link(`adn, `undetvars.get(i), `type());" employing the >>> quotation operator `. It simply requires a boot JDK (14) including the >>> patch minus inference changes in Attr, Infer & InferenceContext. >>> >>> Still not convinced? >> Sadly yes :-) > Paradoxically, I agree with you, a few questions still remain... > >> I mentioned a number of issues, performances aside, in my previous >> email; error recovery seems particularly nasty with an approach such as >> this, > Yes, this is the most problematic issue but I'm rather confident that > if a solution exists the genetic algorithm will converge rapidly > enough (less than 10 generations) otherwise we can consider that an > error occurred. Of course, this would have to be confirmed with many > measures but as far as I know, > * either the context has few inference variables (1 to 4) and a clever > choice of the initial population might simply perform an exhaustive > combinatorial search using multiple threads, > * or the context has potentially many variables which are most of the > time exact copies of themselves resulting in very low liberty-degrees > and thus a very fast convergence too. > > Of course, you might argue that this genetic engine might fail to > infer valid expressions but I believe this is inherent to inference > algorithms in general. Recall JDK-8219318, you said yourself that the > current engine might be "out of gas" in some situations, Let me underline all the things that raise my concern level with your message: * " I'm rather confident that if a solution exists the genetic algorithm will converge rapidly enough (less than 10 generations) otherwise we can consider that an error occurred" - pretty sure that this statement alone is unjustifiable from a JLS perspective, where subtyping chains can be arbitrarily long and complex * "... either the context has few inference variables (1 to 4)" - in such cases the existing inference engine is uber fast, why would you want to improve it? * "combinatorial search using multiple threads" - and... even more complexity. * "or the context has potentially many variables which are most of the time exact copies of themselves" - another assumption which holds for the case you are looking at, but doesn't hold in general. When working with collectors I've seen many cases of inference context which, after normalization (e.g. equivalent type variables dropped) were still in the 10-15 mark. In any case I think we're talking past each other here, and using the term inference engine for different purposes. When I said in my comment to JDK-8219318 that the engine was running out of gas I meant the engine "as specified in the JLS". In fact, this thread seems to forget that, no matter what the impl will do, it will have to be backed up by whatever text is in the JLS - each pass and each fail will have to be explained in terms of normative text in the spec. So, popping back, JDK-8219318 and JDK-8152289 are two _very_ different issues; the former is essentially tied to how inference works in the spec; the latter is an implementation performance issue. I already talked at length as to why I wouldn't like the javac codebase to evolve and embrace some kind of bi-modal genetic inference engine in order to speed up performances. I think that, by extension, by skepticism also applies (in much greater way) to _change the language specifications_ to allow for such changes (e.g. to support JDK-8219318). Popping back even more; we started this thread by discussing your proposal for mutable expressions (although this list shouldn't be used for proposing language changes, but, fine) - both Paul and I replied connecting the work you did with some of the stuff we have in the oven. From there we descended into some kind of inference engine war, which I don't think was the point of your original communication? Inference engine changes have a lot of strings attached to them; it's not about the code and, to a degree, not even about performance, as long as it's acceptable - which I think it is, it's primarily about maintenance, and conformance with the spec. Invariably issues will pop up, and stuff will break, and when that happens, the more similar the spec is to the implementation, the better. So, in my view, the way to move the inference code forward is to make it _more in sync_ with the JLS, so that concepts are implemented in a more 1-1 way (which wasn't possible at the outset in Java 8 as we had to be compatible with pre Java 8 inference - this requirement might go away at some point, so we might be able to cleanup some more). Maurizio From jan.lahoda at oracle.com Mon Apr 6 11:10:54 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 6 Apr 2020 13:10:54 +0200 Subject: RFR: JDK-8240658: Code completion not working for lambdas in method invocations that require type inference In-Reply-To: <7bff733d-a800-a006-731b-e34375f379e2@oracle.com> References: <7bff733d-a800-a006-731b-e34375f379e2@oracle.com> Message-ID: <56f7c9ac-d6db-bec3-414e-0f760b6d4278@oracle.com> Hi, Unfortunately turned out that there's a small bug in the patch - for expression lambdas, we don't need to (and should not) append a return statement (expression lambdas have an "implicit" return; and we cannot cast the expression to block). Diff from the previous iteration: http://cr.openjdk.java.net/~jlahoda/8240658/webrev.00-01/ Updated patch: http://cr.openjdk.java.net/~jlahoda/8240658/webrev.01/ Any comments are welcome! Thanks, Jan On 18. 03. 20 20:26, Vicente Romero wrote: > looks good, > Vicente > > On 3/13/20 8:20 AM, Jan Lahoda wrote: >> Hi, >> >> When a method invocation requires type inference, and the user is in >> the process of typing of a (block) lambda that is a parameter to the >> method invocation, javac may not, in some cases, perform the type >> inference, which then may lead to non working code completion in >> JShell (and possibly other tools). >> >> For example (in JShell): >> Arrays.stream(new Integer[]{1}).forEach(v -> { System.err.println(v. >> >> and press - this leads to no proposals currently, as the type of >> "v" is not inferred. >> >> The idea of the proposed patch is to improve the recovery in cases >> significant for cases where the text is being typed, and allow type >> inference in these cases. The type of "v" is then inferred, and the >> code completion works. >> >> Proposed patch: >> http://cr.openjdk.java.net/~jlahoda/8240658/webrev.00/ >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8240658 >> >> Thanks, >> ??? Jan > From bsrbnd at gmail.com Mon Apr 6 12:25:31 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 6 Apr 2020 14:25:31 +0200 Subject: Enhancing expressions with mutability? In-Reply-To: References: <9238fa7d-3035-6f10-7334-3772df712584@oracle.com> <3C71B207-24D0-429F-80A9-EB9C6E2AC381@oracle.com> <6a4113cb-5e51-4406-cf26-d24d8474f257@oracle.com> <069958fe-9d79-3482-d771-58a319eb5e4f@oracle.com> Message-ID: Thanks for your detailed explanation, Maurizio. On Mon, 6 Apr 2020 at 12:34, Maurizio Cimadamore wrote: > > Popping back even more; we started this thread by discussing your > proposal for mutable expressions (although this list shouldn't be used > for proposing language changes, but, fine) - both Paul and I replied > connecting the work you did with some of the stuff we have in the oven. > > From there we descended into some kind of inference engine war, which I > don't think was the point of your original communication? Of course, my initial intention was only to suggest enhancing expressions with mutability which I tried to illustrate with a concrete prototype using the quotation operator and connecting it to Lisp's S-Expressions. Then, speaking about potential applications, we deviate to inference engine alternative implementations and their potential abilities to solve some known "pathological" issues. However, these were just raw ideas I wanted to experiment with some prototype which I shared in the hope that it might be useful. Finally, finding the right list to discuss about this wasn't an easy task and I thought "discuss" (or maybe "compiler-dev") were appropriate since such proposals may lead to new project creation but you're welcome to forward it to the right list or to ask me to do so if necessary. Cheers, Bernard From james.laskey at oracle.com Mon Apr 6 14:33:31 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 6 Apr 2020 11:33:31 -0300 Subject: RFR: JDK-8241741 - Implement Text Blocks as a standard feature in javac Message-ID: Please take the time to review the code changes to make Text Blocks a standard feature for Java. The changes are pretty light-weight and shouldn't take too long to review. Mostly involves removing "preview" trappings. Cheers, -- Jim webrev: http://cr.openjdk.java.net/~jlaskey/8241741/webrev-00 JBS: https://bugs.openjdk.java.net/browse/JDK-8241741 CSR: https://bugs.openjdk.java.net/browse/JDK-8241745 JEP: https://bugs.openjdk.java.net/browse/JDK-8236934 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Mon Apr 6 14:41:59 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 6 Apr 2020 16:41:59 +0200 Subject: RFR: JDK-8241741 - Implement Text Blocks as a standard feature in javac In-Reply-To: References: Message-ID: <50586c07-6c0b-66e5-4257-8f016b5492b9@oracle.com> Hi Jim, The changes to: src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties Probably mean text blocks will be allowed to all source levels (i.e. also for --release 14; --release 8; etc.) Is that intentional? Also, for tests like (but also many others): test/jdk/java/lang/String/Formatted.java why keep "@run main/othervm"? Should just "@run main" work as well (but faster)? Jan On 06. 04. 20 16:33, Jim Laskey wrote: > Please take the time to review the code changes to make Text Blocks a > standard feature for Java. The changes are pretty light-weight and > shouldn't take too long to review. Mostly involves removing "preview" > trappings. > > Cheers, > > -- Jim > > > webrev: http://cr.openjdk.java.net/~jlaskey/8241741/webrev-00 > > JBS: https://bugs.openjdk.java.net/browse/JDK-8241741 > CSR: https://bugs.openjdk.java.net/browse/JDK-8241745 > JEP: https://bugs.openjdk.java.net/browse/JDK-8236934 > From james.laskey at oracle.com Mon Apr 6 15:50:08 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 6 Apr 2020 12:50:08 -0300 Subject: RFR: JDK-8241741 - Implement Text Blocks as a standard feature in javac In-Reply-To: <50586c07-6c0b-66e5-4257-8f016b5492b9@oracle.com> References: <50586c07-6c0b-66e5-4257-8f016b5492b9@oracle.com> Message-ID: Updated webrev: http://cr.openjdk.java.net/~jlaskey/8241741/webrev-01 > On Apr 6, 2020, at 11:41 AM, Jan Lahoda wrote: > > Hi Jim, > > The changes to: > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties > > Probably mean text blocks will be allowed to all source levels (i.e. also for --release 14; --release 8; etc.) Is that intentional? > > Also, for tests like (but also many others): > test/jdk/java/lang/String/Formatted.java > > why keep "@run main/othervm"? Should just "@run main" work as well (but faster)? > > Jan > > On 06. 04. 20 16:33, Jim Laskey wrote: >> Please take the time to review the code changes to make Text Blocks a standard feature for Java. The changes are pretty light-weight and shouldn't take too long to review. Mostly involves removing "preview" trappings. >> Cheers, >> -- Jim >> webrev: http://cr.openjdk.java.net/~jlaskey/8241741/webrev-00 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8241741 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8241745 >> JEP: https://bugs.openjdk.java.net/browse/JDK-8236934 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Mon Apr 6 22:48:18 2020 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 6 Apr 2020 15:48:18 -0700 Subject: RFR: JDK-8035787: SourcePositions are wrong for Strings concatenated with '+' operator Message-ID: Hi, Please consider this change to add a regression test for start position handling of folding string literals.The associated bug (JDK-8035787) was fixed by more recent improvements to string literal folding (JDK-8134007), this patch just adds a regression test to ensure the start positions continue to be correct. (JDK-8035787 also mentions an issue with end positions for string literals in single-element annotations, but as discussed in the bug that part appears to be working as intended.) bug: https://bugs.openjdk.java.net/browse/JDK-8035787 webrev: http://cr.openjdk.java.net/~cushon/8035787/webrev.00/ Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Mon Apr 6 22:55:12 2020 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 6 Apr 2020 15:55:12 -0700 Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: <447867370.1743633.1585735996671.JavaMail.zimbra@u-pem.fr> References: <240132e3-a88e-ef49-54e2-c9ac5309bb19@oracle.com> <1ba99b6e-3635-5962-7ab6-c1fb883df0bc@oracle.com> <447867370.1743633.1585735996671.JavaMail.zimbra@u-pem.fr> Message-ID: On Wed, Apr 1, 2020 at 3:13 AM wrote: > You have forgotten to update the corresponding comment > Thanks again, fixed: http://cr.openjdk.java.net/~cushon/8241798/webrev.02/jdk.patch -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Tue Apr 7 12:10:28 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 7 Apr 2020 14:10:28 +0200 Subject: RFR: JDK-8035787: SourcePositions are wrong for Strings concatenated with '+' operator In-Reply-To: References: Message-ID: Looks good to me, Liam. Thanks! Jan On 07. 04. 20 0:48, Liam Miller-Cushon wrote: > Hi, > > Please consider this change to add a regression test for start position > handling of folding string literals.The associated bug (JDK-8035787) was > fixed by more recent improvements to string literal folding > (JDK-8134007), this patch just adds a regression test to ensure the > start positions continue to be correct. > > (JDK-8035787 also mentions an issue with end positions for string > literals in single-element annotations, but as discussed in the bug that > part appears to be working as intended.) > > bug: https://bugs.openjdk.java.net/browse/JDK-8035787 > webrev: http://cr.openjdk.java.net/~cushon/8035787/webrev.00/ > > Thanks, > Liam From daniel.smith at oracle.com Tue Apr 7 19:07:17 2020 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 7 Apr 2020 13:07:17 -0600 Subject: 2020 JVM Language Summit Cancelled Message-ID: Due to increasing concerns about the ongoing COVID-19 outbreak, and to help protect the health and safety of our customers, employees, partners, and everyone who helps host the event, Oracle is postponing JVMLS in Santa Clara, California this July, but we look forward to seeing you in 2021. In the meantime, we are evaluating other ways to communicate the exciting developments that have happened since JVMLS 2019. From cushon at google.com Tue Apr 7 21:44:03 2020 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 7 Apr 2020 14:44:03 -0700 Subject: RFR: JDK-8035787: SourcePositions are wrong for Strings concatenated with '+' operator In-Reply-To: References: Message-ID: Thanks for the review! On Tue, Apr 7, 2020 at 5:10 AM Jan Lahoda wrote: > Looks good to me, Liam. > > Thanks! > > Jan > > On 07. 04. 20 0:48, Liam Miller-Cushon wrote: > > Hi, > > > > Please consider this change to add a regression test for start position > > handling of folding string literals.The associated bug (JDK-8035787) was > > fixed by more recent improvements to string literal folding > > (JDK-8134007), this patch just adds a regression test to ensure the > > start positions continue to be correct. > > > > (JDK-8035787 also mentions an issue with end positions for string > > literals in single-element annotations, but as discussed in the bug that > > part appears to be working as intended.) > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8035787 > > webrev: http://cr.openjdk.java.net/~cushon/8035787/webrev.00/ > > > > Thanks, > > Liam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Apr 9 10:15:17 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 9 Apr 2020 11:15:17 +0100 Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: References: <240132e3-a88e-ef49-54e2-c9ac5309bb19@oracle.com> <1ba99b6e-3635-5962-7ab6-c1fb883df0bc@oracle.com> <447867370.1743633.1585735996671.JavaMail.zimbra@u-pem.fr> Message-ID: <6a6a7c25-3093-0f01-1984-d5f9c0d943cc@oracle.com> In the comment, isn't "synthetic" in the wrong place? Maurizio On 06/04/2020 23:55, Liam Miller-Cushon wrote: > On Wed, Apr 1, 2020 at 3:13 AM > wrote: > > You have forgotten to update the corresponding comment > > > Thanks again, fixed: > http://cr.openjdk.java.net/~cushon/8241798/webrev.02/jdk.patch -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Thu Apr 9 19:16:58 2020 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 9 Apr 2020 12:16:58 -0700 Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: <6a6a7c25-3093-0f01-1984-d5f9c0d943cc@oracle.com> References: <240132e3-a88e-ef49-54e2-c9ac5309bb19@oracle.com> <1ba99b6e-3635-5962-7ab6-c1fb883df0bc@oracle.com> <447867370.1743633.1585735996671.JavaMail.zimbra@u-pem.fr> <6a6a7c25-3093-0f01-1984-d5f9c0d943cc@oracle.com> Message-ID: The comment should have used 'synthetic' consistently for both the method and the field, but I don't think the method was incorrect? I updated it to: synthetic private static T[] #values() { return new T[] { a, b, c }; } synthetic private static final T[] #VALUES = #values(); Note that method is the private helper that creates the array whose name is prefixed with syntheticNameChar. It's not the public non-synthetic values method: public static T[] values() { return $VALUES; } I uploaded another version of the patch that cleans up the comment a bit. I also extracted a helper for the logic that ensures we get fresh names for the synthetic members: http://cr.openjdk.java.net/~cushon/8241798/webrev.03/ On Thu, Apr 9, 2020 at 3:15 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > In the comment, isn't "synthetic" in the wrong place? > > Maurizio > On 06/04/2020 23:55, Liam Miller-Cushon wrote: > > On Wed, Apr 1, 2020 at 3:13 AM wrote: > >> You have forgotten to update the corresponding comment >> > > Thanks again, fixed: > http://cr.openjdk.java.net/~cushon/8241798/webrev.02/jdk.patch > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Apr 9 20:22:36 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 9 Apr 2020 16:22:36 -0400 Subject: [informal] RFR: JDK-8242293: allow for local interfaces and enums plus nested records, interfaces and enums Message-ID: Hi, Can I please ask for an "informal" review for [1] at [2]. This patch will be pushed to the amber repo, branch "records-2", but given that it is a non-so-trivial change to the language it will be very helpful to have at least an informal review of it. The patch enables static declarations in local contexts. This was already enabled for records since 14. Well this patch adds the same feature to: interfaces, annotations, enums and static classes. It is still forbidden to add a static type declaration to an inner class. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8242293 [2] http://cr.openjdk.java.net/~vromero/8242293/webrev.00/ From maurizio.cimadamore at oracle.com Thu Apr 9 21:12:20 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 9 Apr 2020 22:12:20 +0100 Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: References: <240132e3-a88e-ef49-54e2-c9ac5309bb19@oracle.com> <1ba99b6e-3635-5962-7ab6-c1fb883df0bc@oracle.com> <447867370.1743633.1585735996671.JavaMail.zimbra@u-pem.fr> <6a6a7c25-3093-0f01-1984-d5f9c0d943cc@oracle.com> Message-ID: <84e40685-8bc4-86ec-cee5-64050ef2d705@oracle.com> Ah - ok; thanks for the clarification. Looks good - minor nit is that I'd prefer to see "$" instead of "#" for the synthetic name char, in sync with other similar comments. Thanks Maurizio On 09/04/2020 20:16, Liam Miller-Cushon wrote: > The comment should have used?'synthetic' consistently for both the > method and the field, but I don't think the method was incorrect? I > updated it to: > > synthetic private static T[] #values() { return new T[] { a, b, c }; } > synthetic private static final T[] #VALUES = #values(); > > Note that method is the private helper that creates the array whose > name is prefixed with syntheticNameChar. It's not the public > non-synthetic values method: > > public static T[] values() { return $VALUES; } > > I uploaded another version of the patch that cleans up the comment a > bit. I also extracted a helper for the logic that ensures we get fresh > names for the synthetic members: > > http://cr.openjdk.java.net/~cushon/8241798/webrev.03/ > > On Thu, Apr 9, 2020 at 3:15 AM Maurizio Cimadamore > > wrote: > > In the comment, isn't "synthetic" in the wrong place? > > Maurizio > > On 06/04/2020 23:55, Liam Miller-Cushon wrote: >> On Wed, Apr 1, 2020 at 3:13 AM > > wrote: >> >> You have forgotten to update the corresponding comment >> >> >> Thanks again, fixed: >> http://cr.openjdk.java.net/~cushon/8241798/webrev.02/jdk.patch > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Thu Apr 9 21:58:51 2020 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 9 Apr 2020 14:58:51 -0700 Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: <84e40685-8bc4-86ec-cee5-64050ef2d705@oracle.com> References: <240132e3-a88e-ef49-54e2-c9ac5309bb19@oracle.com> <1ba99b6e-3635-5962-7ab6-c1fb883df0bc@oracle.com> <447867370.1743633.1585735996671.JavaMail.zimbra@u-pem.fr> <6a6a7c25-3093-0f01-1984-d5f9c0d943cc@oracle.com> <84e40685-8bc4-86ec-cee5-64050ef2d705@oracle.com> Message-ID: On Thu, Apr 9, 2020 at 2:12 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Ah - ok; thanks for the clarification. Looks good - minor nit is that I'd > prefer to see "$" instead of "#" for the synthetic name char, in sync with > other similar comments. > Thanks, fixed: http://cr.openjdk.java.net/~cushon/8241798/webrev.04/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Apr 10 14:22:26 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 10 Apr 2020 15:22:26 +0100 Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: References: <240132e3-a88e-ef49-54e2-c9ac5309bb19@oracle.com> <1ba99b6e-3635-5962-7ab6-c1fb883df0bc@oracle.com> <447867370.1743633.1585735996671.JavaMail.zimbra@u-pem.fr> <6a6a7c25-3093-0f01-1984-d5f9c0d943cc@oracle.com> <84e40685-8bc4-86ec-cee5-64050ef2d705@oracle.com> Message-ID: <573ac148-10b7-a403-a3af-b8a55083c094@oracle.com> Thanks Liam - this looks good to me Maurizio On 09/04/2020 22:58, Liam Miller-Cushon wrote: > On Thu, Apr 9, 2020 at 2:12 PM Maurizio Cimadamore > > wrote: > > Ah - ok; thanks for the clarification. Looks good - minor nit is > that I'd prefer to see "$" instead of "#" for the synthetic name > char, in sync with other similar comments. > > Thanks, fixed: > http://cr.openjdk.java.net/~cushon/8241798/webrev.04/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Apr 13 16:03:18 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 13 Apr 2020 12:03:18 -0400 Subject: RFR: JEP 360: Sealed Types (Preview) Message-ID: <794b4e0e-3ec0-c9d3-388e-3c8f218dc78e@oracle.com> Hi all, The sealed types JEP was already reviewed a while back when we were planning to include it in JDK14. It finally fell off that boat but it is being considered now for JDK15. There have been some changes since then mostly related to subtypes of a sealed type. Before we were planning to infer finality, sealness or non-sealness in the subtypes. We steered away from that direction in favor of explicit declaration at the subtype. I would like to ask for another review of the current version of the JEP that reflects these changes. The JEP is at [1] and the last version of the spec is at [2], Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8227043 [2] http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200228/specs/sealed-types-jls.html From mark.reinhold at oracle.com Mon Apr 13 17:09:58 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 13 Apr 2020 10:09:58 -0700 Subject: RFR: JEP 360: Sealed Types (Preview) In-Reply-To: <794b4e0e-3ec0-c9d3-388e-3c8f218dc78e@oracle.com> References: <794b4e0e-3ec0-c9d3-388e-3c8f218dc78e@oracle.com> Message-ID: <20200413100958.910680983@eggemoggin.niobe.net> 2020/4/13 9:03:18 -0700, vicente.romero at oracle.com: > The sealed types JEP was already reviewed a while back when we were > planning to include it in JDK14. It finally fell off that boat but it is > being considered now for JDK15. There have been some changes since then > mostly related to subtypes of a sealed type. Before we were planning to > infer finality, sealness or non-sealness in the subtypes. We steered > away from that direction in favor of explicit declaration at the > subtype. I would like to ask for another review of the current version > of the JEP that reflects these changes. The JEP is at [1] and the last > version of the spec is at [2], > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8227043 More readably: https://openjdk.java.net/jeps/360 - Mark From paul.sandoz at oracle.com Tue Apr 14 19:51:08 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 14 Apr 2020 12:51:08 -0700 Subject: RFR: JEP 360: Sealed Types (Preview) In-Reply-To: <794b4e0e-3ec0-c9d3-388e-3c8f218dc78e@oracle.com> References: <794b4e0e-3ec0-c9d3-388e-3c8f218dc78e@oracle.com> Message-ID: <6FF3F390-BB1C-4B4B-A826-E51C9E0D51B7@oracle.com> Very nice, another block in the pattern matching tower readies itself for placement :-) Some minor comments on the latest here as of writing: https://openjdk.java.net/jeps/360 - "Do not change final in any way.? -> ?It is not a goal to change final in any way." - You still mention Node instead of Shape in some places. - On the set of restrictions you mention " It is an error if a class has a sealed direct superclass or superinterface and the class is not an enum type or the class is not explicitly declared sealed, final or non-sealed. ? To be complete I presume you can add records to that restriction. Paul. > On Apr 13, 2020, at 9:03 AM, Vicente Romero wrote: > > Hi all, > > The sealed types JEP was already reviewed a while back when we were planning to include it in JDK14. It finally fell off that boat but it is being considered now for JDK15. There have been some changes since then mostly related to subtypes of a sealed type. Before we were planning to infer finality, sealness or non-sealness in the subtypes. We steered away from that direction in favor of explicit declaration at the subtype. I would like to ask for another review of the current version of the JEP that reflects these changes. The JEP is at [1] and the last version of the spec is at [2], > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8227043 > [2] http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200228/specs/sealed-types-jls.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Tue Apr 14 21:25:58 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 14 Apr 2020 14:25:58 -0700 Subject: RFR: JEP 360: Sealed Types (Preview) In-Reply-To: <6FF3F390-BB1C-4B4B-A826-E51C9E0D51B7@oracle.com> References: <794b4e0e-3ec0-c9d3-388e-3c8f218dc78e@oracle.com> <6FF3F390-BB1C-4B4B-A826-E51C9E0D51B7@oracle.com> Message-ID: <16b2ab69-aa00-c983-9a05-79e1c4f11365@oracle.com> // Private On 4/14/2020 12:51 PM, Paul Sandoz wrote: > - You still mention Node instead of Shape in some places. I assume that the JEP is still in editing territory, so I have held off making corrections like this. Vicente, is that true? I mean, there are still access control scenarios to add to the Motivation, plus Brian's two-item response to Ty Young. > - On the set of restrictions you mention > > " > It is an error if a class has a sealed direct superclass or > superinterface and the class is not an enum type or the?class is not > explicitly declared sealed, final or non-sealed. > ? > > To be complete I presume you can add records to that restriction. I assume that Vicente is going to blow up the list of restrictions that is merely an incomplete and hard-to-sync copy of JLS content. I explained why this was important in other mails: the JEP should explain why the language feature works the way it does, because everyone in the Java community is going to read the JEP directly or indirectly (you've seen those InfoQ articles which are 90% copy-paste from JEPs, right?), and the JLS will pick up those designs/policies and turn them into formal mechanical rules, which few people need to read. Alex From alex.buckley at oracle.com Tue Apr 14 21:47:47 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 14 Apr 2020 14:47:47 -0700 Subject: RFR: JEP 360: Sealed Types (Preview) In-Reply-To: <16b2ab69-aa00-c983-9a05-79e1c4f11365@oracle.com> References: <794b4e0e-3ec0-c9d3-388e-3c8f218dc78e@oracle.com> <6FF3F390-BB1C-4B4B-A826-E51C9E0D51B7@oracle.com> <16b2ab69-aa00-c983-9a05-79e1c4f11365@oracle.com> Message-ID: (Was meant to be private, but I didn't spot that compiler-dev was still cc'd after I removed amber-dev. Doesn't matter. Vicente, please do clarify whether you're still working on the text. I would like to see the structure of *Controlling implementations* and *Algebraic sum types* recorded in the Motivation, perhaps under more approachable headings. For the latter, I thought the observations by Jonas Konrad and Swaranga Sarma were on the money -- some interfaces represent "APIs" (implement, don't match) and some represent "data types" (match, don't implement).) On 4/14/2020 2:25 PM, Alex Buckley wrote: > // Private > > On 4/14/2020 12:51 PM, Paul Sandoz wrote: >> - You still mention Node instead of Shape in some places. > > I assume that the JEP is still in editing territory, so I have held off > making corrections like this. Vicente, is that true? I mean, there are > still access control scenarios to add to the Motivation, plus Brian's > two-item response to Ty Young. > >> - On the set of restrictions you mention >> >> " >> It is an error if a class has a sealed direct superclass or >> superinterface and the class is not an enum type or the?class is not >> explicitly declared sealed, final or non-sealed. >> ? >> >> To be complete I presume you can add records to that restriction. > > I assume that Vicente is going to blow up the list of restrictions that > is merely an incomplete and hard-to-sync copy of JLS content. I > explained why this was important in other mails: the JEP should explain > why the language feature works the way it does, because everyone in the > Java community is going to read the JEP directly or indirectly (you've > seen those InfoQ articles which are 90% copy-paste from JEPs, right?), > and the JLS will pick up those designs/policies and turn them into > formal mechanical rules, which few people need to read. > > Alex From jan.lahoda at oracle.com Wed Apr 15 18:43:25 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 15 Apr 2020 20:43:25 +0200 Subject: RFR: JDK-8242802: javac crashes when checking equals and hashCode in unresolvable anonymous class Message-ID: <49916734-2cdc-168e-e321-b01c26c6041c@oracle.com> Hi, javac may crash with an exception when running with -Xlint:options processing code like this: --- public class InvalidAnonymous { private void t() { new Undefined() {}; } } --- --- $ javac -XDdev -Xlint:overrides InvalidAnonymous.java InvalidAnonymous.java:3: error: cannot find symbol new Undefined() {}; ^ symbol: class Undefined location: class InvalidAnonymous 1 error An exception has occurred in the compiler (15-internal). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. java.lang.NullPointerException at jdk.compiler/com.sun.tools.javac.comp.Check.checkClassOverrideEqualsAndHash(Check.java:2148) at jdk.compiler/com.sun.tools.javac.comp.Check.checkClassOverrideEqualsAndHashIfNeeded(Check.java:2138) --- This is because Types.implementation may return null if there is no method implementing the given input method (Object.equals in this case - and due to the "Undefined", the anonymous does not have Object as a supertype, and hence does not have any implementation of equals). The proposed fix is to add a null check on the result of Types.implementation. Webrev: http://cr.openjdk.java.net/~jlahoda/8242802/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8242802 How does this look? Thanks, Jan From joe.darcy at oracle.com Thu Apr 16 05:24:08 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 15 Apr 2020 22:24:08 -0700 Subject: RFR: JDK-8242802: javac crashes when checking equals and hashCode in unresolvable anonymous class In-Reply-To: <49916734-2cdc-168e-e321-b01c26c6041c@oracle.com> References: <49916734-2cdc-168e-e321-b01c26c6041c@oracle.com> Message-ID: Looks fine Jan; cheers, -Joe On 4/15/2020 11:43 AM, Jan Lahoda wrote: > Hi, > > javac may crash with an exception when running with -Xlint:options > processing code like this: > --- > public class InvalidAnonymous { > ??? private void t() { > ??????? new Undefined() {}; > ??? } > } > --- > > --- > $ javac -XDdev -Xlint:overrides InvalidAnonymous.java > InvalidAnonymous.java:3: error: cannot find symbol > ??????? new Undefined() {}; > ??????????? ^ > ? symbol: class Undefined > ? location: class InvalidAnonymous > 1 error > An exception has occurred in the compiler (15-internal). Please file a > bug against the Java compiler via the Java bug reporting page > (http://bugreport.java.com) after checking the Bug Database > (http://bugs.java.com) for duplicates. Include your program, the > following diagnostic, and the parameters passed to the Java compiler > in your report. Thank you. > java.lang.NullPointerException > ??????? at > jdk.compiler/com.sun.tools.javac.comp.Check.checkClassOverrideEqualsAndHash(Check.java:2148) > ??????? at > jdk.compiler/com.sun.tools.javac.comp.Check.checkClassOverrideEqualsAndHashIfNeeded(Check.java:2138) > --- > > This is because Types.implementation may return null if there is no > method implementing the given input method (Object.equals in this case > - and due to the "Undefined", the anonymous does not have Object as a > supertype, and hence does not have any implementation of equals). > > The proposed fix is to add a null check on the result of > Types.implementation. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8242802/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8242802 > > How does this look? > > Thanks, > ??? Jan From TOSHIONA at jp.ibm.com Thu Apr 16 12:39:01 2020 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Thu, 16 Apr 2020 21:39:01 +0900 Subject: RFR: JDK-8233829: Non-ASCII module name cannot be handled under non-UTF8 environment Message-ID: Hi all, Could you review this fix? Also, I'd like to ask a sponsor of the fix, since I'm not a committer. Issue: https://bugs.openjdk.java.net/browse/JDK-8233829 Webrev: http://cr.openjdk.java.net/~tnakamura/8233829/webrev.00/ If module name is in non-ASCII and environment is in non-UTF8, javac's "--add-modules" option cannot find the module. com.sun.tools.javac.jvm.ModuleNameReader.utf8Mapper uses String(byte[], int, int). In problematic case, the String was generated by default encoding which wasn't UTF8. For example, Japanese Windows uses MS932 (Shift_JIS) encoding. The byte[] in utf8Mapper method is always decoded by UTF-8. Tier1 tests on Linux and Windows passed. Best Regards, Toshio Nakamura -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Thu Apr 16 16:56:52 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 16 Apr 2020 18:56:52 +0200 Subject: RFR: JDK-8243000: javac only build fails after removal of Nashorn Message-ID: <5c15bcc5-143e-fdac-11e9-d6d055d4aa66@oracle.com> Hi, The langtools-only ant build is broken after the Nashorn removal, due to the use of scriptmapper. I tried to resolve that using regexpmapper here: http://cr.openjdk.java.net/~jlahoda/8243000/webrev.00/ I did some tests, and it seemed to work reasonably for me - but more testing (especially by folks using Idea) would be welcome. JBS: https://bugs.openjdk.java.net/browse/JDK-8243000 Thanks, Jan From james.laskey at oracle.com Thu Apr 16 18:03:56 2020 From: james.laskey at oracle.com (James Laskey) Date: Thu, 16 Apr 2020 15:03:56 -0300 Subject: RFR: JDK-8243000: javac only build fails after removal of Nashorn In-Reply-To: <5c15bcc5-143e-fdac-11e9-d6d055d4aa66@oracle.com> References: <5c15bcc5-143e-fdac-11e9-d6d055d4aa66@oracle.com> Message-ID: <564BB819-EE0B-4EB8-9521-00565D378876@oracle.com> Check with sundar. He was working n fix as well. On the road. > On Apr 16, 2020, at 1:58 PM, Jan Lahoda wrote: > > ?Hi, > > The langtools-only ant build is broken after the Nashorn removal, due to the use of scriptmapper. I tried to resolve that using regexpmapper here: > http://cr.openjdk.java.net/~jlahoda/8243000/webrev.00/ > > I did some tests, and it seemed to work reasonably for me - but more testing (especially by folks using Idea) would be welcome. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8243000 > > Thanks, > Jan From sundararajan.athijegannathan at oracle.com Fri Apr 17 04:14:15 2020 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 17 Apr 2020 09:44:15 +0530 Subject: RFR: JDK-8243000: javac only build fails after removal of Nashorn In-Reply-To: <564BB819-EE0B-4EB8-9521-00565D378876@oracle.com> References: <5c15bcc5-143e-fdac-11e9-d6d055d4aa66@oracle.com> <564BB819-EE0B-4EB8-9521-00565D378876@oracle.com> Message-ID: <5f9bbfca-1914-cc0d-dd14-45d8dd91b98b@oracle.com> No. I don't have for this issue. This is a private (javac team) ant build script not covered by tests. Thanks -Sundar On 16/04/20 11:33 pm, James Laskey wrote: > Check with sundar. He was working n fix as well. > > On the road. > >> On Apr 16, 2020, at 1:58 PM, Jan Lahoda wrote: >> >> ?Hi, >> >> The langtools-only ant build is broken after the Nashorn removal, due to the use of scriptmapper. I tried to resolve that using regexpmapper here: >> http://cr.openjdk.java.net/~jlahoda/8243000/webrev.00/ >> >> I did some tests, and it seemed to work reasonably for me - but more testing (especially by folks using Idea) would be welcome. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8243000 >> >> Thanks, >> Jan From jan.lahoda at oracle.com Fri Apr 17 09:25:24 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 17 Apr 2020 11:25:24 +0200 Subject: RFR: JDK-8243047: javac may crash when processing exists in class initializers Message-ID: <3a26abc4-b9d9-7858-e55b-e77f8c10c2a6@oracle.com> Hi, For code like: --- public class ExitInInitializer { {return;} } --- If javac is invoked like: $ javac -XDshould-stop.at=FLOW -XDdev ExitInInitializer.java javac eventually crashes with: java.lang.AssertionError at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitMethodDef(Flow.java:558) The reason is that the the (invalid) "return" in the intializer is added to pendingExits, but not removed as the end of the initializer, and when analyzing method, javac checks pendingExits are empty. The proposed solution is to clear pendingExits at the end of initializers. The asserts that an error had to be reported for such exits is preserved, so there shouldn't be a danger of accidentally letting incorrect compilation pass. Webrev: http://cr.openjdk.java.net/~jlahoda/8243047/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8243047 How does this look? Thanks, Jan From maurizio.cimadamore at oracle.com Fri Apr 17 10:23:07 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 17 Apr 2020 11:23:07 +0100 Subject: RFR: JDK-8243000: javac only build fails after removal of Nashorn In-Reply-To: <5f9bbfca-1914-cc0d-dd14-45d8dd91b98b@oracle.com> References: <5c15bcc5-143e-fdac-11e9-d6d055d4aa66@oracle.com> <564BB819-EE0B-4EB8-9521-00565D378876@oracle.com> <5f9bbfca-1914-cc0d-dd14-45d8dd91b98b@oracle.com> Message-ID: <1aa5bbc3-674c-02fd-9dfe-6b827c352b6e@oracle.com> The regex looks good. I'm taking a look at the intellij support, in both langtools and the wider JDK to see which changes need to be made. There is at least one issue there that I'm aware of (e.g. dependency on