From vicente.romero at oracle.com  Sat Dec  1 19:46:33 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Sat, 1 Dec 2018 14:46:33 -0500
Subject: RFR: JDK-8207224: Javac compiles source code despite illegal use of
 unchecked conversions
Message-ID: <bdb24823-103b-ba39-c369-7f89ff5f9ad8@oracle.com>

Please review fix for [1] at [2]. Javac is accepting this program as valid:

class ReturnTypeSubstitutableTest {
 ??? abstract class AbstractDemo<Request extends AbstractResult, 
Response extends AbstractResult> {
 ??????? protected abstract Response test(Request request);
 ??? }

 ??? abstract interface AbstractResult {}

 ??? abstract interface SimpleResult extends AbstractResult {}

 ??? class Result1 implements SimpleResult {}

 ??? class OtherResult implements AbstractResult {}

 ??? public class SimpleDemo<Request extends AbstractResult, Response 
extends AbstractResult> extends AbstractDemo<Request, Response> {
 ??????? @Override
 ??????? protected SimpleResult test(AbstractResult request) {? 
<----------- this method is accepted as a good override for 
AbstractDemo::test
 ??????????? return null;
 ??????? }
 ??? }
}

 From Dan's evaluation at the bug entry [1]:

Per JLS 8.4.8.3, the first method must be return-type-substitutable for 
the second. This can be satisfied in 3 ways (JLS 8.4.5):
- SimpleResult is a subtype of Response (no)
- SimpleResult can be converted to a subtype of Response by unchecked 
conversion (no)
- The methods have different signatures (yep) and SimpleResult = 
erasure(Response) (no)

No case applies, so an error should occur. This fix syncs javac with the 
spec.

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8207224
[2] http://cr.openjdk.java.net/~vromero/8207224/webrev.00/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181201/78287867/attachment.html>

From cushon at google.com  Sun Dec  2 21:01:48 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Sun, 2 Dec 2018 13:01:48 -0800
Subject: RFR: JDK-8207224: Javac compiles source code despite illegal use
 of unchecked conversions
In-Reply-To: <bdb24823-103b-ba39-c369-7f89ff5f9ad8@oracle.com>
References: <bdb24823-103b-ba39-c369-7f89ff5f9ad8@oracle.com>
Message-ID: <CAL4QsgvKmat7exH1JhigzXQFUORaCVbbXZ37dO0dFyeOLWRRfQ@mail.gmail.com>

Hi Vicente,

I did some testing with your fix to get a sense of the source compatibility
impact, and it looks minor: I only found a handful of examples that are
rejected after the change.

One of them is in icu4j. Is this change an expected result of the fix?

icu/icu4j/main/classes/core/src/com/ibm/icu/impl/locale/XLikelySubtags.java:47:
error: make() in <anonymous com.ibm.icu.impl.locale.XLikelySubtags$Maker$1>
cannot override <V>make() in Maker
             public Map<Object,Object> make() {
                                       ^
   return type Map<Object,Object> is not compatible with V
   where V is a type-variable:
     V extends Object declared in method <V>make()
...
https://github.com/unicode-org/icu/blob/master/icu4j/main/classes/core/src/com/ibm/icu/impl/locale/XLikelySubtags.java#L47

Thanks,

On Sat, Dec 1, 2018 at 11:47 AM Vicente Romero <vicente.romero at oracle.com>
wrote:

> Please review fix for [1] at [2]. Javac is accepting this program as valid:
>
> class ReturnTypeSubstitutableTest {
>     abstract class AbstractDemo<Request extends AbstractResult, Response
> extends AbstractResult> {
>         protected abstract Response test(Request request);
>     }
>
>     abstract interface AbstractResult {}
>
>     abstract interface SimpleResult extends AbstractResult {}
>
>     class Result1 implements SimpleResult {}
>
>     class OtherResult implements AbstractResult {}
>
>     public class SimpleDemo<Request extends AbstractResult, Response
> extends AbstractResult> extends AbstractDemo<Request, Response> {
>         @Override
>         protected SimpleResult test(AbstractResult request) {
> <----------- this method is accepted as a good override for
> AbstractDemo::test
>             return null;
>         }
>     }
> }
>
> From Dan's evaluation at the bug entry [1]:
>
> Per JLS 8.4.8.3, the first method must be return-type-substitutable for
> the second. This can be satisfied in 3 ways (JLS 8.4.5):
> - SimpleResult is a subtype of Response (no)
> - SimpleResult can be converted to a subtype of Response by unchecked
> conversion (no)
> - The methods have different signatures (yep) and SimpleResult =
> erasure(Response) (no)
>
> No case applies, so an error should occur. This fix syncs javac with the
> spec.
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8207224
> [2] http://cr.openjdk.java.net/~vromero/8207224/webrev.00/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181202/5ffe1105/attachment.html>

From vicente.romero at oracle.com  Mon Dec  3 02:24:46 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Sun, 2 Dec 2018 21:24:46 -0500
Subject: RFR: JDK-8207224: Javac compiles source code despite illegal use
 of unchecked conversions
In-Reply-To: <CAL4QsgvKmat7exH1JhigzXQFUORaCVbbXZ37dO0dFyeOLWRRfQ@mail.gmail.com>
References: <bdb24823-103b-ba39-c369-7f89ff5f9ad8@oracle.com>
 <CAL4QsgvKmat7exH1JhigzXQFUORaCVbbXZ37dO0dFyeOLWRRfQ@mail.gmail.com>
Message-ID: <cbaaa050-1d23-5b8b-985d-4b47f22707dc@oracle.com>

Hi Liam,

Thanks for testing the change. Yes the change you found is an expected 
result of the fix. If the number of rejected examples is not big I think 
that we could go on with the fix. Eclipse compiler should be rejecting 
that code too.

Vicente

On 12/2/18 4:01 PM, Liam Miller-Cushon wrote:
> Hi Vicente,
>
> I did some testing with your fix to get a sense of the source 
> compatibility impact, and it looks minor: I only found a handful of 
> examples that are rejected after the change.
>
> One of them is in icu4j. Is this change an expected result of the fix?
>
> icu/icu4j/main/classes/core/src/com/ibm/icu/impl/locale/XLikelySubtags.java:47: 
> error: make() in <anonymous 
> com.ibm.icu.impl.locale.XLikelySubtags$Maker$1> cannot override 
> <V>make() in Maker
> ? ? ? ? ? ? ?public Map<Object,Object> make() {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^
> ? ?return type Map<Object,Object> is not compatible with V
> ? ?where V is a type-variable:
> ? ? ?V extends Object declared in method <V>make()
> ...
> https://github.com/unicode-org/icu/blob/master/icu4j/main/classes/core/src/com/ibm/icu/impl/locale/XLikelySubtags.java#L47
>
> Thanks,
>
> On Sat, Dec 1, 2018 at 11:47 AM Vicente Romero 
> <vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>> wrote:
>
>     Please review fix for [1] at [2]. Javac is accepting this program
>     as valid:
>
>     class ReturnTypeSubstitutableTest {
>     ??? abstract class AbstractDemo<Request extends AbstractResult,
>     Response extends AbstractResult> {
>     ??????? protected abstract Response test(Request request);
>     ??? }
>
>     ??? abstract interface AbstractResult {}
>
>     ??? abstract interface SimpleResult extends AbstractResult {}
>
>     ??? class Result1 implements SimpleResult {}
>
>     ??? class OtherResult implements AbstractResult {}
>
>     ??? public class SimpleDemo<Request extends AbstractResult,
>     Response extends AbstractResult> extends AbstractDemo<Request,
>     Response> {
>     ??????? @Override
>     ??????? protected SimpleResult test(AbstractResult request) {?
>     <----------- this method is accepted as a good override for
>     AbstractDemo::test
>     ??????????? return null;
>     ??????? }
>     ??? }
>     }
>
>     From Dan's evaluation at the bug entry [1]:
>
>     Per JLS 8.4.8.3, the first method must be
>     return-type-substitutable for the second. This can be satisfied in
>     3 ways (JLS 8.4.5):
>     - SimpleResult is a subtype of Response (no)
>     - SimpleResult can be converted to a subtype of Response by
>     unchecked conversion (no)
>     - The methods have different signatures (yep) and SimpleResult =
>     erasure(Response) (no)
>
>     No case applies, so an error should occur. This fix syncs javac
>     with the spec.
>
>     Thanks,
>     Vicente
>
>     [1] https://bugs.openjdk.java.net/browse/JDK-8207224
>     [2] http://cr.openjdk.java.net/~vromero/8207224/webrev.00/
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181202/6bda16e5/attachment.html>

From cushon at google.com  Mon Dec  3 03:46:47 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Sun, 2 Dec 2018 19:46:47 -0800
Subject: RFR: JDK-8207224: Javac compiles source code despite illegal use
 of unchecked conversions
In-Reply-To: <cbaaa050-1d23-5b8b-985d-4b47f22707dc@oracle.com>
References: <bdb24823-103b-ba39-c369-7f89ff5f9ad8@oracle.com>
 <CAL4QsgvKmat7exH1JhigzXQFUORaCVbbXZ37dO0dFyeOLWRRfQ@mail.gmail.com>
 <cbaaa050-1d23-5b8b-985d-4b47f22707dc@oracle.com>
Message-ID: <CAL4Qsgtg5c+oRpNev4QRA8qsDaoXTfDXmd_dKfUFq0iGLR01ow@mail.gmail.com>

On Sun, Dec 2, 2018 at 6:24 PM Vicente Romero <vicente.romero at oracle.com>
wrote:

> Yes the change you found is an expected result of the fix.
>

Thanks for confirming,


> If the number of rejected examples is not big I think that we could go on
> with the fix. Eclipse compiler should be rejecting that code too.
>

I only found a very small number, proceeding with the fix SGTM.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181202/8cd29d60/attachment-0001.html>

From maurizio.cimadamore at oracle.com  Mon Dec  3 11:15:53 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 3 Dec 2018 11:15:53 +0000
Subject: RFR: JDK-8207224: Javac compiles source code despite illegal use
 of unchecked conversions
In-Reply-To: <CAL4Qsgtg5c+oRpNev4QRA8qsDaoXTfDXmd_dKfUFq0iGLR01ow@mail.gmail.com>
References: <bdb24823-103b-ba39-c369-7f89ff5f9ad8@oracle.com>
 <CAL4QsgvKmat7exH1JhigzXQFUORaCVbbXZ37dO0dFyeOLWRRfQ@mail.gmail.com>
 <cbaaa050-1d23-5b8b-985d-4b47f22707dc@oracle.com>
 <CAL4Qsgtg5c+oRpNev4QRA8qsDaoXTfDXmd_dKfUFq0iGLR01ow@mail.gmail.com>
Message-ID: <89780d20-9109-c667-3f0d-6917e4806e7a@oracle.com>

Separately,
I think this difference was probably the main one between 
returnTypeSubstitutable and resultSubtype/covariantReturnType... I think 
we should we try and merge them?

Maurizio

On 03/12/2018 03:46, Liam Miller-Cushon wrote:
> On Sun, Dec 2, 2018 at 6:24 PM Vicente Romero 
> <vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>> wrote:
>
>     Yes the change you found is an expected result of the fix.
>
>
> Thanks for confirming,
>
>     If the number of rejected examples is not big I think that we
>     could go on with the fix. Eclipse compiler should be rejecting
>     that code too.
>
>
> I only found a very small number, proceeding with the fix SGTM.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181203/e805f5fa/attachment.html>

From jan.lahoda at oracle.com  Mon Dec  3 12:37:38 2018
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 3 Dec 2018 13:37:38 +0100
Subject: RFR: JDK-8214529: Exception while using Anonymous class in switch
 expression
Message-ID: <5C052392.9020808@oracle.com>

Hi,

In:
https://bugs.openjdk.java.net/browse/JDK-8214529

This is a report that anonymous class' bodies are lost if the anonymous 
class is the break value. This was due to a mistake in desugaring, and 
has been fixed alongside with JDK-8214031, which removes the desugaring. 
But when writing a test for this case, it turned out that "return" 
statements inside the anonymous class are reported as errors:

---
interface TestIntf {
     default int fun() {
         return 1;
     }
}

public class SwitchTest {

         public static void main(String[] args) {
                 int x = 10;
                 var y = switch(x) {
             case 0 -> new TestIntf(){ public int fun() { return 0; }};
             default -> new TestIntf(){};
                         };

                 System.out.println(y.fun());
         }
}
---
---
$ javac --enable-preview --source 12 /tmp/SwitchTest.java
/tmp/SwitchTest.java:12: error: return outside of enclosing switch 
expression
             case 0 -> new TestIntf(){ public int fun() { return 0; }};
                                                          ^
Note: /tmp/SwitchTest.java uses preview language features.
Note: Recompile with -Xlint:preview for details.
1 error
---

This is not appropriate, to my knowledge. The proposed fix is to clear 
the breakResult when creating methodEnv, as is already done for 
lambdaEnv. The breakResult is (also) used to detect inappropriate 
returns nested inside the switch expression, so clearing it eliminates 
the error.

Webrev:
http://cr.openjdk.java.net/~jlahoda/8214529/webrev.00/

How does this look?

Thanks,
     Jan


From maurizio.cimadamore at oracle.com  Mon Dec  3 12:55:56 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 3 Dec 2018 12:55:56 +0000
Subject: RFR: JDK-8214529: Exception while using Anonymous class in switch
 expression
In-Reply-To: <5C052392.9020808@oracle.com>
References: <5C052392.9020808@oracle.com>
Message-ID: <5a3616e0-0b06-b6e7-c45f-f508df7c6ecc@oracle.com>

Looks good - I agree the program should compile.

Maurizio

On 03/12/2018 12:37, Jan Lahoda wrote:
> Hi,
>
> In:
> https://bugs.openjdk.java.net/browse/JDK-8214529
>
> This is a report that anonymous class' bodies are lost if the 
> anonymous class is the break value. This was due to a mistake in 
> desugaring, and has been fixed alongside with JDK-8214031, which 
> removes the desugaring. But when writing a test for this case, it 
> turned out that "return" statements inside the anonymous class are 
> reported as errors:
>
> ---
> interface TestIntf {
> ??? default int fun() {
> ??????? return 1;
> ??? }
> }
>
> public class SwitchTest {
>
> ??????? public static void main(String[] args) {
> ??????????????? int x = 10;
> ??????????????? var y = switch(x) {
> ??????????? case 0 -> new TestIntf(){ public int fun() { return 0; }};
> ??????????? default -> new TestIntf(){};
> ??????????????????????? };
>
> ??????????????? System.out.println(y.fun());
> ??????? }
> }
> ---
> ---
> $ javac --enable-preview --source 12 /tmp/SwitchTest.java
> /tmp/SwitchTest.java:12: error: return outside of enclosing switch 
> expression
> ??????????? case 0 -> new TestIntf(){ public int fun() { return 0; }};
> ???????????????????????????????????????????????????????? ^
> Note: /tmp/SwitchTest.java uses preview language features.
> Note: Recompile with -Xlint:preview for details.
> 1 error
> ---
>
> This is not appropriate, to my knowledge. The proposed fix is to clear 
> the breakResult when creating methodEnv, as is already done for 
> lambdaEnv. The breakResult is (also) used to detect inappropriate 
> returns nested inside the switch expression, so clearing it eliminates 
> the error.
>
> Webrev:
> http://cr.openjdk.java.net/~jlahoda/8214529/webrev.00/
>
> How does this look?
>
> Thanks,
> ??? Jan
>

From vicente.romero at oracle.com  Mon Dec  3 14:08:15 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 3 Dec 2018 09:08:15 -0500
Subject: RFR: JDK-8207224: Javac compiles source code despite illegal use
 of unchecked conversions
In-Reply-To: <CAL4Qsgtg5c+oRpNev4QRA8qsDaoXTfDXmd_dKfUFq0iGLR01ow@mail.gmail.com>
References: <bdb24823-103b-ba39-c369-7f89ff5f9ad8@oracle.com>
 <CAL4QsgvKmat7exH1JhigzXQFUORaCVbbXZ37dO0dFyeOLWRRfQ@mail.gmail.com>
 <cbaaa050-1d23-5b8b-985d-4b47f22707dc@oracle.com>
 <CAL4Qsgtg5c+oRpNev4QRA8qsDaoXTfDXmd_dKfUFq0iGLR01ow@mail.gmail.com>
Message-ID: <21ae08a6-3234-9fc2-51a9-959f78935267@oracle.com>

cool,

thanks
Vicente

On 12/2/18 10:46 PM, Liam Miller-Cushon wrote:
> On Sun, Dec 2, 2018 at 6:24 PM Vicente Romero 
> <vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>> wrote:
>
>     Yes the change you found is an expected result of the fix.
>
>
> Thanks for confirming,
>
>     If the number of rejected examples is not big I think that we
>     could go on with the fix. Eclipse compiler should be rejecting
>     that code too.
>
>
> I only found a very small number, proceeding with the fix SGTM.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181203/0adef054/attachment.html>

From jay.a at outlook.in  Mon Dec  3 16:29:21 2018
From: jay.a at outlook.in (Jayaprakash Artanareeswaran)
Date: Mon, 3 Dec 2018 16:29:21 +0000
Subject: Where do empty compilation units belong?
In-Reply-To: <8884f6e3-98c9-f84a-8e79-f719b70854b6@oracle.com>
References: <CY4PR06MB30459CBAFE24C530F9A410FB87DA0@CY4PR06MB3045.namprd06.prod.outlook.com>
 <5BFC6921.70102@oracle.com>, <8884f6e3-98c9-f84a-8e79-f719b70854b6@oracle.com>
Message-ID: <BN6PR06MB32195133E4477DBCA6415CC087AE0@BN6PR06MB3219.namprd06.prod.outlook.com>

Thanks for the test file Jon. Last week I and Stephan had a discussion and agreed with the specified behavior and made some changes to our compiler.

I can also confirm that both the compilers behave the same way for all the scenarios included in the test file.

Regards,
Jay

________________________________
From: Jonathan Gibbons <jonathan.gibbons at oracle.com>
Sent: Monday, November 26, 2018 11:22 PM
To: Alex Buckley; Jayaprakash Artanareeswaran; jigsaw-dev at openjdk.java.net; compiler-dev
Subject: Re: Where do empty compilation units belong?



On 11/26/2018 01:44 PM, Alex Buckley wrote:
// Adding compiler-dev since the parsing of files into compilation units is not a Jigsaw issue.

On 11/20/2018 9:14 PM, Jayaprakash Artanareeswaran wrote:
"jigsaw-dev" <jigsaw-dev-bounces at openjdk.java.net><mailto:jigsaw-dev-bounces at openjdk.java.net> wrote on 21/11/2018
01:56:42 AM:
 > Jon points out that `OrdinaryCompilationUnit` will match an empty stream
 > of tokens (I dislike the syntax-driven optionality here, but it's
 > longstanding) so the file D.java could be regarded as a compilation unit
 > with no package declaration, no import declarations, and no type
 > declarations.
 >
 > Per JLS 7.4.2, such a compilation unit is in an unnamed package, and
 > must be associated with an unnamed module.
 >
 > I would prefer 7.4.2 to say only that a compilation unit with no package
 > declarations _and at least one type declaration_ is in an unnamed
 > package (and must be associated with an unnamed module; 7.3 should
 > enumerate that possibility). A compilation unit with no package
 > declarations _and no type declarations_ would be deemed unobservable by
 > 7.3, and all these questions about what to do with empty files would
 > disappear.

That would be perfect and make things unambiguous. But for now, the
paragraph above is good enough for me.

Unfortunately, import declarations can have side effects (compile-time errors) so to be sure that the "no package or type decl === unobservable" rule is suitable for a file containing just an import decl, we would have to do a case analysis of how javac and ecj handle the eight combinations of the three parts allowed in an ordinary compilation unit. That's overkill for the situation involving empty files that keeps coming up and that I really want to clarify. I don't think anyone loves that an ordinary compilation unit matches the empty stream, so let's define away that scenario. As Jon said, an empty file doesn't present anything to be checked; there is no compilation unit there, so let's be unambiguous about that.

We can rule out the empty stream in 7.3 with grammar or with semantics. Usually a semantic description is clearest (gives everyone the proper terminology and concepts) but in this case we don't want the description to wrestle with "consists of one, two, or three parts" when the grammar allows zero. So, a new grammatical description is appropriate, and straightforward:

  OrdinaryCompilationUnit:
    PackageDeclaration {ImportDeclaration} {TypeDeclaration}
    ImportDeclaration {ImportDeclaration} {TypeDeclaration}
    TypeDeclaration {TypeDeclaration}

The "three parts, each of which is optional" description is still accurate. The package decl part is optional (as long as you have the import decls part and/or the type decls part); the import decls part is optional (as long as you have either the package decl part or ...) ... you get the picture.

I would leave 7.4.2 alone; an ordinary compilation unit with no package or type decls but with import decls is part of the unnamed package (and thus unnamed module) as before, and compilers can handle that, I think.

Any comments?

Alex

That seems good to me.

To summarize the javac behavior ...

  *   javac accepts/ignores an empty file
  *   javac treats import-only compilation units as in the unnamed package, which is not allowed in a named module
  *   javac enforces file naming constraints when declaring a public class
  *   javac uses file naming constraints when looking on the (module) source path for a file for a class

Attached is a toy class to generate combinations of package, import and type declarations. You can use the source-launcher feature to run it.

-- Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181203/77c87092/attachment-0001.html>

From joe.darcy at oracle.com  Mon Dec  3 18:50:27 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 3 Dec 2018 10:50:27 -0800
Subject: RFR: JDK-8207224: Javac compiles source code despite illegal use
 of unchecked conversions
In-Reply-To: <cbaaa050-1d23-5b8b-985d-4b47f22707dc@oracle.com>
References: <bdb24823-103b-ba39-c369-7f89ff5f9ad8@oracle.com>
 <CAL4QsgvKmat7exH1JhigzXQFUORaCVbbXZ37dO0dFyeOLWRRfQ@mail.gmail.com>
 <cbaaa050-1d23-5b8b-985d-4b47f22707dc@oracle.com>
Message-ID: <fef8cb1d-3aa2-2d77-be52-e2bc16dc2b1d@oracle.com>

Hi Vicente,

Since it sounds like there is nontrivial source compatibility impact 
with this change, please file a CSR for it.

Thanks,

-Joe


On 12/2/2018 6:24 PM, Vicente Romero wrote:
> Hi Liam,
>
> Thanks for testing the change. Yes the change you found is an expected 
> result of the fix. If the number of rejected examples is not big I 
> think that we could go on with the fix. Eclipse compiler should be 
> rejecting that code too.
>
> Vicente
>
> On 12/2/18 4:01 PM, Liam Miller-Cushon wrote:
>> Hi Vicente,
>>
>> I did some testing with your fix to get a sense of the source 
>> compatibility impact, and it looks minor: I only found a handful of 
>> examples that are rejected after the change.
>>
>> One of them is in icu4j. Is this change an expected result of the fix?
>>
>> icu/icu4j/main/classes/core/src/com/ibm/icu/impl/locale/XLikelySubtags.java:47: 
>> error: make() in <anonymous 
>> com.ibm.icu.impl.locale.XLikelySubtags$Maker$1> cannot override 
>> <V>make() in Maker
>> ? ? ? ? ? ? ?public Map<Object,Object> make() {
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^
>> ? ?return type Map<Object,Object> is not compatible with V
>> ? ?where V is a type-variable:
>> ? ? ?V extends Object declared in method <V>make()
>> ...
>> https://github.com/unicode-org/icu/blob/master/icu4j/main/classes/core/src/com/ibm/icu/impl/locale/XLikelySubtags.java#L47
>>
>> Thanks,
>>
>> On Sat, Dec 1, 2018 at 11:47 AM Vicente Romero 
>> <vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>> wrote:
>>
>>     Please review fix for [1] at [2]. Javac is accepting this program
>>     as valid:
>>
>>     class ReturnTypeSubstitutableTest {
>>     ??? abstract class AbstractDemo<Request extends AbstractResult,
>>     Response extends AbstractResult> {
>>     ??????? protected abstract Response test(Request request);
>>     ??? }
>>
>>     ??? abstract interface AbstractResult {}
>>
>>     ??? abstract interface SimpleResult extends AbstractResult {}
>>
>>     ??? class Result1 implements SimpleResult {}
>>
>>     ??? class OtherResult implements AbstractResult {}
>>
>>     ??? public class SimpleDemo<Request extends AbstractResult,
>>     Response extends AbstractResult> extends AbstractDemo<Request,
>>     Response> {
>>     ??????? @Override
>>     ??????? protected SimpleResult test(AbstractResult request)
>>     {<----------- this method is accepted as a good override for
>>     AbstractDemo::test
>>     ??????????? return null;
>>     ??????? }
>>     ??? }
>>     }
>>
>>     From Dan's evaluation at the bug entry [1]:
>>
>>     Per JLS 8.4.8.3, the first method must be
>>     return-type-substitutable for the second. This can be satisfied
>>     in 3 ways (JLS 8.4.5):
>>     - SimpleResult is a subtype of Response (no)
>>     - SimpleResult can be converted to a subtype of Response by
>>     unchecked conversion (no)
>>     - The methods have different signatures (yep) and SimpleResult =
>>     erasure(Response) (no)
>>
>>     No case applies, so an error should occur. This fix syncs javac
>>     with the spec.
>>
>>     Thanks,
>>     Vicente
>>
>>     [1] https://bugs.openjdk.java.net/browse/JDK-8207224
>>     [2] http://cr.openjdk.java.net/~vromero/8207224/webrev.00/
>>     <http://cr.openjdk.java.net/%7Evromero/8207224/webrev.00/>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181203/f2241733/attachment.html>

From vicente.romero at oracle.com  Mon Dec  3 21:01:59 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 3 Dec 2018 16:01:59 -0500
Subject: RFR: JDK-8207224: Javac compiles source code despite illegal use
 of unchecked conversions
In-Reply-To: <bdb24823-103b-ba39-c369-7f89ff5f9ad8@oracle.com>
References: <bdb24823-103b-ba39-c369-7f89ff5f9ad8@oracle.com>
Message-ID: <76e067ba-91f2-0f70-1963-bed523ad1a51@oracle.com>

Hi,

Please review the related CSR [1]

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8214729

On 12/1/18 2:46 PM, Vicente Romero wrote:
> Please review fix for [1] at [2]. Javac is accepting this program as 
> valid:
>
> class ReturnTypeSubstitutableTest {
> ??? abstract class AbstractDemo<Request extends AbstractResult, 
> Response extends AbstractResult> {
> ??????? protected abstract Response test(Request request);
> ??? }
>
> ??? abstract interface AbstractResult {}
>
> ??? abstract interface SimpleResult extends AbstractResult {}
>
> ??? class Result1 implements SimpleResult {}
>
> ??? class OtherResult implements AbstractResult {}
>
> ??? public class SimpleDemo<Request extends AbstractResult, Response 
> extends AbstractResult> extends AbstractDemo<Request, Response> {
> ??????? @Override
> ??????? protected SimpleResult test(AbstractResult request) {? 
> <----------- this method is accepted as a good override for 
> AbstractDemo::test
> ??????????? return null;
> ??????? }
> ??? }
> }
>
> From Dan's evaluation at the bug entry [1]:
>
> Per JLS 8.4.8.3, the first method must be return-type-substitutable 
> for the second. This can be satisfied in 3 ways (JLS 8.4.5):
> - SimpleResult is a subtype of Response (no)
> - SimpleResult can be converted to a subtype of Response by unchecked 
> conversion (no)
> - The methods have different signatures (yep) and SimpleResult = 
> erasure(Response) (no)
>
> No case applies, so an error should occur. This fix syncs javac with 
> the spec.
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8207224
> [2] http://cr.openjdk.java.net/~vromero/8207224/webrev.00/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181203/55974c8e/attachment.html>

From maurizio.cimadamore at oracle.com  Mon Dec  3 21:13:18 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 3 Dec 2018 21:13:18 +0000
Subject: RFR: JDK-8207224: Javac compiles source code despite illegal use
 of unchecked conversions
In-Reply-To: <76e067ba-91f2-0f70-1963-bed523ad1a51@oracle.com>
References: <bdb24823-103b-ba39-c369-7f89ff5f9ad8@oracle.com>
 <76e067ba-91f2-0f70-1963-bed523ad1a51@oracle.com>
Message-ID: <48504207-95f7-b35a-e1db-0f04a50c9edd@oracle.com>

Looks good - btw, if the compatibility cost proves to be too much we 
could consider putting the new behavior behind the source switch (as we 
did with override/hide string clash checking for some time).

Cheers
Maurizio

On 03/12/2018 21:01, Vicente Romero wrote:
> Hi,
>
> Please review the related CSR [1]
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8214729
>
> On 12/1/18 2:46 PM, Vicente Romero wrote:
>> Please review fix for [1] at [2]. Javac is accepting this program as 
>> valid:
>>
>> class ReturnTypeSubstitutableTest {
>> ??? abstract class AbstractDemo<Request extends AbstractResult, 
>> Response extends AbstractResult> {
>> ??????? protected abstract Response test(Request request);
>> ??? }
>>
>> ??? abstract interface AbstractResult {}
>>
>> ??? abstract interface SimpleResult extends AbstractResult {}
>>
>> ??? class Result1 implements SimpleResult {}
>>
>> ??? class OtherResult implements AbstractResult {}
>>
>> ??? public class SimpleDemo<Request extends AbstractResult, Response 
>> extends AbstractResult> extends AbstractDemo<Request, Response> {
>> ??????? @Override
>> ??????? protected SimpleResult test(AbstractResult request) {? 
>> <----------- this method is accepted as a good override for 
>> AbstractDemo::test
>> ??????????? return null;
>> ??????? }
>> ??? }
>> }
>>
>> From Dan's evaluation at the bug entry [1]:
>>
>> Per JLS 8.4.8.3, the first method must be return-type-substitutable 
>> for the second. This can be satisfied in 3 ways (JLS 8.4.5):
>> - SimpleResult is a subtype of Response (no)
>> - SimpleResult can be converted to a subtype of Response by unchecked 
>> conversion (no)
>> - The methods have different signatures (yep) and SimpleResult = 
>> erasure(Response) (no)
>>
>> No case applies, so an error should occur. This fix syncs javac with 
>> the spec.
>>
>> Thanks,
>> Vicente
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8207224
>> [2] http://cr.openjdk.java.net/~vromero/8207224/webrev.00/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181203/8bb11909/attachment-0001.html>

From vicente.romero at oracle.com  Mon Dec  3 21:50:05 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 3 Dec 2018 16:50:05 -0500
Subject: RFR: JDK-8207224: Javac compiles source code despite illegal use
 of unchecked conversions
In-Reply-To: <48504207-95f7-b35a-e1db-0f04a50c9edd@oracle.com>
References: <bdb24823-103b-ba39-c369-7f89ff5f9ad8@oracle.com>
 <76e067ba-91f2-0f70-1963-bed523ad1a51@oracle.com>
 <48504207-95f7-b35a-e1db-0f04a50c9edd@oracle.com>
Message-ID: <3befc99f-430b-b05d-c3f7-62d3034234a5@oracle.com>



On 12/3/18 4:13 PM, Maurizio Cimadamore wrote:
>
> Looks good - btw, if the compatibility cost proves to be too much we 
> could consider putting the new behavior behind the source switch (as 
> we did with override/hide string clash checking for some time).
>

thanks for the review, yes good idea we could do that later if we get 
complains

> Cheers
> Maurizio
>

Vicente

> On 03/12/2018 21:01, Vicente Romero wrote:
>> Hi,
>>
>> Please review the related CSR [1]
>>
>> Thanks,
>> Vicente
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8214729
>>
>> On 12/1/18 2:46 PM, Vicente Romero wrote:
>>> Please review fix for [1] at [2]. Javac is accepting this program as 
>>> valid:
>>>
>>> class ReturnTypeSubstitutableTest {
>>> ??? abstract class AbstractDemo<Request extends AbstractResult, 
>>> Response extends AbstractResult> {
>>> ??????? protected abstract Response test(Request request);
>>> ??? }
>>>
>>> ??? abstract interface AbstractResult {}
>>>
>>> ??? abstract interface SimpleResult extends AbstractResult {}
>>>
>>> ??? class Result1 implements SimpleResult {}
>>>
>>> ??? class OtherResult implements AbstractResult {}
>>>
>>> ??? public class SimpleDemo<Request extends AbstractResult, Response 
>>> extends AbstractResult> extends AbstractDemo<Request, Response> {
>>> ??????? @Override
>>> ??????? protected SimpleResult test(AbstractResult request) {? 
>>> <----------- this method is accepted as a good override for 
>>> AbstractDemo::test
>>> ??????????? return null;
>>> ??????? }
>>> ??? }
>>> }
>>>
>>> From Dan's evaluation at the bug entry [1]:
>>>
>>> Per JLS 8.4.8.3, the first method must be return-type-substitutable 
>>> for the second. This can be satisfied in 3 ways (JLS 8.4.5):
>>> - SimpleResult is a subtype of Response (no)
>>> - SimpleResult can be converted to a subtype of Response by 
>>> unchecked conversion (no)
>>> - The methods have different signatures (yep) and SimpleResult = 
>>> erasure(Response) (no)
>>>
>>> No case applies, so an error should occur. This fix syncs javac with 
>>> the spec.
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8207224
>>> [2] http://cr.openjdk.java.net/~vromero/8207224/webrev.00/
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181203/a7d227c6/attachment.html>

From eolivelli at gmail.com  Mon Dec  3 21:58:32 2018
From: eolivelli at gmail.com (Enrico Olivelli)
Date: Mon, 3 Dec 2018 22:58:32 +0100
Subject: Debugging/Profing javac
Message-ID: <CACcefgdtY0QJNGnK1s1cyx2eF3xGDFQ0pC8yV0THq1-3DcUm2A@mail.gmail.com>

Hi,
I have a java application made of about 2000 classes, and javac take a very
long time to compile the module, like more than one minute (on workstations
which usually are able to compile similar projects faster).

This is very strage and I guess there is some .java file which is making
javac work more than what is needed.
Is there any 'profile' or 'debug' mode which prints the processing time for
each file or group of files/classes ?

Best regards
Enrico Olivelli
-- 


-- Enrico Olivelli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181203/266d76d2/attachment.html>

From vicente.romero at oracle.com  Mon Dec  3 23:32:33 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 3 Dec 2018 18:32:33 -0500
Subject: RFR: JDK-8207224: Javac compiles source code despite illegal use
 of unchecked conversions
In-Reply-To: <48504207-95f7-b35a-e1db-0f04a50c9edd@oracle.com>
References: <bdb24823-103b-ba39-c369-7f89ff5f9ad8@oracle.com>
 <76e067ba-91f2-0f70-1963-bed523ad1a51@oracle.com>
 <48504207-95f7-b35a-e1db-0f04a50c9edd@oracle.com>
Message-ID: <66213894-ec9f-b945-cf2b-d70426e11258@oracle.com>

Hi,

On 12/3/18 4:13 PM, Maurizio Cimadamore wrote:
>
> Looks good - btw, if the compatibility cost proves to be too much we 
> could consider putting the new behavior behind the source switch (as 
> we did with override/hide string clash checking for some time).
>

I have modified the patch adding a guard to execute the new test only if 
source is >= 12, please take a look at the new iteration [1], I have 
also modified the CSR [2] accordingly

> Cheers
> Maurizio
>

Thanks,
Vicente

[1] http://cr.openjdk.java.net/~vromero/8207224/webrev.01/
[2] https://bugs.openjdk.java.net/browse/JDK-8214729

> On 03/12/2018 21:01, Vicente Romero wrote:
>> Hi,
>>
>> Please review the related CSR [1]
>>
>> Thanks,
>> Vicente
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8214729
>>
>> On 12/1/18 2:46 PM, Vicente Romero wrote:
>>> Please review fix for [1] at [2]. Javac is accepting this program as 
>>> valid:
>>>
>>> class ReturnTypeSubstitutableTest {
>>> ??? abstract class AbstractDemo<Request extends AbstractResult, 
>>> Response extends AbstractResult> {
>>> ??????? protected abstract Response test(Request request);
>>> ??? }
>>>
>>> ??? abstract interface AbstractResult {}
>>>
>>> ??? abstract interface SimpleResult extends AbstractResult {}
>>>
>>> ??? class Result1 implements SimpleResult {}
>>>
>>> ??? class OtherResult implements AbstractResult {}
>>>
>>> ??? public class SimpleDemo<Request extends AbstractResult, Response 
>>> extends AbstractResult> extends AbstractDemo<Request, Response> {
>>> ??????? @Override
>>> ??????? protected SimpleResult test(AbstractResult request) {? 
>>> <----------- this method is accepted as a good override for 
>>> AbstractDemo::test
>>> ??????????? return null;
>>> ??????? }
>>> ??? }
>>> }
>>>
>>> From Dan's evaluation at the bug entry [1]:
>>>
>>> Per JLS 8.4.8.3, the first method must be return-type-substitutable 
>>> for the second. This can be satisfied in 3 ways (JLS 8.4.5):
>>> - SimpleResult is a subtype of Response (no)
>>> - SimpleResult can be converted to a subtype of Response by 
>>> unchecked conversion (no)
>>> - The methods have different signatures (yep) and SimpleResult = 
>>> erasure(Response) (no)
>>>
>>> No case applies, so an error should occur. This fix syncs javac with 
>>> the spec.
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8207224
>>> [2] http://cr.openjdk.java.net/~vromero/8207224/webrev.00/
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181203/bdc77dc4/attachment-0001.html>

From alex.buckley at oracle.com  Mon Dec  3 23:50:55 2018
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 03 Dec 2018 15:50:55 -0800
Subject: Where do empty compilation units belong?
In-Reply-To: <BN6PR06MB32195133E4477DBCA6415CC087AE0@BN6PR06MB3219.namprd06.prod.outlook.com>
References: <CY4PR06MB30459CBAFE24C530F9A410FB87DA0@CY4PR06MB3045.namprd06.prod.outlook.com>
 <5BFC6921.70102@oracle.com>,
 <8884f6e3-98c9-f84a-8e79-f719b70854b6@oracle.com>
 <BN6PR06MB32195133E4477DBCA6415CC087AE0@BN6PR06MB3219.namprd06.prod.outlook.com>
Message-ID: <5C05C15F.4090809@oracle.com>

Thanks to Jon and Jay's testing, we can make the following statement:

Compilers ignore a source file that is physically empty (zero length) or 
logically empty (contains only whitespace and/or comments).

(I confirmed this by tweaking Test.java so that the empty case was not 
`""` but rather `" /* Comment */ "`. javac still accepted/ignored it.)

In other words, compilers do not observe an ordinary compilation unit if 
it has no package, import, or type declarations -- a.k.a. a "vacant" 
ordinary compilation unit.

We know this to be true because if compilers did observe a vacant 
ordinary compilation unit, then the lack of a package declaration would 
cause an error when the empty source file is in a modular location; but 
no such error is given.

Compilers are free to take this not-observable stance, per 7.3: "The 
host system determines which compilation units are observable". It would 
be possible to mandate that the host system MUST NOT observe a vacant 
ordinary compilation unit, but such a mandate would probably have 
unintended consequences. It would also be possible to define a vacant 
ordinary compilation unit out of existence, by tweaking 7.3's grammar as 
proposed in the quoted mail below, but again, beware unintended 
consequences. What the JLS should do is affirm the compilers' decision 
to "accept/ignore" a vacant ordinary compilation unit, by clarifying 
that a vacant ordinary compilation unit is exempt from the "part of an 
unnamed package" rule in 7.4.2. I have filed spec bug JDK-8214743; "An 
ordinary compilation unit that has no package declaration, but has at 
least one other kind of declaration, is part of an unnamed package."

Alex

P.S.  In the course of examining 7.3's grammar, I realized that 
OrdinaryCompilationUnit is not congruent with how 2.1 defines a 
production in a context-free grammar as having "a sequence of one or 
more nonterminal and terminal symbols as its right-hand side."

2.1's definition is intended to apply _after_ interpretation of 2.4's 
grammar notation. For example, the production `A: [B]` is really two 
productions, `A: ` and `A: B`. The first has zero symbols as its RHS, so 
the grammar is not context-free -- parsing of an A is possible at any 
time, based on considerations other than the terminals in hand. 
Similarly, the production `C: {D}` is really an infinite number of 
productions `C: ` and `C: D` and `C: D D` and `C: D D D` etc. 
OrdinaryCompilationUnit is significant for being the only production in 
the JLS to allow zero symbols and thus _not_ be context-free. Compilers 
provide the context when they lex an empty source file and decide not to 
observe an ordinary compilation unit therein.

There's nothing good to be done here. We aren't going to change the 
longstanding OrdinaryCompilationUnit production after all, and I don't 
want to complicate 2.1 by special-casing its zero-symbols RHS.

On 12/3/2018 8:29 AM, Jayaprakash Artanareeswaran wrote:
> Thanks for the test file Jon. Last week I and Stephan had a discussion
> and agreed with the specified behavior and made some changes to our
> compiler.
>
> I can also confirm that both the compilers behave the same way for all
> the scenarios included in the test file.
>
> Regards,
> Jay
>
> ------------------------------------------------------------------------
> *From:* Jonathan Gibbons <jonathan.gibbons at oracle.com>
> *Sent:* Monday, November 26, 2018 11:22 PM
> *To:* Alex Buckley; Jayaprakash Artanareeswaran;
> jigsaw-dev at openjdk.java.net; compiler-dev
> *Subject:* Re: Where do empty compilation units belong?
>
>
>
> On 11/26/2018 01:44 PM, Alex Buckley wrote:
>> // Adding compiler-dev since the parsing of files into compilation
>> units is not a Jigsaw issue.
>>
>> On 11/20/2018 9:14 PM, Jayaprakash Artanareeswaran wrote:
>>> "jigsaw-dev" <jigsaw-dev-bounces at openjdk.java.net>
>>> <mailto:jigsaw-dev-bounces at openjdk.java.net> wrote on 21/11/2018
>>> 01:56:42 AM:
>>>  > Jon points out that `OrdinaryCompilationUnit` will match an empty
>>> stream
>>>  > of tokens (I dislike the syntax-driven optionality here, but it's
>>>  > longstanding) so the file D.java could be regarded as a
>>> compilation unit
>>>  > with no package declaration, no import declarations, and no type
>>>  > declarations.
>>>  >
>>>  > Per JLS 7.4.2, such a compilation unit is in an unnamed package, and
>>>  > must be associated with an unnamed module.
>>>  >
>>>  > I would prefer 7.4.2 to say only that a compilation unit with no
>>> package
>>>  > declarations _and at least one type declaration_ is in an unnamed
>>>  > package (and must be associated with an unnamed module; 7.3 should
>>>  > enumerate that possibility). A compilation unit with no package
>>>  > declarations _and no type declarations_ would be deemed
>>> unobservable by
>>>  > 7.3, and all these questions about what to do with empty files would
>>>  > disappear.
>>>
>>> That would be perfect and make things unambiguous. But for now, the
>>> paragraph above is good enough for me.
>>
>> Unfortunately, import declarations can have side effects (compile-time
>> errors) so to be sure that the "no package or type decl ===
>> unobservable" rule is suitable for a file containing just an import
>> decl, we would have to do a case analysis of how javac and ecj handle
>> the eight combinations of the three parts allowed in an ordinary
>> compilation unit. That's overkill for the situation involving empty
>> files that keeps coming up and that I really want to clarify. I don't
>> think anyone loves that an ordinary compilation unit matches the empty
>> stream, so let's define away that scenario. As Jon said, an empty file
>> doesn't present anything to be checked; there is no compilation unit
>> there, so let's be unambiguous about that.
>>
>> We can rule out the empty stream in 7.3 with grammar or with
>> semantics. Usually a semantic description is clearest (gives everyone
>> the proper terminology and concepts) but in this case we don't want
>> the description to wrestle with "consists of one, two, or three parts"
>> when the grammar allows zero. So, a new grammatical description is
>> appropriate, and straightforward:
>>
>>   OrdinaryCompilationUnit:
>>     PackageDeclaration {ImportDeclaration} {TypeDeclaration}
>>     ImportDeclaration {ImportDeclaration} {TypeDeclaration}
>>     TypeDeclaration {TypeDeclaration}
>>
>> The "three parts, each of which is optional" description is still
>> accurate. The package decl part is optional (as long as you have the
>> import decls part and/or the type decls part); the import decls part
>> is optional (as long as you have either the package decl part or ...)
>> ... you get the picture.
>>
>> I would leave 7.4.2 alone; an ordinary compilation unit with no
>> package or type decls but with import decls is part of the unnamed
>> package (and thus unnamed module) as before, and compilers can handle
>> that, I think.
>>
>> Any comments?
>>
>> Alex
>
> That seems good to me.
>
> To summarize the javac behavior ...
>
>   * javac accepts/ignores an empty file
>   * javac treats import-only compilation units as in the unnamed
>     package, which is not allowed in a named module
>   * javac enforces file naming constraints when declaring a public class
>   * javac uses file naming constraints when looking on the (module)
>     source path for a file for a class
>
>
> Attached is a toy class to generate combinations of package, import and
> type declarations. You can use the source-launcher feature to run it.
>
> -- Jon
>

From cushon at google.com  Tue Dec  4 00:29:46 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 3 Dec 2018 16:29:46 -0800
Subject: RFR: JDK-8207224: Javac compiles source code despite illegal use
 of unchecked conversions
In-Reply-To: <fef8cb1d-3aa2-2d77-be52-e2bc16dc2b1d@oracle.com>
References: <bdb24823-103b-ba39-c369-7f89ff5f9ad8@oracle.com>
 <CAL4QsgvKmat7exH1JhigzXQFUORaCVbbXZ37dO0dFyeOLWRRfQ@mail.gmail.com>
 <cbaaa050-1d23-5b8b-985d-4b47f22707dc@oracle.com>
 <fef8cb1d-3aa2-2d77-be52-e2bc16dc2b1d@oracle.com>
Message-ID: <CAL4Qsgtda8V=BaOhGq8W29x+otYs_Rby6VMnxjhU3yVQd0HULQ@mail.gmail.com>

There was a mention of crisper data in the CSR: for the corpus I looked at,
the fix affected one file per 202,000.

On Mon, Dec 3, 2018 at 10:50 AM joe darcy <joe.darcy at oracle.com> wrote:

> Since it sounds like there is nontrivial source compatibility impact with
> this change, please file a CSR for it.
>
Out of curiosity, what's the bar for whether a source incompatibility is
nontrivial-enough to warrant a CSR, or putting behind a flag?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181203/42395178/attachment.html>

From vicente.romero at oracle.com  Tue Dec  4 00:31:37 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 3 Dec 2018 19:31:37 -0500
Subject: Debugging/Profing javac
In-Reply-To: <CACcefgdtY0QJNGnK1s1cyx2eF3xGDFQ0pC8yV0THq1-3DcUm2A@mail.gmail.com>
References: <CACcefgdtY0QJNGnK1s1cyx2eF3xGDFQ0pC8yV0THq1-3DcUm2A@mail.gmail.com>
Message-ID: <62487a98-c96e-b77a-7ed2-9db9be1f6730@oracle.com>

Hi Enrico,

On 12/3/18 4:58 PM, Enrico Olivelli wrote:
> Hi,
> I have a java application made of about 2000 classes, and javac take a 
> very long time to compile the module, like more than one minute (on 
> workstations which usually are able to compile similar projects faster).
>
> This is very strage and I guess there is some .java file which is 
> making javac work more than what is needed.
> Is there any 'profile' or 'debug' mode which prints the processing 
> time for each file or group of files/classes ?

you will need to use an external profiler, is the code accessible in any 
way? is javac the only one to blame, I mean are you using maven or 
similar to build?

>
> Best regards
> Enrico Olivelli
> -- 
>
>
> -- Enrico Olivelli
>
Thanks,
Vicente
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181203/ba52c1b2/attachment.html>

From maurizio.cimadamore at oracle.com  Tue Dec  4 00:37:18 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 4 Dec 2018 00:37:18 +0000
Subject: RFR: JDK-8207224: Javac compiles source code despite illegal use
 of unchecked conversions
In-Reply-To: <66213894-ec9f-b945-cf2b-d70426e11258@oracle.com>
References: <bdb24823-103b-ba39-c369-7f89ff5f9ad8@oracle.com>
 <76e067ba-91f2-0f70-1963-bed523ad1a51@oracle.com>
 <48504207-95f7-b35a-e1db-0f04a50c9edd@oracle.com>
 <66213894-ec9f-b945-cf2b-d70426e11258@oracle.com>
Message-ID: <d4f86449-b7ff-b874-e672-28f4cbff6725@oracle.com>

The patch and CSR look good - but I'm not sure if it's worth playing 
defensively from the start (sorry if my message was misinterpreted).

That is, if there is a chance that by dropping the subtyping test we 
could consolidate the various code paths in Types for checking for 
return type subst, then we should evaluate the cost of breaking clients 
against the cost of having diverging implementations. Of course if the 
breakage is big, the implementation aspects become secondary, but if the 
breakage is minimal/non-observed in practice, then we should strive for 
fidelity with the spec (and cleaner code) ?

Maurizio


On 03/12/2018 23:32, Vicente Romero wrote:
> Hi,
>
> On 12/3/18 4:13 PM, Maurizio Cimadamore wrote:
>>
>> Looks good - btw, if the compatibility cost proves to be too much we 
>> could consider putting the new behavior behind the source switch (as 
>> we did with override/hide string clash checking for some time).
>>
>
> I have modified the patch adding a guard to execute the new test only 
> if source is >= 12, please take a look at the new iteration [1], I 
> have also modified the CSR [2] accordingly
>
>> Cheers
>> Maurizio
>>
>
> Thanks,
> Vicente
>
> [1] http://cr.openjdk.java.net/~vromero/8207224/webrev.01/
> [2] https://bugs.openjdk.java.net/browse/JDK-8214729
>
>> On 03/12/2018 21:01, Vicente Romero wrote:
>>> Hi,
>>>
>>> Please review the related CSR [1]
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8214729
>>>
>>> On 12/1/18 2:46 PM, Vicente Romero wrote:
>>>> Please review fix for [1] at [2]. Javac is accepting this program 
>>>> as valid:
>>>>
>>>> class ReturnTypeSubstitutableTest {
>>>> ??? abstract class AbstractDemo<Request extends AbstractResult, 
>>>> Response extends AbstractResult> {
>>>> ??????? protected abstract Response test(Request request);
>>>> ??? }
>>>>
>>>> ??? abstract interface AbstractResult {}
>>>>
>>>> ??? abstract interface SimpleResult extends AbstractResult {}
>>>>
>>>> ??? class Result1 implements SimpleResult {}
>>>>
>>>> ??? class OtherResult implements AbstractResult {}
>>>>
>>>> ??? public class SimpleDemo<Request extends AbstractResult, 
>>>> Response extends AbstractResult> extends AbstractDemo<Request, 
>>>> Response> {
>>>> ??????? @Override
>>>> ??????? protected SimpleResult test(AbstractResult request) {? 
>>>> <----------- this method is accepted as a good override for 
>>>> AbstractDemo::test
>>>> ??????????? return null;
>>>> ??????? }
>>>> ??? }
>>>> }
>>>>
>>>> From Dan's evaluation at the bug entry [1]:
>>>>
>>>> Per JLS 8.4.8.3, the first method must be return-type-substitutable 
>>>> for the second. This can be satisfied in 3 ways (JLS 8.4.5):
>>>> - SimpleResult is a subtype of Response (no)
>>>> - SimpleResult can be converted to a subtype of Response by 
>>>> unchecked conversion (no)
>>>> - The methods have different signatures (yep) and SimpleResult = 
>>>> erasure(Response) (no)
>>>>
>>>> No case applies, so an error should occur. This fix syncs javac 
>>>> with the spec.
>>>>
>>>> Thanks,
>>>> Vicente
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8207224
>>>> [2] http://cr.openjdk.java.net/~vromero/8207224/webrev.00/
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181204/332d163f/attachment-0001.html>

From vicente.romero at oracle.com  Tue Dec  4 03:33:53 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 3 Dec 2018 22:33:53 -0500
Subject: RFR: 8213703: LambdaConversionException: Invalid receiver type not a
 subtype of implementation type interface
Message-ID: <8bed462b-ff8e-bccd-724b-cc4311d64851@oracle.com>

Please review fix for [1] at [2]. Similar issues has been reported and 
fixed in the past, see for example [3]. The approach to fix these type 
of bugs has been that if the target interface has parameters which are 
intersection or union types then we bail out and produce a lambda 
instead of a method reference. As in this case we are dealing with a 
capture variable it was defeating the our checks.

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8213703
[2] http://cr.openjdk.java.net/~vromero/8213703/webrev.00/
[3] https://bugs.openjdk.java.net/browse/JDK-8191655

From eolivelli at gmail.com  Tue Dec  4 06:09:31 2018
From: eolivelli at gmail.com (Enrico Olivelli)
Date: Tue, 4 Dec 2018 07:09:31 +0100
Subject: Debugging/Profing javac
In-Reply-To: <62487a98-c96e-b77a-7ed2-9db9be1f6730@oracle.com>
References: <CACcefgdtY0QJNGnK1s1cyx2eF3xGDFQ0pC8yV0THq1-3DcUm2A@mail.gmail.com>
 <62487a98-c96e-b77a-7ed2-9db9be1f6730@oracle.com>
Message-ID: <CACcefgf4izfC-X7aGiCj7PChh1nqbG3wsge4DJfoaochGx+zyw@mail.gmail.com>

Il mar 4 dic 2018, 04:04 Vicente Romero <vicente.romero at oracle.com> ha
scritto:

> Hi Enrico,
>
> On 12/3/18 4:58 PM, Enrico Olivelli wrote:
>
> Hi,
> I have a java application made of about 2000 classes, and javac take a
> very long time to compile the module, like more than one minute (on
> workstations which usually are able to compile similar projects faster).
>
> This is very strage and I guess there is some .java file which is making
> javac work more than what is needed.
> Is there any 'profile' or 'debug' mode which prints the processing time
> for each file or group of files/classes ?
>
>
> you will need to use an external profiler, is the code accessible in any
> way? is javac the only one to blame, I mean are you using maven or similar
> to build?
>

Vicente,

Unfortunately it is not opensource code.
I can use yourkit, jvisualvm,jmc or what you suggest, but with a profiler
you don't get the info to understand which files are the hotspot.
I can share some dump, or sample  JVM stacktraces.
For what I can understand it is not a problem about I/O.
I am using Maven, but I am sure the problem is only the pure javac
execution. I am running javac in the process as Maven, but even 'forking'
javac has the same result.
I can try to reproduce it without Maven (I can grab the command line in
form mode and relaunch javac)

If there is no out of the box flag, maybe I can add some logging on javac
but I need some advice about what to instrument.

I forgot to say that I am on linux, with latest jdk11 openjdk published
build, but with jdk8 the result is pretty the same. Code is compiled with
source/target = 8.

I am not able to track down to the commit in my code which introduced the
slowdown.


Thank you

Enrico


>
> Best regards
> Enrico Olivelli
> --
>
>
> -- Enrico Olivelli
>
> Thanks,
> Vicente
>
-- 


-- Enrico Olivelli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181204/402f1a0d/attachment.html>

From vicente.romero at oracle.com  Tue Dec  4 13:15:44 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 4 Dec 2018 08:15:44 -0500
Subject: Debugging/Profing javac
In-Reply-To: <CACcefgf4izfC-X7aGiCj7PChh1nqbG3wsge4DJfoaochGx+zyw@mail.gmail.com>
References: <CACcefgdtY0QJNGnK1s1cyx2eF3xGDFQ0pC8yV0THq1-3DcUm2A@mail.gmail.com>
 <62487a98-c96e-b77a-7ed2-9db9be1f6730@oracle.com>
 <CACcefgf4izfC-X7aGiCj7PChh1nqbG3wsge4DJfoaochGx+zyw@mail.gmail.com>
Message-ID: <5313916b-1bc2-5488-2eaa-ecf7e82bda09@oracle.com>



On 12/4/18 1:09 AM, Enrico Olivelli wrote:
>
>
> Il mar 4 dic 2018, 04:04 Vicente Romero <vicente.romero at oracle.com 
> <mailto:vicente.romero at oracle.com>> ha scritto:
>
>     Hi Enrico,
>
>     On 12/3/18 4:58 PM, Enrico Olivelli wrote:
>>     Hi,
>>     I have a java application made of about 2000 classes, and javac
>>     take a very long time to compile the module, like more than one
>>     minute (on workstations which usually are able to compile similar
>>     projects faster).
>>
>>     This is very strage and I guess there is some .java file which is
>>     making javac work more than what is needed.
>>     Is there any 'profile' or 'debug' mode which prints the
>>     processing time for each file or group of files/classes ?
>
>     you will need to use an external profiler, is the code accessible
>     in any way? is javac the only one to blame, I mean are you using
>     maven or similar to build?
>
>
> Vicente,
>
> Unfortunately it is not opensource code.
> I can use yourkit, jvisualvm,jmc or what you suggest, but with a 
> profiler you don't get the info to understand which files are the hotspot.

Java Mission Control should be fine to get a global picture.

> I can share some dump, or sample? JVM stacktraces.

yes that could help

> For what I can understand it is not a problem about I/O.
> I am using Maven, but I am sure the problem is only the pure javac 
> execution. I am running javac in the process as Maven, but even 
> 'forking' javac has the same result.
> I can try to reproduce it without Maven (I can grab the command line 
> in form mode and relaunch javac)
yes removing Maven from the picture will be helpful isolating the issue.
>
> If there is no out of the box flag, maybe I can add some logging on 
> javac but I need some advice about what to instrument.

IMO adding logging could alter the results

>
> I forgot to say that I am on linux, with latest jdk11 openjdk 
> published build, but with jdk8 the result is pretty the same. Code is 
> compiled with source/target = 8.

what happens if you remove the source/target=8 provided that that is an 
option?

>
> I am not able to track down to the commit in my code which introduced 
> the slowdown.
>
>
> Thank you
>
> Enrico

Vicente

>
>
>>
>>     Best regards
>>     Enrico Olivelli
>>     -- 
>>
>>
>>     -- Enrico Olivelli
>>
>     Thanks,
>     Vicente
>
> -- 
>
>
> -- Enrico Olivelli
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181204/756c1fd0/attachment.html>

From eolivelli at gmail.com  Tue Dec  4 13:58:45 2018
From: eolivelli at gmail.com (Enrico Olivelli)
Date: Tue, 4 Dec 2018 14:58:45 +0100
Subject: Debugging/Profing javac
In-Reply-To: <5313916b-1bc2-5488-2eaa-ecf7e82bda09@oracle.com>
References: <CACcefgdtY0QJNGnK1s1cyx2eF3xGDFQ0pC8yV0THq1-3DcUm2A@mail.gmail.com>
 <62487a98-c96e-b77a-7ed2-9db9be1f6730@oracle.com>
 <CACcefgf4izfC-X7aGiCj7PChh1nqbG3wsge4DJfoaochGx+zyw@mail.gmail.com>
 <5313916b-1bc2-5488-2eaa-ecf7e82bda09@oracle.com>
Message-ID: <CACcefgdN0iqifnAnbusD9NHFrhN=PmdzJVL4=SFZiaQFS0jiVQ@mail.gmail.com>

Il giorno mar 4 dic 2018 alle ore 14:15 Vicente Romero
<vicente.romero at oracle.com> ha scritto:
>
>
>
> On 12/4/18 1:09 AM, Enrico Olivelli wrote:
>
>
>
> Il mar 4 dic 2018, 04:04 Vicente Romero <vicente.romero at oracle.com> ha scritto:
>>
>> Hi Enrico,
>>
>> On 12/3/18 4:58 PM, Enrico Olivelli wrote:
>>
>> Hi,
>> I have a java application made of about 2000 classes, and javac take a very long time to compile the module, like more than one minute (on workstations which usually are able to compile similar projects faster).
>>
>> This is very strage and I guess there is some .java file which is making javac work more than what is needed.
>> Is there any 'profile' or 'debug' mode which prints the processing time for each file or group of files/classes ?
>>
>>
>> you will need to use an external profiler, is the code accessible in any way? is javac the only one to blame, I mean are you using maven or similar to build?
>
>
> Vicente,
>
> Unfortunately it is not opensource code.
> I can use yourkit, jvisualvm,jmc or what you suggest, but with a profiler you don't get the info to understand which files are the hotspot.
>
>
> Java Mission Control should be fine to get a global picture.

Ok, using JMC 7 (the one downloadable from openjdk website)

>
> I can share some dump, or sample  JVM stacktraces.
>
>
> yes that could help

How can I share with you the .jfr file of the recording ? Are you
interested in specific information ?
I don't know javac internals, so I can't point specific issues.

>
> For what I can understand it is not a problem about I/O.
> I am using Maven, but I am sure the problem is only the pure javac execution. I am running javac in the process as Maven, but even 'forking' javac has the same result.
> I can try to reproduce it without Maven (I can grab the command line in form mode and relaunch javac)
>
> yes removing Maven from the picture will be helpful isolating the issue.

Now I am using fork=false, so javac is a separate process and I am
able to grab a live recording.

>
>
> If there is no out of the box flag, maybe I can add some logging on javac but I need some advice about what to instrument.
>
>
> IMO adding logging could alter the results

got it
>
>
> I forgot to say that I am on linux, with latest jdk11 openjdk published build, but with jdk8 the result is pretty the same. Code is compiled with source/target = 8.
>
>
> what happens if you remove the source/target=8 provided that that is an option?

Same results

Enrico

>
>
> I am not able to track down to the commit in my code which introduced the slowdown.
>
>
> Thank you
>
> Enrico
>
>
> Vicente
>
>
>>
>>
>> Best regards
>> Enrico Olivelli
>> --
>>
>>
>> -- Enrico Olivelli
>>
>> Thanks,
>> Vicente
>
> --
>
>
> -- Enrico Olivelli
>
>

From joe.darcy at oracle.com  Wed Dec  5 06:46:25 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 4 Dec 2018 22:46:25 -0800
Subject: JDK 13 RFR of CSR JDK-8214829: Update preview language features for
 start of JDK 13
Message-ID: <ba02936a-7218-2a30-f498-6b71e15839a5@oracle.com>

Hello,

Getting ready for JDK 13, please review the CSR for

 ??? JDK-8214829: Update preview language features for start of JDK 13
 ??? https://bugs.openjdk.java.net/browse/JDK-8214829

In brief, preview features, such as raw string literals and switch 
expressions in 12, are tied to a particular release value.

The CSR proposes to continue to allow these features to be used at the 
start of JDK 13 as now in JDK 12. This is not preclude a different 
stance toward those features (remove, keep as preview, graduate to 
normal feature) later in JDK 13.

Thanks,

-Joe


From maurizio.cimadamore at oracle.com  Wed Dec  5 10:48:27 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 5 Dec 2018 10:48:27 +0000
Subject: RFR: 8213703: LambdaConversionException: Invalid receiver type
 not a subtype of implementation type interface
In-Reply-To: <8bed462b-ff8e-bccd-724b-cc4311d64851@oracle.com>
References: <8bed462b-ff8e-bccd-724b-cc4311d64851@oracle.com>
Message-ID: <178c479e-a99e-c47c-4dc7-3eeab81f11cb@oracle.com>

Looks good!

Maurizio

On 04/12/2018 03:33, Vicente Romero wrote:
> Please review fix for [1] at [2]. Similar issues has been reported and 
> fixed in the past, see for example [3]. The approach to fix these type 
> of bugs has been that if the target interface has parameters which are 
> intersection or union types then we bail out and produce a lambda 
> instead of a method reference. As in this case we are dealing with a 
> capture variable it was defeating the our checks.
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8213703
> [2] http://cr.openjdk.java.net/~vromero/8213703/webrev.00/
> [3] https://bugs.openjdk.java.net/browse/JDK-8191655

From maurizio.cimadamore at oracle.com  Wed Dec  5 10:54:16 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 5 Dec 2018 10:54:16 +0000
Subject: JDK 13 RFR of CSR JDK-8214829: Update preview language features
 for start of JDK 13
In-Reply-To: <ba02936a-7218-2a30-f498-6b71e15839a5@oracle.com>
References: <ba02936a-7218-2a30-f498-6b71e15839a5@oracle.com>
Message-ID: <5f9d776a-bd42-b73a-2331-c5175d34c6bb@oracle.com>

Looks good - added myself as reviewer.

Maurizio

On 05/12/2018 06:46, joe darcy wrote:
> Hello,
>
> Getting ready for JDK 13, please review the CSR for
>
> ??? JDK-8214829: Update preview language features for start of JDK 13
> ??? https://bugs.openjdk.java.net/browse/JDK-8214829
>
> In brief, preview features, such as raw string literals and switch 
> expressions in 12, are tied to a particular release value.
>
> The CSR proposes to continue to allow these features to be used at the 
> start of JDK 13 as now in JDK 12. This is not preclude a different 
> stance toward those features (remove, keep as preview, graduate to 
> normal feature) later in JDK 13.
>
> Thanks,
>
> -Joe
>

From joe.darcy at oracle.com  Wed Dec  5 17:46:50 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 5 Dec 2018 09:46:50 -0800
Subject: JDK 13 RFR of JDK-8205626: Start of release updates for JDK 13
Message-ID: <bdb206a7-c8ee-a472-b792-5839a0785c75@oracle.com>

Hello,

With JDK 13 inception right around the corner, please review the 
langtools portions of

 ??? JDK-8205626: Start of release updates for JDK 13
 ??? http://cr.openjdk.java.net/~darcy/jdk13-fork.2

which include fixes for the bugs

 ??? JDK-8205393: Add SourceVersion.RELEASE_13
 ??? JDK-8205394: Add source 13 and target 13 to javac
 ??? JDK-8214825: Update preview language features for start of JDK 13

The changes to add SourceVersion.RELEASE_13 and the new -source/-target 
value are analogous to corresponding updates in earlier releases. Given 
the mechanisms used to implement the policies of JEP 12: "Preview 
Language and VM Features" (http://openjdk.java.net/jeps/12), in the 
tests for the preview language features many "12"s had to updated "13"s. 
We may look to streamline how such edits need to occur in future releases.

With this set of changes, the langtools regression tests pass cleanly. 
The build changes are being reviewed separately 
(http://mail.openjdk.java.net/pipermail/build-dev/2018-December/024285.html) 
and the core libs and hotspot changes will have their own threads once 
those changes are further along.

Thanks,

-Joe


From cushon at google.com  Wed Dec  5 19:36:33 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 5 Dec 2018 11:36:33 -0800
Subject: RFR: 8214902: Pretty-printing marker annotations add unnecessary
 parenthesis
Message-ID: <CAL4QsgtErnuFCXYSVE33t4gdt6rd0ZoAj3CAMfqEMrowWM2=sg@mail.gmail.com>

Hi,

Please consider this small improvement to pretty-printing annotation AST
nodes, which omits the parens for marker annotations (e.g. `@A` vs. `@A()`).

webrev: http://cr.openjdk.java.net/~cushon/8214902/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8214902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181205/aa1aec06/attachment.html>

From jonathan.gibbons at oracle.com  Wed Dec  5 20:39:12 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 5 Dec 2018 12:39:12 -0800
Subject: RFR: 8214902: Pretty-printing marker annotations add unnecessary
 parenthesis
In-Reply-To: <CAL4QsgtErnuFCXYSVE33t4gdt6rd0ZoAj3CAMfqEMrowWM2=sg@mail.gmail.com>
References: <CAL4QsgtErnuFCXYSVE33t4gdt6rd0ZoAj3CAMfqEMrowWM2=sg@mail.gmail.com>
Message-ID: <ad13b96d-f6e2-ac81-a35b-5c3cbca6f4ed@oracle.com>

Liam,

It is interesting to see the ongoing evolution of Pretty from what was 
originally an internal debug feature to something more useful. :-)

Just checking ... there seems to be two things going on in this review ...

1. You have improved Pretty and some obviously related tests, like 
*test/langtools/tools/javac/tree/TypeAnnotationsPretty.java*

2. You have separately chosen to tidy up the source code for a bunch of 
unrelated tests, by removing unnecessary parens from annotations.

Is that right?? I don't see that many of the modified tests are directly 
affected by the change.

(And, to be clear, I'm not objecting to the cleanup; I'm just calling it 
out as "convenient cleanup at this time".)

-- Jon

On 12/5/18 11:36 AM, Liam Miller-Cushon wrote:
> Hi,
>
> Please consider this small improvement to pretty-printing annotation 
> AST nodes, which omits the parens for marker annotations (e.g. `@A` 
> vs. `@A()`).
>
> webrev: http://cr.openjdk.java.net/~cushon/8214902/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8214902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181205/77ea98d1/attachment.html>

From cushon at google.com  Wed Dec  5 22:28:40 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 5 Dec 2018 14:28:40 -0800
Subject: RFR: 8214902: Pretty-printing marker annotations add unnecessary
 parenthesis
In-Reply-To: <ad13b96d-f6e2-ac81-a35b-5c3cbca6f4ed@oracle.com>
References: <CAL4QsgtErnuFCXYSVE33t4gdt6rd0ZoAj3CAMfqEMrowWM2=sg@mail.gmail.com>
 <ad13b96d-f6e2-ac81-a35b-5c3cbca6f4ed@oracle.com>
Message-ID: <CAL4QsgtpwnJGJJQ4FBFDD3FSPY0=9EwFSY=s-b7ABUKkHhb5sQ@mail.gmail.com>

On Wed, Dec 5, 2018 at 12:42 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> 1. You have improved Pretty and some obviously related tests, like
> *test/langtools/tools/javac/tree/TypeAnnotationsPretty.java*
> 2. You have separately chosen to tidy up the source code for a bunch of
> unrelated tests, by removing unnecessary parens from annotations.
>
> Is that right?  I don't see that many of the modified tests are directly
> affected by the change.
>

Yes, that's right: it was just as easy to clean up all of them, and I
figured the cleanup had some slight positive value.

(If you'd prefer to avoid the churn I'm happy to back out the ones that
aren't required.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181205/b76ba94b/attachment.html>

From jonathan.gibbons at oracle.com  Wed Dec  5 23:54:51 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 5 Dec 2018 15:54:51 -0800
Subject: RFR: 8214902: Pretty-printing marker annotations add unnecessary
 parenthesis
In-Reply-To: <CAL4QsgtpwnJGJJQ4FBFDD3FSPY0=9EwFSY=s-b7ABUKkHhb5sQ@mail.gmail.com>
References: <CAL4QsgtErnuFCXYSVE33t4gdt6rd0ZoAj3CAMfqEMrowWM2=sg@mail.gmail.com>
 <ad13b96d-f6e2-ac81-a35b-5c3cbca6f4ed@oracle.com>
 <CAL4QsgtpwnJGJJQ4FBFDD3FSPY0=9EwFSY=s-b7ABUKkHhb5sQ@mail.gmail.com>
Message-ID: <a7e92a10-6fea-9bb1-231e-bc638d630eae@oracle.com>

Now, the cleanup is nice.

I'd suggest you put a note in the JBS issue, if there is nothing there 
already, saying this is an opportunity to cleanup the unnecessary parens 
in other tests.

Review looks good to me.

-- Jon

On 12/5/18 2:28 PM, Liam Miller-Cushon wrote:
> On Wed, Dec 5, 2018 at 12:42 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     1. You have improved Pretty and some obviously related tests, like
>     *test/langtools/tools/javac/tree/TypeAnnotationsPretty.java*
>
>     2. You have separately chosen to tidy up the source code for a
>     bunch of unrelated tests, by removing unnecessary parens from
>     annotations.
>
>     Is that right?? I don't see that many of the modified tests are
>     directly affected by the change.
>
>
> Yes, that's right: it was just as easy to clean up all of them, and I 
> figured the cleanup had some slight positive value.
>
> (If you'd prefer to avoid the churn I'm happy to back out the ones 
> that aren't required.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181205/3d45ba97/attachment-0001.html>

From cushon at google.com  Thu Dec  6 01:53:18 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 5 Dec 2018 17:53:18 -0800
Subject: RFR: 8214902: Pretty-printing marker annotations add unnecessary
 parenthesis
In-Reply-To: <a7e92a10-6fea-9bb1-231e-bc638d630eae@oracle.com>
References: <CAL4QsgtErnuFCXYSVE33t4gdt6rd0ZoAj3CAMfqEMrowWM2=sg@mail.gmail.com>
 <ad13b96d-f6e2-ac81-a35b-5c3cbca6f4ed@oracle.com>
 <CAL4QsgtpwnJGJJQ4FBFDD3FSPY0=9EwFSY=s-b7ABUKkHhb5sQ@mail.gmail.com>
 <a7e92a10-6fea-9bb1-231e-bc638d630eae@oracle.com>
Message-ID: <CAL4QsguCzYOE+NOOp99PUO-q3NrbJh4yX4+kX67bo=_wQR-dyg@mail.gmail.com>

On Wed, Dec 5, 2018 at 3:54 PM Jonathan Gibbons <jonathan.gibbons at oracle.com>
wrote:

> I'd suggest you put a note in the JBS issue, if there is nothing there
> already, saying this is an opportunity to cleanup the unnecessary parens in
> other tests.
>
Done

> Review looks good to me.
>
Thanks for the review!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181205/48220aea/attachment.html>

From jan.lahoda at oracle.com  Thu Dec  6 16:51:25 2018
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 6 Dec 2018 17:51:25 +0100
Subject: RFR: JDK-8214114: Switch expressions with try-catch statements
Message-ID: <5C09538D.9090309@oracle.com>

Hi,

Switch expressions that contain try-catch statements don't work 
currently, as the catch handlers require that the stack is empty when 
the handler is invoked, but this may not be true when the switch 
expression is inside an expression evaluation (and so some values are 
already on the stack).

The proposed solution is to stash the stack content to local variables 
before "running" the switch expression, and fill the stack content back 
when breaking out of the switch expression. This is done only if the 
try-catch statement is present in the switch expression, as it produces 
longer bytecode.

Also, it turned out variables inside switch expressions in field 
initializers don't work properly (as their owner is the field, not a 
method), attempted to fix that as well.

JBS: https://bugs.openjdk.java.net/browse/JDK-8214114
Webrev: http://cr.openjdk.java.net/~jlahoda/8214114/webrev.00/

How does this look?

Thanks,
     Jan

From vicente.romero at oracle.com  Thu Dec  6 21:50:02 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 6 Dec 2018 16:50:02 -0500
Subject: RFR: JDK-8214114: Switch expressions with try-catch statements
In-Reply-To: <5C09538D.9090309@oracle.com>
References: <5C09538D.9090309@oracle.com>
Message-ID: <ff1eeeac-abb2-31ba-3fa4-f59dd12bbb4a@oracle.com>

Hi Jan,

Probably I'm missing something but shouldn't it be enough to generate 
the right stackframe for the exception handler? Which in this case 
should only contain:

stack = [ class java/lang/Exception ]

Thanks,
Vicente

On 12/6/18 11:51 AM, Jan Lahoda wrote:
> Hi,
>
> Switch expressions that contain try-catch statements don't work 
> currently, as the catch handlers require that the stack is empty when 
> the handler is invoked, but this may not be true when the switch 
> expression is inside an expression evaluation (and so some values are 
> already on the stack).
>
> The proposed solution is to stash the stack content to local variables 
> before "running" the switch expression, and fill the stack content 
> back when breaking out of the switch expression. This is done only if 
> the try-catch statement is present in the switch expression, as it 
> produces longer bytecode.
>
> Also, it turned out variables inside switch expressions in field 
> initializers don't work properly (as their owner is the field, not a 
> method), attempted to fix that as well.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8214114
> Webrev: http://cr.openjdk.java.net/~jlahoda/8214114/webrev.00/
>
> How does this look?
>
> Thanks,
> ??? Jan


From maurizio.cimadamore at oracle.com  Thu Dec  6 21:52:57 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 6 Dec 2018 21:52:57 +0000
Subject: RFR: JDK-8214114: Switch expressions with try-catch statements
In-Reply-To: <5C09538D.9090309@oracle.com>
References: <5C09538D.9090309@oracle.com>
Message-ID: <f97b5234-af6d-9cd5-abf6-2c71b207d408@oracle.com>

Maybe I'm misreading your description, but I don't think the problem is 
that the stack must be empty; the problem is that the VM will empty the 
stack anyway, as per the spec:

(JVM 6.5 - athrow):

"The objectref must be of type reference and must refer to an object 
that is an instance of class Throwable or of a subclass of Throwable. It 
is popped from the operand stack. The objectref is then thrown by 
searching the current method (?2.6) for the first exception handler that 
matches the class of objectref, as given by the algorithm in ?2.10."

So, I believe in your case the issue was that, once you were inside the 
handler, the VM got rid of the stuff that was on the stack and that had 
nothing to do with the switch expression, right?

As for the changes in the front-end, when doing lambdas we had to be 
quite creative in handling lambda parameters inside a field initializer 
context - but for a lambda was kind of possible because we could always 
fake some kind of (synthetic) method scope. So it appears you have no 
alternatives here - ugh (I'm a bit afraid that it will end up in a 
whack-a-mole exercise to find out all cases which assume that a variable 
owner must be something other than a variable).

Maurizio

On 06/12/2018 16:51, Jan Lahoda wrote:
> Hi,
>
> Switch expressions that contain try-catch statements don't work 
> currently, as the catch handlers require that the stack is empty when 
> the handler is invoked, but this may not be true when the switch 
> expression is inside an expression evaluation (and so some values are 
> already on the stack).
>
> The proposed solution is to stash the stack content to local variables 
> before "running" the switch expression, and fill the stack content 
> back when breaking out of the switch expression. This is done only if 
> the try-catch statement is present in the switch expression, as it 
> produces longer bytecode.
>
> Also, it turned out variables inside switch expressions in field 
> initializers don't work properly (as their owner is the field, not a 
> method), attempted to fix that as well.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8214114
> Webrev: http://cr.openjdk.java.net/~jlahoda/8214114/webrev.00/
>
> How does this look?
>
> Thanks,
> ??? Jan

From maurizio.cimadamore at oracle.com  Thu Dec  6 22:04:40 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 6 Dec 2018 22:04:40 +0000
Subject: RFR: JDK-8214114: Switch expressions with try-catch statements
In-Reply-To: <ff1eeeac-abb2-31ba-3fa4-f59dd12bbb4a@oracle.com>
References: <5C09538D.9090309@oracle.com>
 <ff1eeeac-abb2-31ba-3fa4-f59dd12bbb4a@oracle.com>
Message-ID: <34bab17d-70aa-0849-ecdb-e0779975ecf4@oracle.com>

While I don't think the stack should be as what Vicente says (after all, 
there's a Println object somewhere that should be tracked), I tend to 
agree with Vicente that there's something fishy here - I looked at the 
bug report and also run the example and the verifier crashes _before_ 
entering the exception handler - it crashes on the 'new' when the 
exception is allocated. That doesn't seem to match what you said in the 
RFR. Now, as I pointed out in my other message, I believe some stashing 
is unavoidable as the VM will wipe out the stack, but it seems like 
there could be more issues piled up here?

Maurizio

On 06/12/2018 21:50, Vicente Romero wrote:
> Hi Jan,
>
> Probably I'm missing something but shouldn't it be enough to generate 
> the right stackframe for the exception handler? Which in this case 
> should only contain:
>
> stack = [ class java/lang/Exception ]
>
> Thanks,
> Vicente
>
> On 12/6/18 11:51 AM, Jan Lahoda wrote:
>> Hi,
>>
>> Switch expressions that contain try-catch statements don't work 
>> currently, as the catch handlers require that the stack is empty when 
>> the handler is invoked, but this may not be true when the switch 
>> expression is inside an expression evaluation (and so some values are 
>> already on the stack).
>>
>> The proposed solution is to stash the stack content to local 
>> variables before "running" the switch expression, and fill the stack 
>> content back when breaking out of the switch expression. This is done 
>> only if the try-catch statement is present in the switch expression, 
>> as it produces longer bytecode.
>>
>> Also, it turned out variables inside switch expressions in field 
>> initializers don't work properly (as their owner is the field, not a 
>> method), attempted to fix that as well.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8214114
>> Webrev: http://cr.openjdk.java.net/~jlahoda/8214114/webrev.00/
>>
>> How does this look?
>>
>> Thanks,
>> ??? Jan
>

From jan.lahoda at oracle.com  Thu Dec  6 23:24:42 2018
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 7 Dec 2018 00:24:42 +0100
Subject: RFR: JDK-8214114: Switch expressions with try-catch statements
In-Reply-To: <34bab17d-70aa-0849-ecdb-e0779975ecf4@oracle.com>
References: <5C09538D.9090309@oracle.com>
 <ff1eeeac-abb2-31ba-3fa4-f59dd12bbb4a@oracle.com>
 <34bab17d-70aa-0849-ecdb-e0779975ecf4@oracle.com>
Message-ID: <5C09AFBA.30302@oracle.com>

On 6.12.2018 23:04, Maurizio Cimadamore wrote:
> While I don't think the stack should be as what Vicente says (after all,
> there's a Println object somewhere that should be tracked), I tend to
> agree with Vicente that there's something fishy here - I looked at the
> bug report and also run the example and the verifier crashes _before_
> entering the exception handler - it crashes on the 'new' when the
> exception is allocated. That doesn't seem to match what you said in the
> RFR. Now, as I pointed out in my other message, I believe some stashing
> is unavoidable as the VM will wipe out the stack, but it seems like
> there could be more issues piled up here?

Sorry, I should have been more precise. What I meant is that the 
StackMap for catch handler must not have anything on stack (except for 
the Exception) (because VM will wipe the stack, that is, I think, 
another angle to look at this). That is not related only to athrow - the 
exception may be coming from a method invocation, for example. The 
reason the verifier barks on "new" is, I think, because the instruction 
may throw an exception as well. So it checks the StackMap for the 
exception handler, and finds out there's something on the stack (in the 
StackMap) that should not be there, and fails (or, from another angle, 
when checking the exception handler, the verifier finds out the handler 
expects something on the stack, besides the exception, which can't be 
there).

Jan

>
> Maurizio
>
> On 06/12/2018 21:50, Vicente Romero wrote:
>> Hi Jan,
>>
>> Probably I'm missing something but shouldn't it be enough to generate
>> the right stackframe for the exception handler? Which in this case
>> should only contain:
>>
>> stack = [ class java/lang/Exception ]
>>
>> Thanks,
>> Vicente
>>
>> On 12/6/18 11:51 AM, Jan Lahoda wrote:
>>> Hi,
>>>
>>> Switch expressions that contain try-catch statements don't work
>>> currently, as the catch handlers require that the stack is empty when
>>> the handler is invoked, but this may not be true when the switch
>>> expression is inside an expression evaluation (and so some values are
>>> already on the stack).
>>>
>>> The proposed solution is to stash the stack content to local
>>> variables before "running" the switch expression, and fill the stack
>>> content back when breaking out of the switch expression. This is done
>>> only if the try-catch statement is present in the switch expression,
>>> as it produces longer bytecode.
>>>
>>> Also, it turned out variables inside switch expressions in field
>>> initializers don't work properly (as their owner is the field, not a
>>> method), attempted to fix that as well.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8214114
>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8214114/webrev.00/
>>>
>>> How does this look?
>>>
>>> Thanks,
>>>     Jan
>>

From vicente.romero at oracle.com  Thu Dec  6 23:36:17 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 6 Dec 2018 18:36:17 -0500
Subject: RFR: JDK-8214114: Switch expressions with try-catch statements
In-Reply-To: <34bab17d-70aa-0849-ecdb-e0779975ecf4@oracle.com>
References: <5C09538D.9090309@oracle.com>
 <ff1eeeac-abb2-31ba-3fa4-f59dd12bbb4a@oracle.com>
 <34bab17d-70aa-0849-ecdb-e0779975ecf4@oracle.com>
Message-ID: <c3e20baf-a649-7a75-5feb-1202ee1bee89@oracle.com>



On 12/6/18 5:04 PM, Maurizio Cimadamore wrote:
> While I don't think the stack should be as what Vicente says (after 
> all, there's a Println object somewhere that should be tracked), I 
> tend to agree with Vicente that there's something fishy here - I 
> looked at the bug report and also run the example and the verifier 
> crashes _before_ entering the exception handler - it crashes on the 'new' 

I think the verifier is just referring to where the frame that produced 
the error starts. It's not saying that the `new` is the one that 
produced the error

> when the exception is allocated. That doesn't seem to match what you 
> said in the RFR. Now, as I pointed out in my other message, I believe 
> some stashing is unavoidable as the VM will wipe out the stack, but it 
> seems like there could be more issues piled up here?
>
> Maurizio

Vicente

>
> On 06/12/2018 21:50, Vicente Romero wrote:
>> Hi Jan,
>>
>> Probably I'm missing something but shouldn't it be enough to generate 
>> the right stackframe for the exception handler? Which in this case 
>> should only contain:
>>
>> stack = [ class java/lang/Exception ]
>>
>> Thanks,
>> Vicente
>>
>> On 12/6/18 11:51 AM, Jan Lahoda wrote:
>>> Hi,
>>>
>>> Switch expressions that contain try-catch statements don't work 
>>> currently, as the catch handlers require that the stack is empty 
>>> when the handler is invoked, but this may not be true when the 
>>> switch expression is inside an expression evaluation (and so some 
>>> values are already on the stack).
>>>
>>> The proposed solution is to stash the stack content to local 
>>> variables before "running" the switch expression, and fill the stack 
>>> content back when breaking out of the switch expression. This is 
>>> done only if the try-catch statement is present in the switch 
>>> expression, as it produces longer bytecode.
>>>
>>> Also, it turned out variables inside switch expressions in field 
>>> initializers don't work properly (as their owner is the field, not a 
>>> method), attempted to fix that as well.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8214114
>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8214114/webrev.00/
>>>
>>> How does this look?
>>>
>>> Thanks,
>>> ??? Jan
>>


From maurizio.cimadamore at oracle.com  Thu Dec  6 23:42:21 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 6 Dec 2018 23:42:21 +0000
Subject: RFR: JDK-8214114: Switch expressions with try-catch statements
In-Reply-To: <5C09AFBA.30302@oracle.com>
References: <5C09538D.9090309@oracle.com>
 <ff1eeeac-abb2-31ba-3fa4-f59dd12bbb4a@oracle.com>
 <34bab17d-70aa-0849-ecdb-e0779975ecf4@oracle.com> <5C09AFBA.30302@oracle.com>
Message-ID: <0b9b8d4c-b94a-6423-789e-cec51c6f5389@oracle.com>


On 06/12/2018 23:24, Jan Lahoda wrote:
> On 6.12.2018 23:04, Maurizio Cimadamore wrote:
>> While I don't think the stack should be as what Vicente says (after all,
>> there's a Println object somewhere that should be tracked), I tend to
>> agree with Vicente that there's something fishy here - I looked at the
>> bug report and also run the example and the verifier crashes _before_
>> entering the exception handler - it crashes on the 'new' when the
>> exception is allocated. That doesn't seem to match what you said in the
>> RFR. Now, as I pointed out in my other message, I believe some stashing
>> is unavoidable as the VM will wipe out the stack, but it seems like
>> there could be more issues piled up here?
>
> Sorry, I should have been more precise. What I meant is that the 
> StackMap for catch handler must not have anything on stack (except for 
> the Exception) (because VM will wipe the stack, that is, I think, 
> another angle to look at this). That is not related only to athrow - 
> the exception may be coming from a method invocation, for example. The 
> reason the verifier barks on "new" is, I think, because the 
> instruction may throw an exception as well. So it checks the StackMap 
> for the exception handler, and finds out there's something on the 
> stack (in the StackMap) that should not be there, and fails (or, from 
> another angle, when checking the exception handler, the verifier finds 
> out the handler expects something on the stack, besides the exception, 
> which can't be there).

And sorry for the confusion - I realized I misread the verifier error - 
it's actually pointing at the handler entry (as javac generated both 
[PrintStream, Exception], while the VM expects just [Exception] - it 
being an handler). So what you did is correct and I think just fixing 
the stackmap is not a real solution as then we need a way to recover the 
values before leaving the switch.

Maurizio

>
> Jan
>
>>
>> Maurizio
>>
>> On 06/12/2018 21:50, Vicente Romero wrote:
>>> Hi Jan,
>>>
>>> Probably I'm missing something but shouldn't it be enough to generate
>>> the right stackframe for the exception handler? Which in this case
>>> should only contain:
>>>
>>> stack = [ class java/lang/Exception ]
>>>
>>> Thanks,
>>> Vicente
>>>
>>> On 12/6/18 11:51 AM, Jan Lahoda wrote:
>>>> Hi,
>>>>
>>>> Switch expressions that contain try-catch statements don't work
>>>> currently, as the catch handlers require that the stack is empty when
>>>> the handler is invoked, but this may not be true when the switch
>>>> expression is inside an expression evaluation (and so some values are
>>>> already on the stack).
>>>>
>>>> The proposed solution is to stash the stack content to local
>>>> variables before "running" the switch expression, and fill the stack
>>>> content back when breaking out of the switch expression. This is done
>>>> only if the try-catch statement is present in the switch expression,
>>>> as it produces longer bytecode.
>>>>
>>>> Also, it turned out variables inside switch expressions in field
>>>> initializers don't work properly (as their owner is the field, not a
>>>> method), attempted to fix that as well.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8214114
>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8214114/webrev.00/
>>>>
>>>> How does this look?
>>>>
>>>> Thanks,
>>>> ??? Jan
>>>

From vicente.romero at oracle.com  Fri Dec  7 00:17:03 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 6 Dec 2018 19:17:03 -0500
Subject: RFR: JDK-8214114: Switch expressions with try-catch statements
In-Reply-To: <5C09AFBA.30302@oracle.com>
References: <5C09538D.9090309@oracle.com>
 <ff1eeeac-abb2-31ba-3fa4-f59dd12bbb4a@oracle.com>
 <34bab17d-70aa-0849-ecdb-e0779975ecf4@oracle.com> <5C09AFBA.30302@oracle.com>
Message-ID: <757d3e29-1256-981c-b479-814569ef914d@oracle.com>



On 12/6/18 6:24 PM, Jan Lahoda wrote:
> On 6.12.2018 23:04, Maurizio Cimadamore wrote:
>> While I don't think the stack should be as what Vicente says (after all,
>> there's a Println object somewhere that should be tracked), I tend to
>> agree with Vicente that there's something fishy here - I looked at the
>> bug report and also run the example and the verifier crashes _before_
>> entering the exception handler - it crashes on the 'new' when the
>> exception is allocated. That doesn't seem to match what you said in the
>> RFR. Now, as I pointed out in my other message, I believe some stashing
>> is unavoidable as the VM will wipe out the stack, but it seems like
>> there could be more issues piled up here?
>
> Sorry, I should have been more precise. What I meant is that the 
> StackMap for catch handler must not have anything on stack (except for 
> the Exception) (because VM will wipe the stack, that is, I think, 
> another angle to look at this).

yep the verifier is just doing what the spec says, 4.10.2.2 The Bytecode 
Verifier:

...

In the special case of control transfer to an exception handler:
? Record that a single object, of the exception type indicated by the 
exception
handler, is the state of the operand stack prior to executing the successor
instruction. There must be sufficient room on the operand stack for this 
single
value, as if an instruction had pushed it.



> That is not related only to athrow - the exception may be coming from 
> a method invocation, for example. The reason the verifier barks on 
> "new" is, I think, because the instruction may throw an exception as 
> well. So it checks the StackMap for the exception handler, and finds 
> out there's something on the stack (in the StackMap) that should not 
> be there, and fails (or, from another angle, when checking the 
> exception handler, the verifier finds out the handler expects 
> something on the stack, besides the exception, which can't be there).
>
> Jan

Sorry for the confusion,

Vicente
>
>>
>> Maurizio
>>
>> On 06/12/2018 21:50, Vicente Romero wrote:
>>> Hi Jan,
>>>
>>> Probably I'm missing something but shouldn't it be enough to generate
>>> the right stackframe for the exception handler? Which in this case
>>> should only contain:
>>>
>>> stack = [ class java/lang/Exception ]
>>>
>>> Thanks,
>>> Vicente
>>>
>>> On 12/6/18 11:51 AM, Jan Lahoda wrote:
>>>> Hi,
>>>>
>>>> Switch expressions that contain try-catch statements don't work
>>>> currently, as the catch handlers require that the stack is empty when
>>>> the handler is invoked, but this may not be true when the switch
>>>> expression is inside an expression evaluation (and so some values are
>>>> already on the stack).
>>>>
>>>> The proposed solution is to stash the stack content to local
>>>> variables before "running" the switch expression, and fill the stack
>>>> content back when breaking out of the switch expression. This is done
>>>> only if the try-catch statement is present in the switch expression,
>>>> as it produces longer bytecode.
>>>>
>>>> Also, it turned out variables inside switch expressions in field
>>>> initializers don't work properly (as their owner is the field, not a
>>>> method), attempted to fix that as well.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8214114
>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8214114/webrev.00/
>>>>
>>>> How does this look?
>>>>
>>>> Thanks,
>>>> ??? Jan
>>>


From jan.lahoda at oracle.com  Fri Dec  7 13:47:47 2018
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 7 Dec 2018 14:47:47 +0100
Subject: RFR: JDK-8214114: Switch expressions with try-catch statements
In-Reply-To: <0b9b8d4c-b94a-6423-789e-cec51c6f5389@oracle.com>
References: <5C09538D.9090309@oracle.com>
 <ff1eeeac-abb2-31ba-3fa4-f59dd12bbb4a@oracle.com>
 <34bab17d-70aa-0849-ecdb-e0779975ecf4@oracle.com> <5C09AFBA.30302@oracle.com>
 <0b9b8d4c-b94a-6423-789e-cec51c6f5389@oracle.com>
Message-ID: <5C0A7A03.1010303@oracle.com>

On 7.12.2018 00:42, Maurizio Cimadamore wrote:
>
> On 06/12/2018 23:24, Jan Lahoda wrote:
>> On 6.12.2018 23:04, Maurizio Cimadamore wrote:
>>> While I don't think the stack should be as what Vicente says (after all,
>>> there's a Println object somewhere that should be tracked), I tend to
>>> agree with Vicente that there's something fishy here - I looked at the
>>> bug report and also run the example and the verifier crashes _before_
>>> entering the exception handler - it crashes on the 'new' when the
>>> exception is allocated. That doesn't seem to match what you said in the
>>> RFR. Now, as I pointed out in my other message, I believe some stashing
>>> is unavoidable as the VM will wipe out the stack, but it seems like
>>> there could be more issues piled up here?
>>
>> Sorry, I should have been more precise. What I meant is that the
>> StackMap for catch handler must not have anything on stack (except for
>> the Exception) (because VM will wipe the stack, that is, I think,
>> another angle to look at this). That is not related only to athrow -
>> the exception may be coming from a method invocation, for example. The
>> reason the verifier barks on "new" is, I think, because the
>> instruction may throw an exception as well. So it checks the StackMap
>> for the exception handler, and finds out there's something on the
>> stack (in the StackMap) that should not be there, and fails (or, from
>> another angle, when checking the exception handler, the verifier finds
>> out the handler expects something on the stack, besides the exception,
>> which can't be there).
>
> And sorry for the confusion - I realized I misread the verifier error -

I apologize to all - I should have been more precise/detailed in the 
original e-mail.

> it's actually pointing at the handler entry (as javac generated both
> [PrintStream, Exception], while the VM expects just [Exception] - it
> being an handler). So what you did is correct and I think just fixing
> the stackmap is not a real solution as then we need a way to recover the
> values before leaving the switch.

Yes, exactly.

Thanks,
     Jan

>
> Maurizio
>
>>
>> Jan
>>
>>>
>>> Maurizio
>>>
>>> On 06/12/2018 21:50, Vicente Romero wrote:
>>>> Hi Jan,
>>>>
>>>> Probably I'm missing something but shouldn't it be enough to generate
>>>> the right stackframe for the exception handler? Which in this case
>>>> should only contain:
>>>>
>>>> stack = [ class java/lang/Exception ]
>>>>
>>>> Thanks,
>>>> Vicente
>>>>
>>>> On 12/6/18 11:51 AM, Jan Lahoda wrote:
>>>>> Hi,
>>>>>
>>>>> Switch expressions that contain try-catch statements don't work
>>>>> currently, as the catch handlers require that the stack is empty when
>>>>> the handler is invoked, but this may not be true when the switch
>>>>> expression is inside an expression evaluation (and so some values are
>>>>> already on the stack).
>>>>>
>>>>> The proposed solution is to stash the stack content to local
>>>>> variables before "running" the switch expression, and fill the stack
>>>>> content back when breaking out of the switch expression. This is done
>>>>> only if the try-catch statement is present in the switch expression,
>>>>> as it produces longer bytecode.
>>>>>
>>>>> Also, it turned out variables inside switch expressions in field
>>>>> initializers don't work properly (as their owner is the field, not a
>>>>> method), attempted to fix that as well.
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8214114
>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8214114/webrev.00/
>>>>>
>>>>> How does this look?
>>>>>
>>>>> Thanks,
>>>>>     Jan
>>>>

From srinivas.dama at oracle.com  Fri Dec  7 14:27:05 2018
From: srinivas.dama at oracle.com (srinivas)
Date: Fri, 7 Dec 2018 19:57:05 +0530
Subject: RFR: 8208184 : IllegalArgumentException while invoking code
 completion on netbeans IDE
Message-ID: <385d6090-c94a-afe6-dc07-de39a240f28f@oracle.com>

Hi,

Please review,

Bug: https://bugs.openjdk.java.net/browse/JDK-8208184

webrev: http://cr.openjdk.java.net/~sdama/8208184/webrev.01/

Regards,

Srinivas


From cushon at google.com  Fri Dec  7 23:32:58 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 7 Dec 2018 15:32:58 -0800
Subject: spec clarification: type annotations on static nested types
In-Reply-To: <5BF46953.8060101@oracle.com>
References: <CAL4QsgtuZj7ynAguJoKGSZzabLMZZZQ6pumub1AJvJ2HrLe-gA@mail.gmail.com>
 <CAL4QsgviMKe0o4XM2fW8Qo8eZv_PCQ2WZQfsMpGXqKNYSBAZCg@mail.gmail.com>
 <5A53D7C6.1070809@oracle.com>
 <CAL4Qsgs6n4OrV-uUMJrRB-0xK48cMzHjoO3CQrYDY0AHQF+4Lg@mail.gmail.com>
 <CAL4QsgvsZ7=0j1E2twUYTfgv1+XxO6eH0nTnHxPShUHzFkHyRQ@mail.gmail.com>
 <CAL4Qsgve67jPcQZ9e8PJJpOZwu1vo4aR6k0B1g_BDXbMvKCWLg@mail.gmail.com>
 <5A8DF60F.7040002@oracle.com>
 <CAL4Qsgv9JA2rS9ywzaOVTwP8oQzvjx+oMbsgfr52yxSUBTmW5w@mail.gmail.com>
 <CAL4Qsgu0hCE27R3Tcn=U7KQg+ZehP7u2NiOm+NqrmO1+jHaHVA@mail.gmail.com>
 <5BF46953.8060101@oracle.com>
Message-ID: <CAL4QsguVjbRX4fXmq-9WfXUJZgSBcc24BScpXvz1UnY8ycRsDA@mail.gmail.com>

Thanks Alex,

I filed a specification/vm bug as suggested:
https://bugs.openjdk.java.net/browse/JDK-8215035

(I also fixed typos in JDK-8198526 with the static nested class example,
and a reference to the wrong type_path_kind. Let me know if I missed
anything.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181207/9c4d067d/attachment.html>

From jonathan.gibbons at oracle.com  Mon Dec 10 05:41:09 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sun, 9 Dec 2018 21:41:09 -0800
Subject: Changes to ct.sym in JDK 12
In-Reply-To: <BN6PR06MB321977B1BA73F07110A4A84887A50@BN6PR06MB3219.namprd06.prod.outlook.com>
References: <BN6PR06MB321977B1BA73F07110A4A84887A50@BN6PR06MB3219.namprd06.prod.outlook.com>
Message-ID: <a33265dc-4ffc-57fe-ff62-198c27433716@oracle.com>

Jay,

This is better discussed on compiler-dev.

It's about consistency, and better supporting the historical modular 
releases.

-- Jon

On 12/9/18 9:24 PM, Jayaprakash Artanareeswaran wrote:
> Hello experts,
>
>    I see that the ct.sym has been restructured in JDK 12. Specifically, I am curious about the fact that even for non modular releases such as 7 and 8, I see the classes being placed inside their respective modules.
>
> Is it just about consistency? Are the modules always ignored or is there a scenario where the modular structure will be useful?
>
> Sorry if this was discussed already, but I couldn't find much about this particular change.
>
> Regards,
> Jay

From alex.buckley at oracle.com  Mon Dec 10 22:56:51 2018
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 10 Dec 2018 14:56:51 -0800
Subject: spec clarification: type annotations on static nested types
In-Reply-To: <CAL4QsguVjbRX4fXmq-9WfXUJZgSBcc24BScpXvz1UnY8ycRsDA@mail.gmail.com>
References: <CAL4QsgtuZj7ynAguJoKGSZzabLMZZZQ6pumub1AJvJ2HrLe-gA@mail.gmail.com>
 <CAL4QsgviMKe0o4XM2fW8Qo8eZv_PCQ2WZQfsMpGXqKNYSBAZCg@mail.gmail.com>
 <5A53D7C6.1070809@oracle.com>
 <CAL4Qsgs6n4OrV-uUMJrRB-0xK48cMzHjoO3CQrYDY0AHQF+4Lg@mail.gmail.com>
 <CAL4QsgvsZ7=0j1E2twUYTfgv1+XxO6eH0nTnHxPShUHzFkHyRQ@mail.gmail.com>
 <CAL4Qsgve67jPcQZ9e8PJJpOZwu1vo4aR6k0B1g_BDXbMvKCWLg@mail.gmail.com>
 <5A8DF60F.7040002@oracle.com>
 <CAL4Qsgv9JA2rS9ywzaOVTwP8oQzvjx+oMbsgfr52yxSUBTmW5w@mail.gmail.com>
 <CAL4Qsgu0hCE27R3Tcn=U7KQg+ZehP7u2NiOm+NqrmO1+jHaHVA@mail.gmail.com>
 <5BF46953.8060101@oracle.com>
 <CAL4QsguVjbRX4fXmq-9WfXUJZgSBcc24BScpXvz1UnY8ycRsDA@mail.gmail.com>
Message-ID: <5C0EEF33.2030605@oracle.com>

On 12/7/2018 3:32 PM, Liam Miller-Cushon wrote:
> I filed a specification/vm bug as suggested:
> https://bugs.openjdk.java.net/browse/JDK-8215035

Thanks.

A small comment on this part: "If the value of path_length is 0, and the 
annotation appears on a nested type, the annotation applies to the 
outermost enclosing type for which a type annotation is admissible."

It's possible to read this and say, "The outermost enclosing type OF 
WHAT? Oh, it must mean the outermost enclosing type _of the nested type 
on which the annotation appears_. But I don't know the nested type on 
which the annotation appears -- that's what type_path is meant to tell me."

(See table 4.7.20.2-F proposed in JDK-8215035) That is, "nested type" 
can mean "the nested type Outer.MiddleStatic.Inner on which @A appears 
somewhere", as suggested by the formulation of "T1.T2" in the 
introduction; or it can mean "the nested type Inner or the nested type 
Inner2 or the nested type Inner3 which are all components of the nested 
type Outer.MiddleStatic.Inner.Inner2.Inner3", and if you do that, then 
path_length=0 could be referring non-deterministically to any of them in 
order to point to the outermost enclosing admissible location (i.e. 
MiddleStatic).

To avoid confusion, the rule should be: "If the value of path_length is 
0, and the type being annotated is a nested type, then the annotation 
applies to the outermost [DELETE]enclosing[/DELETE] part of the type for 
which a type annotation is admissible."  [I don't say "outermost 
component" because component is used in connection with array types.]

There's a certain "top-down" feel to this, which is unavoidable because 
a class file reader comes to type_path knowing the (say) parameter type 
which is being annotated, and wishing to know which part of the type has 
the annotation. 4.7.20.2 used to be like that -- "the top level type or 
any member type" -- but got itself turned around -- "the innermost 
member type and any enclosing ...".

Make sense?

> (I also fixed typos in JDK-8198526 with the static nested class example,
> and a reference to the wrong type_path_kind. Let me know if I missed
> anything.)

I made some small corrections, e.g. to avoid "enclosing instance type".

Alex

From cushon at google.com  Tue Dec 11 02:14:19 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 10 Dec 2018 18:14:19 -0800
Subject: spec clarification: type annotations on static nested types
In-Reply-To: <5C0EEF33.2030605@oracle.com>
References: <CAL4QsgtuZj7ynAguJoKGSZzabLMZZZQ6pumub1AJvJ2HrLe-gA@mail.gmail.com>
 <CAL4QsgviMKe0o4XM2fW8Qo8eZv_PCQ2WZQfsMpGXqKNYSBAZCg@mail.gmail.com>
 <5A53D7C6.1070809@oracle.com>
 <CAL4Qsgs6n4OrV-uUMJrRB-0xK48cMzHjoO3CQrYDY0AHQF+4Lg@mail.gmail.com>
 <CAL4QsgvsZ7=0j1E2twUYTfgv1+XxO6eH0nTnHxPShUHzFkHyRQ@mail.gmail.com>
 <CAL4Qsgve67jPcQZ9e8PJJpOZwu1vo4aR6k0B1g_BDXbMvKCWLg@mail.gmail.com>
 <5A8DF60F.7040002@oracle.com>
 <CAL4Qsgv9JA2rS9ywzaOVTwP8oQzvjx+oMbsgfr52yxSUBTmW5w@mail.gmail.com>
 <CAL4Qsgu0hCE27R3Tcn=U7KQg+ZehP7u2NiOm+NqrmO1+jHaHVA@mail.gmail.com>
 <5BF46953.8060101@oracle.com>
 <CAL4QsguVjbRX4fXmq-9WfXUJZgSBcc24BScpXvz1UnY8ycRsDA@mail.gmail.com>
 <5C0EEF33.2030605@oracle.com>
Message-ID: <CAL4QsgsU2BAjzirNK=iNEWm6abLdcU6k6fz0CARx8rV3cr0ZmA@mail.gmail.com>

On Mon, Dec 10, 2018 at 2:57 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> To avoid confusion, the rule should be: "If the value of path_length is
> 0, and the type being annotated is a nested type, then the annotation
> applies to the outermost [DELETE]enclosing[/DELETE] part of the type for
> which a type annotation is admissible."  [I don't say "outermost
> component" because component is used in connection with array types.]
>

Thanks, I updated the bug.

"the type being annotated is a nested type" is much better than "the
annotation
appears on a nested type".

Does "outermost part of a type" refer to the idea of enclosing/nested types
in general,
or just in this specific context since we're only talking about nested
types?
Put another way, is it meaningful to talk about the 'outermost part' of
arbitrary
types?


> There's a certain "top-down" feel to this, which is unavoidable because
> a class file reader comes to type_path knowing the (say) parameter type
> which is being annotated, and wishing to know which part of the type has
> the annotation. 4.7.20.2 used to be like that -- "the top level type or
> any member type" -- but got itself turned around -- "the innermost
> member type and any enclosing ...".
>

Class reading might have felt more natural if type_path=0 applied to the
innermost nested type, and type_path_kind=1 was a step *outwards* to
the enclosing type. But there are trade-offs there. It looks like there was
some discussion of this (framed as "inside-out v. outside-in") in the
2012-11
type-annotations-spec-experts archives.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181210/41190ce0/attachment.html>

From alex.buckley at oracle.com  Tue Dec 11 20:03:41 2018
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 11 Dec 2018 12:03:41 -0800
Subject: spec clarification: type annotations on static nested types
In-Reply-To: <CAL4QsgsU2BAjzirNK=iNEWm6abLdcU6k6fz0CARx8rV3cr0ZmA@mail.gmail.com>
References: <CAL4QsgtuZj7ynAguJoKGSZzabLMZZZQ6pumub1AJvJ2HrLe-gA@mail.gmail.com>
 <CAL4QsgviMKe0o4XM2fW8Qo8eZv_PCQ2WZQfsMpGXqKNYSBAZCg@mail.gmail.com>
 <5A53D7C6.1070809@oracle.com>
 <CAL4Qsgs6n4OrV-uUMJrRB-0xK48cMzHjoO3CQrYDY0AHQF+4Lg@mail.gmail.com>
 <CAL4QsgvsZ7=0j1E2twUYTfgv1+XxO6eH0nTnHxPShUHzFkHyRQ@mail.gmail.com>
 <CAL4Qsgve67jPcQZ9e8PJJpOZwu1vo4aR6k0B1g_BDXbMvKCWLg@mail.gmail.com>
 <5A8DF60F.7040002@oracle.com>
 <CAL4Qsgv9JA2rS9ywzaOVTwP8oQzvjx+oMbsgfr52yxSUBTmW5w@mail.gmail.com>
 <CAL4Qsgu0hCE27R3Tcn=U7KQg+ZehP7u2NiOm+NqrmO1+jHaHVA@mail.gmail.com>
 <5BF46953.8060101@oracle.com>
 <CAL4QsguVjbRX4fXmq-9WfXUJZgSBcc24BScpXvz1UnY8ycRsDA@mail.gmail.com>
 <5C0EEF33.2030605@oracle.com>
 <CAL4QsgsU2BAjzirNK=iNEWm6abLdcU6k6fz0CARx8rV3cr0ZmA@mail.gmail.com>
Message-ID: <5C10181D.6080806@oracle.com>

On 12/10/2018 6:14 PM, Liam Miller-Cushon wrote:
> On Mon, Dec 10, 2018 at 2:57 PM Alex Buckley <alex.buckley at oracle.com
> <mailto:alex.buckley at oracle.com>> wrote:
>
>     To avoid confusion, the rule should be: "If the value of path_length is
>     0, and the type being annotated is a nested type, then the annotation
>     applies to the outermost [DELETE]enclosing[/DELETE] part of the type
>     for which a type annotation is admissible."
...
>
> Does "outermost part of a type" refer to the idea of enclosing/nested
> types in general, or just in this specific context since we're only
> talking about nested types? Put another way, is it meaningful to talk
> about the 'outermost part' of arbitrary types?

Words based on "inner" and "outer" connect most strongly with nested 
types, where the containment relation is clear from the declaration 
site. Still, I can imagine that "outermost part" could be ascribed 
meaning for a array type or a parameterized type, where the containment 
exists but is driven by the use site. For example, given a use of the 
type T[][], the outermost type is T[][] and the innermost type is T; 
given a use of the type A<B<C>>, the outermost type is A<..> and the 
innermost type is C. This would specify the meaning of a non-zero 
path_length more firmly than "... each entry in the path array 
represents an iterative, left-to-right step towards the precise location 
of the annotation in an array type, nested type, or parameterized type". 
Is that the direction you were heading in?

Alex

From cushon at google.com  Tue Dec 11 22:28:48 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 11 Dec 2018 14:28:48 -0800
Subject: spec clarification: type annotations on static nested types
In-Reply-To: <5C10181D.6080806@oracle.com>
References: <CAL4QsgtuZj7ynAguJoKGSZzabLMZZZQ6pumub1AJvJ2HrLe-gA@mail.gmail.com>
 <CAL4QsgviMKe0o4XM2fW8Qo8eZv_PCQ2WZQfsMpGXqKNYSBAZCg@mail.gmail.com>
 <5A53D7C6.1070809@oracle.com>
 <CAL4Qsgs6n4OrV-uUMJrRB-0xK48cMzHjoO3CQrYDY0AHQF+4Lg@mail.gmail.com>
 <CAL4QsgvsZ7=0j1E2twUYTfgv1+XxO6eH0nTnHxPShUHzFkHyRQ@mail.gmail.com>
 <CAL4Qsgve67jPcQZ9e8PJJpOZwu1vo4aR6k0B1g_BDXbMvKCWLg@mail.gmail.com>
 <5A8DF60F.7040002@oracle.com>
 <CAL4Qsgv9JA2rS9ywzaOVTwP8oQzvjx+oMbsgfr52yxSUBTmW5w@mail.gmail.com>
 <CAL4Qsgu0hCE27R3Tcn=U7KQg+ZehP7u2NiOm+NqrmO1+jHaHVA@mail.gmail.com>
 <5BF46953.8060101@oracle.com>
 <CAL4QsguVjbRX4fXmq-9WfXUJZgSBcc24BScpXvz1UnY8ycRsDA@mail.gmail.com>
 <5C0EEF33.2030605@oracle.com>
 <CAL4QsgsU2BAjzirNK=iNEWm6abLdcU6k6fz0CARx8rV3cr0ZmA@mail.gmail.com>
 <5C10181D.6080806@oracle.com>
Message-ID: <CAL4QsguemPYdzY-S0-73fjf_ccE6twsgx+BeO0bOX1neoodE7w@mail.gmail.com>

On Tue, Dec 11, 2018 at 12:04 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> On 12/10/2018 6:14 PM, Liam Miller-Cushon wrote:
> > On Mon, Dec 10, 2018 at 2:57 PM Alex Buckley <alex.buckley at oracle.com
> > <mailto:alex.buckley at oracle.com>> wrote:
> >
> >     To avoid confusion, the rule should be: "If the value of path_length
> is
> >     0, and the type being annotated is a nested type, then the annotation
> >     applies to the outermost [DELETE]enclosing[/DELETE] part of the type
> >     for which a type annotation is admissible."
> ...
> >
> > Does "outermost part of a type" refer to the idea of enclosing/nested
> > types in general, or just in this specific context since we're only
> > talking about nested types? Put another way, is it meaningful to talk
> > about the 'outermost part' of arbitrary types?
>
> Words based on "inner" and "outer" connect most strongly with nested
> types, where the containment relation is clear from the declaration
> site. Still, I can imagine that "outermost part" could be ascribed
> meaning for a array type or a parameterized type, where the containment
> exists but is driven by the use site. For example, given a use of the
> type T[][], the outermost type is T[][] and the innermost type is T;
> given a use of the type A<B<C>>, the outermost type is A<..> and the
> innermost type is C. This would specify the meaning of a non-zero
> path_length more firmly than "... each entry in the path array
> represents an iterative, left-to-right step towards the precise location
> of the annotation in an array type, nested type, or parameterized type".
> Is that the direction you were heading in?
>

It was, it seemed like it might be a way to avoid special-casing nested
types:

"If the value of path_length is 0 then the annotation applies to the
outermost
part of the type for which a type annotation is admissible."

Regarding that "left-to-right step" part, I was struggling a bit with it
earlier.
Is left and right referring to the position in the type_path structure
itself,
or in the canonical string representation of the type, or perhaps in the
type descriptor?

Assuming an example like 4.7.20.2-C, we step in to the array type like so:

String *[]* [] []
       ^

String [] *[]* []
          ^

String [] [] *[]*
             ^

*String* [] [] []
^

Thinking of that as "left-to-right" seems confusing.

It works better applied to the type descriptor, but the rest of 4.7.20.2
talks about types more abstractly.

*[*[[Ljava/lang/String;
^

[*[*[Ljava/lang/String;
 ^

[[*[*Ljava/lang/String;
  ^

[[[*Ljava/lang/String;*
   ^

What do you think about trying to use the idea of containment more
extensively in 4.7.20.2?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181211/69826e87/attachment.html>

From alex.buckley at oracle.com  Tue Dec 11 22:41:19 2018
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 11 Dec 2018 14:41:19 -0800
Subject: spec clarification: type annotations on static nested types
In-Reply-To: <CAL4QsguemPYdzY-S0-73fjf_ccE6twsgx+BeO0bOX1neoodE7w@mail.gmail.com>
References: <CAL4QsgtuZj7ynAguJoKGSZzabLMZZZQ6pumub1AJvJ2HrLe-gA@mail.gmail.com>
 <CAL4QsgviMKe0o4XM2fW8Qo8eZv_PCQ2WZQfsMpGXqKNYSBAZCg@mail.gmail.com>
 <5A53D7C6.1070809@oracle.com>
 <CAL4Qsgs6n4OrV-uUMJrRB-0xK48cMzHjoO3CQrYDY0AHQF+4Lg@mail.gmail.com>
 <CAL4QsgvsZ7=0j1E2twUYTfgv1+XxO6eH0nTnHxPShUHzFkHyRQ@mail.gmail.com>
 <CAL4Qsgve67jPcQZ9e8PJJpOZwu1vo4aR6k0B1g_BDXbMvKCWLg@mail.gmail.com>
 <5A8DF60F.7040002@oracle.com>
 <CAL4Qsgv9JA2rS9ywzaOVTwP8oQzvjx+oMbsgfr52yxSUBTmW5w@mail.gmail.com>
 <CAL4Qsgu0hCE27R3Tcn=U7KQg+ZehP7u2NiOm+NqrmO1+jHaHVA@mail.gmail.com>
 <5BF46953.8060101@oracle.com>
 <CAL4QsguVjbRX4fXmq-9WfXUJZgSBcc24BScpXvz1UnY8ycRsDA@mail.gmail.com>
 <5C0EEF33.2030605@oracle.com>
 <CAL4QsgsU2BAjzirNK=iNEWm6abLdcU6k6fz0CARx8rV3cr0ZmA@mail.gmail.com>
 <5C10181D.6080806@oracle.com>
 <CAL4QsguemPYdzY-S0-73fjf_ccE6twsgx+BeO0bOX1neoodE7w@mail.gmail.com>
Message-ID: <5C103D0F.5020507@oracle.com>

On 12/11/2018 2:28 PM, Liam Miller-Cushon wrote:
> What do you think about trying to use the idea of containment more
> extensively in 4.7.20.2?

Everything you say makes sense. The example-driven tables were a 
best-effort spec given limited time and community interest in 2014. Feel 
free to file an RFE in specification/language that describes the 
type-walking motions in 4.7.20.2 more precisely.

Alex

From maurizio.cimadamore at oracle.com  Wed Dec 12 11:19:07 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 12 Dec 2018 11:19:07 +0000
Subject: Issue with Comparator.comparing
Message-ID: <4759fd3f-959e-ae39-8dad-d5a02a4bd3ba@oracle.com>

Hi,
this issue has been reported by Remi on amber-dev, on a discussion on 
enhanced enums [1]. As suspected, I have been able to reproduce (and 
simplify) the problem on a vanilla JDK - here's the test case:

import java.util.*;
import java.util.stream.*;
import java.util.function.*;

class Foo<T extends Comparable<T>> {

 ??? static Foo<String> S = new Foo<>("");
 ??? static Foo<Integer> I = new Foo<>(42);

 ??? private T t;

 ??? Foo(T t) {
 ??????? this.t = t;
 ??? }

 ??? T t() {
 ??????? return t;
 ??? }

 ??? public static void main(String[] args) {
 ??????? List<Foo<?>> l = new ArrayList<>();
 ??????? l.add(S);
 ??????? l.add(I);
 ??????? Comparator<? super Foo<?>> comp = Comparator.comparing(Foo::t); 
//<---- ???
 ??????? Collections.sort(l, comp);
 ??? }
}


This program compiles w/o warnings or errors, yet it fails at runtime 
with this:

Exception in thread "main" java.lang.ClassCastException: class 
java.lang.String cannot be cast to class java.lang.Integer 
(java.lang.String and java.lang.Integer are in module java.base of 
loader 'bootstrap')
 ??? at java.base/java.lang.Integer.compareTo(Integer.java:59)
 ??? at 
java.base/java.util.Comparator.lambda$comparing$77a9974f$1(Comparator.java:469)
 ??? at 
java.base/java.util.TimSort.countRunAndMakeAscending(TimSort.java:355)
 ??? at java.base/java.util.TimSort.sort(TimSort.java:220)
 ??? at java.base/java.util.Arrays.sort(Arrays.java:1516)
 ??? at java.base/java.util.ArrayList.sort(ArrayList.java:1749)
 ??? at java.base/java.util.Collections.sort(Collections.java:177)
 ??? at Foo.main(Test.java:25)


In other words, it seems like the type system is being tricked here into 
thinking that the comparator is working on an homogeneous type, while in 
reality there can be many types. I have a feeling that this is connected to:

https://bugs.openjdk.java.net/browse/JDK-8029307

(btw, the bug is marked as open, but the compiler dutifully applies the 
capture conversion described in the spec).

If I remove the capture conversion described in that issue, the compiler 
then will fail to compile the above example (as expected?):

error: incompatible types: inference variable U has incompatible bounds
 ??????? Comparator<? super Foo<?>> comp = Comparator.comparing(Foo::t); 
//<---- HERE
 ????????????????????????????????????????????????????????????? ^
 ??? lower bounds: Comparable<? super U>
 ??? lower bounds: ?
 ? where U,T are type-variables:
 ??? U extends Comparable<? super U> declared in method 
<T,U>comparing(Function<? super T,? extends U>)
 ??? T extends Object declared in method <T,U>comparing(Function<? super 
T,? extends U>)
1 error


To me, this looks related to this spec bug:

https://bugs.openjdk.java.net/browse/JDK-8170887

Dan, can you please confirm?

Thanks
Maurizio

[1] - 
http://mail.openjdk.java.net/pipermail/amber-dev/2018-December/003816.html


From bsrbnd at gmail.com  Wed Dec 12 14:55:13 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Wed, 12 Dec 2018 15:55:13 +0100
Subject: RFR JDK-8208470: Type annotations on inner type that is an array
 component
In-Reply-To: <CAEgw74BtYQAT0gupY7xbgbzroNsYnFbMX_OAXqNB+eYm-tK_1A@mail.gmail.com>
References: <CAEgw74DrgaXekYoj58dSJpfe2HnU1iD_V89b2gqKrUeviT4oVw@mail.gmail.com>
 <CAEgw74BtYQAT0gupY7xbgbzroNsYnFbMX_OAXqNB+eYm-tK_1A@mail.gmail.com>
Message-ID: <CAEgw74B5UO8n_ygDp_Z3U8ZmmZE8AUT9q8YqFO1V8Or0fHRZNQ@mail.gmail.com>

Hi,

During a private conversation, Werner noticed an interesting point
related to [4].

The following expression produces two raw type warnings:

@TA B @TA[] arr = new @TA B @TA [0];

Currently, none of them refers to @TA but with the suggested fix, only
the first one will.

So, I tried some other examples to see what's currently done in
similar situations:

$ cat Warning.java
import java.lang.annotation.*;

// See test warnings/6747671
class Warning {
    @Target(ElementType.TYPE_USE)
    @interface TA {}

    static class B<X> {}

    Warning. at TA B b1 = new Warning. at TA B();
    @TA B b2 = new @TA B();

    Warning. at TA B @TA[] a2 = new Warning. at TA B @TA [0];
    @TA B @TA[] a1 = new @TA B @TA [0];
}

Without fix:

$ javac -XDrawDiagnostics -Xlint:rawtypes Warning.java
Warning.java:10:13: compiler.warn.raw.class.use: @Warning.TA
Warning.B, Warning.B<X>
Warning.java:10:36: compiler.warn.raw.class.use: Warning.B, Warning.B<X>
Warning.java:11:9: compiler.warn.raw.class.use: @Warning.TA Warning.B,
Warning.B<X>
Warning.java:11:20: compiler.warn.raw.class.use: Warning.B, Warning.B<X>
Warning.java:13:13: compiler.warn.raw.class.use: @Warning.TA
Warning.B, Warning.B<X>
Warning.java:13:42: compiler.warn.raw.class.use: Warning.B, Warning.B<X>
Warning.java:14:9: compiler.warn.raw.class.use: Warning.B, Warning.B<X>
Warning.java:14:26: compiler.warn.raw.class.use: Warning.B, Warning.B<X>
8 warnings

With fix:

$ javac -XDrawDiagnostics -Xlint:rawtypes Warning.java
Warning.java:10:13: compiler.warn.raw.class.use: @Warning.TA
Warning.B, Warning.B<X>
Warning.java:10:36: compiler.warn.raw.class.use: Warning.B, Warning.B<X>
Warning.java:11:9: compiler.warn.raw.class.use: @Warning.TA Warning.B,
Warning.B<X>
Warning.java:11:20: compiler.warn.raw.class.use: Warning.B, Warning.B<X>
Warning.java:13:13: compiler.warn.raw.class.use: @Warning.TA
Warning.B, Warning.B<X>
Warning.java:13:42: compiler.warn.raw.class.use: Warning.B, Warning.B<X>
Warning.java:14:9: compiler.warn.raw.class.use: @Warning.TA Warning.B,
Warning.B<X>
Warning.java:14:26: compiler.warn.raw.class.use: Warning.B, Warning.B<X>
8 warnings

We see that the fix brings more warning consistency by adding one
missing @TA at line 14:9.

Now, the question of Werner to be addressed in a separate issue is why
isn't there any @TA on "new" expression warnings?

Any clarification about this would be very helpful.

Thanks,
Bernard


On Sat, 22 Sep 2018 at 18:59, B. Blaser <bsrbnd at gmail.com> wrote:
>
> Hi,
>
> I tried the initial example at processing and at runtime:
> [...]
> All seems to be fine with the fix:
> [...]
>
> Thoughts?
>
> Thanks,
> Bernard
>
> On Tue, 18 Sep 2018 at 15:41, B. Blaser <bsrbnd at gmail.com> wrote:
> >
> > Hi,
> >
> > Please review the following fix for [1]:
> >
> > http://cr.openjdk.java.net/~bsrbnd/jdk8208470/webrev.00/
> >
> > We've seen in thread [2] that [3] has probably caused the regression.
> > Among the variants we explored, Werner's one enhanced as discussed in
> > [2] seems quite good to me.
> > It has a small side-effect as the array element type would then carry
> > the annotation which is revealed by test [4], but I'm of Werner's
> > opinion that this would be correct.
> > I've made other attempts [5] to avoid this side-effect but I'm not
> > sure this is really the right approach.
> >
> > Any feedback is welcome (langtools:tier1 is OK),
> > Bernard
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8208470
> > [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012199.html
> > [3] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/62e285806e83#l6.440
> > [4] http://cr.openjdk.java.net/~bsrbnd/jdk8208470/webrev.00/test/langtools/tools/javac/warnings/6747671/T6747671.out.frames.html
> > [5] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012266.html

From cushon at google.com  Wed Dec 12 21:20:44 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 12 Dec 2018 13:20:44 -0800
Subject: spec clarification: type annotations on static nested types
In-Reply-To: <5C103D0F.5020507@oracle.com>
References: <CAL4QsgtuZj7ynAguJoKGSZzabLMZZZQ6pumub1AJvJ2HrLe-gA@mail.gmail.com>
 <CAL4QsgviMKe0o4XM2fW8Qo8eZv_PCQ2WZQfsMpGXqKNYSBAZCg@mail.gmail.com>
 <5A53D7C6.1070809@oracle.com>
 <CAL4Qsgs6n4OrV-uUMJrRB-0xK48cMzHjoO3CQrYDY0AHQF+4Lg@mail.gmail.com>
 <CAL4QsgvsZ7=0j1E2twUYTfgv1+XxO6eH0nTnHxPShUHzFkHyRQ@mail.gmail.com>
 <CAL4Qsgve67jPcQZ9e8PJJpOZwu1vo4aR6k0B1g_BDXbMvKCWLg@mail.gmail.com>
 <5A8DF60F.7040002@oracle.com>
 <CAL4Qsgv9JA2rS9ywzaOVTwP8oQzvjx+oMbsgfr52yxSUBTmW5w@mail.gmail.com>
 <CAL4Qsgu0hCE27R3Tcn=U7KQg+ZehP7u2NiOm+NqrmO1+jHaHVA@mail.gmail.com>
 <5BF46953.8060101@oracle.com>
 <CAL4QsguVjbRX4fXmq-9WfXUJZgSBcc24BScpXvz1UnY8ycRsDA@mail.gmail.com>
 <5C0EEF33.2030605@oracle.com>
 <CAL4QsgsU2BAjzirNK=iNEWm6abLdcU6k6fz0CARx8rV3cr0ZmA@mail.gmail.com>
 <5C10181D.6080806@oracle.com>
 <CAL4QsguemPYdzY-S0-73fjf_ccE6twsgx+BeO0bOX1neoodE7w@mail.gmail.com>
 <5C103D0F.5020507@oracle.com>
Message-ID: <CAL4Qsgu4WXrHxJL-9xXpeN=DmkSASsTjY9W0ySzWrdFZPkMtJQ@mail.gmail.com>

On Tue, Dec 11, 2018 at 2:42 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> Feel free to file an RFE in specification/language that describes the
> type-walking motions in 4.7.20.2 more precisely.
>

Thanks, I filed JDK-8215321
<https://bugs.openjdk.java.net/browse/JDK-8215321> to track that idea.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181212/df06edc3/attachment.html>

From bsrbnd at gmail.com  Wed Dec 12 23:44:27 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Thu, 13 Dec 2018 00:44:27 +0100
Subject: Issue with Comparator.comparing
In-Reply-To: <4759fd3f-959e-ae39-8dad-d5a02a4bd3ba@oracle.com>
References: <4759fd3f-959e-ae39-8dad-d5a02a4bd3ba@oracle.com>
Message-ID: <CAEgw74CXWW7LiA_mQEqOHv2iGydQ8SFAxC07uX3aeSE75KAbWg@mail.gmail.com>

Hi Maurizio,

On Wed, 12 Dec 2018 at 12:20, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
> [...]
> If I remove the capture conversion described in that issue, the compiler
> then will fail to compile the above example (as expected?):

Semantically, 'List<Foo<?>>' means potentially heterogeneous, not definitely.

The language cannot determine at compile time the type of the elements
present in the list and should accept any kind of potential comparator
of these elements which may or may not fail at runtime depending on
what's present in the list.

It's interesting to see that your example fails when invoking
'Integer::compareTo' but not when invoking 'Comparator::compare':

http://hg.openjdk.java.net/jdk/jdk/file/4bb6e0871bf7/src/java.base/share/classes/java/util/Comparator.java#l469

You could even have a comparator that successfully compares
heterogeneous elements.
So, at my mind, the current behavior inherent to potentially
heterogeneous collections is sound.

Bernard

From cushon at google.com  Thu Dec 13 01:05:27 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 12 Dec 2018 17:05:27 -0800
Subject: RFR JDK-8208470: Type annotations on inner type that is an array
 component
In-Reply-To: <CAEgw74B5UO8n_ygDp_Z3U8ZmmZE8AUT9q8YqFO1V8Or0fHRZNQ@mail.gmail.com>
References: <CAEgw74DrgaXekYoj58dSJpfe2HnU1iD_V89b2gqKrUeviT4oVw@mail.gmail.com>
 <CAEgw74BtYQAT0gupY7xbgbzroNsYnFbMX_OAXqNB+eYm-tK_1A@mail.gmail.com>
 <CAEgw74B5UO8n_ygDp_Z3U8ZmmZE8AUT9q8YqFO1V8Or0fHRZNQ@mail.gmail.com>
Message-ID: <CAL4Qsgsm+RmTe3QzXhdqS3QD0rkvW=FEhErYU2ZbMRkqP5siKw@mail.gmail.com>

Hi Bernard,

On Tue, Sep 18, 2018 at 6:42 AM B. Blaser <bsrbnd at gmail.com> wrote:

> Please review the following fix for [1]:
> http://cr.openjdk.java.net/~bsrbnd/jdk8208470/webrev.00/


I'm not a Reviewer, but this approach looks good to me overall.

A couple of minor notes:

There was some previous discussion (
http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012264.html)
about this part:

```
// Update positions
for (TypeCompound tc : annotations) {
    if (tc.position == null)
        tc.position = pos;
}
```

As far as I can tell it's redundant. Adding the following assertion to
`typeWithAnnotations` doesn't break any tests:

```
for (TypeCompound tc : annotations) {
    Assert.check(tc.position == pos);
}
```

... which matches the comment in the logic for nested types in
`typeWithAnnotations` that "all annotations share the same position; modify
the first one", and suggests that could be cleaned up too. (
http://hg.openjdk.java.net/jdk/jdk/file/2626982cf4f7/src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java#l525
)

```
-                    // All annotations share the same position; modify the
first one.
-                    Attribute.TypeCompound a = annotations.get(0);
-                    TypeAnnotationPosition p = a.position;
-                    p.location = p.location.appendList(depth.toList());
+                    pos.location = pos.location.appendList(depth.toList());
```

I'm wondering if maybe we can remove that part of `rewriteArrayType`?

nit: arrayTypeTree is inconsistent about asserting on unexpected types vs.
just performing casts (e.g. it would throw a CCE for a non-array
JCAnnotatedType tree). Unless that assertion is defending against something
specific, consider just:

```
private JCArrayTypeTree arrayTypeTree(JCTree typetree) {
  if (typetree.getKind() == JCTree.Kind.ANNOTATED_TYPE) {
    typetree = ((JCAnnotatedType) typetree).underlyingType;
  }
  return (JCArrayTypeTree) typetree;
}
```

On Wed, Dec 12, 2018 at 6:56 AM B. Blaser <bsrbnd at gmail.com> wrote:

> Now, the question of Werner to be addressed in a separate issue is why
> isn't there any @TA on "new" expression warnings?
>

I did some debugging, and it looks like the rawtypes diagnostic
pretty-prints the attributed type, and at that point the type annotations
in `B [] arr = new @TA B [0];` have been deferred and not yet added to the
type (see Annotate#flush).

I'm not sure what the principled fix is, but forcing the deferred
annotations to be processed before emitting the diagnostics (by adding in
an explicit call to `flush()`) makes the diagnostics consistently include
type annotation information. In my opinion the effect on diagnostic quality
is fairly minor, and fixing that inconsistency could safely be deferred.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181212/fce9b6f3/attachment.html>

From maurizio.cimadamore at oracle.com  Thu Dec 13 12:29:59 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 13 Dec 2018 12:29:59 +0000
Subject: Issue with Comparator.comparing
In-Reply-To: <CAEgw74CXWW7LiA_mQEqOHv2iGydQ8SFAxC07uX3aeSE75KAbWg@mail.gmail.com>
References: <4759fd3f-959e-ae39-8dad-d5a02a4bd3ba@oracle.com>
 <CAEgw74CXWW7LiA_mQEqOHv2iGydQ8SFAxC07uX3aeSE75KAbWg@mail.gmail.com>
Message-ID: <65f3704a-1f89-f974-c14a-63eadfe2015c@oracle.com>


On 12/12/2018 23:44, B. Blaser wrote:
> It's interesting to see that your example fails when invoking
> 'Integer::compareTo' but not when invoking 'Comparator::compare':

Actually, the failure happens in this line:

if (c.compare(a[runHi++], a[lo]) < 0) { // Descending

Where, c is a Comparator<? super T>, and the array to be sorted is a T[].

The comparator generated by Comparator.comparing is then failing 
because, if you look at how the method is implemented:

public static <T, U extends Comparable<? super U>> Comparator<T> comparing(
 ??????????? Function<? super T, ? extends U> keyExtractor)
 ??? {
 ??????? Objects.requireNonNull(keyExtractor);
 ??????? return (Comparator<T> & Serializable)
 ??????????? (c1, c2) -> 
keyExtractor.apply(c1).compareTo(keyExtractor.apply(c2));
 ??? }

It is clear that the method implementation relies on the assumption that 
keyExtractor returns homogeneous things.


But note that, even if the signature was made stricter, as in:

public static <T, U extends Comparable<U>> Comparator<T> comparing(
 ??????????? Function<? super T, ? extends U> keyExtractor) { ... }

The example I posted in my previous email would still compile - because 
U is inferred as a capture variable generated during method reference 
typing. In other words, the compiler *thinks* that the method reference 
Foo::t is really returning things that can be compareTo with each other, 
which is a flawed assumption!

Note that, what you say:

 > Semantically, 'List<Foo<?>>' means potentially heterogeneous, not 
definitely.

Is already an hint that something is going wrong - generic types are 
universally qualified things - whatever we prove for them must hold FOR 
ALL possible instantiation. Which seems clearly *not* to be the case 
here, as it's easy to think of examples where allowing the above list to 
be treated as an homogeneous comparable collection would lead to issues.


Concluding, I really believe that the capture conversion introduced by 
JDK-8029307, which was kind of a forced move (to type check a method 
reference you have to reason about membership, which implies capture of 
the receiver), is messing things up here, because, from a type system 
perspective, it makes it look as if all possible calls to the functional 
interface derived from that method reference is _always_ going to yield 
the _same_ captured type, where in reality different captures will be 
emitted. This is what made me think that this is indeed a type system 
issue, very close (if not the same) to the one described in JDK-8170887.

Maurizio



From bsrbnd at gmail.com  Thu Dec 13 13:52:06 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Thu, 13 Dec 2018 14:52:06 +0100
Subject: Issue with Comparator.comparing
In-Reply-To: <65f3704a-1f89-f974-c14a-63eadfe2015c@oracle.com>
References: <4759fd3f-959e-ae39-8dad-d5a02a4bd3ba@oracle.com>
 <CAEgw74CXWW7LiA_mQEqOHv2iGydQ8SFAxC07uX3aeSE75KAbWg@mail.gmail.com>
 <65f3704a-1f89-f974-c14a-63eadfe2015c@oracle.com>
Message-ID: <CAEgw74BkYEttSLAOGpTTkYTsU3bHuGzS-JeTtW_33O+FEQX_Ng@mail.gmail.com>

On Thu, 13 Dec 2018 at 13:30, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
> [...]
>
> Concluding, I really believe that the capture conversion introduced by
> JDK-8029307, which was kind of a forced move (to type check a method
> reference you have to reason about membership, which implies capture of
> the receiver), is messing things up here, because, from a type system
> perspective, it makes it look as if all possible calls to the functional
> interface derived from that method reference is _always_ going to yield
> the _same_ captured type, where in reality different captures will be
> emitted. This is what made me think that this is indeed a type system
> issue, very close (if not the same) to the one described in JDK-8170887.

At my mind, the problem is more within 'Comparator::comparing' which
assumes that the key extractor is the same for both elements
concluding that 'compareTo' should be applicable.
So, I think It might be more an API design concern than a type system
issue, but I understand your position.

Bernard

> Maurizio

From bsrbnd at gmail.com  Thu Dec 13 14:16:59 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Thu, 13 Dec 2018 15:16:59 +0100
Subject: RFR JDK-8208470: Type annotations on inner type that is an array
 component
In-Reply-To: <CAL4Qsgsm+RmTe3QzXhdqS3QD0rkvW=FEhErYU2ZbMRkqP5siKw@mail.gmail.com>
References: <CAEgw74DrgaXekYoj58dSJpfe2HnU1iD_V89b2gqKrUeviT4oVw@mail.gmail.com>
 <CAEgw74BtYQAT0gupY7xbgbzroNsYnFbMX_OAXqNB+eYm-tK_1A@mail.gmail.com>
 <CAEgw74B5UO8n_ygDp_Z3U8ZmmZE8AUT9q8YqFO1V8Or0fHRZNQ@mail.gmail.com>
 <CAL4Qsgsm+RmTe3QzXhdqS3QD0rkvW=FEhErYU2ZbMRkqP5siKw@mail.gmail.com>
Message-ID: <CAEgw74B1NksTx4GGuC0WgAwb5iVJMs3HoLDF0KKxTNDr0qyidg@mail.gmail.com>

Hi Liam,

On Thu, 13 Dec 2018 at 02:05, Liam Miller-Cushon <cushon at google.com> wrote:
>
> Hi Bernard,
>
> On Tue, Sep 18, 2018 at 6:42 AM B. Blaser <bsrbnd at gmail.com> wrote:
>>
>> Please review the following fix for [1]:
>> http://cr.openjdk.java.net/~bsrbnd/jdk8208470/webrev.00/
>
>
> I'm not a Reviewer, but this approach looks good to me overall.

Thanks for your feedback, I'll wait for a Reviewer approval before
integrating it.

> A couple of minor notes:
>
> There was some previous discussion (http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012264.html) about this part:
>
> ```
> // Update positions
> for (TypeCompound tc : annotations) {
>     if (tc.position == null)
>         tc.position = pos;
> }
> ```
>
> As far as I can tell it's redundant. Adding the following assertion to `typeWithAnnotations` doesn't break any tests:

Good, but this isn't a guarantee.
If we want to clean up this part, I suggest to address this in a separate issue?

> ```
> for (TypeCompound tc : annotations) {
>     Assert.check(tc.position == pos);
> }
> ```

And I think we should live with the assertion above for a while before
eventually dropping it...

> ... which matches the comment in the logic for nested types in `typeWithAnnotations` that "all annotations share the same position; modify the first one", and suggests that could be cleaned up too. (http://hg.openjdk.java.net/jdk/jdk/file/2626982cf4f7/src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java#l525)
>
> ```
> -                    // All annotations share the same position; modify the first one.
> -                    Attribute.TypeCompound a = annotations.get(0);
> -                    TypeAnnotationPosition p = a.position;
> -                    p.location = p.location.appendList(depth.toList());
> +                    pos.location = pos.location.appendList(depth.toList());
> ```

This cleanup seems harmless to me and I guess I like it, but maybe we
should address all of them in another issue?

> I'm wondering if maybe we can remove that part of `rewriteArrayType`?

I'd play defensively by deferring it as discussed above.

> nit: arrayTypeTree is inconsistent about asserting on unexpected types vs. just performing casts (e.g. it would throw a CCE for a non-array JCAnnotatedType tree). Unless that assertion is defending against something specific, consider just:
>
> ```
> private JCArrayTypeTree arrayTypeTree(JCTree typetree) {
>   if (typetree.getKind() == JCTree.Kind.ANNOTATED_TYPE) {
>     typetree = ((JCAnnotatedType) typetree).underlyingType;
>   }
>   return (JCArrayTypeTree) typetree;
> }
> ```

This method is reinstated from:

http://hg.openjdk.java.net/jdk9/dev/langtools/rev/62e285806e83#l6.515

I'm not its author, but I imagine that the assertion is only
protecting from malformed trees?

That said, I think I like your suggestion which doesn't seem too dangerous...
But if we are unsure, we could also live with the assertion for a
while and address this as part of the cleanup issue?

> On Wed, Dec 12, 2018 at 6:56 AM B. Blaser <bsrbnd at gmail.com> wrote:
>>
>> Now, the question of Werner to be addressed in a separate issue is why
>> isn't there any @TA on "new" expression warnings?
>
>
> I did some debugging, and it looks like the rawtypes diagnostic pretty-prints the attributed type, and at that point the type annotations in `B [] arr = new @TA B [0];` have been deferred and not yet added to the type (see Annotate#flush).

Great explanation, thanks for the debugging!

> I'm not sure what the principled fix is, but forcing the deferred annotations to be processed before emitting the diagnostics (by adding in an explicit call to `flush()`) makes the diagnostics consistently include type annotation information. In my opinion the effect on diagnostic quality is fairly minor, and fixing that inconsistency could safely be deferred.

I'm of your opinion. This is a minor cosmetic issue and the output is
consistent enough at my mind.

Thanks for your help,
Bernard

From wdietl at gmail.com  Thu Dec 13 17:47:38 2018
From: wdietl at gmail.com (Werner Dietl)
Date: Thu, 13 Dec 2018 12:47:38 -0500
Subject: spec clarification: type annotations on static nested types
In-Reply-To: <CAL4Qsgu4WXrHxJL-9xXpeN=DmkSASsTjY9W0ySzWrdFZPkMtJQ@mail.gmail.com>
References: <CAL4QsgtuZj7ynAguJoKGSZzabLMZZZQ6pumub1AJvJ2HrLe-gA@mail.gmail.com>
 <CAL4QsgviMKe0o4XM2fW8Qo8eZv_PCQ2WZQfsMpGXqKNYSBAZCg@mail.gmail.com>
 <5A53D7C6.1070809@oracle.com>
 <CAL4Qsgs6n4OrV-uUMJrRB-0xK48cMzHjoO3CQrYDY0AHQF+4Lg@mail.gmail.com>
 <CAL4QsgvsZ7=0j1E2twUYTfgv1+XxO6eH0nTnHxPShUHzFkHyRQ@mail.gmail.com>
 <CAL4Qsgve67jPcQZ9e8PJJpOZwu1vo4aR6k0B1g_BDXbMvKCWLg@mail.gmail.com>
 <5A8DF60F.7040002@oracle.com>
 <CAL4Qsgv9JA2rS9ywzaOVTwP8oQzvjx+oMbsgfr52yxSUBTmW5w@mail.gmail.com>
 <CAL4Qsgu0hCE27R3Tcn=U7KQg+ZehP7u2NiOm+NqrmO1+jHaHVA@mail.gmail.com>
 <5BF46953.8060101@oracle.com>
 <CAL4QsguVjbRX4fXmq-9WfXUJZgSBcc24BScpXvz1UnY8ycRsDA@mail.gmail.com>
 <5C0EEF33.2030605@oracle.com>
 <CAL4QsgsU2BAjzirNK=iNEWm6abLdcU6k6fz0CARx8rV3cr0ZmA@mail.gmail.com>
 <5C10181D.6080806@oracle.com>
 <CAL4QsguemPYdzY-S0-73fjf_ccE6twsgx+BeO0bOX1neoodE7w@mail.gmail.com>
 <5C103D0F.5020507@oracle.com>
 <CAL4Qsgu4WXrHxJL-9xXpeN=DmkSASsTjY9W0ySzWrdFZPkMtJQ@mail.gmail.com>
Message-ID: <CAJYRO=4_-EEqWefEKR+8EUmGv1Dw2xmjs8OpMKnU97R94y5RpA@mail.gmail.com>

Liam, Alex,

Thanks for all your work on this and sorry for staying out of it till now.
The changes to JVMS 4.7.20.2 as described in JDK-8215035 sound correct to
me and reflect the intention we had on the JLS side.
I also like the clarifications proposed in JDK-8215321.

Best,
cu, WMD.

On Dec 12, 2018 16:21, "Liam Miller-Cushon" <cushon at google.com> wrote:

On Tue, Dec 11, 2018 at 2:42 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> Feel free to file an RFE in specification/language that describes the
> type-walking motions in 4.7.20.2 more precisely.
>

Thanks, I filed JDK-8215321
<https://bugs.openjdk.java.net/browse/JDK-8215321> to track that idea.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181213/448bd8c0/attachment.html>

From cushon at google.com  Thu Dec 13 18:36:57 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 13 Dec 2018 10:36:57 -0800
Subject: RFR JDK-8208470: Type annotations on inner type that is an array
 component
In-Reply-To: <CAEgw74B1NksTx4GGuC0WgAwb5iVJMs3HoLDF0KKxTNDr0qyidg@mail.gmail.com>
References: <CAEgw74DrgaXekYoj58dSJpfe2HnU1iD_V89b2gqKrUeviT4oVw@mail.gmail.com>
 <CAEgw74BtYQAT0gupY7xbgbzroNsYnFbMX_OAXqNB+eYm-tK_1A@mail.gmail.com>
 <CAEgw74B5UO8n_ygDp_Z3U8ZmmZE8AUT9q8YqFO1V8Or0fHRZNQ@mail.gmail.com>
 <CAL4Qsgsm+RmTe3QzXhdqS3QD0rkvW=FEhErYU2ZbMRkqP5siKw@mail.gmail.com>
 <CAEgw74B1NksTx4GGuC0WgAwb5iVJMs3HoLDF0KKxTNDr0qyidg@mail.gmail.com>
Message-ID: <CAL4QsgvTUs3DQTdu3z5Yi=YGx5gwgvaCHOymzcG_SW-t7yZrFQ@mail.gmail.com>

On Thu, Dec 13, 2018 at 6:17 AM B. Blaser <bsrbnd at gmail.com> wrote:

> > As far as I can tell it's redundant. Adding the following assertion to
> `typeWithAnnotations` doesn't break any tests:
>
> Good, but this isn't a guarantee.
> If we want to clean up this part, I suggest to address this in a separate
> issue?
>

It might just be a signal that we need more test coverage here, but from
what I can tell the call sites to typeWithAnnotations all maintain that
invariant. There's some risk to changing the code, but leaving redundant
code in isn't necessarily safer if we don't understand why it's there and
it doesn't have test coverage.

I filed https://bugs.openjdk.java.net/browse/JDK-8215366 to look at that
part separately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181213/67f16333/attachment-0001.html>

From cushon at google.com  Thu Dec 13 18:37:06 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 13 Dec 2018 10:37:06 -0800
Subject: RFR: 8215366: Code quality improvements in
 com.sun.tools.javac.code.TypeAnnotations
Message-ID: <CAL4QsguQgq0-KXBZ9DoYBWn1QWf36jb+ewE-Pof6nRBvAp6-iw@mail.gmail.com>

Hi,

Please consider this small cleanup to TypeAnnotations, which was based on
discussion in the review thread for JDK-8208470. The change removes an
unused helper method, and makes the handling of type annotation position
information more consistent.

bug: https://bugs.openjdk.java.net/browse/JDK-8215366
webrev: http://cr.openjdk.java.net/~cushon/8215366/webrev.00/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181213/4f3e9b7e/attachment.html>

From cushon at google.com  Thu Dec 13 19:08:22 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 13 Dec 2018 11:08:22 -0800
Subject: RFR: 8215368: Make Check.checkOverride call diagnosticPositionFor
 lazily
Message-ID: <CAL4QsgsaJkRJ+4pNU2HqYvyfjRfhXz88aj_AVxV4ig_Mstaz-g@mail.gmail.com>

Hi,

Please consider this trivial performance fix to Check.checkOverride, which
achieved roughly a 2x speedup on a compilation of a pathological generated
source file.

bug: https://bugs.openjdk.java.net/browse/JDK-8215368
webrev: http://cr.openjdk.java.net/~cushon/8215368/webrev.00
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181213/7df6f638/attachment.html>

From bsrbnd at gmail.com  Thu Dec 13 20:29:09 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Thu, 13 Dec 2018 21:29:09 +0100
Subject: RFR: 8215366: Code quality improvements in
 com.sun.tools.javac.code.TypeAnnotations
In-Reply-To: <CAL4QsguQgq0-KXBZ9DoYBWn1QWf36jb+ewE-Pof6nRBvAp6-iw@mail.gmail.com>
References: <CAL4QsguQgq0-KXBZ9DoYBWn1QWf36jb+ewE-Pof6nRBvAp6-iw@mail.gmail.com>
Message-ID: <CAEgw74C_2+LDfAjA=wO_t2ab0mmY-_M8HSc-WVhJffMtAyZm7g@mail.gmail.com>

You'll still need a Reviewer approval but these changes seem good to
me, as discussed earlier, excepted that you'd need to update the
copyright year.

Thanks,
Bernard

On Thu, 13 Dec 2018 at 19:37, Liam Miller-Cushon <cushon at google.com> wrote:
>
> Hi,
>
> Please consider this small cleanup to TypeAnnotations, which was based on discussion in the review thread for JDK-8208470. The change removes an unused helper method, and makes the handling of type annotation position information more consistent.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8215366
> webrev: http://cr.openjdk.java.net/~cushon/8215366/webrev.00/

From orionllmain at gmail.com  Fri Dec 14 05:00:26 2018
From: orionllmain at gmail.com (Zheka Kozlov)
Date: Fri, 14 Dec 2018 12:00:26 +0700
Subject: Type inference bug
Message-ID: <CAF2POUfwKZfsZcxWVmFTvRmbKWxmHFdKHErxCPh+u9Wb0DEOcQ@mail.gmail.com>

javac fails to compile the following simple code:

import java.util.List;
import java.util.Set;
import java.util.function.IntFunction;

public class App {
    static <A> List<A> tabulate(int size, IntFunction<A> f) {
        throw new UnsupportedOperationException();
    }

    static <A extends Comparable<A>> Set<A> fromIterable(Iterable<A>
iterable) {
        throw new UnsupportedOperationException();
    }

    public static void main(String[] args) {
        Set<String> unique = fromIterable(tabulate(100_000, i -> "a"));
    }
}

Obviously, this is a correctly typed program, but javac fails with an error.

JDK 8:
App.java:15: error: method fromIterable in class App cannot be applied to
given types;
        Set<String> unique = fromIterable(tabulate(100_000, i -> "a"));
                             ^
  required: Iterable<A>
  found: List<Object>
  reason: inferred type does not conform to upper bound(s)
    inferred: Object
    upper bound(s): Comparable<Object>,Object
  where A is a type-variable:
    A extends Comparable<A> declared in method <A>fromIterable(Iterable<A>)
1 error

JDK 11:
App.java:15: error: method fromIterable in class App cannot be applied to
given types;
        Set<String> unique = fromIterable(tabulate(100_000, i -> "a"));
                             ^
  required: Iterable<A#1>
  found: List<Object>
  reason: inferred type does not conform to equality constraint(s)
    inferred: A#2
    equality constraints(s): A#3
  where A#1,A#2,A#3 are type-variables:
    A#1 extends Comparable<A#1> declared in method
<A#1>fromIterable(Iterable<A#1>)
    A#2 extends Comparable<A#3>
    A#3 extends Comparable<A#3>
1 error

IDEA and Eclipse do not report any compilation errors.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181214/97c2ca81/attachment.html>

From bsrbnd at gmail.com  Fri Dec 14 13:52:49 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Fri, 14 Dec 2018 14:52:49 +0100
Subject: Issue with Comparator.comparing
In-Reply-To: <CAEgw74BkYEttSLAOGpTTkYTsU3bHuGzS-JeTtW_33O+FEQX_Ng@mail.gmail.com>
References: <4759fd3f-959e-ae39-8dad-d5a02a4bd3ba@oracle.com>
 <CAEgw74CXWW7LiA_mQEqOHv2iGydQ8SFAxC07uX3aeSE75KAbWg@mail.gmail.com>
 <65f3704a-1f89-f974-c14a-63eadfe2015c@oracle.com>
 <CAEgw74BkYEttSLAOGpTTkYTsU3bHuGzS-JeTtW_33O+FEQX_Ng@mail.gmail.com>
Message-ID: <CAEgw74B2ig1_NfeiNZA2yJf+61d0wfvv=6Ak_kYdmkiGrrRRxA@mail.gmail.com>

On Thu, 13 Dec 2018 at 14:52, B. Blaser <bsrbnd at gmail.com> wrote:
>
> On Thu, 13 Dec 2018 at 13:30, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
> >
> > [...]
> >
> > Concluding, I really believe that the capture conversion introduced by
> > JDK-8029307, which was kind of a forced move (to type check a method
> > reference you have to reason about membership, which implies capture of
> > the receiver), is messing things up here, because, from a type system
> > perspective, it makes it look as if all possible calls to the functional
> > interface derived from that method reference is _always_ going to yield
> > the _same_ captured type, where in reality different captures will be
> > emitted. This is what made me think that this is indeed a type system
> > issue, very close (if not the same) to the one described in JDK-8170887.
>
> At my mind, the problem is more within 'Comparator::comparing' which
> assumes that the key extractor is the same for both elements
> concluding that 'compareTo' should be applicable.
> So, I think It might be more an API design concern than a type system
> issue, but I understand your position.

Explicitly, what I meant is that you'd have to provide a custom
'keyComparator' to sort an heterogeneous collection, as below.
Did I miss anything in your original example that would suggest a type
system issue rather than an API misuse?

Bernard

import java.util.*;
import java.util.stream.*;
import java.util.function.*;

class Foo2<T extends Comparable<T>> {
    static Foo2<String> S = new Foo2<>("");
    static Foo2<Integer> I = new Foo2<>(42);
    static Foo2<Integer> J = new Foo2<>(41);

    private T t;

    Foo2(T t) {
        this.t = t;
    }

    T t() {
        return t;
    }

    static int keyComp(Comparable<?> t1, Comparable<?> t2) {
        if (t1 instanceof Integer && t2 instanceof Integer)
            return (Integer)t1 - (Integer)t2;
        else
            return t1.getClass().hashCode() - t2.getClass().hashCode();
    }

     public static void main(String[] args) {
        List<Foo2<?>> l = new ArrayList<>();
        l.add(S);
        l.add(I);
        l.add(J);

        Comparator<Comparable<?>> kc = Foo2::keyComp;
        Comparator<? super Foo2<?>> comp = Comparator.comparing(Foo2::t, kc);
        Collections.sort(l, comp);

        for (Foo2<?> f: l)
            System.out.println(f.t);
    }
}

From maurizio.cimadamore at oracle.com  Fri Dec 14 15:28:27 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 14 Dec 2018 15:28:27 +0000
Subject: Issue with Comparator.comparing
In-Reply-To: <CAEgw74B2ig1_NfeiNZA2yJf+61d0wfvv=6Ak_kYdmkiGrrRRxA@mail.gmail.com>
References: <4759fd3f-959e-ae39-8dad-d5a02a4bd3ba@oracle.com>
 <CAEgw74CXWW7LiA_mQEqOHv2iGydQ8SFAxC07uX3aeSE75KAbWg@mail.gmail.com>
 <65f3704a-1f89-f974-c14a-63eadfe2015c@oracle.com>
 <CAEgw74BkYEttSLAOGpTTkYTsU3bHuGzS-JeTtW_33O+FEQX_Ng@mail.gmail.com>
 <CAEgw74B2ig1_NfeiNZA2yJf+61d0wfvv=6Ak_kYdmkiGrrRRxA@mail.gmail.com>
Message-ID: <398bd521-33a2-31b6-4d85-5d5d97f6264b@oracle.com>

I get that there are other ways to make the example working. But the API 
says:

"Accepts a function that extracts a |Comparable| 
<https://docs.oracle.com/javase/8/docs/api/java/lang/Comparable.html> 
sort key from a type |T|, and returns a |Comparator<T>| that compares by 
that sort key."

There's no other note in the API which hints at the fact that it might 
spectacularly fail because of heap pollution. And the fact that it is a 
synthetic cast that is failing, is strongly hinting at something at odds 
with the type-system.

Maurizio


On 14/12/2018 13:52, B. Blaser wrote:
> On Thu, 13 Dec 2018 at 14:52, B. Blaser <bsrbnd at gmail.com> wrote:
>> On Thu, 13 Dec 2018 at 13:30, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>>> [...]
>>>
>>> Concluding, I really believe that the capture conversion introduced by
>>> JDK-8029307, which was kind of a forced move (to type check a method
>>> reference you have to reason about membership, which implies capture of
>>> the receiver), is messing things up here, because, from a type system
>>> perspective, it makes it look as if all possible calls to the functional
>>> interface derived from that method reference is _always_ going to yield
>>> the _same_ captured type, where in reality different captures will be
>>> emitted. This is what made me think that this is indeed a type system
>>> issue, very close (if not the same) to the one described in JDK-8170887.
>> At my mind, the problem is more within 'Comparator::comparing' which
>> assumes that the key extractor is the same for both elements
>> concluding that 'compareTo' should be applicable.
>> So, I think It might be more an API design concern than a type system
>> issue, but I understand your position.
> Explicitly, what I meant is that you'd have to provide a custom
> 'keyComparator' to sort an heterogeneous collection, as below.
> Did I miss anything in your original example that would suggest a type
> system issue rather than an API misuse?
>
> Bernard
>
> import java.util.*;
> import java.util.stream.*;
> import java.util.function.*;
>
> class Foo2<T extends Comparable<T>> {
>      static Foo2<String> S = new Foo2<>("");
>      static Foo2<Integer> I = new Foo2<>(42);
>      static Foo2<Integer> J = new Foo2<>(41);
>
>      private T t;
>
>      Foo2(T t) {
>          this.t = t;
>      }
>
>      T t() {
>          return t;
>      }
>
>      static int keyComp(Comparable<?> t1, Comparable<?> t2) {
>          if (t1 instanceof Integer && t2 instanceof Integer)
>              return (Integer)t1 - (Integer)t2;
>          else
>              return t1.getClass().hashCode() - t2.getClass().hashCode();
>      }
>
>       public static void main(String[] args) {
>          List<Foo2<?>> l = new ArrayList<>();
>          l.add(S);
>          l.add(I);
>          l.add(J);
>
>          Comparator<Comparable<?>> kc = Foo2::keyComp;
>          Comparator<? super Foo2<?>> comp = Comparator.comparing(Foo2::t, kc);
>          Collections.sort(l, comp);
>
>          for (Foo2<?> f: l)
>              System.out.println(f.t);
>      }
> }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181214/46e89f32/attachment.html>

From cushon at google.com  Fri Dec 14 17:31:52 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 14 Dec 2018 09:31:52 -0800
Subject: RFR: 8215371: Better nodes for concatenated string literals
Message-ID: <CAL4QsgvD85XSyKpyL0vFzCRvpDcAcqwiz_V3pDY8XLFfsH=wjw@mail.gmail.com>

Hi,

I've been thinking a bit about the discussion of string literals
in JDK-8182769, and I started a separate bug for that part:
https://bugs.openjdk.java.net/browse/JDK-8215371

The issue is that long string concatenation chains are represented as
unbalanced binary expression trees, and it's easy to run out of stack when
processing those trees recursively. As a work-around, javac currently
supports folding concatenated string literals during parsing, but that
work-around reduces the fidelity of the AST and is problematic for IDE-like
tooling.

A possible fix is to remove the early constant folding, and instead balance
the binary trees for concatentation:
http://cr.openjdk.java.net/~cushon/8215371/webrev.00/

There's some discussion of the tradeoffs in the comments on JDK-8182769.
Other ideas include:

* Refactoring code processing string literals to avoid recursion. This
removes the constraint on the shape on the AST, but might reduce
readability. The problem also affects non-javac users of the com.sun.source
APIs which we don't have the option of refactoring.

* Introducing a new AST node to represent concatenated string literals as a
flat list. This would require more refactoring to javac, and an addition to
the com.sun.source APIs.

What do you think? My prototype fix is kind of a work-around, but I think
it's a modest improvement over the status quo. If there are ideas of a more
principled solution I'm happy to investigate alternatives.

Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181214/6d3706b8/attachment.html>

From brian.goetz at oracle.com  Fri Dec 14 18:47:16 2018
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 14 Dec 2018 13:47:16 -0500
Subject: RFR: 8215371: Better nodes for concatenated string literals
In-Reply-To: <CAL4QsgvD85XSyKpyL0vFzCRvpDcAcqwiz_V3pDY8XLFfsH=wjw@mail.gmail.com>
References: <CAL4QsgvD85XSyKpyL0vFzCRvpDcAcqwiz_V3pDY8XLFfsH=wjw@mail.gmail.com>
Message-ID: <82f857af-d62f-5e39-a55d-7944d6d9037a@oracle.com>

It sounds like you're suggesting a multi-string-concat node, which would 
greedily parse a sequence of strings to be concatenated, and put a list 
of string-valued nodes into it, so that if we had:

 ??? "foo" + "bar " + i + " baz"

we'd have

 ??? StringConcatNode[ Literal["foo"],
 ????????????????????? Literal["bar "],
 ????????????????????? Apply(Integer.toString, Var[i]),
 ????????????????????? Literal(" baz")]

and then do the folding later?

Given that we're adding more sophisticated constant folding to the 
compiler in a separate pass, there's an obvious place to do such folding 
(and ideally, one such place.? Then, most of the time, gen just hands 
the contents of this node to indy.)? That seems a more honest solution 
than trying to balance the tree (especially as some of the concat nodes 
might have side-effects, such as ++x, and we'd have to be careful to 
manage the order of side effects.)

Or, wait for multi-line string literals, and its less of a problem...

On 12/14/2018 12:31 PM, Liam Miller-Cushon wrote:
> Hi,
>
> I've been thinking a bit about the discussion of string literals 
> in?JDK-8182769, and I started a separate bug for that part: 
> https://bugs.openjdk.java.net/browse/JDK-8215371
>
> The issue is that long string concatenation chains are represented as 
> unbalanced binary expression trees, and it's easy to run out of stack 
> when processing those trees recursively. As a work-around, javac 
> currently supports folding concatenated string literals during 
> parsing, but that work-around reduces the fidelity of the AST and is 
> problematic for IDE-like tooling.
>
> A possible fix is to remove the early constant folding, and instead 
> balance the binary trees for concatentation: 
> http://cr.openjdk.java.net/~cushon/8215371/webrev.00/
>
> There's some discussion of the tradeoffs in the comments 
> on?JDK-8182769. Other ideas include:
>
> * Refactoring code processing string literals to avoid recursion. This 
> removes the constraint on the shape on the AST, but might reduce 
> readability. The problem also affects non-javac users of the 
> com.sun.source APIs which we don't have the option of refactoring.
>
> * Introducing a new AST node to represent concatenated string literals 
> as a flat list. This would require more refactoring to javac, and an 
> addition to the com.sun.source APIs.
>
> What do you think? My prototype fix is kind of a work-around, but I 
> think it's a modest improvement over the status quo. If there are 
> ideas of a more principled solution I'm happy to investigate alternatives.
>
> Thanks,


From cushon at google.com  Fri Dec 14 19:39:21 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 14 Dec 2018 11:39:21 -0800
Subject: RFR: 8215371: Better nodes for concatenated string literals
In-Reply-To: <82f857af-d62f-5e39-a55d-7944d6d9037a@oracle.com>
References: <CAL4QsgvD85XSyKpyL0vFzCRvpDcAcqwiz_V3pDY8XLFfsH=wjw@mail.gmail.com>
 <82f857af-d62f-5e39-a55d-7944d6d9037a@oracle.com>
Message-ID: <CAL4QsgsNEjdL7_ZAPD8ViW+4EovW_RJN1T40TGmFmkADPhbVxA@mail.gmail.com>

On Fri, Dec 14, 2018 at 10:47 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> It sounds like you're suggesting a multi-string-concat node, which would
> greedily parse a sequence of strings to be concatenated, and put a list
> of string-valued nodes into it, so that if we had:
>
>      "foo" + "bar " + i + " baz"
>
> we'd have
>
>      StringConcatNode[ Literal["foo"],
>                        Literal["bar "],
>                        Apply(Integer.toString, Var[i]),
>                        Literal(" baz")]
>

Yes, exactly.

The parser would see it as something like `StringConcatNode[
Literal["foo"], Literal["bar "], Ident["i"], Literal[" baz"]]`.


> and then do the folding later?
>

The general constant folding infrastructure already takes care of any
strings that aren't folded eagerly by the parser.
The folding in the parser can be disabled with -XDallowStringFolding, so we
don't rely on it for behaviour.

That seems a more honest solution than trying to balance the tree


Agreed! I wanted to get a sense of whether there was interest in that
approach before before pursuing it.


> (especially as some of the concat nodes might have side-effects,

such as ++x, and we'd have to be careful to manage the order of

side effects.)
>

I think order of side effects would be preserved: the operands need to be
evaluated in pre-order
traversal order, and balancing the string concat nodes wouldn't change
that, right?


> Or, wait for multi-line string literals, and its less of a problem...
>

True, but it'll take some time before it's a ubiquitous solution to this
problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181214/e881cc04/attachment.html>

From john.r.rose at oracle.com  Fri Dec 14 21:24:50 2018
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 14 Dec 2018 13:24:50 -0800
Subject: RFR: 8215371: Better nodes for concatenated string literals
In-Reply-To: <CAL4QsgvD85XSyKpyL0vFzCRvpDcAcqwiz_V3pDY8XLFfsH=wjw@mail.gmail.com>
References: <CAL4QsgvD85XSyKpyL0vFzCRvpDcAcqwiz_V3pDY8XLFfsH=wjw@mail.gmail.com>
Message-ID: <F27C919D-2B3D-4674-A952-D44BAAD2C757@oracle.com>

On Dec 14, 2018, at 9:31 AM, Liam Miller-Cushon <cushon at google.com> wrote:
> 
> What do you think? My prototype fix is kind of a work-around, but I think it's a modest improvement over the status quo. If there are ideas of a more principled solution I'm happy to investigate alternatives.

Slightly more principled solution (along one axis):  Treat string concat
as a similar form to existing signature-polymorphic methods invokeExact,
etc.  That treats it as a method call (rather than special control flow or
block structure), so common method-call code would apply.

Then at code generation time transform the sig-poly call down to indy
or open-coded StringBuilder stuff or whatever else the user has requested.

The advantage of sig-poly calls is that they don't try to dictate argument
types; they accept actual arguments as-is.  This is what you want to
preserve if you are going to try to hold a high-level form of AST and
defer lowering to indy or SBs to a later phase.

One disadvantage of sig-poly calls:  They are not defined for
more than 255 arguments, whereas varargs allow up to 2^31-1
arguments.  This could be handled by having the new "principled"
form of sig-poly invocation AST to *optionally* limit the number of
arguments (argument slots, TBE) to 255.

One reason I suggest this is that I think there are more uses likely
in the future for signature-polymorphic APIs and/or APIs which lower
late (after constant folding).  I don't think string append is unique,
at all, in this respect.  So if you want to think about a more general
AST pattern for loosely typed (TBE use-site typed) method calls,
where the methods might be intrinsics of some sort, and where the
arity limit is not just 255, and you want to preserve usual evaluation
order (i.e., not && or ?: or __Let), then late-bound method calls are
the natural semantics to reach for.  In that case, the sig-poly is a
good first cut.

Another consideration:  I aspire to, some day, change the translation
strategy for varargs and auto-boxing call sites to translate into relaxed
typed, signature polymorphic style, to avoid emitting bytecodes for
converting and boxing arguments and argument lists.  The point of
that is to defer conversion to the runtime, making the call site easier
to parse and hence optimize and/or raise to expression.  The JVM
would create adapter logic at link time (per call site) to manage the
difference between the use-site and def-site of the resolved method.
No language-level semantics need change; it's a translation strategy.
Could be prototyped today with indy (and I think Remi Forax has).

Another consideration:  Some day we might have better varargs
based on value types, which do not commit so many extra boxes
to the heap.  Again, a sig-poly static translation strategy with runtime
adapter generation will make it easier to engineer such a thing,
and even evolve it without recompilation.

HTH
? John


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181214/5e950cf2/attachment.html>

From alex.buckley at oracle.com  Fri Dec 14 21:41:47 2018
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 14 Dec 2018 13:41:47 -0800
Subject: RFR: 8215371: Better nodes for concatenated string literals
In-Reply-To: <F27C919D-2B3D-4674-A952-D44BAAD2C757@oracle.com>
References: <CAL4QsgvD85XSyKpyL0vFzCRvpDcAcqwiz_V3pDY8XLFfsH=wjw@mail.gmail.com>
 <F27C919D-2B3D-4674-A952-D44BAAD2C757@oracle.com>
Message-ID: <5C14239B.2000500@oracle.com>

On 12/14/2018 1:24 PM, John Rose wrote:
> Slightly more principled solution (along one axis):  Treat string concat
> as a similar form to existing signature-polymorphic methods invokeExact,
> etc.  That treats it as a method call (rather than special control flow or
> block structure), so common method-call code would apply.
>
> Then at code generation time transform the sig-poly call down to indy
> or open-coded StringBuilder stuff or whatever else the user has requested.
>
> The advantage of sig-poly calls is that they don't try to dictate argument
> types; they accept actual arguments as-is.  This is what you want to
> preserve if you are going to try to hold a high-level form of AST and
> defer lowering to indy or SBs to a later phase.

FYI John is referring to the treatment of sig-poly methods here:

https://docs.oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.12.3-400

(Contrast "The compile-time parameter types are the types of the formal 
parameters of the compile-time declaration." with "The compile-time 
parameter types are the types of the actual argument expressions."  The 
compile-time parameter types, amongst other things, flow into the 
symbolic reference to a method that must be put in the class file, per 
13.1.)

Alex

From Alan.Bateman at oracle.com  Sat Dec 15 09:40:45 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 15 Dec 2018 09:40:45 +0000
Subject: 8215449: Several tests failing when jtreg run with
 -vmoption:--illegal-access=deny
Message-ID: <b2736372-9a92-7149-d73d-3f4bc49c6dd6@oracle.com>

This is test only change to fix a few tests that don't have complete 
@modules or --add-exports options and so fail when running jtreg with 
vmoption:--illegal-access=deny.

The only change that might not be obvious is to 
langtools/tools/javac/platform/CanHandleClassFilesTest.java. That test 
creates a custom class loader to load the CreateSymbols tool from the 
make tree. jtreg doesn't know how to export packages to the unnamed 
module of custom class loaders so the test is changed to open the 
packages to the test and then pass on the rights to the unnamed module 
of the custom class loader.

http://cr.openjdk.java.net/~alanb/8215449/webrev/index.html

-Alan

From eolivelli at gmail.com  Sat Dec 15 09:53:58 2018
From: eolivelli at gmail.com (Enrico Olivelli)
Date: Sat, 15 Dec 2018 10:53:58 +0100
Subject: 8215449: Several tests failing when jtreg run with
 -vmoption:--illegal-access=deny
In-Reply-To: <b2736372-9a92-7149-d73d-3f4bc49c6dd6@oracle.com>
References: <b2736372-9a92-7149-d73d-3f4bc49c6dd6@oracle.com>
Message-ID: <CACcefgdXb0t7=Bd31-TfDdYfOQXjUTd__2vL9ghsWnaaReLB8w@mail.gmail.com>

Hi Alan,
A little off-topic: Is there any plan to move to 'deny' by default in Java
12 ?

Enrico

Il sab 15 dic 2018, 10:41 Alan Bateman <Alan.Bateman at oracle.com> ha scritto:

> This is test only change to fix a few tests that don't have complete
> @modules or --add-exports options and so fail when running jtreg with
> vmoption:--illegal-access=deny.
>
> The only change that might not be obvious is to
> langtools/tools/javac/platform/CanHandleClassFilesTest.java. That test
> creates a custom class loader to load the CreateSymbols tool from the
> make tree. jtreg doesn't know how to export packages to the unnamed
> module of custom class loaders so the test is changed to open the
> packages to the test and then pass on the rights to the unnamed module
> of the custom class loader.
>
> http://cr.openjdk.java.net/~alanb/8215449/webrev/index.html
>
> -Alan
>
-- 


-- Enrico Olivelli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181215/4c5a3295/attachment-0001.html>

From claes.redestad at oracle.com  Sat Dec 15 14:58:43 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 15 Dec 2018 15:58:43 +0100
Subject: 8215449: Several tests failing when jtreg run with
 -vmoption:--illegal-access=deny
In-Reply-To: <b2736372-9a92-7149-d73d-3f4bc49c6dd6@oracle.com>
References: <b2736372-9a92-7149-d73d-3f4bc49c6dd6@oracle.com>
Message-ID: <ae17d437-6ee8-5e6a-d0c4-172565ca185f@oracle.com>

Hi Alan,

On 2018-12-15 10:40, Alan Bateman wrote:
> This is test only change to fix a few tests that don't have complete 
> @modules or --add-exports options and so fail when running jtreg with 
> vmoption:--illegal-access=deny.
> 
> The only change that might not be obvious is to 
> langtools/tools/javac/platform/CanHandleClassFilesTest.java. That test 
> creates a custom class loader to load the CreateSymbols tool from the 
> make tree. jtreg doesn't know how to export packages to the unnamed 
> module of custom class loaders so the test is changed to open the 
> packages to the test and then pass on the rights to the unnamed module 
> of the custom class loader.
> 
> http://cr.openjdk.java.net/~alanb/8215449/webrev/index.html

looks ok to me.

/Claes

From Alan.Bateman at oracle.com  Sat Dec 15 16:12:24 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 15 Dec 2018 16:12:24 +0000
Subject: 8215449: Several tests failing when jtreg run with
 -vmoption:--illegal-access=deny
In-Reply-To: <CACcefgdXb0t7=Bd31-TfDdYfOQXjUTd__2vL9ghsWnaaReLB8w@mail.gmail.com>
References: <b2736372-9a92-7149-d73d-3f4bc49c6dd6@oracle.com>
 <CACcefgdXb0t7=Bd31-TfDdYfOQXjUTd__2vL9ghsWnaaReLB8w@mail.gmail.com>
Message-ID: <72cb9e84-8a5b-9148-e645-87a931a16de5@oracle.com>

On 15/12/2018 09:53, Enrico Olivelli wrote:
> Hi Alan,
> A little off-topic: Is there any plan to move to 'deny' by default in 
> Java 12 ?
>
Not for JDK 12 as that release is in Rampdown Phase One.

-Alan

From eolivelli at gmail.com  Sat Dec 15 16:51:10 2018
From: eolivelli at gmail.com (Enrico Olivelli)
Date: Sat, 15 Dec 2018 17:51:10 +0100
Subject: 8215449: Several tests failing when jtreg run with
 -vmoption:--illegal-access=deny
In-Reply-To: <72cb9e84-8a5b-9148-e645-87a931a16de5@oracle.com>
References: <b2736372-9a92-7149-d73d-3f4bc49c6dd6@oracle.com>
 <CACcefgdXb0t7=Bd31-TfDdYfOQXjUTd__2vL9ghsWnaaReLB8w@mail.gmail.com>
 <72cb9e84-8a5b-9148-e645-87a931a16de5@oracle.com>
Message-ID: <CACcefgd9h8LsrEX+k09ubecEy_UqXBr6Pmjo1NZfDcd18K5WKQ@mail.gmail.com>

Il sab 15 dic 2018, 17:12 Alan Bateman <Alan.Bateman at oracle.com> ha scritto:

> On 15/12/2018 09:53, Enrico Olivelli wrote:
> > Hi Alan,
> > A little off-topic: Is there any plan to move to 'deny' by default in
> > Java 12 ?
> >
> Not for JDK 12 as that release is in Rampdown Phase One.
>


Thanks
Enrico

>
> -Alan
>
-- 


-- Enrico Olivelli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181215/dc466524/attachment.html>

From maurizio.cimadamore at oracle.com  Sat Dec 15 22:02:35 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Sat, 15 Dec 2018 22:02:35 +0000
Subject: RFR: 8215371: Better nodes for concatenated string literals
In-Reply-To: <CAL4QsgvD85XSyKpyL0vFzCRvpDcAcqwiz_V3pDY8XLFfsH=wjw@mail.gmail.com>
References: <CAL4QsgvD85XSyKpyL0vFzCRvpDcAcqwiz_V3pDY8XLFfsH=wjw@mail.gmail.com>
Message-ID: <c629604c-f0b0-4c6b-4d59-0e96e79009d0@oracle.com>

Hi Liam,
form an hgh level perspective, having a better tree representation for 
string concat has always looked like the natural place where the impl 
should go. Far too much time has been spent micro-optimizing the 
existing code, trying to come up with clever ways to avoid creation of 
deeply recursive trees - optimizations which work... until they don't. 
For instance, javac is not very good at removing recursion when you mix 
constants and variables, and so there are way to end up in a badly 
stack-heavy scenario.

Then there's the problem of IDEs, which do not like much javac messing 
up with the source representation (which is why we do have flags to 
avoid the eager folding, which is, I believe, used by Netbeans).

So, I think I'd be interested to see what an approach using a different 
tree would look like; but at the same time I don't think it will be easy.

One possible complication in flattening the tree representation is that 
string concat is, right now, pretty much handled by the logic which 
handles all other binary operators (see Attr::visitBinary/Operators); 
all that type-checking code is made to work on a pair of operands at a 
time, and it might be tricky to refactor it so that it works on n-ary 
inputs - and I think this will force you to remove string concat from 
the list of operators - which then would probably result in asymmetries 
with the += string concat assign operator.

Another (perhaps bigger) question mark is whether the parser has enough 
info to classify the expression as a string concat: if you see the 
expression:

a + b + 12

How can you tell (at parse time) whether is a string concat or not? It 
depends on the types of 'a' and 'b' - so there's a resolution process in 
the middle (not unlike what happens with method resolution). So I'm not 
sure we can pull this off (unless you rewrite the AST later in the 
pipeline, but that would defeat some of the purpose?) - it seems that, 
if you pull the string long enough, you end up in a place where perhaps 
you need to flatten _all_ the binary expression trees, which, while 
doable, starts looking as a much much bigger patch.

Then there's the problem of evolving the c.s.s.tree API - can we switch 
to a different, non-recursive internal representation w/o touching the 
API (or providing some sensible behavior for existing methods?). Maybe, 
but that will also require work.

Unless we are convinced that we have sound solutions for all these 
issues, I think it might be better to stick with your more pragmatic 
balancing fix in the meantime (although I'd love to aim for something 
more principled, of course).

Maurizio

On 14/12/2018 17:31, Liam Miller-Cushon wrote:
> Hi,
>
> I've been thinking a bit about the discussion of string literals 
> in?JDK-8182769, and I started a separate bug for that part: 
> https://bugs.openjdk.java.net/browse/JDK-8215371
>
> The issue is that long string concatenation chains are represented as 
> unbalanced binary expression trees, and it's easy to run out of stack 
> when processing those trees recursively. As a work-around, javac 
> currently supports folding concatenated string literals during 
> parsing, but that work-around reduces the fidelity of the AST and is 
> problematic for IDE-like tooling.
>
> A possible fix is to remove the early constant folding, and instead 
> balance the binary trees for concatentation: 
> http://cr.openjdk.java.net/~cushon/8215371/webrev.00/
>
> There's some discussion of the tradeoffs in the comments 
> on?JDK-8182769. Other ideas include:
>
> * Refactoring code processing string literals to avoid recursion. This 
> removes the constraint on the shape on the AST, but might reduce 
> readability. The problem also affects non-javac users of the 
> com.sun.source APIs which we don't have the option of refactoring.
>
> * Introducing a new AST node to represent concatenated string literals 
> as a flat list. This would require more refactoring to javac, and an 
> addition to the com.sun.source APIs.
>
> What do you think? My prototype fix is kind of a work-around, but I 
> think it's a modest improvement over the status quo. If there are 
> ideas of a more principled solution I'm happy to investigate alternatives.
>
> Thanks,

From gunnar at hibernate.org  Sun Dec 16 10:04:17 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sun, 16 Dec 2018 11:04:17 +0100
Subject: How to pass compiler options when running a single-file source-code
 Java program?
Message-ID: <CADGJaX8zxO6Hn0f+qG2nfTc-Kdex3gmGkvYkHFzVUw+HMgjjBA@mail.gmail.com>

Hi,

I'd like to use JEP 330 [1] to run a single-file source-code program
with Java (>= 11).

Doing so, I'd like to pass options understood by javac but not by the
runtime (java), e.g. -XDsuppressNotes. But this causes e.g. the
following invocation to fail:

    java --enable-preview --source=12 -XDsuppressNotes Test.java

    Unrecognized option: -XDsuppressNotes
    Error: Could not create the Java Virtual Machine.
    Error: A fatal exception has occurred. Program will exit.

There's this related sentence in the JEP:

> The source-launcher implementation class has access to any relevant
> command-line options, such as those to define the class path, module path,
> and the module graph, and passes those options to the compiler to configure
> the compilation environment.

So I'd expect an option such as -XDsuppressNotes to be propagated, but
it seems there's no authoritative list of options propagated to javac
defined.

Is there any way to pass this option when implicitly invoking the
compiler through the java command in this case?

Thanks,

--Gunnar

[1] https://openjdk.java.net/jeps/330

From bsrbnd at gmail.com  Mon Dec 17 12:36:20 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Mon, 17 Dec 2018 13:36:20 +0100
Subject: Issue with Comparator.comparing
In-Reply-To: <398bd521-33a2-31b6-4d85-5d5d97f6264b@oracle.com>
References: <4759fd3f-959e-ae39-8dad-d5a02a4bd3ba@oracle.com>
 <CAEgw74CXWW7LiA_mQEqOHv2iGydQ8SFAxC07uX3aeSE75KAbWg@mail.gmail.com>
 <65f3704a-1f89-f974-c14a-63eadfe2015c@oracle.com>
 <CAEgw74BkYEttSLAOGpTTkYTsU3bHuGzS-JeTtW_33O+FEQX_Ng@mail.gmail.com>
 <CAEgw74B2ig1_NfeiNZA2yJf+61d0wfvv=6Ak_kYdmkiGrrRRxA@mail.gmail.com>
 <398bd521-33a2-31b6-4d85-5d5d97f6264b@oracle.com>
Message-ID: <CAEgw74AHVof98b3Doq=W_m-XLonrQ0JDhcnPpQsJeV-2bOG_Lw@mail.gmail.com>

On Fri, 14 Dec 2018 at 16:28, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
> I get that there are other ways to make the example working. But the API says:
>
> "Accepts a function that extracts a Comparable sort key from a type T, and returns a Comparator<T> that compares by that sort key."
>
> There's no other note in the API which hints at the fact that it might spectacularly fail because of heap pollution. And the fact that it is a synthetic cast that is failing, is strongly hinting at something at odds with the type-system.
>
> Maurizio

I agree there's something odd, but I really believe this isn't when
capturing the receiver which still ends up with a type variable (JLS
?5.1.10), the key extractor remaining generic and not instantiated.

As I said previously, the issue might be in the following expression:

  (c1, c2) -> keyExtractor.apply(c1).compareTo(keyExtractor.apply(c2));

in 'Comparator::comparing':

http://hg.openjdk.java.net/jdk/jdk/file/dcbb71b9e7c0/src/java.base/share/classes/java/util/Comparator.java#l469

which is where 'keyExtractor' is "instantiated" to the type of c1 and
c2 which is assumed to be the same, 'T' in this case:

http://hg.openjdk.java.net/jdk/jdk/file/dcbb71b9e7c0/src/java.base/share/classes/java/util/Comparator.java#l468

I don't think there's any type system issue here, the API simply
requires all elements to be of the same type 'T' and thus returning
keys comparable between themselves (U extends Comparable<? super U>):

http://hg.openjdk.java.net/jdk/jdk/file/dcbb71b9e7c0/src/java.base/share/classes/java/util/Comparator.java#l465

This assertion being wrong in your example as 'T = ? super Foo<?>' and
keys aren't always comparable between themselves.

The doc should simply says something like here under.

What do you think?
Bernard

diff --git a/src/java.base/share/classes/java/util/Comparator.java
b/src/java.base/share/classes/java/util/Comparator.java
--- a/src/java.base/share/classes/java/util/Comparator.java
+++ b/src/java.base/share/classes/java/util/Comparator.java
@@ -459,6 +459,7 @@
      *         Comparable} sort key
      * @return a comparator that compares by an extracted key
      * @throws NullPointerException if the argument is null
+     * @throws ClassCastException if sort keys aren't comparable
between themselves
      * @since 1.8
      */
     public static <T, U extends Comparable<? super U>> Comparator<T> comparing(

From maurizio.cimadamore at oracle.com  Mon Dec 17 12:49:38 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 17 Dec 2018 12:49:38 +0000
Subject: Issue with Comparator.comparing
In-Reply-To: <CAEgw74AHVof98b3Doq=W_m-XLonrQ0JDhcnPpQsJeV-2bOG_Lw@mail.gmail.com>
References: <4759fd3f-959e-ae39-8dad-d5a02a4bd3ba@oracle.com>
 <CAEgw74CXWW7LiA_mQEqOHv2iGydQ8SFAxC07uX3aeSE75KAbWg@mail.gmail.com>
 <65f3704a-1f89-f974-c14a-63eadfe2015c@oracle.com>
 <CAEgw74BkYEttSLAOGpTTkYTsU3bHuGzS-JeTtW_33O+FEQX_Ng@mail.gmail.com>
 <CAEgw74B2ig1_NfeiNZA2yJf+61d0wfvv=6Ak_kYdmkiGrrRRxA@mail.gmail.com>
 <398bd521-33a2-31b6-4d85-5d5d97f6264b@oracle.com>
 <CAEgw74AHVof98b3Doq=W_m-XLonrQ0JDhcnPpQsJeV-2bOG_Lw@mail.gmail.com>
Message-ID: <ffd3ef86-25a3-e384-0791-894da679915e@oracle.com>


On 17/12/2018 12:36, B. Blaser wrote:
> This assertion being wrong in your example as 'T = ? super Foo<?>' and
> keys aren't always comparable between themselves.

This is where we disagree. You are treating this as "you are calling a 
method with the bad input" whereas I'm saying "it's an issue you are 
able to call the method in the first place".

As you say, I have a ? super Foo<?> on my hand, but, thanks to capture 
conversion, we can trick the compiler into thinking that all things 
coming out of the function we pass to Comparator::comparing will _all_ 
have the same captured type, which is wrong. In reality, '? super 
Foo<?>' gets re-captured on every call of the method reference, so 
assuming that all method reference call will yield the same captured 
type is simply wrong.

Challenge: can you find an example which ends up with same behavior 
(ClassCastException) that does _not_ involve method references and/or 
lambdas?

Maurizio



From maurizio.cimadamore at oracle.com  Mon Dec 17 14:15:46 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 17 Dec 2018 14:15:46 +0000
Subject: RFR: 8215366: Code quality improvements in
 com.sun.tools.javac.code.TypeAnnotations
In-Reply-To: <CAEgw74C_2+LDfAjA=wO_t2ab0mmY-_M8HSc-WVhJffMtAyZm7g@mail.gmail.com>
References: <CAL4QsguQgq0-KXBZ9DoYBWn1QWf36jb+ewE-Pof6nRBvAp6-iw@mail.gmail.com>
 <CAEgw74C_2+LDfAjA=wO_t2ab0mmY-_M8HSc-WVhJffMtAyZm7g@mail.gmail.com>
Message-ID: <5a41c453-d267-f96a-1c12-06dbff483f31@oracle.com>

Looks good

Thanks
Maurizio

On 13/12/2018 20:29, B. Blaser wrote:
> You'll still need a Reviewer approval but these changes seem good to
> me, as discussed earlier, excepted that you'd need to update the
> copyright year.
>
> Thanks,
> Bernard
>
> On Thu, 13 Dec 2018 at 19:37, Liam Miller-Cushon <cushon at google.com> wrote:
>> Hi,
>>
>> Please consider this small cleanup to TypeAnnotations, which was based on discussion in the review thread for JDK-8208470. The change removes an unused helper method, and makes the handling of type annotation position information more consistent.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8215366
>> webrev: http://cr.openjdk.java.net/~cushon/8215366/webrev.00/

From maurizio.cimadamore at oracle.com  Mon Dec 17 14:17:21 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 17 Dec 2018 14:17:21 +0000
Subject: RFR: 8215368: Make Check.checkOverride call diagnosticPositionFor
 lazily
In-Reply-To: <CAL4QsgsaJkRJ+4pNU2HqYvyfjRfhXz88aj_AVxV4ig_Mstaz-g@mail.gmail.com>
References: <CAL4QsgsaJkRJ+4pNU2HqYvyfjRfhXz88aj_AVxV4ig_Mstaz-g@mail.gmail.com>
Message-ID: <0151a35f-b49d-c1d2-5984-b59b22f22723@oracle.com>

Looks good

Thanks
Maurizio

On 13/12/2018 19:08, Liam Miller-Cushon wrote:
> Hi,
>
> Please consider this trivial performance fix to?Check.checkOverride, 
> which achieved roughly a 2x speedup on a compilation of a pathological 
> generated source file.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8215368
> webrev: http://cr.openjdk.java.net/~cushon/8215368/webrev.00

From bsrbnd at gmail.com  Mon Dec 17 14:42:42 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Mon, 17 Dec 2018 15:42:42 +0100
Subject: RFR: 8215366: Code quality improvements in
 com.sun.tools.javac.code.TypeAnnotations
In-Reply-To: <5a41c453-d267-f96a-1c12-06dbff483f31@oracle.com>
References: <CAL4QsguQgq0-KXBZ9DoYBWn1QWf36jb+ewE-Pof6nRBvAp6-iw@mail.gmail.com>
 <CAEgw74C_2+LDfAjA=wO_t2ab0mmY-_M8HSc-WVhJffMtAyZm7g@mail.gmail.com>
 <5a41c453-d267-f96a-1c12-06dbff483f31@oracle.com>
Message-ID: <CAEgw74CtuGP0Eo3D_crGQraQEg8p=chLf6oEb7VB4DQjK8zaHg@mail.gmail.com>

Perfect, I'll re-base the fix for JDK-8208470 once Liam has pushed this.
Bernard

On Mon, 17 Dec 2018 at 15:15, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
> Looks good
>
> Thanks
> Maurizio
>
> On 13/12/2018 20:29, B. Blaser wrote:
> > You'll still need a Reviewer approval but these changes seem good to
> > me, as discussed earlier, excepted that you'd need to update the
> > copyright year.
> >
> > Thanks,
> > Bernard
> >
> > On Thu, 13 Dec 2018 at 19:37, Liam Miller-Cushon <cushon at google.com> wrote:
> >> Hi,
> >>
> >> Please consider this small cleanup to TypeAnnotations, which was based on discussion in the review thread for JDK-8208470. The change removes an unused helper method, and makes the handling of type annotation position information more consistent.
> >>
> >> bug: https://bugs.openjdk.java.net/browse/JDK-8215366
> >> webrev: http://cr.openjdk.java.net/~cushon/8215366/webrev.00/

From bsrbnd at gmail.com  Mon Dec 17 14:53:04 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Mon, 17 Dec 2018 15:53:04 +0100
Subject: Issue with Comparator.comparing
In-Reply-To: <ffd3ef86-25a3-e384-0791-894da679915e@oracle.com>
References: <4759fd3f-959e-ae39-8dad-d5a02a4bd3ba@oracle.com>
 <CAEgw74CXWW7LiA_mQEqOHv2iGydQ8SFAxC07uX3aeSE75KAbWg@mail.gmail.com>
 <65f3704a-1f89-f974-c14a-63eadfe2015c@oracle.com>
 <CAEgw74BkYEttSLAOGpTTkYTsU3bHuGzS-JeTtW_33O+FEQX_Ng@mail.gmail.com>
 <CAEgw74B2ig1_NfeiNZA2yJf+61d0wfvv=6Ak_kYdmkiGrrRRxA@mail.gmail.com>
 <398bd521-33a2-31b6-4d85-5d5d97f6264b@oracle.com>
 <CAEgw74AHVof98b3Doq=W_m-XLonrQ0JDhcnPpQsJeV-2bOG_Lw@mail.gmail.com>
 <ffd3ef86-25a3-e384-0791-894da679915e@oracle.com>
Message-ID: <CAEgw74Dbg6G6ohbNi9oGKYvJFzNnES94rc_+qtM0DJjxAunsNQ@mail.gmail.com>

On Mon, 17 Dec 2018 at 13:49, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> [...]
> Challenge: can you find an example which ends up with same behavior
> (ClassCastException) that does _not_ involve method references and/or
> lambdas?
>
> Maurizio

I like challenges, but I agree this one is hard as it involves a raw
'Foo3' to simulate the capture side-effect as here under.

Thoughts?
Bernard

import java.util.*;
import java.util.stream.*;
import java.util.function.*;

class Foo3<T extends Comparable<T>> {

    static Foo3<String> S = new Foo3<>("");
    static Foo3<Integer> I = new Foo3<>(42);

    private T t;

    Foo3(T t) {
        this.t = t;
    }

    T t() {
        return t;
    }

    public static void main(String[] args) {
        List<Foo3<?>> l = new ArrayList<>();
        l.add(S);
        l.add(I);

        Comparator<? super Foo3<?>> comp = new Comparator<Foo3>() {
            public int compare(Foo3 f1, Foo3 f2) {
                return f1.t().compareTo(f2.t());
            }
        };
        Collections.sort(l, comp);
    }
}

From vicente.romero at oracle.com  Mon Dec 17 15:10:51 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 17 Dec 2018 10:10:51 -0500
Subject: RFR: 8215368: Make Check.checkOverride call diagnosticPositionFor
 lazily
In-Reply-To: <CAL4QsgsaJkRJ+4pNU2HqYvyfjRfhXz88aj_AVxV4ig_Mstaz-g@mail.gmail.com>
References: <CAL4QsgsaJkRJ+4pNU2HqYvyfjRfhXz88aj_AVxV4ig_Mstaz-g@mail.gmail.com>
Message-ID: <26bec0d7-352a-a46c-bf1b-6ba9cc63f2c9@oracle.com>

looks good,
Vicente

On 12/13/18 2:08 PM, Liam Miller-Cushon wrote:
> Hi,
>
> Please consider this trivial performance fix to?Check.checkOverride, 
> which achieved roughly a 2x speedup on a compilation of a pathological 
> generated source file.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8215368
> webrev: http://cr.openjdk.java.net/~cushon/8215368/webrev.00


From maurizio.cimadamore at oracle.com  Mon Dec 17 15:26:43 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 17 Dec 2018 15:26:43 +0000
Subject: Issue with Comparator.comparing
In-Reply-To: <CAEgw74Dbg6G6ohbNi9oGKYvJFzNnES94rc_+qtM0DJjxAunsNQ@mail.gmail.com>
References: <4759fd3f-959e-ae39-8dad-d5a02a4bd3ba@oracle.com>
 <CAEgw74CXWW7LiA_mQEqOHv2iGydQ8SFAxC07uX3aeSE75KAbWg@mail.gmail.com>
 <65f3704a-1f89-f974-c14a-63eadfe2015c@oracle.com>
 <CAEgw74BkYEttSLAOGpTTkYTsU3bHuGzS-JeTtW_33O+FEQX_Ng@mail.gmail.com>
 <CAEgw74B2ig1_NfeiNZA2yJf+61d0wfvv=6Ak_kYdmkiGrrRRxA@mail.gmail.com>
 <398bd521-33a2-31b6-4d85-5d5d97f6264b@oracle.com>
 <CAEgw74AHVof98b3Doq=W_m-XLonrQ0JDhcnPpQsJeV-2bOG_Lw@mail.gmail.com>
 <ffd3ef86-25a3-e384-0791-894da679915e@oracle.com>
 <CAEgw74Dbg6G6ohbNi9oGKYvJFzNnES94rc_+qtM0DJjxAunsNQ@mail.gmail.com>
Message-ID: <b79f0721-7f97-e454-d77f-8c0e2d6d65cd@oracle.com>

yep - you ended up using raw types; something I thought about, but note 
that this will generate an unchecked warning:

warning: [unchecked] unchecked call to compareTo(T) as a member of the 
raw type Comparable
 ??????????????? return f1.t().compareTo(f2.t());
 ?????????????????????????????????????? ^
 ? where T is a type-variable:
 ??? T extends Object declared in interface Comparable

So, strictly speaking the class cast exception comes at no surprise here.

But there's no warning in the original code!!! (not suggesting we should 
add warnings here or there, just noting that we have a case of heap 
pollution that goes under the radar).

Maurizio


On 17/12/2018 14:53, B. Blaser wrote:
> On Mon, 17 Dec 2018 at 13:49, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>> [...]
>> Challenge: can you find an example which ends up with same behavior
>> (ClassCastException) that does _not_ involve method references and/or
>> lambdas?
>>
>> Maurizio
> I like challenges, but I agree this one is hard as it involves a raw
> 'Foo3' to simulate the capture side-effect as here under.
>
> Thoughts?
> Bernard
>
> import java.util.*;
> import java.util.stream.*;
> import java.util.function.*;
>
> class Foo3<T extends Comparable<T>> {
>
>      static Foo3<String> S = new Foo3<>("");
>      static Foo3<Integer> I = new Foo3<>(42);
>
>      private T t;
>
>      Foo3(T t) {
>          this.t = t;
>      }
>
>      T t() {
>          return t;
>      }
>
>      public static void main(String[] args) {
>          List<Foo3<?>> l = new ArrayList<>();
>          l.add(S);
>          l.add(I);
>
>          Comparator<? super Foo3<?>> comp = new Comparator<Foo3>() {
>              public int compare(Foo3 f1, Foo3 f2) {
>                  return f1.t().compareTo(f2.t());
>              }
>          };
>          Collections.sort(l, comp);
>      }
> }

From maurizio.cimadamore at oracle.com  Mon Dec 17 16:59:11 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 17 Dec 2018 16:59:11 +0000
Subject: Issue with Comparator.comparing
In-Reply-To: <b79f0721-7f97-e454-d77f-8c0e2d6d65cd@oracle.com>
References: <4759fd3f-959e-ae39-8dad-d5a02a4bd3ba@oracle.com>
 <CAEgw74CXWW7LiA_mQEqOHv2iGydQ8SFAxC07uX3aeSE75KAbWg@mail.gmail.com>
 <65f3704a-1f89-f974-c14a-63eadfe2015c@oracle.com>
 <CAEgw74BkYEttSLAOGpTTkYTsU3bHuGzS-JeTtW_33O+FEQX_Ng@mail.gmail.com>
 <CAEgw74B2ig1_NfeiNZA2yJf+61d0wfvv=6Ak_kYdmkiGrrRRxA@mail.gmail.com>
 <398bd521-33a2-31b6-4d85-5d5d97f6264b@oracle.com>
 <CAEgw74AHVof98b3Doq=W_m-XLonrQ0JDhcnPpQsJeV-2bOG_Lw@mail.gmail.com>
 <ffd3ef86-25a3-e384-0791-894da679915e@oracle.com>
 <CAEgw74Dbg6G6ohbNi9oGKYvJFzNnES94rc_+qtM0DJjxAunsNQ@mail.gmail.com>
 <b79f0721-7f97-e454-d77f-8c0e2d6d65cd@oracle.com>
Message-ID: <5137a32f-9947-6ba1-7bd9-b22718b17b83@oracle.com>

Since we're discussing this, I believe the closest you can get w/o 
method reference is this:

import java.util.*;
import java.util.stream.*;
import java.util.function.*;

class Foo3<T extends Comparable<T>> {

 ??? static Foo3<String> S = new Foo3<>("");
 ??? static Foo3<Integer> I = new Foo3<>(42);

 ??? private T t;

 ??? Foo3(T t) {
 ??????? this.t = t;
 ??? }

 ??? T t() {
 ??????? return t;
 ??? }

 ??? public static void main(String[] args) {
 ??????? List<Foo3<?>> l = new ArrayList<>();
 ??????? l.add(S);
 ??????? l.add(I);

 ??????? Comparator<? super Foo3<?>> comp = makeComp();
 ??????? Collections.sort(l, comp);
 ??? }

 ??? static <Z extends Foo3<?>> Comparator<Z> makeComp() {
 ??????? return new Comparator<Z>() {
 ??????????? public int compare(Z f1, Z f2) {
 ??????????????? return f1.t().compareTo(f2.t());
 ??????????? }
 ?????? };

 ??? }
}


Note how this example doesn't use any raw types, and relies on inference 
instead.

But, when this is compiled, you get an error:

 ?error: incompatible types: Comparable<CAP#1> cannot be converted to CAP#2
 ??????????????? return f1.t().compareTo(f2.t());
 ??????????????????????????????????????????? ^
 ? where CAP#1,CAP#2 are fresh type-variables:
 ??? CAP#1 extends Comparable<CAP#1> from capture of ?
 ??? CAP#2 extends Comparable<CAP#2> from capture of ?
Note: Some messages have been simplified; recompile with -Xdiags:verbose 
to get full output
1 error


Of course the compiler stops this: there's no static guarantee that 
f1.t() has same type as f2.t(). They are both some Foo<#CAP>, but of 
different captured types (and so, incompatible).


To compensate for this, you can define makeComp as follows:

static <Z extends Comparable<Z>> Comparator<Foo3<?>> 
makeComp(Function<Foo3<?>, Z> func) {
 ??????? return new Comparator<Foo3<?>>() {
 ??????????? public int compare(Foo3<?> f1, Foo3<?> f2) {
 ??????????????? return func.apply(f1).compareTo(func.apply(f2));
 ??????????? }
 ?????? };

 ??? }

And then call it like this:

makeComp(Foo3::t)

And this will work (and then fail at runtime with CCE). But here we are 
essentially relying on the compiler to capture the result of Foo<?>::t 
once, and then generate a function that will keep yielding the same 
captured type - hence making the comparator call type-check.

Maurizio

On 17/12/2018 15:26, Maurizio Cimadamore wrote:
> yep - you ended up using raw types; something I thought about, but 
> note that this will generate an unchecked warning:
>
> warning: [unchecked] unchecked call to compareTo(T) as a member of the 
> raw type Comparable
> ??????????????? return f1.t().compareTo(f2.t());
> ?????????????????????????????????????? ^
> ? where T is a type-variable:
> ??? T extends Object declared in interface Comparable
>
> So, strictly speaking the class cast exception comes at no surprise here.
>
> But there's no warning in the original code!!! (not suggesting we 
> should add warnings here or there, just noting that we have a case of 
> heap pollution that goes under the radar).
>
> Maurizio
>
>
> On 17/12/2018 14:53, B. Blaser wrote:
>> On Mon, 17 Dec 2018 at 13:49, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>>> [...]
>>> Challenge: can you find an example which ends up with same behavior
>>> (ClassCastException) that does _not_ involve method references and/or
>>> lambdas?
>>>
>>> Maurizio
>> I like challenges, but I agree this one is hard as it involves a raw
>> 'Foo3' to simulate the capture side-effect as here under.
>>
>> Thoughts?
>> Bernard
>>
>> import java.util.*;
>> import java.util.stream.*;
>> import java.util.function.*;
>>
>> class Foo3<T extends Comparable<T>> {
>>
>> ???? static Foo3<String> S = new Foo3<>("");
>> ???? static Foo3<Integer> I = new Foo3<>(42);
>>
>> ???? private T t;
>>
>> ???? Foo3(T t) {
>> ???????? this.t = t;
>> ???? }
>>
>> ???? T t() {
>> ???????? return t;
>> ???? }
>>
>> ???? public static void main(String[] args) {
>> ???????? List<Foo3<?>> l = new ArrayList<>();
>> ???????? l.add(S);
>> ???????? l.add(I);
>>
>> ???????? Comparator<? super Foo3<?>> comp = new Comparator<Foo3>() {
>> ???????????? public int compare(Foo3 f1, Foo3 f2) {
>> ???????????????? return f1.t().compareTo(f2.t());
>> ???????????? }
>> ???????? };
>> ???????? Collections.sort(l, comp);
>> ???? }
>> }

From mandy.chung at oracle.com  Mon Dec 17 17:43:12 2018
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 17 Dec 2018 09:43:12 -0800
Subject: 8215449: Several tests failing when jtreg run with
 -vmoption:--illegal-access=deny
In-Reply-To: <b2736372-9a92-7149-d73d-3f4bc49c6dd6@oracle.com>
References: <b2736372-9a92-7149-d73d-3f4bc49c6dd6@oracle.com>
Message-ID: <6bbd7cfd-3a00-e358-7571-864ec42c6d4a@oracle.com>



On 12/15/18 1:40 AM, Alan Bateman wrote:
> This is test only change to fix a few tests that don't have complete 
> @modules or --add-exports options and so fail when running jtreg with 
> vmoption:--illegal-access=deny.
>
> The only change that might not be obvious is to 
> langtools/tools/javac/platform/CanHandleClassFilesTest.java. That test 
> creates a custom class loader to load the CreateSymbols tool from the 
> make tree. jtreg doesn't know how to export packages to the unnamed 
> module of custom class loaders so the test is changed to open the 
> packages to the test and then pass on the rights to the unnamed module 
> of the custom class loader.
>
> http://cr.openjdk.java.net/~alanb/8215449/webrev/index.html

Looks good to me.

Mandy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181217/e31790b8/attachment.html>

From jonathan.gibbons at oracle.com  Mon Dec 17 18:41:51 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 17 Dec 2018 10:41:51 -0800
Subject: 8215449: Several tests failing when jtreg run with
 -vmoption:--illegal-access=deny
In-Reply-To: <b2736372-9a92-7149-d73d-3f4bc49c6dd6@oracle.com>
References: <b2736372-9a92-7149-d73d-3f4bc49c6dd6@oracle.com>
Message-ID: <4951e90a-06af-1192-f215-1b71160427e3@oracle.com>

The change to the langtools test looks OK

-- Jon

On 12/15/18 1:40 AM, Alan Bateman wrote:
> This is test only change to fix a few tests that don't have complete 
> @modules or --add-exports options and so fail when running jtreg with 
> vmoption:--illegal-access=deny.
>
> The only change that might not be obvious is to 
> langtools/tools/javac/platform/CanHandleClassFilesTest.java. That test 
> creates a custom class loader to load the CreateSymbols tool from the 
> make tree. jtreg doesn't know how to export packages to the unnamed 
> module of custom class loaders so the test is changed to open the 
> packages to the test and then pass on the rights to the unnamed module 
> of the custom class loader.
>
> http://cr.openjdk.java.net/~alanb/8215449/webrev/index.html
>
> -Alan

From jonathan.gibbons at oracle.com  Mon Dec 17 19:03:40 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 17 Dec 2018 11:03:40 -0800
Subject: How to pass compiler options when running a single-file
 source-code Java program?
In-Reply-To: <CADGJaX8zxO6Hn0f+qG2nfTc-Kdex3gmGkvYkHFzVUw+HMgjjBA@mail.gmail.com>
References: <CADGJaX8zxO6Hn0f+qG2nfTc-Kdex3gmGkvYkHFzVUw+HMgjjBA@mail.gmail.com>
Message-ID: <582f0fad-9503-94e5-7a7f-6e63544ef55e@oracle.com>


On 12/16/18 2:04 AM, Gunnar Morling wrote:
> Hi,
>
> I'd like to use JEP 330 [1] to run a single-file source-code program
> with Java (>= 11).
>
> Doing so, I'd like to pass options understood by javac but not by the
> runtime (java), e.g. -XDsuppressNotes. But this causes e.g. the
> following invocation to fail:
>
>      java --enable-preview --source=12 -XDsuppressNotes Test.java
>
>      Unrecognized option: -XDsuppressNotes
>      Error: Could not create the Java Virtual Machine.
>      Error: A fatal exception has occurred. Program will exit.
>
> There's this related sentence in the JEP:
>
>> The source-launcher implementation class has access to any relevant
>> command-line options, such as those to define the class path, module path,
>> and the module graph, and passes those options to the compiler to configure
>> the compilation environment.
> So I'd expect an option such as -XDsuppressNotes to be propagated, but
> it seems there's no authoritative list of options propagated to javac
> defined.

That's not the intent of the sentence in the JEP.

The intent of the sentence is that if there are any runtime options
that could/should reasonably be applied in the context of the compilation
environment, then those options will be passed through to the
compiler.? There has never been any intent to provide a mechanism
to pass arbitrary options to the compiler when using the source-launcher
feature of the Java launcher.

The set of applicable options was not specified explicitly, so as not
to preclude options being added in future -- but maybe we could
add a Note with the currently applicable options.? The list is

--add-exports
--add-modules
--class-path -classpath -cp
--enable-preview
--limit-modules
--module-path -p
--patch-module
--upgrade-module-path


>
> Is there any way to pass this option when implicitly invoking the
> compiler through the java command in this case?

No.? If you want to specify arbitrary javac options, use javac.

I would also note that you are trying to use a -XD option.
That is a non-standard, undocumented, unsupported option for javac.
Even if we were to open up access to some additional javac options
when using the source launcher, it is not likely that we would expose
that particular option.

-- Jon

>
> Thanks,
>
> --Gunnar
>
> [1] https://openjdk.java.net/jeps/330

From cushon at google.com  Mon Dec 17 23:28:25 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 17 Dec 2018 15:28:25 -0800
Subject: RFR: 8215366: Code quality improvements in
 com.sun.tools.javac.code.TypeAnnotations
In-Reply-To: <CAJYRO=64JfgbMMcXdnn1oA2zDTqBubm5kZK_7-r-pVdTNMN2Lw@mail.gmail.com>
References: <CAL4QsguQgq0-KXBZ9DoYBWn1QWf36jb+ewE-Pof6nRBvAp6-iw@mail.gmail.com>
 <CAEgw74C_2+LDfAjA=wO_t2ab0mmY-_M8HSc-WVhJffMtAyZm7g@mail.gmail.com>
 <5a41c453-d267-f96a-1c12-06dbff483f31@oracle.com>
 <CAEgw74CtuGP0Eo3D_crGQraQEg8p=chLf6oEb7VB4DQjK8zaHg@mail.gmail.com>
 <CAJYRO=64JfgbMMcXdnn1oA2zDTqBubm5kZK_7-r-pVdTNMN2Lw@mail.gmail.com>
Message-ID: <CAL4Qsgs_=4ZnMz1Ag_TRgCLXUiYcP37aVDcN9BvRTR7fS8rPbA@mail.gmail.com>

Pushed as: http://hg.openjdk.java.net/jdk/jdk/rev/d5a2a29ca589

Thanks for the reviews!

On Mon, Dec 17, 2018 at 8:11 AM Werner Dietl <wdietl at gmail.com> wrote:

> Thanks for these cleanups, Liam!
> cu, WMD.
> On Mon, Dec 17, 2018 at 9:43 AM B. Blaser <bsrbnd at gmail.com> wrote:
> >
> > Perfect, I'll re-base the fix for JDK-8208470 once Liam has pushed this.
> > Bernard
> >
> > On Mon, 17 Dec 2018 at 15:15, Maurizio Cimadamore
> > <maurizio.cimadamore at oracle.com> wrote:
> > >
> > > Looks good
> > >
> > > Thanks
> > > Maurizio
> > >
> > > On 13/12/2018 20:29, B. Blaser wrote:
> > > > You'll still need a Reviewer approval but these changes seem good to
> > > > me, as discussed earlier, excepted that you'd need to update the
> > > > copyright year.
> > > >
> > > > Thanks,
> > > > Bernard
> > > >
> > > > On Thu, 13 Dec 2018 at 19:37, Liam Miller-Cushon <cushon at google.com>
> wrote:
> > > >> Hi,
> > > >>
> > > >> Please consider this small cleanup to TypeAnnotations, which was
> based on discussion in the review thread for JDK-8208470. The change
> removes an unused helper method, and makes the handling of type annotation
> position information more consistent.
> > > >>
> > > >> bug: https://bugs.openjdk.java.net/browse/JDK-8215366
> > > >> webrev: http://cr.openjdk.java.net/~cushon/8215366/webrev.00/
>
>
>
> --
> http://www.google.com/profiles/wdietl
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181217/18f55e9f/attachment.html>

From jay.a at outlook.in  Tue Dec 18 08:08:42 2018
From: jay.a at outlook.in (Jayaprakash Artanareeswaran)
Date: Tue, 18 Dec 2018 08:08:42 +0000
Subject: Fw: Changes to ct.sym in JDK 12
In-Reply-To: <BN6PR06MB3219CEA0D4DF7F4936ACDE9887A70@BN6PR06MB3219.namprd06.prod.outlook.com>
References: <BN6PR06MB321977B1BA73F07110A4A84887A50@BN6PR06MB3219.namprd06.prod.outlook.com>,
 <BN6PR06MB3219CEA0D4DF7F4936ACDE9887A70@BN6PR06MB3219.namprd06.prod.outlook.com>
Message-ID: <BN6PR06MB32199245D7A4155FFA9F095687BD0@BN6PR06MB3219.namprd06.prod.outlook.com>

Thanks Jon!

Can someone please point me to a document or bug where this is
discussed or documented? I am particularly interested in knowing
this file's structure, especially how older versions of classes
are stored. I can gather some information by looking at the
file's content, but would rather an official document to
understand things better.

Thanks,
Jay


> Jay,
>
> This is better discussed on compiler-dev.

> It's about consistency, and better supporting the historical modular
> releases.

-- Jon

On 12/9/18 9:24 PM, Jayaprakash Artanareeswaran wrote:
> Hello experts,
>>    I see that the ct.sym has been restructured in JDK 12. Specifically, I am curious about the fact that even for non modular releases such as 7 and 8, I see the classes being placed inside their respective modules.
>> Is it just about consistency? Are the modules always ignored or is there a scenario where the modular structure will be useful?
>> Sorry if this was discussed already, but I couldn't find much about this particular change.
>> Regards,
> Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181218/ff345760/attachment.html>

From gunnar at hibernate.org  Tue Dec 18 09:04:08 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 18 Dec 2018 10:04:08 +0100
Subject: How to pass compiler options when running a single-file
 source-code Java program?
In-Reply-To: <582f0fad-9503-94e5-7a7f-6e63544ef55e@oracle.com>
References: <CADGJaX8zxO6Hn0f+qG2nfTc-Kdex3gmGkvYkHFzVUw+HMgjjBA@mail.gmail.com>
 <582f0fad-9503-94e5-7a7f-6e63544ef55e@oracle.com>
Message-ID: <CADGJaX8i1PehB_S-HQm4o4AjgFaHxyNhvAv89ycnyDvcjry89A@mail.gmail.com>

Thanks for the confirmation!

> but maybe we could add a Note with the currently applicable options.

Yes, that'd be helpful.

> Even if we were to open up access to some additional javac options when using the source launcher, it is not likely that we would expose that particular option.

I see. I feel this convolutes one prime use case of source file mode
though, which is using it to explore new (including preview) language
features. Given I'm explicitly opting into using the preview mode, it
IMO adds unnecessary noise to the program output. E.g. see this little
example where the node adds quite some verbosity to the output:

    https://twitter.com/gunnarmorling/status/1074635092566384641

In addition one cannot even do what the note says, as the
-Xlint:preview option is unsupported in source file mode, too.

So if there's no way to pass -XDsuppressNotes, could you perhaps
consider to implicitly suppress that note when running in source file
mode with preview enabled?

Thanks,

--Gunnar

Am Mo., 17. Dez. 2018 um 20:04 Uhr schrieb Jonathan Gibbons
<jonathan.gibbons at oracle.com>:
>
>
> On 12/16/18 2:04 AM, Gunnar Morling wrote:
> > Hi,
> >
> > I'd like to use JEP 330 [1] to run a single-file source-code program
> > with Java (>= 11).
> >
> > Doing so, I'd like to pass options understood by javac but not by the
> > runtime (java), e.g. -XDsuppressNotes. But this causes e.g. the
> > following invocation to fail:
> >
> >      java --enable-preview --source=12 -XDsuppressNotes Test.java
> >
> >      Unrecognized option: -XDsuppressNotes
> >      Error: Could not create the Java Virtual Machine.
> >      Error: A fatal exception has occurred. Program will exit.
> >
> > There's this related sentence in the JEP:
> >
> >> The source-launcher implementation class has access to any relevant
> >> command-line options, such as those to define the class path, module path,
> >> and the module graph, and passes those options to the compiler to configure
> >> the compilation environment.
> > So I'd expect an option such as -XDsuppressNotes to be propagated, but
> > it seems there's no authoritative list of options propagated to javac
> > defined.
>
> That's not the intent of the sentence in the JEP.
>
> The intent of the sentence is that if there are any runtime options
> that could/should reasonably be applied in the context of the compilation
> environment, then those options will be passed through to the
> compiler.  There has never been any intent to provide a mechanism
> to pass arbitrary options to the compiler when using the source-launcher
> feature of the Java launcher.
>
> The set of applicable options was not specified explicitly, so as not
> to preclude options being added in future -- but maybe we could
> add a Note with the currently applicable options.  The list is
>
> --add-exports
> --add-modules
> --class-path -classpath -cp
> --enable-preview
> --limit-modules
> --module-path -p
> --patch-module
> --upgrade-module-path
>
>
> >
> > Is there any way to pass this option when implicitly invoking the
> > compiler through the java command in this case?
>
> No.  If you want to specify arbitrary javac options, use javac.
>
> I would also note that you are trying to use a -XD option.
> That is a non-standard, undocumented, unsupported option for javac.
> Even if we were to open up access to some additional javac options
> when using the source launcher, it is not likely that we would expose
> that particular option.
>
> -- Jon
>
> >
> > Thanks,
> >
> > --Gunnar
> >
> > [1] https://openjdk.java.net/jeps/330

From jonathan.gibbons at oracle.com  Tue Dec 18 17:05:44 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 18 Dec 2018 09:05:44 -0800
Subject: How to pass compiler options when running a single-file
 source-code Java program?
In-Reply-To: <CADGJaX8i1PehB_S-HQm4o4AjgFaHxyNhvAv89ycnyDvcjry89A@mail.gmail.com>
References: <CADGJaX8zxO6Hn0f+qG2nfTc-Kdex3gmGkvYkHFzVUw+HMgjjBA@mail.gmail.com>
 <582f0fad-9503-94e5-7a7f-6e63544ef55e@oracle.com>
 <CADGJaX8i1PehB_S-HQm4o4AjgFaHxyNhvAv89ycnyDvcjry89A@mail.gmail.com>
Message-ID: <ee2859e8-0918-9d6f-9eaa-a32ecf14cf47@oracle.com>


On 12/18/18 1:04 AM, Gunnar Morling wrote:
> Thanks for the confirmation!
>
>> but maybe we could add a Note with the currently applicable options.
> Yes, that'd be helpful.
>
>> Even if we were to open up access to some additional javac options when using the source launcher, it is not likely that we would expose that particular option.
> I see. I feel this convolutes one prime use case of source file mode
> though, which is using it to explore new (including preview) language
> features. Given I'm explicitly opting into using the preview mode, it
> IMO adds unnecessary noise to the program output. E.g. see this little
> example where the node adds quite some verbosity to the output:
>
>      https://twitter.com/gunnarmorling/status/1074635092566384641
>
> In addition one cannot even do what the note says, as the
> -Xlint:preview option is unsupported in source file mode, too.
>
> So if there's no way to pass -XDsuppressNotes, could you perhaps
> consider to implicitly suppress that note when running in source file
> mode with preview enabled?

Suppressing the note entirely would require changes to JEP 12,
which specifies that javac generates a note when it detects the use
of preview features. That being said, it may be reasonable to
modify/remove the suggestion to use -Xlint in circumstances
like this when the option is not available.

-- Jon


>
> Thanks,
>
> --Gunnar
>
> Am Mo., 17. Dez. 2018 um 20:04 Uhr schrieb Jonathan Gibbons
> <jonathan.gibbons at oracle.com>:
>>
>> On 12/16/18 2:04 AM, Gunnar Morling wrote:
>>> Hi,
>>>
>>> I'd like to use JEP 330 [1] to run a single-file source-code program
>>> with Java (>= 11).
>>>
>>> Doing so, I'd like to pass options understood by javac but not by the
>>> runtime (java), e.g. -XDsuppressNotes. But this causes e.g. the
>>> following invocation to fail:
>>>
>>>       java --enable-preview --source=12 -XDsuppressNotes Test.java
>>>
>>>       Unrecognized option: -XDsuppressNotes
>>>       Error: Could not create the Java Virtual Machine.
>>>       Error: A fatal exception has occurred. Program will exit.
>>>
>>> There's this related sentence in the JEP:
>>>
>>>> The source-launcher implementation class has access to any relevant
>>>> command-line options, such as those to define the class path, module path,
>>>> and the module graph, and passes those options to the compiler to configure
>>>> the compilation environment.
>>> So I'd expect an option such as -XDsuppressNotes to be propagated, but
>>> it seems there's no authoritative list of options propagated to javac
>>> defined.
>> That's not the intent of the sentence in the JEP.
>>
>> The intent of the sentence is that if there are any runtime options
>> that could/should reasonably be applied in the context of the compilation
>> environment, then those options will be passed through to the
>> compiler.  There has never been any intent to provide a mechanism
>> to pass arbitrary options to the compiler when using the source-launcher
>> feature of the Java launcher.
>>
>> The set of applicable options was not specified explicitly, so as not
>> to preclude options being added in future -- but maybe we could
>> add a Note with the currently applicable options.  The list is
>>
>> --add-exports
>> --add-modules
>> --class-path -classpath -cp
>> --enable-preview
>> --limit-modules
>> --module-path -p
>> --patch-module
>> --upgrade-module-path
>>
>>
>>> Is there any way to pass this option when implicitly invoking the
>>> compiler through the java command in this case?
>> No.  If you want to specify arbitrary javac options, use javac.
>>
>> I would also note that you are trying to use a -XD option.
>> That is a non-standard, undocumented, unsupported option for javac.
>> Even if we were to open up access to some additional javac options
>> when using the source launcher, it is not likely that we would expose
>> that particular option.
>>
>> -- Jon
>>
>>> Thanks,
>>>
>>> --Gunnar
>>>
>>> [1] https://openjdk.java.net/jeps/330

From vicente.romero at oracle.com  Tue Dec 18 19:52:35 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 18 Dec 2018 14:52:35 -0500
Subject: RFR: JDK-8207224: Javac compiles source code despite illegal use
 of unchecked conversions
In-Reply-To: <48504207-95f7-b35a-e1db-0f04a50c9edd@oracle.com>
References: <bdb24823-103b-ba39-c369-7f89ff5f9ad8@oracle.com>
 <76e067ba-91f2-0f70-1963-bed523ad1a51@oracle.com>
 <48504207-95f7-b35a-e1db-0f04a50c9edd@oracle.com>
Message-ID: <35e4d4bf-dc22-99f0-e1d4-341acd39f45b@oracle.com>

Hi,

This bug was delayed to 13 and needed some changes. Can I have a final 
OK before pushing it? Please see [1]

Thanks,
Vicente

[1] http://cr.openjdk.java.net/~vromero/8207224/webrev.02/

On 12/3/18 4:13 PM, Maurizio Cimadamore wrote:
>
> Looks good - btw, if the compatibility cost proves to be too much we 
> could consider putting the new behavior behind the source switch (as 
> we did with override/hide string clash checking for some time).
>
> Cheers
> Maurizio
>
> On 03/12/2018 21:01, Vicente Romero wrote:
>> Hi,
>>
>> Please review the related CSR [1]
>>
>> Thanks,
>> Vicente
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8214729
>>
>> On 12/1/18 2:46 PM, Vicente Romero wrote:
>>> Please review fix for [1] at [2]. Javac is accepting this program as 
>>> valid:
>>>
>>> class ReturnTypeSubstitutableTest {
>>> ??? abstract class AbstractDemo<Request extends AbstractResult, 
>>> Response extends AbstractResult> {
>>> ??????? protected abstract Response test(Request request);
>>> ??? }
>>>
>>> ??? abstract interface AbstractResult {}
>>>
>>> ??? abstract interface SimpleResult extends AbstractResult {}
>>>
>>> ??? class Result1 implements SimpleResult {}
>>>
>>> ??? class OtherResult implements AbstractResult {}
>>>
>>> ??? public class SimpleDemo<Request extends AbstractResult, Response 
>>> extends AbstractResult> extends AbstractDemo<Request, Response> {
>>> ??????? @Override
>>> ??????? protected SimpleResult test(AbstractResult request) {? 
>>> <----------- this method is accepted as a good override for 
>>> AbstractDemo::test
>>> ??????????? return null;
>>> ??????? }
>>> ??? }
>>> }
>>>
>>> From Dan's evaluation at the bug entry [1]:
>>>
>>> Per JLS 8.4.8.3, the first method must be return-type-substitutable 
>>> for the second. This can be satisfied in 3 ways (JLS 8.4.5):
>>> - SimpleResult is a subtype of Response (no)
>>> - SimpleResult can be converted to a subtype of Response by 
>>> unchecked conversion (no)
>>> - The methods have different signatures (yep) and SimpleResult = 
>>> erasure(Response) (no)
>>>
>>> No case applies, so an error should occur. This fix syncs javac with 
>>> the spec.
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8207224
>>> [2] http://cr.openjdk.java.net/~vromero/8207224/webrev.00/
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181218/c7ea4e6e/attachment.html>

From joe.darcy at oracle.com  Tue Dec 18 20:27:46 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 18 Dec 2018 12:27:46 -0800
Subject: RFR: JDK-8207224: Javac compiles source code despite illegal use
 of unchecked conversions
In-Reply-To: <CAL4Qsgtda8V=BaOhGq8W29x+otYs_Rby6VMnxjhU3yVQd0HULQ@mail.gmail.com>
References: <bdb24823-103b-ba39-c369-7f89ff5f9ad8@oracle.com>
 <CAL4QsgvKmat7exH1JhigzXQFUORaCVbbXZ37dO0dFyeOLWRRfQ@mail.gmail.com>
 <cbaaa050-1d23-5b8b-985d-4b47f22707dc@oracle.com>
 <fef8cb1d-3aa2-2d77-be52-e2bc16dc2b1d@oracle.com>
 <CAL4Qsgtda8V=BaOhGq8W29x+otYs_Rby6VMnxjhU3yVQd0HULQ@mail.gmail.com>
Message-ID: <e7288a98-ff47-4316-7db2-38007c128d5b@oracle.com>

Hello,

We don't have quantitatively limits per se, but try to be guided by the 
numbers in a reasonable way. For example, we used a quantitative 
approach to help design diamond and subsequent language features.

At some level, with nearly any javac change there is a risk of some 
source incompatibility. That said, we don't want to bloat either the 
release notes documenting mostly innocuous changes or push us bug fixes 
to future source levels. Of course It is more concerning if the changes 
prevents code that previously compiled from compiling.

For this change, I think it is more reasonable to get it in at the start 
of a release cycle rather than toward rampdown to allow more time for 
adjustment if needed.

HTH,

-Joe

On 12/3/2018 4:29 PM, Liam Miller-Cushon wrote:
> There was a mention of crisper data in the CSR: for the corpus I 
> looked at, the fix affected one file per 202,000.
>
> On Mon, Dec 3, 2018 at 10:50 AM joe darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>     Since it sounds like there is nontrivial source compatibility
>     impact with this change, please file a CSR for it.
>
> Out of curiosity, what's the bar for whether a source incompatibility 
> is nontrivial-enough?to warrant a CSR, or putting behind a flag?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181218/6be5f20e/attachment.html>

From maurizio.cimadamore at oracle.com  Tue Dec 18 20:59:19 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 18 Dec 2018 20:59:19 +0000
Subject: RFR: JDK-8207224: Javac compiles source code despite illegal use
 of unchecked conversions
In-Reply-To: <35e4d4bf-dc22-99f0-e1d4-341acd39f45b@oracle.com>
References: <bdb24823-103b-ba39-c369-7f89ff5f9ad8@oracle.com>
 <76e067ba-91f2-0f70-1963-bed523ad1a51@oracle.com>
 <48504207-95f7-b35a-e1db-0f04a50c9edd@oracle.com>
 <35e4d4bf-dc22-99f0-e1d4-341acd39f45b@oracle.com>
Message-ID: <528673cf-c546-45db-568b-9dabdbd974a9@oracle.com>

Looks good

Maurizio

On 18/12/2018 19:52, Vicente Romero wrote:
> Hi,
>
> This bug was delayed to 13 and needed some changes. Can I have a final 
> OK before pushing it? Please see [1]
>
> Thanks,
> Vicente
>
> [1] http://cr.openjdk.java.net/~vromero/8207224/webrev.02/
>
> On 12/3/18 4:13 PM, Maurizio Cimadamore wrote:
>>
>> Looks good - btw, if the compatibility cost proves to be too much we 
>> could consider putting the new behavior behind the source switch (as 
>> we did with override/hide string clash checking for some time).
>>
>> Cheers
>> Maurizio
>>
>> On 03/12/2018 21:01, Vicente Romero wrote:
>>> Hi,
>>>
>>> Please review the related CSR [1]
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8214729
>>>
>>> On 12/1/18 2:46 PM, Vicente Romero wrote:
>>>> Please review fix for [1] at [2]. Javac is accepting this program 
>>>> as valid:
>>>>
>>>> class ReturnTypeSubstitutableTest {
>>>> ??? abstract class AbstractDemo<Request extends AbstractResult, 
>>>> Response extends AbstractResult> {
>>>> ??????? protected abstract Response test(Request request);
>>>> ??? }
>>>>
>>>> ??? abstract interface AbstractResult {}
>>>>
>>>> ??? abstract interface SimpleResult extends AbstractResult {}
>>>>
>>>> ??? class Result1 implements SimpleResult {}
>>>>
>>>> ??? class OtherResult implements AbstractResult {}
>>>>
>>>> ??? public class SimpleDemo<Request extends AbstractResult, 
>>>> Response extends AbstractResult> extends AbstractDemo<Request, 
>>>> Response> {
>>>> ??????? @Override
>>>> ??????? protected SimpleResult test(AbstractResult request) {? 
>>>> <----------- this method is accepted as a good override for 
>>>> AbstractDemo::test
>>>> ??????????? return null;
>>>> ??????? }
>>>> ??? }
>>>> }
>>>>
>>>> From Dan's evaluation at the bug entry [1]:
>>>>
>>>> Per JLS 8.4.8.3, the first method must be return-type-substitutable 
>>>> for the second. This can be satisfied in 3 ways (JLS 8.4.5):
>>>> - SimpleResult is a subtype of Response (no)
>>>> - SimpleResult can be converted to a subtype of Response by 
>>>> unchecked conversion (no)
>>>> - The methods have different signatures (yep) and SimpleResult = 
>>>> erasure(Response) (no)
>>>>
>>>> No case applies, so an error should occur. This fix syncs javac 
>>>> with the spec.
>>>>
>>>> Thanks,
>>>> Vicente
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8207224
>>>> [2] http://cr.openjdk.java.net/~vromero/8207224/webrev.00/
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181218/f4b96f23/attachment-0001.html>

From jonathan.gibbons at oracle.com  Tue Dec 18 21:20:15 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 18 Dec 2018 13:20:15 -0800
Subject: Fw: Changes to ct.sym in JDK 12
In-Reply-To: <BN6PR06MB32199245D7A4155FFA9F095687BD0@BN6PR06MB3219.namprd06.prod.outlook.com>
References: <BN6PR06MB321977B1BA73F07110A4A84887A50@BN6PR06MB3219.namprd06.prod.outlook.com>
 <BN6PR06MB3219CEA0D4DF7F4936ACDE9887A70@BN6PR06MB3219.namprd06.prod.outlook.com>
 <BN6PR06MB32199245D7A4155FFA9F095687BD0@BN6PR06MB3219.namprd06.prod.outlook.com>
Message-ID: <79b03f62-5838-d6e8-d976-6b6d1e1359a8@oracle.com>


Jay,

Check out the thread beginning here [1] from March of this year.

-- Jon

[1] 
http://mail.openjdk.java.net/pipermail/compiler-dev/2018-March/011736.html


On 12/18/2018 12:08 AM, Jayaprakash Artanareeswaran wrote:
> Thanks Jon!
>
> Can someone please point me to a document or bug where this is
> discussed or documented? I am particularly interested in knowing
> this file's structure, especially how older versions of classes
> are stored. I can gather some information by looking at the
> file's content, but would rather an official document to
> understand things better.
>
> Thanks,
> Jay
>
>
> > Jay,
> >
> > This is better discussed on compiler-dev.
>
> > It's about consistency, and better supporting the historical modular 
> > releases.
>
> -- Jon
>
> On 12/9/18 9:24 PM, Jayaprakash Artanareeswaran wrote:
> >/Hello experts, />>/I see that the ct.sym has been restructured in JDK 12. Specifically, I 
> am curious about the fact that even for non modular releases such as 7 
> and 8, I see the classes being placed inside their respective modules. />>/Is it just about consistency? Are the modules always ignored or is 
> there a scenario where the modular structure will be useful? />>/Sorry if this was discussed already, but I couldn't find much about 
> this particular change. />>/Regards, />/Jay/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181218/3ca10ee5/attachment.html>

From cushon at google.com  Tue Dec 18 23:39:15 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 18 Dec 2018 15:39:15 -0800
Subject: RFR: 8215371: Better nodes for concatenated string literals
In-Reply-To: <F27C919D-2B3D-4674-A952-D44BAAD2C757@oracle.com>
References: <CAL4QsgvD85XSyKpyL0vFzCRvpDcAcqwiz_V3pDY8XLFfsH=wjw@mail.gmail.com>
 <F27C919D-2B3D-4674-A952-D44BAAD2C757@oracle.com>
Message-ID: <CAL4QsgspOC6Hmsnm=wms1Kuq1dekK3Ru6USEGA0fecNUUPHWZg@mail.gmail.com>

On Fri, Dec 14, 2018 at 1:24 PM John Rose <john.r.rose at oracle.com> wrote:
>
> Slightly more principled solution (along one axis):  Treat string concat
> as a similar form to existing signature-polymorphic methods invokeExact,
> etc.  That treats it as a method call (rather than special control flow or
> block structure), so common method-call code would apply.

That seems like a nice option for supporting the translation
strategies we want, but is potentially less good for the 'IDE-like
tooling' use-case, where tools may not expect concat to be represented
similarly to invocations. Maybe there's room for both approaches? We
could have a higher-fidelity representation in the front-end, and then
lower through a signature-polymorphic invocation.

From cushon at google.com  Tue Dec 18 23:39:37 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 18 Dec 2018 15:39:37 -0800
Subject: RFR: 8215371: Better nodes for concatenated string literals
In-Reply-To: <c629604c-f0b0-4c6b-4d59-0e96e79009d0@oracle.com>
References: <CAL4QsgvD85XSyKpyL0vFzCRvpDcAcqwiz_V3pDY8XLFfsH=wjw@mail.gmail.com>
 <c629604c-f0b0-4c6b-4d59-0e96e79009d0@oracle.com>
Message-ID: <CAL4QsgvZYmc9U=LgLtqYqHEh38yMe+XqNEmtxF0TgvkGa+oSpw@mail.gmail.com>

> How can you tell (at parse time) whether is a string concat or not? It
> depends on the types of 'a' and 'b' - so there's a resolution process in
> the middle (not unlike what happens with method resolution). So I'm not
> sure we can pull this off (unless you rewrite the AST later in the
> pipeline, but that would defeat some of the purpose?) - it seems that,
> if you pull the string long enough, you end up in a place where perhaps
> you need to flatten _all_ the binary expression trees, which, while
> doable, starts looking as a much much bigger patch.

I don't see any good ways to do that disambiguation.

Rewriting later in the pipeline would still have some value, but
doesn't help tools that only want the syntax (e.g. code formatters),
and it would be nice to keep the representation consistent from
parsing up to lowering.

Another option would be to use the improved representation only in
cases where it's easy to identify string concatenation (e.g. one of
the components is a string literal). But that would also make the
representation less consistent.

Applying flatting to all binary expression trees doesn't necessarily
seem like a bad outcome, but it would definitely be a more invasive
change.

> Then there's the problem of evolving the c.s.s.tree API - can we switch
> to a different, non-recursive internal representation w/o touching the
> API (or providing some sensible behavior for existing methods?).

The naive update to c.s.s.tree would be to add a new Tree and
corresponding visit methods, which would have similar compatibility
implications to adding support for new language features. The change
could be tied to the language level to make it easier for users to
migrate. Is that level of breakage tolerable? There are other changes
that would increase the fidelity of the AST (like the nodes for enum
declarations discussed in JDK-8182769) that seem to require similar
breaking changes.





> Unless we are convinced that we have sound solutions for all these
> issues, I think it might be better to stick with your more pragmatic
> balancing fix in the meantime (although I'd love to aim for something
> more principled, of course).
>
> Maurizio
>
> On 14/12/2018 17:31, Liam Miller-Cushon wrote:
> > Hi,
> >
> > I've been thinking a bit about the discussion of string literals
> > in JDK-8182769, and I started a separate bug for that part:
> > https://bugs.openjdk.java.net/browse/JDK-8215371
> >
> > The issue is that long string concatenation chains are represented as
> > unbalanced binary expression trees, and it's easy to run out of stack
> > when processing those trees recursively. As a work-around, javac
> > currently supports folding concatenated string literals during
> > parsing, but that work-around reduces the fidelity of the AST and is
> > problematic for IDE-like tooling.
> >
> > A possible fix is to remove the early constant folding, and instead
> > balance the binary trees for concatentation:
> > http://cr.openjdk.java.net/~cushon/8215371/webrev.00/
> >
> > There's some discussion of the tradeoffs in the comments
> > on JDK-8182769. Other ideas include:
> >
> > * Refactoring code processing string literals to avoid recursion. This
> > removes the constraint on the shape on the AST, but might reduce
> > readability. The problem also affects non-javac users of the
> > com.sun.source APIs which we don't have the option of refactoring.
> >
> > * Introducing a new AST node to represent concatenated string literals
> > as a flat list. This would require more refactoring to javac, and an
> > addition to the com.sun.source APIs.
> >
> > What do you think? My prototype fix is kind of a work-around, but I
> > think it's a modest improvement over the status quo. If there are
> > ideas of a more principled solution I'm happy to investigate alternatives.
> >
> > Thanks,

From maurizio.cimadamore at oracle.com  Wed Dec 19 12:04:26 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 19 Dec 2018 12:04:26 +0000
Subject: RFR: 8215371: Better nodes for concatenated string literals
In-Reply-To: <CAL4QsgvZYmc9U=LgLtqYqHEh38yMe+XqNEmtxF0TgvkGa+oSpw@mail.gmail.com>
References: <CAL4QsgvD85XSyKpyL0vFzCRvpDcAcqwiz_V3pDY8XLFfsH=wjw@mail.gmail.com>
 <c629604c-f0b0-4c6b-4d59-0e96e79009d0@oracle.com>
 <CAL4QsgvZYmc9U=LgLtqYqHEh38yMe+XqNEmtxF0TgvkGa+oSpw@mail.gmail.com>
Message-ID: <ce868b9e-d306-f76e-7231-c3227ac2a725@oracle.com>

Hi Liam,
while I agree that some degree of breakage in c.s.s.t API can be 
tolerated in name of better consistency, in the light of our exchange, 
it doesn't really seem that we have a credible solution for sticking 
with a more principled approach; yes, we could swap trees at later 
stages, but this would not improve the code much, and will create 
confusion for clients of the tree API which will see different tree at 
different points of the compiler pipeline.

I'd say, let's stick with your pragmatic balancing solution (which I 
still like) and keep thinking about alternatives as a separate effort?

Maurizio

On 18/12/2018 23:39, Liam Miller-Cushon wrote:
>> How can you tell (at parse time) whether is a string concat or not? It
>> depends on the types of 'a' and 'b' - so there's a resolution process in
>> the middle (not unlike what happens with method resolution). So I'm not
>> sure we can pull this off (unless you rewrite the AST later in the
>> pipeline, but that would defeat some of the purpose?) - it seems that,
>> if you pull the string long enough, you end up in a place where perhaps
>> you need to flatten _all_ the binary expression trees, which, while
>> doable, starts looking as a much much bigger patch.
> I don't see any good ways to do that disambiguation.
>
> Rewriting later in the pipeline would still have some value, but
> doesn't help tools that only want the syntax (e.g. code formatters),
> and it would be nice to keep the representation consistent from
> parsing up to lowering.
>
> Another option would be to use the improved representation only in
> cases where it's easy to identify string concatenation (e.g. one of
> the components is a string literal). But that would also make the
> representation less consistent.
>
> Applying flatting to all binary expression trees doesn't necessarily
> seem like a bad outcome, but it would definitely be a more invasive
> change.
>
>> Then there's the problem of evolving the c.s.s.tree API - can we switch
>> to a different, non-recursive internal representation w/o touching the
>> API (or providing some sensible behavior for existing methods?).
> The naive update to c.s.s.tree would be to add a new Tree and
> corresponding visit methods, which would have similar compatibility
> implications to adding support for new language features. The change
> could be tied to the language level to make it easier for users to
> migrate. Is that level of breakage tolerable? There are other changes
> that would increase the fidelity of the AST (like the nodes for enum
> declarations discussed in JDK-8182769) that seem to require similar
> breaking changes.
>
>
>
>
>
>> Unless we are convinced that we have sound solutions for all these
>> issues, I think it might be better to stick with your more pragmatic
>> balancing fix in the meantime (although I'd love to aim for something
>> more principled, of course).
>>
>> Maurizio
>>
>> On 14/12/2018 17:31, Liam Miller-Cushon wrote:
>>> Hi,
>>>
>>> I've been thinking a bit about the discussion of string literals
>>> in JDK-8182769, and I started a separate bug for that part:
>>> https://bugs.openjdk.java.net/browse/JDK-8215371
>>>
>>> The issue is that long string concatenation chains are represented as
>>> unbalanced binary expression trees, and it's easy to run out of stack
>>> when processing those trees recursively. As a work-around, javac
>>> currently supports folding concatenated string literals during
>>> parsing, but that work-around reduces the fidelity of the AST and is
>>> problematic for IDE-like tooling.
>>>
>>> A possible fix is to remove the early constant folding, and instead
>>> balance the binary trees for concatentation:
>>> http://cr.openjdk.java.net/~cushon/8215371/webrev.00/
>>>
>>> There's some discussion of the tradeoffs in the comments
>>> on JDK-8182769. Other ideas include:
>>>
>>> * Refactoring code processing string literals to avoid recursion. This
>>> removes the constraint on the shape on the AST, but might reduce
>>> readability. The problem also affects non-javac users of the
>>> com.sun.source APIs which we don't have the option of refactoring.
>>>
>>> * Introducing a new AST node to represent concatenated string literals
>>> as a flat list. This would require more refactoring to javac, and an
>>> addition to the com.sun.source APIs.
>>>
>>> What do you think? My prototype fix is kind of a work-around, but I
>>> think it's a modest improvement over the status quo. If there are
>>> ideas of a more principled solution I'm happy to investigate alternatives.
>>>
>>> Thanks,

From bsrbnd at gmail.com  Wed Dec 19 13:28:35 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Wed, 19 Dec 2018 14:28:35 +0100
Subject: RFR JDK-8214700: Compilation fails when extend and implement same
 method signature with generics
Message-ID: <CAEgw74B6TpBBUg90nGohzVbdQNt+xeLsLZ+GLqNaCEi1+=OaRw@mail.gmail.com>

Hi,

The fix for JDK-8207224 being now integrated, please review the
following fix for [1]:

http://cr.openjdk.java.net/~bsrbnd/jdk8214700/webrev.00/

which simply checks that return types are substitutable per JLS ?8.4.5
in both direct and inherited implementation.

Thanks (tier1 is OK),
Bernard

[1] https://bugs.openjdk.java.net/browse/JDK-8214700

From vicente.romero at oracle.com  Wed Dec 19 14:06:45 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 19 Dec 2018 09:06:45 -0500
Subject: RFR JDK-8214700: Compilation fails when extend and implement same
 method signature with generics
In-Reply-To: <CAEgw74B6TpBBUg90nGohzVbdQNt+xeLsLZ+GLqNaCEi1+=OaRw@mail.gmail.com>
References: <CAEgw74B6TpBBUg90nGohzVbdQNt+xeLsLZ+GLqNaCEi1+=OaRw@mail.gmail.com>
Message-ID: <3efb397a-2bec-d603-c1d1-e520be5841e8@oracle.com>

unfortunately the fix for JDK-8207224 has provoked several tests to 
fail. I could be that we will need to delta apply it,

Vicente


On 12/19/18 8:28 AM, B. Blaser wrote:
> Hi,
>
> The fix for JDK-8207224 being now integrated, please review the
> following fix for [1]:
>
> http://cr.openjdk.java.net/~bsrbnd/jdk8214700/webrev.00/
>
> which simply checks that return types are substitutable per JLS ?8.4.5
> in both direct and inherited implementation.
>
> Thanks (tier1 is OK),
> Bernard
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8214700


From bsrbnd at gmail.com  Wed Dec 19 14:46:25 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Wed, 19 Dec 2018 15:46:25 +0100
Subject: RFR JDK-8214700: Compilation fails when extend and implement same
 method signature with generics
In-Reply-To: <3efb397a-2bec-d603-c1d1-e520be5841e8@oracle.com>
References: <CAEgw74B6TpBBUg90nGohzVbdQNt+xeLsLZ+GLqNaCEi1+=OaRw@mail.gmail.com>
 <3efb397a-2bec-d603-c1d1-e520be5841e8@oracle.com>
Message-ID: <CAEgw74CatM0Ggg01=e_yBmFb-gzdsyRJsudtyHC+2kWJdAyQbw@mail.gmail.com>

Note that this fix works independently from JDK-8207224 and should be
applied as the current behavior for the inherited implementation of an
erased signature isn't orthogonal to the behavior for the direct
implementation.
Reverting the fix for JDK-8207224 would only remove some side-effects
in some marginal cases (see my JBS comment), as expected?

Shouldn't we go ahead with this one independently from JDK-8207224?

Bernard


On Wed, 19 Dec 2018 at 15:06, Vicente Romero <vicente.romero at oracle.com> wrote:
>
> unfortunately the fix for JDK-8207224 has provoked several tests to
> fail. I could be that we will need to delta apply it,
>
> Vicente
>
>
> On 12/19/18 8:28 AM, B. Blaser wrote:
> > Hi,
> >
> > The fix for JDK-8207224 being now integrated, please review the
> > following fix for [1]:
> >
> > http://cr.openjdk.java.net/~bsrbnd/jdk8214700/webrev.00/
> >
> > which simply checks that return types are substitutable per JLS ?8.4.5
> > in both direct and inherited implementation.
> >
> > Thanks (tier1 is OK),
> > Bernard
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8214700
>

From maurizio.cimadamore at oracle.com  Wed Dec 19 14:57:42 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 19 Dec 2018 14:57:42 +0000
Subject: RFR JDK-8214700: Compilation fails when extend and implement same
 method signature with generics
In-Reply-To: <CAEgw74CatM0Ggg01=e_yBmFb-gzdsyRJsudtyHC+2kWJdAyQbw@mail.gmail.com>
References: <CAEgw74B6TpBBUg90nGohzVbdQNt+xeLsLZ+GLqNaCEi1+=OaRw@mail.gmail.com>
 <3efb397a-2bec-d603-c1d1-e520be5841e8@oracle.com>
 <CAEgw74CatM0Ggg01=e_yBmFb-gzdsyRJsudtyHC+2kWJdAyQbw@mail.gmail.com>
Message-ID: <06cf6e66-100d-2d00-5f8f-e3f3cc6b39c8@oracle.com>

I think it's better to leave this alone for the time being, until we 
have a clearer idea of what went wrong with 8207224; while the two fixes 
are mostly orthogonal, we don't want to introduce many type-system 
changes in related areas at the same time (esp. when there are failing 
tests), as that will make it very hard to troubleshoot problems.

Thanks
Maurizio

On 19/12/2018 14:46, B. Blaser wrote:
> Note that this fix works independently from JDK-8207224 and should be
> applied as the current behavior for the inherited implementation of an
> erased signature isn't orthogonal to the behavior for the direct
> implementation.
> Reverting the fix for JDK-8207224 would only remove some side-effects
> in some marginal cases (see my JBS comment), as expected?
>
> Shouldn't we go ahead with this one independently from JDK-8207224?
>
> Bernard
>
>
> On Wed, 19 Dec 2018 at 15:06, Vicente Romero <vicente.romero at oracle.com> wrote:
>> unfortunately the fix for JDK-8207224 has provoked several tests to
>> fail. I could be that we will need to delta apply it,
>>
>> Vicente
>>
>>
>> On 12/19/18 8:28 AM, B. Blaser wrote:
>>> Hi,
>>>
>>> The fix for JDK-8207224 being now integrated, please review the
>>> following fix for [1]:
>>>
>>> http://cr.openjdk.java.net/~bsrbnd/jdk8214700/webrev.00/
>>>
>>> which simply checks that return types are substitutable per JLS ?8.4.5
>>> in both direct and inherited implementation.
>>>
>>> Thanks (tier1 is OK),
>>> Bernard
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8214700

From cushon at google.com  Wed Dec 19 18:56:42 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 19 Dec 2018 10:56:42 -0800
Subject: RFR: 8215371: Better nodes for concatenated string literals
In-Reply-To: <ce868b9e-d306-f76e-7231-c3227ac2a725@oracle.com>
References: <CAL4QsgvD85XSyKpyL0vFzCRvpDcAcqwiz_V3pDY8XLFfsH=wjw@mail.gmail.com>
 <c629604c-f0b0-4c6b-4d59-0e96e79009d0@oracle.com>
 <CAL4QsgvZYmc9U=LgLtqYqHEh38yMe+XqNEmtxF0TgvkGa+oSpw@mail.gmail.com>
 <ce868b9e-d306-f76e-7231-c3227ac2a725@oracle.com>
Message-ID: <CAL4QsgsbYzA8sHp2rKtMneS1g+eVKGy1GnfidZSnBF+kDPi2OQ@mail.gmail.com>

> I'd say, let's stick with your pragmatic balancing solution (which I
> still like) and keep thinking about alternatives as a separate effort?

That sounds good to me. I agree that tree balancing seems to have the
fewest downsides, and doesn't close the door or any of the
alternatives.

From jonathan.gibbons at oracle.com  Wed Dec 19 22:05:54 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 19 Dec 2018 14:05:54 -0800
Subject: RFR: 8208184 : IllegalArgumentException while invoking code
 completion on netbeans IDE
In-Reply-To: <385d6090-c94a-afe6-dc07-de39a240f28f@oracle.com>
References: <385d6090-c94a-afe6-dc07-de39a240f28f@oracle.com>
Message-ID: <c133572b-4ad8-06be-186a-94d1d58be610@oracle.com>

Looks OK to me.

-- Jon

On 12/7/18 6:27 AM, srinivas wrote:
> Hi,
>
> Please review,
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8208184
>
> webrev: http://cr.openjdk.java.net/~sdama/8208184/webrev.01/
>
> Regards,
>
> Srinivas
>

From james.laskey at oracle.com  Thu Dec 20 13:20:25 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 20 Dec 2018 09:20:25 -0400
Subject: RFR - JDK-8215681 Remove compiler support for Raw String Literals
 from JDK 12
Message-ID: <1768A8D0-A8DE-477D-910A-1902E5D92F97@oracle.com>

With the withdrawal of JEP 326: Raw String Literals (Preview) from JDK 12, code introduced into javac to support the specification must be removed.

webrev: http://cr.openjdk.java.net/~jlaskey/8215681/webrev/index.html <http://cr.openjdk.java.net/~jlaskey/8215681/webrev/index.html>
JBS: https://bugs.openjdk.java.net/browse/JDK-8215681 <https://bugs.openjdk.java.net/browse/JDK-8215681>

Thank you.

Cheers,

? Jim

CSR: https://bugs.openjdk.java.net/browse/JDK-8215682 <https://bugs.openjdk.java.net/browse/JDK-8215682>


 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181220/c2d3ce17/attachment.html>

From maurizio.cimadamore at oracle.com  Thu Dec 20 21:03:51 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 20 Dec 2018 21:03:51 +0000
Subject: RFR - JDK-8215681 Remove compiler support for Raw String Literals
 from JDK 12
In-Reply-To: <1768A8D0-A8DE-477D-910A-1902E5D92F97@oracle.com>
References: <1768A8D0-A8DE-477D-910A-1902E5D92F97@oracle.com>
Message-ID: <05a14d06-2418-fa4c-998d-53d1d3bb1d26@oracle.com>

It's already hinted in the webrev - but just for the records - I 
approved this :-)

Maurizio

On 20/12/2018 13:20, Jim Laskey wrote:
> With the withdrawal of JEP 326: Raw String Literals (Preview) from JDK 
> 12, code introduced into javac to support the specification must be 
> removed.
>
> webrev: http://cr.openjdk.java.net/~jlaskey/8215681/webrev/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8215681
>
> Thank you.
>
> Cheers,
>
> ? Jim
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8215682
>
>

From bsrbnd at gmail.com  Fri Dec 21 12:28:28 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Fri, 21 Dec 2018 13:28:28 +0100
Subject: RFR JDK-8208470: Type annotations on inner type that is an array
 component
In-Reply-To: <CAL4QsgvTUs3DQTdu3z5Yi=YGx5gwgvaCHOymzcG_SW-t7yZrFQ@mail.gmail.com>
References: <CAEgw74DrgaXekYoj58dSJpfe2HnU1iD_V89b2gqKrUeviT4oVw@mail.gmail.com>
 <CAEgw74BtYQAT0gupY7xbgbzroNsYnFbMX_OAXqNB+eYm-tK_1A@mail.gmail.com>
 <CAEgw74B5UO8n_ygDp_Z3U8ZmmZE8AUT9q8YqFO1V8Or0fHRZNQ@mail.gmail.com>
 <CAL4Qsgsm+RmTe3QzXhdqS3QD0rkvW=FEhErYU2ZbMRkqP5siKw@mail.gmail.com>
 <CAEgw74B1NksTx4GGuC0WgAwb5iVJMs3HoLDF0KKxTNDr0qyidg@mail.gmail.com>
 <CAL4QsgvTUs3DQTdu3z5Yi=YGx5gwgvaCHOymzcG_SW-t7yZrFQ@mail.gmail.com>
Message-ID: <CAEgw74Aa9uQ7vpnBpEVLjpRguN5odXLT8wKDpt2nUMOuNJubJg@mail.gmail.com>

On Thu, 13 Dec 2018 at 19:37, Liam Miller-Cushon <cushon at google.com> wrote:
>
> On Thu, Dec 13, 2018 at 6:17 AM B. Blaser <bsrbnd at gmail.com> wrote:
>>
>> If we want to clean up this part, I suggest to address this in a separate issue?
>
> I filed https://bugs.openjdk.java.net/browse/JDK-8215366 to look at that part separately.

I re-based the fix on JDK-8215366, removed the assertion from
'arrayTypeTree' as you suggested earlier and returned the 'elemtype'
directly as Werner suggested in [1]:

http://cr.openjdk.java.net/~bsrbnd/jdk8208470/webrev.01/

Does this look good (tier1 is still OK)?

Thanks,
Bernard

[1] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012262.html

From cushon at google.com  Fri Dec 21 16:50:51 2018
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 21 Dec 2018 08:50:51 -0800
Subject: RFR JDK-8208470: Type annotations on inner type that is an array
 component
In-Reply-To: <CAEgw74Aa9uQ7vpnBpEVLjpRguN5odXLT8wKDpt2nUMOuNJubJg@mail.gmail.com>
References: <CAEgw74DrgaXekYoj58dSJpfe2HnU1iD_V89b2gqKrUeviT4oVw@mail.gmail.com>
 <CAEgw74BtYQAT0gupY7xbgbzroNsYnFbMX_OAXqNB+eYm-tK_1A@mail.gmail.com>
 <CAEgw74B5UO8n_ygDp_Z3U8ZmmZE8AUT9q8YqFO1V8Or0fHRZNQ@mail.gmail.com>
 <CAL4Qsgsm+RmTe3QzXhdqS3QD0rkvW=FEhErYU2ZbMRkqP5siKw@mail.gmail.com>
 <CAEgw74B1NksTx4GGuC0WgAwb5iVJMs3HoLDF0KKxTNDr0qyidg@mail.gmail.com>
 <CAL4QsgvTUs3DQTdu3z5Yi=YGx5gwgvaCHOymzcG_SW-t7yZrFQ@mail.gmail.com>
 <CAEgw74Aa9uQ7vpnBpEVLjpRguN5odXLT8wKDpt2nUMOuNJubJg@mail.gmail.com>
Message-ID: <CAL4QsgsEAvrcWWhY2P0pFBdqwBNw5+=bncb6v4jSJGXpMCrV8A@mail.gmail.com>

It looks good to me. Thanks Bernard.

On Fri, Dec 21, 2018 at 4:28 AM B. Blaser <bsrbnd at gmail.com> wrote:

> On Thu, 13 Dec 2018 at 19:37, Liam Miller-Cushon <cushon at google.com>
> wrote:
> >
> > On Thu, Dec 13, 2018 at 6:17 AM B. Blaser <bsrbnd at gmail.com> wrote:
> >>
> >> If we want to clean up this part, I suggest to address this in a
> separate issue?
> >
> > I filed https://bugs.openjdk.java.net/browse/JDK-8215366 to look at
> that part separately.
>
> I re-based the fix on JDK-8215366, removed the assertion from
> 'arrayTypeTree' as you suggested earlier and returned the 'elemtype'
> directly as Werner suggested in [1]:
>
> http://cr.openjdk.java.net/~bsrbnd/jdk8208470/webrev.01/
>
> Does this look good (tier1 is still OK)?
>
> Thanks,
> Bernard
>
> [1]
> http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012262.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181221/521af25c/attachment.html>

From ronshapiro at google.com  Mon Dec 31 16:09:21 2018
From: ronshapiro at google.com (Ron Shapiro)
Date: Mon, 31 Dec 2018 11:09:21 -0500
Subject: Name.contentEquals() performance
In-Reply-To: <5BBEA4E8.7080609@oracle.com>
References: <CACA6h9to7szM0dSpOjUhLWFWTUEHCvRNFhS_x+TgeesS6qYC_w@mail.gmail.com>
 <4617a955-de22-f5d3-d9af-ed8e0dc2eb40@oracle.com>
 <5693ec10-55f3-6f5a-d6bb-d811df1faeaf@oracle.com>
 <5BB50F15.6030701@oracle.com> <5BBEA4E8.7080609@oracle.com>
Message-ID: <CACA6h9vK3J4_F5AOxyLWkD6jOF5FuRUJG-4ULafd5P1ieziYng@mail.gmail.com>

Jon - in reference to your comment about the use of contentEquals - I'm for
the most part seeing this in code that lives outside of javac (annotation
processors & ErrorProne checks), where we are only aware of
javax.lang.model.element.Name, so no contract around interned-ness. In many
cases, we're checking the contents against a string constant (or a
Class.getName() call).

If the intention is to create an interned string, maybe it should store the
string directly instead of the utf bytes?

On Wed, Oct 10, 2018 at 9:18 PM Joseph D. Darcy <joe.darcy at oracle.com>
wrote:

> Is String creation for other types done as a guard against possible
> concurrent modification?
>
> -Joe
>
> On 10/3/2018 11:48 AM, Jonathan Gibbons wrote:
> > It is very depressing that Name.contentEquals actually creates
> > strings. I would have expected it to iterate over the code points of
> > the items being compared.
> >
> > It is also somewhat depressing that .contentEquals is being used so
> > much, because the intent of the Name class is to function as an
> > interned string.
> >
> > -- Jon
> >
> > On 10/03/2018 06:22 AM, Maurizio Cimadamore wrote:
> >>
> >>
> >> On 03/10/18 14:16, Maurizio Cimadamore wrote:
> >>> (That said, out of curiosity I tried to instrument the JDK build to
> >>> see how many names were created (this is a bit hard given that the
> >>> build internally reuses java compilers using the sjavac server), but
> >>> name creation seem to peak at around 33K, which would give an
> >>> overhead of a couple of hundred of kB for an extra field like the
> >>> one you suggest, which doesn't seem excessive in terms of footprint
> >>> increase)
> >> Actually, now that I think more, if you store the toString() result
> >> in an extra field, while the footprint of the Name class (shallow
> >> size) won't change much (8 more bytes per instance), we could
> >> potentially be talking about 33K more (in the JDK build case) strings
> >> be retained by the javac code - which is probably going to balloon up
> >> the memory footprint cost significantly.
> >>
> >> Maurizio
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181231/5bacfeb1/attachment.html>