From amaembo at gmail.com  Fri Feb  1 04:54:08 2019
From: amaembo at gmail.com (Tagir Valeev)
Date: Fri, 1 Feb 2019 11:54:08 +0700
Subject: Qualified class name inside qualified instance creation expression
In-Reply-To: <5C53706A.8090203@oracle.com>
References: <CAE+3fjbTjWNkp81Oc+2mtjQRUEJqBBKFCEJciiFkXEbMJZEO8w@mail.gmail.com>
 <5C53706A.8090203@oracle.com>
Message-ID: <CAE+3fjbTM5NhZYr8wMk0PQyBs-RAwEzQjAM0HWok=qXvuk4auw@mail.gmail.com>

Hello, Alex! Thank you for your answer.

> Correct. There has been shimmer in this part of the language. In Java SE
> 7, `this.new Test.Inner()` was illegal; only `this.new SIMPLENAME()` was
> allowed. (See
> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.9)
> In Java SE 8, the grammar of `ClassInstanceCreationExpression` was
> modified to support type annotations, and `this.new QUALIFIEDNAME()` was
> allowed. In principle, there is no reason to disallow a qualified name
> in a qualified CICE. The phrase `new Test.Inner()` is meaningful as an
> unqualified CICE, and enriching the phrase to be a qualified CICE, with
> an explicit immediately enclosing instance, doesn't make it
> unmeaningful. I suspect javac is still expecting (modulo type arguments)
> a simple name after `new`.

Thank you for Java 7 pointer, I wasn't aware that this part was changed.

In our IDE we don't highlight such code as erroneous, and people complain
that it's our problem, because javac rejects it. Seems we have to mimic javac
behavior even if it violates the spec.

With best regards,
Tagir Valeev.

From GROEGES at uk.ibm.com  Fri Feb  1 12:46:01 2019
From: GROEGES at uk.ibm.com (Steve Groeger)
Date: Fri, 1 Feb 2019 12:46:01 +0000
Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation
 processor is on the classpath
In-Reply-To: <c6f78065-0cb2-c4ea-8d31-bd5b0a1cc379@oracle.com>
References: <OFF593C632.E3B4428B-ON80258391.003BB8A6-80258391.003E18A6@notes.na.collabserv.com>
 <c1cf308a-86d6-1222-9244-54c2fa45d8b9@oracle.com>
 <OFEE1EB4EE.D5ADB174-ON80258393.005BD593-80258393.005C6191@notes.na.collabserv.com>
 <c6f78065-0cb2-c4ea-8d31-bd5b0a1cc379@oracle.com>
Message-ID: <OF7F83CFD9.F0F7295C-ON80258394.0045435B-80258394.004621E7@notes.na.collabserv.com>

Hi all, 

I have made some changes to the code for issue [1] for both jdk8u and jdk 
(jdk13)
The latest webrevs have a few extra changes suggested by  Jonathan Gibbons 
mentioned in an earlier mailing [2]
The webrevs are for jdk8u [3] and for jdk [4].
Please could someone review these changes and let me know if there are any 
issues.

[1] https://bugs.openjdk.java.net/browse/JDK-8218152
[2] 
https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012920.html
[3] http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.01/
[4] http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.01/

Thanks
Steve Groeger
IBM Runtime Technologies
Hursley, Winchester
Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
Fax (44) 1962 816800
Lotus Notes: Steve Groeger/UK/IBM
Internet: groeges at uk.ibm.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



From:   Jonathan Gibbons <jonathan.gibbons at oracle.com>
To:     Steve Groeger <GROEGES at uk.ibm.com>
Cc:     compiler-dev at openjdk.java.net
Date:   31/01/2019 16:56
Subject:        Re: [NEW_BUG] javac fails and exits with no error if a bad 
annotation processor is on the classpath



Steve,
When you post the new webrevs, can I suggest that you change the Subject 
line of this thread to something like 
RFR: 8218152 [javac] fails and exits with no error if a bad annotation 
processor provided
That will help get attention from reviewers, and help any subsequent 
bug-archaeology.
I can sponsor the changes for you once they have been reviewed.
-- Jon
On 1/31/19 8:49 AM, Steve Groeger wrote:
Hi Jonathan, 

Thanks for responding. 

I have created a couple of webrevs for jdk8u [1] and jdk [2] which also 
include some JTReg tests. 
I would be grateful if you, or someone else could review these just to 
ensure I am doing the right thing. 
I will update the code with the additional 'throw FatalError' that you 
mentioned and will then create some new webrevs 

If you are able to sponsor these changes for me I would be very grateful. 

PS. As you saw I have created a JBS issue for this here [3] 

[1] http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.00/ 
[2] http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.00/ 
[3https://bugs.openjdk.java.net/browse/JDK-8218152 

Thanks
Steve Groeger
IBM Runtime Technologies
Hursley, Winchester
Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
Fax (44) 1962 816800
Lotus Notes: Steve Groeger/UK/IBM
Internet: groeges at uk.ibm.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 




From:        Jonathan Gibbons <jonathan.gibbons at oracle.com> 
To:        Steve Groeger <GROEGES at uk.ibm.com>, 
compiler-dev at openjdk.java.net 
Date:        31/01/2019 16:33 
Subject:        Re: [NEW_BUG] javac fails and exits with no error if a bad 
annotation processor is on the classpath 



Steve, 
Your fix is generally good: Abort should only be used after a suitable 
message has been reported. 
There's a `catch (Throwable t)` in the same set of catch blocks that you 
did not update. Rather than add yet another message for that case, it 
might be better to throw FatalError, to provoke the standard "javac crash" 
output for the unknown exception. 
You should provide a test case ... i.e. as a jtreg test. 
-- Jon 
On 1/29/19 3:18 AM, Steve Groeger wrote: 
Hi all, 

I have identified a potential issue where javac fails and exits with no 
error if a bad annotation processor is on the classpath. 

Background: an Annotation Processor class can be packaged in a jar file 
and is identified by a special text file inside the jar named: 
META-INF/services/javax.annotation.processing.Processor. This text file 
has only one line, specifying the class name of the annotation process 
class to run. When javac runs, it checks all jars on the classpath and if 
it finds the special text file in any jar file, then it attempts to run 
the class listed there. 

The issue here is that when the annotation processor class can't be 
executed, javac catches the exception and exits without reporting on the 
reason for the exit. Examples of reasons why the annotation processor 
can't be executed include: 
the annotation processor class is compiled for a higher version of Java 
than the javac is running, giving UnsupportedClassVersionError. 
the annotation processor class file is corrupt so can't be loaded.

In either of the above cases javac will swallow the error and exit without 
telling the user why it failed to compile the java source code as 
expected. 

Testcase 
   put HelloWorld.java in current directory, edit <path_to_jar> and run: 
         javac -cp .:<path_to_jar>/bad.annotation.processor.jar 
HelloWorld.java 

Instead of producing HelloWorld.class as expected, javac exits silently. 

Here, bad.annotation.processor.jar is a file that I created to contain: 
      META-INF/services/javax.annotation.processing.Processor <<-- text 
file to list bad class
     bad/notaclass.class <<-- dummy file, can't be loaded as a java class 

Does anyone know whether this is a bug and that this should throw an error 
in these cases? 
If so, I will raise a bug for this. 

I have looked at the code and seen where javac Aborts the processing, and 
if I make the following changes the javac detects the issue and reports an 
error before Aborting. 

diff -r 5178e4b58b17 
src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
--- 
a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java   
   Mon Jan 28 09:56:00 2019 +0100 
+++ 
b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java   
   Tue Jan 29 11:14:57 2019 +0000 
@@ -1,5 +1,5 @@ 
 /* 
- * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights 
reserved. 
+ * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights 
reserved. 
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 
  * 
  * This code is free software; you can redistribute it and/or modify it 
@@ -436,6 +436,12 @@ 
             } catch(ServiceConfigurationError sce) { 
                
 log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); 
                 throw new Abort(sce); 
+            } catch (UnsupportedClassVersionError ucve) { 
+               
 log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage())); 
+                throw new Abort(ucve); 
+            } catch (ClassFormatError cfe) { 
+               
 log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage())); 
+                throw new Abort(cfe); 
             } catch (Throwable t) { 
                 throw new Abort(t); 
             } 

and to add a new message there is this change 

diff -r 5178e4b58b17 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
--- 
a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties   
   Mon Jan 28 09:56:00 2019 +0100 
+++ 
b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties   
   Tue Jan 29 11:16:03 2019 +0000 
@@ -1,5 +1,5 @@ 
 # 
-# Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights 
reserved. 
+# Copyright (c) 1999, 2019, Oracle and/or its affiliates. All rights 
reserved. 
 # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 
 # 
 # This code is free software; you can redistribute it and/or modify it 
@@ -1051,6 +1051,10 @@ 
 compiler.err.proc.cant.find.class=\ 
     Could not find class file for ''{0}''. 

+# 0: string 
+compiler.err.proc.cant.load.class=\ 
+    Could not load processor class file due to ''{0}''. 
+ 
 # Print a client-generated error message; assumed to be localized, no 
translation required 
 # 0: string 
 compiler.err.proc.messager=\ 


If this is deemed a bug and the change seems OK, please could someone 
sponsor this for me and I will create a proper webrev for the change for a 
full review. 

Thanks
Steve Groeger
IBM Runtime Technologies
Hursley, Winchester
Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
Fax (44) 1962 816800
Lotus Notes: Steve Groeger/UK/IBM
Internet: groeges at uk.ibm.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190201/65a1152a/attachment-0001.html>

From bsrbnd at gmail.com  Fri Feb  1 15:00:08 2019
From: bsrbnd at gmail.com (B. Blaser)
Date: Fri, 1 Feb 2019 16:00:08 +0100
Subject: Qualified class name inside qualified instance creation expression
In-Reply-To: <5C53706A.8090203@oracle.com>
References: <CAE+3fjbTjWNkp81Oc+2mtjQRUEJqBBKFCEJciiFkXEbMJZEO8w@mail.gmail.com>
 <5C53706A.8090203@oracle.com>
Message-ID: <CAEgw74DtKH4r5hx61=wTJVxfff1E0aeAgiL-4-q5zi6Drb2TCA@mail.gmail.com>

Hi,

On Thu, 31 Jan 2019 at 23:05, Alex Buckley <alex.buckley at oracle.com> wrote:
>
> On 1/31/2019 3:33 AM, Tagir Valeev wrote:
> > Consider the following code:
> >
> > class Test {
> >      class Inner {}
> >
> >      void test() {
> >          new Test.Inner(); // compiles successfully
> >          this.new Test.Inner(); // error
> >      }
> > }
>
> Both the unqualified class instance creation expression and the
> qualified class instance creation expression should compile. Each has
> `this` as the immediately enclosing instance.
>
> > javac reports:
> > Test.java:6: error: '(' expected
> >          this.new Test.Inner();
> >                       ^
> > 1 error
> >
> > I read JLS 15.9 [1]:
> > ClassInstanceCreationExpression:
> >      UnqualifiedClassInstanceCreationExpression
> >      ExpressionName . UnqualifiedClassInstanceCreationExpression
> >      Primary . UnqualifiedClassInstanceCreationExpression
> > UnqualifiedClassInstanceCreationExpression:
> >      new [TypeArguments] ClassOrInterfaceTypeToInstantiate (
> > [ArgumentList] ) [ClassBody]
> > ClassOrInterfaceTypeToInstantiate:
> >      {Annotation} Identifier {. {Annotation} Identifier} [TypeArgumentsOrDiamond]
> >
> > Thus this.new Test.Inner() could be parsed as Primary .
> > UnqualifiedClassInstanceCreationExpression where
> > ClassOrInterfaceTypeToInstantiate could be parsed as Identifier .
> > Identifier, so there should not be parse error.
>
> Correct. There has been shimmer in this part of the language. In Java SE
> 7, `this.new Test.Inner()` was illegal; only `this.new SIMPLENAME()` was
> allowed. (See
> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.9)
> In Java SE 8, the grammar of `ClassInstanceCreationExpression` was
> modified to support type annotations, and `this.new QUALIFIEDNAME()` was
> allowed. In principle, there is no reason to disallow a qualified name
> in a qualified CICE. The phrase `new Test.Inner()` is meaningful as an
> unqualified CICE, and enriching the phrase to be a qualified CICE, with
> an explicit immediately enclosing instance, doesn't make it
> unmeaningful. I suspect javac is still expecting (modulo type arguments)
> a simple name after `new`.

Right, I note that the parser doesn't conform to the current JLS grammar:

http://hg.openjdk.java.net/jdk/jdk/file/c53a3355dbb4/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java#l2272

InnerCreator = [Annotations] Ident [TypeArguments] ClassCreatorRest

It seems 'InnerCreator' is missing '{. [Annotations] Ident}'.
Is there any open JBS issue for this?

I tried a quick fix, here under, in 'JavacParser' and 'Attr' which
solve the problem; any feedback is welcome.
Langtools:tier1 is OK but I'm not sure all is right with type
annotations, etc...
I might dig a bit more and send out a RFR soon but please let me know
the priority of this before investing too much time now?

Thanks,
Bernard


diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
@@ -2311,7 +2311,9 @@
             // TODO 308: in <expr>.new C, do we also want to add the
type annotations
             // from expr to the combined type, or not? Yes, do this.
             clazzid1 = make.at(clazz.pos).Select(make.Type(encltype),
-                                                 ((JCIdent) clazzid).name);
+                    clazzid.hasTag(SELECT) ?
+                    ((JCFieldAccess) clazzid).name :
+                    ((JCIdent) clazzid).name);

             EndPosTable endPosTable = this.env.toplevel.endPositions;
             endPosTable.storeEnd(clazzid1, tree.getEndPosition(endPosTable));
@@ -2351,7 +2353,16 @@

         clazztype = chk.checkDiamond(tree, clazztype);
         chk.validate(clazz, localEnv);
-        if (tree.encl != null) {
+        if (tree.encl != null && clazzid.hasTag(SELECT)) {
+            try {
+                Type qualified = attribType(tree.clazz, env);
+                if (!types.isSameType(clazztype, qualified))
+                    log.error(tree.pos(),
Errors.IncomparableTypes(clazztype, qualified));
+            } finally {
+                env.info.isNewClass = false;
+            }
+        }
+        else if (tree.encl != null) {
             // We have to work in this case to store
             // symbol + type back into the attributed tree.
             tree.clazz.type = clazztype;
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1999, 2019, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -2269,7 +2269,7 @@
         }
     }

-    /** InnerCreator = [Annotations] Ident [TypeArguments] ClassCreatorRest
+    /** InnerCreator = [Annotations] Ident {. [Annotations] Ident}
[TypeArguments] ClassCreatorRest
      */
     JCExpression innerCreator(int newpos, List<JCExpression>
typeArgs, JCExpression encl) {
         List<JCAnnotation> newAnnotations = typeAnnotationsOpt();
@@ -2280,6 +2280,15 @@
             t =
toP(F.at(newAnnotations.head.pos).AnnotatedType(newAnnotations, t));
         }

+        while (token.kind == DOT) {
+            nextToken();
+            newAnnotations = typeAnnotationsOpt();
+            t = toP(F.at(token.pos).Select(t, ident()));
+            if (newAnnotations.nonEmpty()) {
+                t =
toP(F.at(newAnnotations.head.pos).AnnotatedType(newAnnotations, t));
+            }
+        }
+
         if (token.kind == LT) {
             int oldmode = mode;
             t = typeArguments(t, true);
diff --git a/test/langtools/tools/javac/QualifiedAccess/QualifiedAccess_4.out
b/test/langtools/tools/javac/QualifiedAccess/QualifiedAccess_4.out
--- a/test/langtools/tools/javac/QualifiedAccess/QualifiedAccess_4.out
+++ b/test/langtools/tools/javac/QualifiedAccess/QualifiedAccess_4.out
@@ -1,2 +1,2 @@
-QualifiedAccess_4.java:17:28: compiler.err.expected: '('
+QualifiedAccess_4.java:17:19: compiler.err.cant.resolve.location:
kindname.variable, x, , , (compiler.misc.location: kindname.class,
CMain, null)
 1 error

From amaembo at gmail.com  Fri Feb  1 15:09:24 2019
From: amaembo at gmail.com (Tagir Valeev)
Date: Fri, 1 Feb 2019 22:09:24 +0700
Subject: Qualified class name inside qualified instance creation expression
In-Reply-To: <CAEgw74DtKH4r5hx61=wTJVxfff1E0aeAgiL-4-q5zi6Drb2TCA@mail.gmail.com>
References: <CAE+3fjbTjWNkp81Oc+2mtjQRUEJqBBKFCEJciiFkXEbMJZEO8w@mail.gmail.com>
 <5C53706A.8090203@oracle.com>
 <CAEgw74DtKH4r5hx61=wTJVxfff1E0aeAgiL-4-q5zi6Drb2TCA@mail.gmail.com>
Message-ID: <CAE+3fjafYwrJzsM951uNcSyH_-=dngckpeH7ndkgzv+R4BUwxw@mail.gmail.com>

Hello!

I filed an issue:
https://bugs.openjdk.java.net/browse/JDK-8218194
Thank you for looking into this.

With best regards,
Tagir Valeev

On Fri, Feb 1, 2019 at 10:01 PM B. Blaser <bsrbnd at gmail.com> wrote:
>
> Hi,
>
> On Thu, 31 Jan 2019 at 23:05, Alex Buckley <alex.buckley at oracle.com> wrote:
> >
> > On 1/31/2019 3:33 AM, Tagir Valeev wrote:
> > > Consider the following code:
> > >
> > > class Test {
> > >      class Inner {}
> > >
> > >      void test() {
> > >          new Test.Inner(); // compiles successfully
> > >          this.new Test.Inner(); // error
> > >      }
> > > }
> >
> > Both the unqualified class instance creation expression and the
> > qualified class instance creation expression should compile. Each has
> > `this` as the immediately enclosing instance.
> >
> > > javac reports:
> > > Test.java:6: error: '(' expected
> > >          this.new Test.Inner();
> > >                       ^
> > > 1 error
> > >
> > > I read JLS 15.9 [1]:
> > > ClassInstanceCreationExpression:
> > >      UnqualifiedClassInstanceCreationExpression
> > >      ExpressionName . UnqualifiedClassInstanceCreationExpression
> > >      Primary . UnqualifiedClassInstanceCreationExpression
> > > UnqualifiedClassInstanceCreationExpression:
> > >      new [TypeArguments] ClassOrInterfaceTypeToInstantiate (
> > > [ArgumentList] ) [ClassBody]
> > > ClassOrInterfaceTypeToInstantiate:
> > >      {Annotation} Identifier {. {Annotation} Identifier} [TypeArgumentsOrDiamond]
> > >
> > > Thus this.new Test.Inner() could be parsed as Primary .
> > > UnqualifiedClassInstanceCreationExpression where
> > > ClassOrInterfaceTypeToInstantiate could be parsed as Identifier .
> > > Identifier, so there should not be parse error.
> >
> > Correct. There has been shimmer in this part of the language. In Java SE
> > 7, `this.new Test.Inner()` was illegal; only `this.new SIMPLENAME()` was
> > allowed. (See
> > https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.9)
> > In Java SE 8, the grammar of `ClassInstanceCreationExpression` was
> > modified to support type annotations, and `this.new QUALIFIEDNAME()` was
> > allowed. In principle, there is no reason to disallow a qualified name
> > in a qualified CICE. The phrase `new Test.Inner()` is meaningful as an
> > unqualified CICE, and enriching the phrase to be a qualified CICE, with
> > an explicit immediately enclosing instance, doesn't make it
> > unmeaningful. I suspect javac is still expecting (modulo type arguments)
> > a simple name after `new`.
>
> Right, I note that the parser doesn't conform to the current JLS grammar:
>
> http://hg.openjdk.java.net/jdk/jdk/file/c53a3355dbb4/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java#l2272
>
> InnerCreator = [Annotations] Ident [TypeArguments] ClassCreatorRest
>
> It seems 'InnerCreator' is missing '{. [Annotations] Ident}'.
> Is there any open JBS issue for this?
>
> I tried a quick fix, here under, in 'JavacParser' and 'Attr' which
> solve the problem; any feedback is welcome.
> Langtools:tier1 is OK but I'm not sure all is right with type
> annotations, etc...
> I might dig a bit more and send out a RFR soon but please let me know
> the priority of this before investing too much time now?
>
> Thanks,
> Bernard
>
>
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> @@ -2311,7 +2311,9 @@
>              // TODO 308: in <expr>.new C, do we also want to add the
> type annotations
>              // from expr to the combined type, or not? Yes, do this.
>              clazzid1 = make.at(clazz.pos).Select(make.Type(encltype),
> -                                                 ((JCIdent) clazzid).name);
> +                    clazzid.hasTag(SELECT) ?
> +                    ((JCFieldAccess) clazzid).name :
> +                    ((JCIdent) clazzid).name);
>
>              EndPosTable endPosTable = this.env.toplevel.endPositions;
>              endPosTable.storeEnd(clazzid1, tree.getEndPosition(endPosTable));
> @@ -2351,7 +2353,16 @@
>
>          clazztype = chk.checkDiamond(tree, clazztype);
>          chk.validate(clazz, localEnv);
> -        if (tree.encl != null) {
> +        if (tree.encl != null && clazzid.hasTag(SELECT)) {
> +            try {
> +                Type qualified = attribType(tree.clazz, env);
> +                if (!types.isSameType(clazztype, qualified))
> +                    log.error(tree.pos(),
> Errors.IncomparableTypes(clazztype, qualified));
> +            } finally {
> +                env.info.isNewClass = false;
> +            }
> +        }
> +        else if (tree.encl != null) {
>              // We have to work in this case to store
>              // symbol + type back into the attributed tree.
>              tree.clazz.type = clazztype;
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2019, Oracle and/or its affiliates. All rights reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -2269,7 +2269,7 @@
>          }
>      }
>
> -    /** InnerCreator = [Annotations] Ident [TypeArguments] ClassCreatorRest
> +    /** InnerCreator = [Annotations] Ident {. [Annotations] Ident}
> [TypeArguments] ClassCreatorRest
>       */
>      JCExpression innerCreator(int newpos, List<JCExpression>
> typeArgs, JCExpression encl) {
>          List<JCAnnotation> newAnnotations = typeAnnotationsOpt();
> @@ -2280,6 +2280,15 @@
>              t =
> toP(F.at(newAnnotations.head.pos).AnnotatedType(newAnnotations, t));
>          }
>
> +        while (token.kind == DOT) {
> +            nextToken();
> +            newAnnotations = typeAnnotationsOpt();
> +            t = toP(F.at(token.pos).Select(t, ident()));
> +            if (newAnnotations.nonEmpty()) {
> +                t =
> toP(F.at(newAnnotations.head.pos).AnnotatedType(newAnnotations, t));
> +            }
> +        }
> +
>          if (token.kind == LT) {
>              int oldmode = mode;
>              t = typeArguments(t, true);
> diff --git a/test/langtools/tools/javac/QualifiedAccess/QualifiedAccess_4.out
> b/test/langtools/tools/javac/QualifiedAccess/QualifiedAccess_4.out
> --- a/test/langtools/tools/javac/QualifiedAccess/QualifiedAccess_4.out
> +++ b/test/langtools/tools/javac/QualifiedAccess/QualifiedAccess_4.out
> @@ -1,2 +1,2 @@
> -QualifiedAccess_4.java:17:28: compiler.err.expected: '('
> +QualifiedAccess_4.java:17:19: compiler.err.cant.resolve.location:
> kindname.variable, x, , , (compiler.misc.location: kindname.class,
> CMain, null)
>  1 error

From james.laskey at oracle.com  Mon Feb  4 15:09:15 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Mon, 4 Feb 2019 11:09:15 -0400
Subject: RFR - 8212975 - ClassDesc should have a full name method
Message-ID: <EE33023A-6B70-46AB-86EB-01D1C43B9B87@oracle.com>

Please review the webrev below.

Though generally useful for debugging ClassDesc (or using Class::forName), ClassDesc::fullDisplayName allows compiler devs to use a ClassDesc directly to optimally add classes to the symbol table.

Past:

	ClassDesc cd = ...
	String className = cd.packageName().isEmpty() ? cd.displayName() : cd.packageName() + "." + cd.displayName();
	Symbol classSym = names.fromString(className);

Future:

	ClassDesc cd = ...
	String className = cd.fullDisplayName();
	Symbol classSym = names.fromString(className);

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

From eolivelli at gmail.com  Mon Feb  4 22:22:31 2019
From: eolivelli at gmail.com (Enrico Olivelli)
Date: Mon, 4 Feb 2019 23:22:31 +0100
Subject: spotBugs and JDK-8194978: Javac produces dead code for
 try-with-resource
In-Reply-To: <5C4F0647.2010809@oracle.com>
References: <CAD5tkZZ7kKGDVY_drJTksV-Fi0JwxJzy19_-evpS8hKQMCkrAg@mail.gmail.com>
 <CAD5tkZa4tT+UmXJ9+zLoNO5RMZpBvQg=ot+KjwjYhq3RHqN=iA@mail.gmail.com>
 <25e5d853-e4d4-41aa-8221-00462389fc67@oracle.com>
 <5BE60326.4090202@oracle.com>
 <CACcefgdRvF5x3T1RUuFxJ1K0ZMBhedTgMtcsZXw6FSe7d_5uJw@mail.gmail.com>
 <CACcefgczgk5yFeQBPhD5SHaCVavAUbNPDCC1bNMo-aUvfZegew@mail.gmail.com>
 <CACcefgc=VKvEp7apa7rxRfemvrvxYRnsDczxPTeSeHHz-p9pYg@mail.gmail.com>
 <5C4F0647.2010809@oracle.com>
Message-ID: <CACcefgfR6zQeP1z1aOF-eXmGbu5ZN+AoMtFGH_0RO7MadELW+Q@mail.gmail.com>

Jan, sorry for late reply.
I appreciate your explanation.

Best regards
Enrico

Il giorno lun 28 gen 2019, 14:40 Jan Lahoda <jan.lahoda at oracle.com> ha
scritto:

> Hi Enrico,
>
> One thing I'd like to point out is that I don't think that JDK-8194978
> added any new checks. There have been improvements to the
> try-with-resources desugaring over the past years, usually with the goal
> of making the bytecode shorter.
>
> So, for example, having:
> try (InputStream in = new FileInputStream(...)) {
> ...
> }
>
> AFAIK, originally, before "close()" was called on "in" there was a check
> if "in" is non-null, which happened every time. In case the resources is
> initialized with the new class instance expression, this check was
> removed, but in all other cases it was still there, as far as I known.
> (And I suspect Find/SpotBugs have heuristics to detect this pattern and
> ignore it.)
>
> The $closeResource method was also introduced to make the bytecode
> smaller, but was only used when there were enough try-with-resources
> constructs in the given file, as the method itself also had an space
> overhead. So some classfiles had the try-with-resources code without
> $closeResource.
>
> With JDK-8194978, the code generated for try-with-resources has been
> improved once again, to eliminate some of the branches in the "finally"
> block that cannot be used at the given places where finally is inlined.
> This made the $closeResource method unnecessary, so it is not produced
> anymore.
>
> Basically, here we are talking about eliding the null check on the
> resource if the resource must be non-null because a NullPointerException
> would already appear before reaching the point where the check is done.
> I don't think there are current plans to do that, sorry.
>
> If SpotBugs can detect the new pattern and ignore it (as I suspect it is
> doing with the older patterns), that would be helpful.
>
> Jan
>
> On 25.1.2019 21:44, Enrico Olivelli wrote:
> > Up
> >
> > Regards
> > Enrico
> >
> > Il 10 gen 2019 8:13 PM, "Enrico Olivelli" <eolivelli at gmail.com
> > <mailto:eolivelli at gmail.com>> ha scritto:
> >
> >     Kindly pinging on this..
> >
> >     Cheers
> >     Enrico
> >
> >     Il lun 7 gen 2019, 14:28 Enrico Olivelli <eolivelli at gmail.com
> >     <mailto:eolivelli at gmail.com>> ha scritto:
> >
> >         Two questions/ideas:
> >         1) Wouldn't it be possible for javac to annotate such code
> >         blocks and
> >         write into the class file that that code is "synthetic" ? I
> really
> >         don't know where to store such flags, but maybe someone could
> >         elaborate more this idea
> >         2) Why isn't javac adding  the "$closeResource" method ?
> >
> >         Enrico
> >
> >         Il giorno ven 9 nov 2018 alle ore 23:01 Alex Buckley
> >         <alex.buckley at oracle.com <mailto:alex.buckley at oracle.com>> ha
> >         scritto:
> >          >
> >          > On 11/9/2018 12:31 PM, Vicente Romero wrote:
> >          > > My evaluation on this issue is that javac is generating code
> >          > > according to the spec, see JLS11 14.20.3.1 [1]. There is an
> >         explicit
> >          > > check for null on the resource before invoking the close()
> >         method.
> >          > > This is the null check javac is generating.
> >          >
> >          > I confirm that the explicit null check on the resource
> >         variable is
> >          > required, per the translation in
> >          >
> >
> https://docs.oracle.com/javase/specs/jls/se11/html/jls-14.html#jls-14.20.3.1-140
> >         <
> https://docs.oracle.com/javase/specs/jls/se11/html/jls-14.html#jls-14.20.3.1-140
> >
> >          > -- it has been specified that way since JLS7.
> >          >
> >          > > Fix for JDK-8194978 went a bit further trying to eliminate
> >         dead code
> >          > > for some cases for which javac could statically determine
> >         that the
> >          > > resource would be different from null. In particular if the
> >         resource
> >          > > was initialized with a new class expression.
> >          >
> >          > I confirm it's acceptable to not perform the null check in
> >         generated
> >          > code if you can prove the resource variable is non-null.
> Frankly,
> >          > though, there is so much that can occur in a "new class
> >         expression" --
> >          > `new Outer(a(b(c)))<>.new <String>Inner(d(e(f)))` -- that I
> >         would be
> >          > wary of trying to prove anything.
> >          >
> >          > > It could be argued that we could try to analyze the body
> >         and if we
> >          > > find out that a NPE must be thrown in the body of the try,
> >         then the
> >          > > null check on the resource would be deemed unnecessary. But
> >         then we
> >          > > can get to an implementation that will be out of sync with
> >         the spec
> >          > > plus it probably won't cover all cases.
> >          >
> >          > Right, let's not be too clever.
> >          >
> >          > Alex
> >          >
> >          > > Thanks,
> >          > > Vicente
> >          > >
> >          > > [1]
> >          > >
> >
> https://docs.oracle.com/javase/specs/jls/se11/html/jls-14.html#jls-14.20.3.1
> >         <
> https://docs.oracle.com/javase/specs/jls/se11/html/jls-14.html#jls-14.20.3.1
> >
> >          > >
> >          > > On 11/9/18 10:22 AM, Ismael Juma wrote:
> >          > >> Any comments on this? Many people are disabling spotBugs
> when
> >          > >> compiling with Java 11 due to this issue:
> >          > >>
> >          > >> https://github.com/spotbugs/spotbugs/issues/756
> >         <https://github.com/spotbugs/spotbugs/issues/756>
> >          > >>
> >          > >> Ismael
> >          > >>
> >          > >> On Thu, Sep 13, 2018 at 10:05 PM Ismael Juma
> >         <mlists at juma.me.uk <mailto:mlists at juma.me.uk>
> >          > >> <mailto:mlists at juma.me.uk <mailto:mlists at juma.me.uk>>>
> wrote:
> >          > >>
> >          > >>     Hi all,
> >          > >>
> >          > >>     JDK-8194978 introduced some changes to the bytecode
> >         generated by
> >          > >>     javac for the try with resource construct. In the
> >         following code,
> >          > >>     it seems to generate a null check on a reference after
> >         invoking a
> >          > >>     method on it:
> >          > >>
> >          > >>         public static void readFileAsString(String path)
> >         throws
> >          > >>     IOException {
> >          > >>             try (FileChannel fc =
> >         FileChannel.open(Paths.get(path))) {
> >          > >>                 fc.size();
> >          > >>             }
> >          > >>
> >          > >>         }
> >          > >>
> >          > >>     In line 16 to 22 of the bytecode, it looks like we
> >         check for null
> >          > >>     after calling a method on the fc reference:
> >          > >>
> >          > >>           16: aload_1
> >          > >>           17: invokevirtual #6                  // Method
> >          > >>     java/nio/channels/FileChannel.size:()J
> >          > >>           20: pop2
> >          > >>           21: aload_1
> >          > >>           22: ifnull        52
> >          > >>           25: aload_1
> >          > >>           26: invokevirtual #7                  // Method
> >          > >>     java/nio/channels/FileChannel.close:()V
> >          > >>
> >          > >>     Is this intentional? I ask because this pattern
> triggers a
> >          > >>     spotBugs warning since it often implies a bug in
> >         user's code:
> >          > >>
> >          > >>     RCN | Nullcheck of fc at line 10 of value previously
> >         dereferenced
> >          > >>     in TryTest.readFileAsString(String, Charset)
> >          > >>
> >          > >>     Note that this works fine in Java versions older than
> >         Java 11.
> >          > >>     Since this spotBugs warning is generally useful, it
> >         would be handy
> >          > >>     if javac did not trigger it. Alternatively, if there's
> >         a good way
> >          > >>     to detect the code that was generated by javac,
> >         spotBugs could be
> >          > >>     updated to ignore it. For reference, this was
> >         discussed in the
> >          > >>     spotBugs issue tracker:
> >          > >>
> >          > >> https://github.com/spotbugs/spotbugs/issues/756
> >         <https://github.com/spotbugs/spotbugs/issues/756>
> >          > >>
> >          > >>     And method bytecode in full:
> >          > >>
> >          > >>       public static void
> >         readFileAsString(java.lang.String) throws
> >          > >>     java.io.IOException;
> >          > >>         Code:
> >          > >>            0: aload_0
> >          > >>            1: iconst_0
> >          > >>            2: anewarray     #2                  // class
> >         java/lang/String
> >          > >>            5: invokestatic  #3                  // Method
> >          > >>
> >
>  java/nio/file/Paths.get:(Ljava/lang/String;[Ljava/lang/String;)Ljava/nio/file/Path;
> >          > >>            8: iconst_0
> >          > >>            9: anewarray     #4                  // class
> >          > >>     java/nio/file/OpenOption
> >          > >>           12: invokestatic  #5                  // Method
> >          > >>
> >
>  java/nio/channels/FileChannel.open:(Ljava/nio/file/Path;[Ljava/nio/file/OpenOption;)Ljava/nio/channels/FileChannel;
> >          > >>           15: astore_1
> >          > >>           16: aload_1
> >          > >>           17: invokevirtual #6                  // Method
> >          > >>     java/nio/channels/FileChannel.size:()J
> >          > >>           20: pop2
> >          > >>           21: aload_1
> >          > >>           22: ifnull        52
> >          > >>           25: aload_1
> >          > >>           26: invokevirtual #7                  // Method
> >          > >>     java/nio/channels/FileChannel.close:()V
> >          > >>           29: goto          52
> >          > >>           32: astore_2
> >          > >>           33: aload_1
> >          > >>           34: ifnull        50
> >          > >>           37: aload_1
> >          > >>           38: invokevirtual #7                  // Method
> >          > >>     java/nio/channels/FileChannel.close:()V
> >          > >>           41: goto          50
> >          > >>           44: astore_3
> >          > >>           45: aload_2
> >          > >>           46: aload_3
> >          > >>           47: invokevirtual #9                  // Method
> >          > >>
>  java/lang/Throwable.addSuppressed:(Ljava/lang/Throwable;)V
> >          > >>           50: aload_2
> >          > >>           51: athrow
> >          > >>           52: return
> >          > >>         Exception table:
> >          > >>            from    to  target type
> >          > >>               16    21    32   Class java/lang/Throwable
> >          > >>               37    41    44   Class java/lang/Throwable
> >          > >>
> >          > >>     Thanks,
> >          > >>     Ismael
> >          > >>
> >          > >
> >
> >     --
> >
> >
> >     -- Enrico Olivelli
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190204/8fbde81c/attachment-0001.html>

From vitalyd at gmail.com  Wed Feb  6 14:14:15 2019
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 6 Feb 2019 14:14:15 +0000
Subject: Backporting JDK-8210483 to Java 11
In-Reply-To: <bb7ca696-3fa9-250d-ac27-b29fc8bb1372@oracle.com>
References: <CAHTgnkrGw+BZZD6E0mUE=KBoJc82zb9kAYFToNRHqfMBVvjbVA@mail.gmail.com>
 <bb7ca696-3fa9-250d-ac27-b29fc8bb1372@oracle.com>
Message-ID: <CAHjP37Fo6cey0inpz7fCuxw+Vt8yLE9RADe05Fi5B6KyWmEWRQ@mail.gmail.com>

Hi Vicente (and others),

May I ask why there's no plan to backport this to 11? We're seeing the same
javac failure on our code, and simply moving to java 12 is a non-starter
given it's a non-LTS release.  Is there something fundamentally difficult
about backporting this fix to 11?

Thanks!

On Wed, Jan 9, 2019 at 1:31 PM Vicente Romero <vicente.romero at oracle.com>
wrote:

> Hi,
>
> I don't think there is any plan to backport it to 11,
>
> Thanks,
> Vicente
>
> On 1/9/19 3:40 AM, Mattias Nordin Kettil wrote:
> > Hello!
> >
> > I have searched the bug pages and mailing list archives for this, but
> > I can't find any information about a potential backport of
> > the JDK-8210483 fix to Java 11. Will it be included in Java 11, and if
> > so, is it possible to say when?
> >
> > Best regards,
> > Mattias Nordin Kettil
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190206/013a324e/attachment.html>

From brian.goetz at oracle.com  Wed Feb  6 14:30:14 2019
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 6 Feb 2019 15:30:14 +0100
Subject: Backporting JDK-8210483 to Java 11
In-Reply-To: <CAHjP37Fo6cey0inpz7fCuxw+Vt8yLE9RADe05Fi5B6KyWmEWRQ@mail.gmail.com>
References: <CAHTgnkrGw+BZZD6E0mUE=KBoJc82zb9kAYFToNRHqfMBVvjbVA@mail.gmail.com>
 <bb7ca696-3fa9-250d-ac27-b29fc8bb1372@oracle.com>
 <CAHjP37Fo6cey0inpz7fCuxw+Vt8yLE9RADe05Fi5B6KyWmEWRQ@mail.gmail.com>
Message-ID: <FC7935BB-030C-4F94-AE90-ED2B7DD2963A@oracle.com>

> May I ask why there's no plan to backport this to 11? We're seeing the same javac failure on our code, and simply moving to java 12 is a non-starter given it's a non-LTS release.  Is there something fundamentally difficult about backporting this fix to 11?

You seem to implicitly assume that difficulty is the only criteria for back porting, but that is not, and has never been, the case.  With the advent of the rapid release cadence, where the next version is much closer in time, the bar for back porting has gotten significantly higher.  (Back porting any given issue might seem easy, but in the aggregate, back porting in general has enormous costs, as well as stability risks.  We would prefer to invest more of our efforts in feature development, and less in back ports.)  

You have choices; you can stay on the leading edge (in which case the fix is in 12), or you can stick with LTS.  Which features are back ported to an LTS distribution is the choice of your LTS provider.  If you are getting your LTS releases from a commercial contract (such as Oracle?s Java SE subscription), you should ask for this through the support channel you are paying for ? that?s what its there for.  If you are relying on LTS from OpenJDK, this is decided by whomever is leading the 11-updates project.  Currently this has not been handed over from Oracle to someone else, but that is likely to happen soon, in which case the updates list would be the place for this request (or to volunteer to do the back port!)  



From vitalyd at gmail.com  Wed Feb  6 15:27:16 2019
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 6 Feb 2019 15:27:16 +0000
Subject: Backporting JDK-8210483 to Java 11
In-Reply-To: <FC7935BB-030C-4F94-AE90-ED2B7DD2963A@oracle.com>
References: <CAHTgnkrGw+BZZD6E0mUE=KBoJc82zb9kAYFToNRHqfMBVvjbVA@mail.gmail.com>
 <bb7ca696-3fa9-250d-ac27-b29fc8bb1372@oracle.com>
 <CAHjP37Fo6cey0inpz7fCuxw+Vt8yLE9RADe05Fi5B6KyWmEWRQ@mail.gmail.com>
 <FC7935BB-030C-4F94-AE90-ED2B7DD2963A@oracle.com>
Message-ID: <CAHjP37GLB-OyXieBruP2LUbfVa0FqeRrmb-JCH48Gn2HN+2p2w@mail.gmail.com>

On Wed, Feb 6, 2019 at 2:30 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> > May I ask why there's no plan to backport this to 11? We're seeing the
> same javac failure on our code, and simply moving to java 12 is a
> non-starter given it's a non-LTS release.  Is there something fundamentally
> difficult about backporting this fix to 11?
>
> You seem to implicitly assume that difficulty is the only criteria for
> back porting, but that is not, and has never been, the case.  With the
> advent of the rapid release cadence, where the next version is much closer
> in time, the bar for back porting has gotten significantly higher.  (Back
> porting any given issue might seem easy, but in the aggregate, back porting
> in general has enormous costs, as well as stability risks.  We would prefer
> to invest more of our efforts in feature development, and less in back
> ports.)
>
Yes, I'd assume the difficulty and perceived (in)stability of a backport
request would be weighed in the decision to backport or not.  But, this is
a bug fix - javac fails on fairly pedestrian code.

>
> You have choices; you can stay on the leading edge (in which case the fix
> is in 12), or you can stick with LTS.  Which features are back ported to an
> LTS distribution is the choice of your LTS provider.

Again, I'd imagine a javac bug of the sort here would be deemed critical to
backport to an LTS release.  But ok, if the answer is "refer to your LTS
provider", then so be it.

>   If you are getting your LTS releases from a commercial contract (such as
> Oracle?s Java SE subscription), you should ask for this through the support
> channel you are paying for ? that?s what its there for.  If you are relying
> on LTS from OpenJDK, this is decided by whomever is leading the 11-updates
> project.  Currently this has not been handed over from Oracle to someone
> else, but that is likely to happen soon, in which case the updates list
> would be the place for this request (or to volunteer to do the back port!)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190206/77feb2ef/attachment.html>

From martijnverburg at gmail.com  Wed Feb  6 15:39:46 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 6 Feb 2019 15:39:46 +0000
Subject: Backporting JDK-8210483 to Java 11
In-Reply-To: <CAHjP37GLB-OyXieBruP2LUbfVa0FqeRrmb-JCH48Gn2HN+2p2w@mail.gmail.com>
References: <CAHTgnkrGw+BZZD6E0mUE=KBoJc82zb9kAYFToNRHqfMBVvjbVA@mail.gmail.com>
 <bb7ca696-3fa9-250d-ac27-b29fc8bb1372@oracle.com>
 <CAHjP37Fo6cey0inpz7fCuxw+Vt8yLE9RADe05Fi5B6KyWmEWRQ@mail.gmail.com>
 <FC7935BB-030C-4F94-AE90-ED2B7DD2963A@oracle.com>
 <CAHjP37GLB-OyXieBruP2LUbfVa0FqeRrmb-JCH48Gn2HN+2p2w@mail.gmail.com>
Message-ID: <CAP7YuARB0WgcPxLw=e6qe1+_kNzvz6UYb1eqJTk0DOaY3r+WzA@mail.gmail.com>

Hi Vitaly/All,

With the new release cadence, comes a new responsibility for members of the
community to step up and start taking over some of the back-porting etc
themselves. We can't expect vendors like Oracle to keep fixing every stream
for free! Everyone has to eat :-).

At the recent OpenJDK Committers Workshop (only a couple of days ago), we
discussed adding more documentation to the wikis of the relevant projects
to aid newcomers in submitting patches.  The jdk11u project page/wiki will
get updated in the coming weeks as will others.

Please excuse the dust and have patience in the meantime, it's a transition
period and we're all adjusting to the new way of working!

Cheers,
Martijn


On Wed, 6 Feb 2019 at 15:27, Vitaly Davidovich <vitalyd at gmail.com> wrote:

>
>
> On Wed, Feb 6, 2019 at 2:30 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>
>> > May I ask why there's no plan to backport this to 11? We're seeing the
>> same javac failure on our code, and simply moving to java 12 is a
>> non-starter given it's a non-LTS release.  Is there something fundamentally
>> difficult about backporting this fix to 11?
>>
>> You seem to implicitly assume that difficulty is the only criteria for
>> back porting, but that is not, and has never been, the case.  With the
>> advent of the rapid release cadence, where the next version is much closer
>> in time, the bar for back porting has gotten significantly higher.  (Back
>> porting any given issue might seem easy, but in the aggregate, back porting
>> in general has enormous costs, as well as stability risks.  We would prefer
>> to invest more of our efforts in feature development, and less in back
>> ports.)
>>
> Yes, I'd assume the difficulty and perceived (in)stability of a backport
> request would be weighed in the decision to backport or not.  But, this is
> a bug fix - javac fails on fairly pedestrian code.
>
>>
>> You have choices; you can stay on the leading edge (in which case the fix
>> is in 12), or you can stick with LTS.  Which features are back ported to an
>> LTS distribution is the choice of your LTS provider.
>
> Again, I'd imagine a javac bug of the sort here would be deemed critical
> to backport to an LTS release.  But ok, if the answer is "refer to your LTS
> provider", then so be it.
>
>>   If you are getting your LTS releases from a commercial contract (such
>> as Oracle?s Java SE subscription), you should ask for this through the
>> support channel you are paying for ? that?s what its there for.  If you are
>> relying on LTS from OpenJDK, this is decided by whomever is leading the
>> 11-updates project.  Currently this has not been handed over from Oracle to
>> someone else, but that is likely to happen soon, in which case the updates
>> list would be the place for this request (or to volunteer to do the back
>> port!)
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190206/70ae4c41/attachment-0001.html>

From adinn at redhat.com  Wed Feb  6 16:19:11 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 6 Feb 2019 16:19:11 +0000
Subject: Backporting JDK-8210483 to Java 11
In-Reply-To: <CAHjP37GLB-OyXieBruP2LUbfVa0FqeRrmb-JCH48Gn2HN+2p2w@mail.gmail.com>
References: <CAHTgnkrGw+BZZD6E0mUE=KBoJc82zb9kAYFToNRHqfMBVvjbVA@mail.gmail.com>
 <bb7ca696-3fa9-250d-ac27-b29fc8bb1372@oracle.com>
 <CAHjP37Fo6cey0inpz7fCuxw+Vt8yLE9RADe05Fi5B6KyWmEWRQ@mail.gmail.com>
 <FC7935BB-030C-4F94-AE90-ED2B7DD2963A@oracle.com>
 <CAHjP37GLB-OyXieBruP2LUbfVa0FqeRrmb-JCH48Gn2HN+2p2w@mail.gmail.com>
Message-ID: <dd8fcffe-af47-cf6f-d179-79508d04d491@redhat.com>

Hi Vitaly,

On 06/02/2019 15:27, Vitaly Davidovich wrote:
> Yes, I'd assume the difficulty and perceived (in)stability of a backport
> request would be weighed in the decision to backport or not.? But, this
> is a bug fix - javac fails on fairly pedestrian code.

It may seem counter-intuitive but Brian is 100% correct in stating that
decisions over backports require balancing of pros and cons -- even in
cases where the proposed backport is a bug fix. Changes may have
unintended consequences. Risk aversion sometimes trumps corrective
action, especially when correcting a rare error case.

> Again, I'd imagine a javac bug of the sort here would be deemed critical
> to backport to an LTS release.? But ok, if the answer is "refer to your
> LTS provider", then so be it. 
What Brian specifically recommended was that you negotiated this request
with the maintainer of a specific LTS release. When the maintainer has a
private, proprietary tree (like, say, Oracle) the utility of such a
request may depend on you being in a commercial, contractual
relationship. An alternative route is to approach those maintaining the
tree for the continuing open source project. Fixes applied to that tree
should appear in subsequent open source LTS releases which you will be
able to obtain without the requirement to be in a commercial,
contractual relationship.

Neither path guarantees a patch will be provided. Neither rules it out.

At this point I would normally route you straight to the jdk11u project
maintainer -- except that the jdk11u project is in the process of being
handed over from Oracle to an as yet unconfirmed project lead. That
situation ought to change very soon and, when it does, I suggest you
post to the jdk updates list (jdk-updates-dev at openjdk.java.net) asking
whether a backport is possible.

Bonus points would definitely be awarded if your request included a
jdk11-ready version of the upstream patch in that request, preferably
accompanied with reports of tests confirming its validity. And, as Brian
hinted: What do points mean? a healthy open source eco-system!

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From vitalyd at gmail.com  Wed Feb  6 16:47:19 2019
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 6 Feb 2019 16:47:19 +0000
Subject: Backporting JDK-8210483 to Java 11
In-Reply-To: <CAP7YuARB0WgcPxLw=e6qe1+_kNzvz6UYb1eqJTk0DOaY3r+WzA@mail.gmail.com>
References: <CAHTgnkrGw+BZZD6E0mUE=KBoJc82zb9kAYFToNRHqfMBVvjbVA@mail.gmail.com>
 <bb7ca696-3fa9-250d-ac27-b29fc8bb1372@oracle.com>
 <CAHjP37Fo6cey0inpz7fCuxw+Vt8yLE9RADe05Fi5B6KyWmEWRQ@mail.gmail.com>
 <FC7935BB-030C-4F94-AE90-ED2B7DD2963A@oracle.com>
 <CAHjP37GLB-OyXieBruP2LUbfVa0FqeRrmb-JCH48Gn2HN+2p2w@mail.gmail.com>
 <CAP7YuARB0WgcPxLw=e6qe1+_kNzvz6UYb1eqJTk0DOaY3r+WzA@mail.gmail.com>
Message-ID: <CAHjP37FJ9Fhr4EqTN_SAEMiVQGSUcwbt7bMHZSke=3ZOE5yG-w@mail.gmail.com>

Hi Martijn,

On Wed, Feb 6, 2019 at 3:39 PM Martijn Verburg <martijnverburg at gmail.com>
wrote:

> Hi Vitaly/All,
>
> With the new release cadence, comes a new responsibility for members of
> the community to step up and start taking over some of the back-porting etc
> themselves. We can't expect vendors like Oracle to keep fixing every stream
> for free! Everyone has to eat :-).
>
I understand - this is why I asked about the backport via the AdoptOpenJDK
channel (as you saw) first as, frankly, it's not crystal clear to me how
backports are handled in the new world.  The response there was,
essentially, it's up to upstream to backport to 11, at which point AOJDK
would build it.  Perhaps I misunderstood that but, either way, with this
email thread I think I have a better understanding.

I guess I was also surprised by this specific case.  Backporting a javac
bug of this nature to jdk11u, which is the LTS tree for mostly everyone
(right?), seemed like an "obvious" thing to do.  I understand there's a
question of who should do it, and that's a good fair question to ask.  I'm
happy if that's the only question at this point, rather than whether this
bug warrants a backport at all.


> At the recent OpenJDK Committers Workshop (only a couple of days ago), we
> discussed adding more documentation to the wikis of the relevant projects
> to aid newcomers in submitting patches.  The jdk11u project page/wiki will
> get updated in the coming weeks as will others.
>
> Please excuse the dust and have patience in the meantime, it's a
> transition period and we're all adjusting to the new way of working!
>
Great, your (and others') work on this is appreciated!

>
> Cheers,
> Martijn
>
>
> On Wed, 6 Feb 2019 at 15:27, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>>
>>
>> On Wed, Feb 6, 2019 at 2:30 PM Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>>
>>> > May I ask why there's no plan to backport this to 11? We're seeing the
>>> same javac failure on our code, and simply moving to java 12 is a
>>> non-starter given it's a non-LTS release.  Is there something fundamentally
>>> difficult about backporting this fix to 11?
>>>
>>> You seem to implicitly assume that difficulty is the only criteria for
>>> back porting, but that is not, and has never been, the case.  With the
>>> advent of the rapid release cadence, where the next version is much closer
>>> in time, the bar for back porting has gotten significantly higher.  (Back
>>> porting any given issue might seem easy, but in the aggregate, back porting
>>> in general has enormous costs, as well as stability risks.  We would prefer
>>> to invest more of our efforts in feature development, and less in back
>>> ports.)
>>>
>> Yes, I'd assume the difficulty and perceived (in)stability of a backport
>> request would be weighed in the decision to backport or not.  But, this is
>> a bug fix - javac fails on fairly pedestrian code.
>>
>>>
>>> You have choices; you can stay on the leading edge (in which case the
>>> fix is in 12), or you can stick with LTS.  Which features are back ported
>>> to an LTS distribution is the choice of your LTS provider.
>>
>> Again, I'd imagine a javac bug of the sort here would be deemed critical
>> to backport to an LTS release.  But ok, if the answer is "refer to your LTS
>> provider", then so be it.
>>
>>>   If you are getting your LTS releases from a commercial contract (such
>>> as Oracle?s Java SE subscription), you should ask for this through the
>>> support channel you are paying for ? that?s what its there for.  If you are
>>> relying on LTS from OpenJDK, this is decided by whomever is leading the
>>> 11-updates project.  Currently this has not been handed over from Oracle to
>>> someone else, but that is likely to happen soon, in which case the updates
>>> list would be the place for this request (or to volunteer to do the back
>>> port!)
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190206/652d8e50/attachment.html>

From vitalyd at gmail.com  Wed Feb  6 16:53:38 2019
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 6 Feb 2019 16:53:38 +0000
Subject: Backporting JDK-8210483 to Java 11
In-Reply-To: <dd8fcffe-af47-cf6f-d179-79508d04d491@redhat.com>
References: <CAHTgnkrGw+BZZD6E0mUE=KBoJc82zb9kAYFToNRHqfMBVvjbVA@mail.gmail.com>
 <bb7ca696-3fa9-250d-ac27-b29fc8bb1372@oracle.com>
 <CAHjP37Fo6cey0inpz7fCuxw+Vt8yLE9RADe05Fi5B6KyWmEWRQ@mail.gmail.com>
 <FC7935BB-030C-4F94-AE90-ED2B7DD2963A@oracle.com>
 <CAHjP37GLB-OyXieBruP2LUbfVa0FqeRrmb-JCH48Gn2HN+2p2w@mail.gmail.com>
 <dd8fcffe-af47-cf6f-d179-79508d04d491@redhat.com>
Message-ID: <CAHjP37GuvxytNKDZo9np1oJALwd+pL+mfOYYdrmvykJ39r-zMQ@mail.gmail.com>

Hey Andrew,

On Wed, Feb 6, 2019 at 4:19 PM Andrew Dinn <adinn at redhat.com> wrote:

> Hi Vitaly,
>
> On 06/02/2019 15:27, Vitaly Davidovich wrote:
> > Yes, I'd assume the difficulty and perceived (in)stability of a backport
> > request would be weighed in the decision to backport or not.  But, this
> > is a bug fix - javac fails on fairly pedestrian code.
>
> It may seem counter-intuitive but Brian is 100% correct in stating that
> decisions over backports require balancing of pros and cons -- even in
> cases where the proposed backport is a bug fix. Changes may have
> unintended consequences. Risk aversion sometimes trumps corrective
> action, especially when correcting a rare error case.
>
Hmm, I don't think there's anything counter-intuitive - I understand
Brian's (and your) point in general, but I was interested in this specific
bug only, not a more general backport policy.

>
> > Again, I'd imagine a javac bug of the sort here would be deemed critical
> > to backport to an LTS release.  But ok, if the answer is "refer to your
> > LTS provider", then so be it.
> What Brian specifically recommended was that you negotiated this request
> with the maintainer of a specific LTS release. When the maintainer has a
> private, proprietary tree (like, say, Oracle) the utility of such a
> request may depend on you being in a commercial, contractual
> relationship. An alternative route is to approach those maintaining the
> tree for the continuing open source project. Fixes applied to that tree
> should appear in subsequent open source LTS releases which you will be
> able to obtain without the requirement to be in a commercial,
> contractual relationship.
>
> Neither path guarantees a patch will be provided. Neither rules it out.
>
Sure.  Perhaps my impression of this bug's severity differs from reality,
but I'm having a hard time seeing a case where it doesn't require a fix in
11.  There're the unanswered questions around who'll do the backport work,
which I understand now.

>
> At this point I would normally route you straight to the jdk11u project
> maintainer -- except that the jdk11u project is in the process of being
> handed over from Oracle to an as yet unconfirmed project lead. That
> situation ought to change very soon and, when it does, I suggest you
> post to the jdk updates list (jdk-updates-dev at openjdk.java.net) asking
> whether a backport is possible.
>
Thanks, I wasn't aware of this mailing list - I'll keep that in mind going
forward.

>
> Bonus points would definitely be awarded if your request included a
> jdk11-ready version of the upstream patch in that request, preferably
> accompanied with reports of tests confirming its validity. And, as Brian
> hinted: What do points mean? a healthy open source eco-system!
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190206/d1b9101c/attachment-0001.html>

From jan.lahoda at oracle.com  Thu Feb  7 16:42:15 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 7 Feb 2019 17:42:15 +0100
Subject: RFR: JDK-8217868: Crash for overlap between source path and patch
 module path
Message-ID: <5C5C5FE7.3050406@oracle.com>

Hi,

Consider code like this:
---src/module-info.java
module m { uses test.Test; }
---src/test/Test.java
package test; public class Test { }

And javac invocation like:
javac -sourcepath src --patch-module m2=src module-info.java

While analysing the module-info, javac will try to lazily/implicitly 
load the test.Test class. And when Modules.setCompilationUnitModules is 
called for test.Test, it will eventually call singleModuleOverride, 
which will look at --patch-module to find if the given source is on any 
module patch. And it will find out it is a module patch for m2, but as 
javac never heard about m2 before, it will crash.

Seems that the biggest underlying problem is that even though javac 
knows which modules owns the class, it will try to look for the owner on 
the patch path. The proposed patch fixes that, and uses the correct 
owning module. This requires also a little cleanup in javadoc.

Webrev: cr.openjdk.java.net/~jlahoda/8217868/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8217868

How does this look?

Thanks,
     Jan

From jan.lahoda at oracle.com  Thu Feb  7 17:15:36 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 7 Feb 2019 18:15:36 +0100
Subject: RFR: JDK-8218630: CreateSymbols includes class and module headers
 unnecessarily.
Message-ID: <5C5C67B8.5050302@oracle.com>

Hi,

Joe noted that the proposed historical data for JDK 12:
http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/
may contain unnecessary items, and it indeed is the case.

The main problems appear to be:
-when the class headers are being compared, the nestMembers for the 
current version may be null, and the nestMembers for the previous 
version may be an empty list. So, currently, such headers won't match 
and the header will be generated again to the historical record. 
listMatch can be used to consider null and empty list to be the same

-module header descriptions may refer to 
RequiresDescription/ProvidesDescription, which are missing 
hashCode/equals, which means that headers that have either requires or 
provides won't match any of the existing headers. The fix is to add 
hashCode and equals

I generated the ct.sym for the original JDK 12 historical data from
http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/

and the historical data generated by this patch, and the resulting 
content appears to be equivalent.

Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8218630/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8218630

How does this look?

Thanks,
     Jan

From jan.lahoda at oracle.com  Thu Feb  7 17:21:45 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 7 Feb 2019 18:21:45 +0100
Subject: RFR(13): JDK-8216263: Add historical data for JDK 12
In-Reply-To: <5C4207A4.1040203@oracle.com>
References: <5C334A87.5080207@oracle.com> <5C33D7E0.2020609@oracle.com>
 <5C3477B7.8060307@oracle.com> <5C3FD6A8.1080803@oracle.com>
 <5C40B289.7070408@oracle.com>
 <967fdd5a-9810-4790-a164-2e39394fed66@oracle.com>
 <5C40CF23.4050608@oracle.com> <5C4207A4.1040203@oracle.com>
Message-ID: <5C5C6929.30108@oracle.com>

Hello,

I've regenerated the patch using JDK 12b30, and also using the patch from:
https://mail.openjdk.java.net/pipermail/compiler-dev/2019-February/012938.html

(which makes the historical record smaller).

The updated patch is here:
http://cr.openjdk.java.net/~jlahoda/8216263/webrev.04/

How does that look?

Thanks,
     Jan

On 18.1.2019 18:06, Jan Lahoda wrote:
> Adding build-dev.
>
> Jan
>
> On 17.1.2019 19:53, Jan Lahoda wrote:
>> On 17.1.2019 17:58, Jonathan Gibbons wrote:
>>> Re:
>>>
>>>    36 #   The checkout must not have any local changes that could
>>> interfere with the new data. In particular,
>>>    37 #   there must be absolutely no changed, new or removed files
>>> under the ${JDK_CHECKOUT}/make/data/symbols
>>>    38 #   directory.
>>>
>>> That seems like a simple check that could be incorporated into the
>>> script itself.
>>>
>>> But, it also seems reasonable to separate enhancements like that from
>>> the specific issue here, to add historical data for 12.
>>
>> Ok. Sent as:
>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012879.html
>>
>>
>>
>> And limited this patch to the historical data only:
>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.03/
>>
>> Thanks,
>>     Jan
>>
>>>
>>> -- Jon
>>>
>>> On 1/17/19 8:51 AM, Jan Lahoda wrote:
>>>> Hi Joe,
>>>>
>>>> On 17.1.2019 02:13, Joseph D. Darcy wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On 1/8/2019 2:13 AM, Jan Lahoda wrote:
>>>>>> Hi Joe,
>>>>>>
>>>>>> Thanks for the comments, some responses inline. Updated webrev:
>>>>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.01/
>>>>>>
>>>>>> On 7.1.2019 23:51, Joseph D. Darcy wrote:
>>>>>>> Hi Jan,
>>>>>>>
>>>>>>> On 1/7/2019 4:48 AM, Jan Lahoda wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> To make --release 12 work, we need to add historical data for JDK
>>>>>>>> 12.
>>>>>>>> The current historical data is based on:
>>>>>>>> $ javac  -fullversion
>>>>>>>> javac full version "12-ea+26"
>>>>>>>>
>>>>>>>> We may need to update the data once JDK 12 is out to cover any
>>>>>>>> changes
>>>>>>>> to the APIs that might happen.
>>>>>>>>
>>>>>>>> The patch also adds a simple (shell) script to generate the
>>>>>>>> data, so
>>>>>>>> all that was needed to generate the data was:
>>>>>>>> $ cd make/data/symbols
>>>>>>>> $ sh generate-data <path-to-JDK-12>
>>>>>>>>
>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8216263
>>>>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/
>>>>>>>>
>>>>>>>> How does this look?
>>>>>>>
>>>>>>> If the overhead is small enough and we don't mind a few updates to
>>>>>>> the
>>>>>>> JDK N+1 data, than perhaps the generation of this information
>>>>>>> could be
>>>>>>> included as part of the start of JDK N+1 activities.
>>>>>>
>>>>>> That would be perfect!
>>>>>>
>>>>>>>
>>>>>>> I suggest a more extensive description of how to
>>>>>>> make/data/symbols/generate-data. For example, this builds the data
>>>>>>> for
>>>>>>> the current release independent of whether or not the current
>>>>>>> release
>>>>>>> has already had its data generated, correct?
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>>>
>>>>>>> Concretely, if JDK N+1 has already forked, what is the proper way
>>>>>>> to get
>>>>>>> data for JDK N? Likewise, how should a re-build of the data for JDK
>>>>>>> N be
>>>>>>> done?
>>>>>>
>>>>>> What exactly should be there? To the existing description:
>>>>>> # to generate (add) data for JDK N, do:
>>>>>> # cd make/data/symbols
>>>>>> # sh generate-data <path-to-JDK-N>
>>>>>>
>>>>>> I've added (in .01):
>>>>>> # to regenerate the data for JDK N, run the above commands again
>>>>>>
>>>>>> What more should be there?
>>>>>>
>>>>>
>>>>> I'd appreciate somewhere to have a textual discussion of how
>>>>> make/data/symbols/symbols should be updated, the A = 10, B = 11, etc.
>>>>> convention, what else need to be done to generate the contents of this
>>>>> changeset.
>>>>>
>>>>> The <patch-to-JDK-N> is the contents of the build directory?
>>>>>
>>>>> In general, a description of how the data of JDK N should be added to
>>>>> JDK (N+1).
>>>>
>>>> I've added more textual description to the script, an updated webrev
>>>> is here:
>>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.02/
>>>>
>>>> Jan
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Joe
>>>>>
>>>>>

From jonathan.gibbons at oracle.com  Thu Feb  7 18:27:31 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 7 Feb 2019 10:27:31 -0800
Subject: RFR: JDK-8218630: CreateSymbols includes class and module headers
 unnecessarily.
In-Reply-To: <5C5C67B8.5050302@oracle.com>
References: <5C5C67B8.5050302@oracle.com>
Message-ID: <3747b7e8-c8a2-a4ca-264d-38b2df8dc5f8@oracle.com>

Looks good to me.

-- Jon

On 2/7/19 9:15 AM, Jan Lahoda wrote:
> Hi,
>
> Joe noted that the proposed historical data for JDK 12:
> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/
> may contain unnecessary items, and it indeed is the case.
>
> The main problems appear to be:
> -when the class headers are being compared, the nestMembers for the 
> current version may be null, and the nestMembers for the previous 
> version may be an empty list. So, currently, such headers won't match 
> and the header will be generated again to the historical record. 
> listMatch can be used to consider null and empty list to be the same
>
> -module header descriptions may refer to 
> RequiresDescription/ProvidesDescription, which are missing 
> hashCode/equals, which means that headers that have either requires or 
> provides won't match any of the existing headers. The fix is to add 
> hashCode and equals
>
> I generated the ct.sym for the original JDK 12 historical data from
> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/
>
> and the historical data generated by this patch, and the resulting 
> content appears to be equivalent.
>
> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8218630/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8218630
>
> How does this look?
>
> Thanks,
> ??? Jan

From jonathan.gibbons at oracle.com  Thu Feb  7 18:30:16 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 7 Feb 2019 10:30:16 -0800
Subject: RFR(13): JDK-8216263: Add historical data for JDK 12
In-Reply-To: <5C5C6929.30108@oracle.com>
References: <5C334A87.5080207@oracle.com> <5C33D7E0.2020609@oracle.com>
 <5C3477B7.8060307@oracle.com> <5C3FD6A8.1080803@oracle.com>
 <5C40B289.7070408@oracle.com>
 <967fdd5a-9810-4790-a164-2e39394fed66@oracle.com>
 <5C40CF23.4050608@oracle.com> <5C4207A4.1040203@oracle.com>
 <5C5C6929.30108@oracle.com>
Message-ID: <c48c7393-59d8-3f56-b47e-691983a796fd@oracle.com>

Looks good to me.

-- Jon

On 2/7/19 9:21 AM, Jan Lahoda wrote:
> Hello,
>
> I've regenerated the patch using JDK 12b30, and also using the patch 
> from:
> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-February/012938.html 
>
>
> (which makes the historical record smaller).
>
> The updated patch is here:
> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.04/
>
> How does that look?
>
> Thanks,
> ??? Jan
>
> On 18.1.2019 18:06, Jan Lahoda wrote:
>> Adding build-dev.
>>
>> Jan
>>
>> On 17.1.2019 19:53, Jan Lahoda wrote:
>>> On 17.1.2019 17:58, Jonathan Gibbons wrote:
>>>> Re:
>>>>
>>>> ?? 36 #?? The checkout must not have any local changes that could
>>>> interfere with the new data. In particular,
>>>> ?? 37 #?? there must be absolutely no changed, new or removed files
>>>> under the ${JDK_CHECKOUT}/make/data/symbols
>>>> ?? 38 #?? directory.
>>>>
>>>> That seems like a simple check that could be incorporated into the
>>>> script itself.
>>>>
>>>> But, it also seems reasonable to separate enhancements like that from
>>>> the specific issue here, to add historical data for 12.
>>>
>>> Ok. Sent as:
>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012879.html 
>>>
>>>
>>>
>>>
>>> And limited this patch to the historical data only:
>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.03/
>>>
>>> Thanks,
>>> ??? Jan
>>>
>>>>
>>>> -- Jon
>>>>
>>>> On 1/17/19 8:51 AM, Jan Lahoda wrote:
>>>>> Hi Joe,
>>>>>
>>>>> On 17.1.2019 02:13, Joseph D. Darcy wrote:
>>>>>> Hi Jan,
>>>>>>
>>>>>> On 1/8/2019 2:13 AM, Jan Lahoda wrote:
>>>>>>> Hi Joe,
>>>>>>>
>>>>>>> Thanks for the comments, some responses inline. Updated webrev:
>>>>>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.01/
>>>>>>>
>>>>>>> On 7.1.2019 23:51, Joseph D. Darcy wrote:
>>>>>>>> Hi Jan,
>>>>>>>>
>>>>>>>> On 1/7/2019 4:48 AM, Jan Lahoda wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> To make --release 12 work, we need to add historical data for JDK
>>>>>>>>> 12.
>>>>>>>>> The current historical data is based on:
>>>>>>>>> $ javac? -fullversion
>>>>>>>>> javac full version "12-ea+26"
>>>>>>>>>
>>>>>>>>> We may need to update the data once JDK 12 is out to cover any
>>>>>>>>> changes
>>>>>>>>> to the APIs that might happen.
>>>>>>>>>
>>>>>>>>> The patch also adds a simple (shell) script to generate the
>>>>>>>>> data, so
>>>>>>>>> all that was needed to generate the data was:
>>>>>>>>> $ cd make/data/symbols
>>>>>>>>> $ sh generate-data <path-to-JDK-12>
>>>>>>>>>
>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8216263
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/
>>>>>>>>>
>>>>>>>>> How does this look?
>>>>>>>>
>>>>>>>> If the overhead is small enough and we don't mind a few updates to
>>>>>>>> the
>>>>>>>> JDK N+1 data, than perhaps the generation of this information
>>>>>>>> could be
>>>>>>>> included as part of the start of JDK N+1 activities.
>>>>>>>
>>>>>>> That would be perfect!
>>>>>>>
>>>>>>>>
>>>>>>>> I suggest a more extensive description of how to
>>>>>>>> make/data/symbols/generate-data. For example, this builds the data
>>>>>>>> for
>>>>>>>> the current release independent of whether or not the current
>>>>>>>> release
>>>>>>>> has already had its data generated, correct?
>>>>>>>
>>>>>>> Yes.
>>>>>>>
>>>>>>>>
>>>>>>>> Concretely, if JDK N+1 has already forked, what is the proper way
>>>>>>>> to get
>>>>>>>> data for JDK N? Likewise, how should a re-build of the data for 
>>>>>>>> JDK
>>>>>>>> N be
>>>>>>>> done?
>>>>>>>
>>>>>>> What exactly should be there? To the existing description:
>>>>>>> # to generate (add) data for JDK N, do:
>>>>>>> # cd make/data/symbols
>>>>>>> # sh generate-data <path-to-JDK-N>
>>>>>>>
>>>>>>> I've added (in .01):
>>>>>>> # to regenerate the data for JDK N, run the above commands again
>>>>>>>
>>>>>>> What more should be there?
>>>>>>>
>>>>>>
>>>>>> I'd appreciate somewhere to have a textual discussion of how
>>>>>> make/data/symbols/symbols should be updated, the A = 10, B = 11, 
>>>>>> etc.
>>>>>> convention, what else need to be done to generate the contents of 
>>>>>> this
>>>>>> changeset.
>>>>>>
>>>>>> The <patch-to-JDK-N> is the contents of the build directory?
>>>>>>
>>>>>> In general, a description of how the data of JDK N should be 
>>>>>> added to
>>>>>> JDK (N+1).
>>>>>
>>>>> I've added more textual description to the script, an updated webrev
>>>>> is here:
>>>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.02/
>>>>>
>>>>> Jan
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Joe
>>>>>>
>>>>>>

From joe.darcy at oracle.com  Thu Feb  7 19:04:31 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 7 Feb 2019 11:04:31 -0800
Subject: RFR: JDK-8218630: CreateSymbols includes class and module headers
 unnecessarily.
In-Reply-To: <5C5C67B8.5050302@oracle.com>
References: <5C5C67B8.5050302@oracle.com>
Message-ID: <749c1759-8a84-995b-12f0-e81f369ddd02@oracle.com>

Hi Jan,

Is the revised historical data also available for review?

Thanks,

-Joe

On 2/7/2019 9:15 AM, Jan Lahoda wrote:
> Hi,
>
> Joe noted that the proposed historical data for JDK 12:
> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/
> may contain unnecessary items, and it indeed is the case.
>
> The main problems appear to be:
> -when the class headers are being compared, the nestMembers for the 
> current version may be null, and the nestMembers for the previous 
> version may be an empty list. So, currently, such headers won't match 
> and the header will be generated again to the historical record. 
> listMatch can be used to consider null and empty list to be the same
>
> -module header descriptions may refer to 
> RequiresDescription/ProvidesDescription, which are missing 
> hashCode/equals, which means that headers that have either requires or 
> provides won't match any of the existing headers. The fix is to add 
> hashCode and equals
>
> I generated the ct.sym for the original JDK 12 historical data from
> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/
>
> and the historical data generated by this patch, and the resulting 
> content appears to be equivalent.
>
> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8218630/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8218630
>
> How does this look?
>
> Thanks,
> ??? Jan

From joe.darcy at oracle.com  Thu Feb  7 19:08:15 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 7 Feb 2019 11:08:15 -0800
Subject: RFR: JDK-8218630: CreateSymbols includes class and module headers
 unnecessarily.
In-Reply-To: <749c1759-8a84-995b-12f0-e81f369ddd02@oracle.com>
References: <5C5C67B8.5050302@oracle.com>
 <749c1759-8a84-995b-12f0-e81f369ddd02@oracle.com>
Message-ID: <27d215e2-d5b4-ea53-bf9c-135fa6caaa98@oracle.com>

PS I see that data is already out for review on a different thread:

https://mail.openjdk.java.net/pipermail/compiler-dev/2019-February/012939.html
https://mail.openjdk.java.net/pipermail/build-dev/2019-February/024936.html

Thanks,

-Joe

On 2/7/2019 11:04 AM, Joe Darcy wrote:
> Hi Jan,
>
> Is the revised historical data also available for review?
>
> Thanks,
>
> -Joe
>
> On 2/7/2019 9:15 AM, Jan Lahoda wrote:
>> Hi,
>>
>> Joe noted that the proposed historical data for JDK 12:
>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/
>> may contain unnecessary items, and it indeed is the case.
>>
>> The main problems appear to be:
>> -when the class headers are being compared, the nestMembers for the 
>> current version may be null, and the nestMembers for the previous 
>> version may be an empty list. So, currently, such headers won't match 
>> and the header will be generated again to the historical record. 
>> listMatch can be used to consider null and empty list to be the same
>>
>> -module header descriptions may refer to 
>> RequiresDescription/ProvidesDescription, which are missing 
>> hashCode/equals, which means that headers that have either requires 
>> or provides won't match any of the existing headers. The fix is to 
>> add hashCode and equals
>>
>> I generated the ct.sym for the original JDK 12 historical data from
>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/
>>
>> and the historical data generated by this patch, and the resulting 
>> content appears to be equivalent.
>>
>> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8218630/webrev.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8218630
>>
>> How does this look?
>>
>> Thanks,
>> ??? Jan

From joe.darcy at oracle.com  Thu Feb  7 19:17:54 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 7 Feb 2019 11:17:54 -0800
Subject: RFR(13): JDK-8216263: Add historical data for JDK 12
In-Reply-To: <5C5C6929.30108@oracle.com>
References: <5C334A87.5080207@oracle.com> <5C33D7E0.2020609@oracle.com>
 <5C3477B7.8060307@oracle.com> <5C3FD6A8.1080803@oracle.com>
 <5C40B289.7070408@oracle.com>
 <967fdd5a-9810-4790-a164-2e39394fed66@oracle.com>
 <5C40CF23.4050608@oracle.com> <5C4207A4.1040203@oracle.com>
 <5C5C6929.30108@oracle.com>
Message-ID: <364fcd61-9e64-79c2-df7d-8bdfc6fa9f06@oracle.com>

Hi Jan,

Thanks for looking into this. The generated information is much smaller 
as you note, 1087 inserted lines vs 16328 inserted lines before.

 From looking over data for several modules, the revised changes look 
plausible in terms of corresponding to known work in those areas.

Looks good!

Cheers,

-Joe

On 2/7/2019 9:21 AM, Jan Lahoda wrote:
> Hello,
>
> I've regenerated the patch using JDK 12b30, and also using the patch 
> from:
> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-February/012938.html 
>
>
> (which makes the historical record smaller).
>
> The updated patch is here:
> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.04/
>
> How does that look?
>
> Thanks,
> ??? Jan
>
> On 18.1.2019 18:06, Jan Lahoda wrote:
>> Adding build-dev.
>>
>> Jan
>>
>> On 17.1.2019 19:53, Jan Lahoda wrote:
>>> On 17.1.2019 17:58, Jonathan Gibbons wrote:
>>>> Re:
>>>>
>>>> ?? 36 #?? The checkout must not have any local changes that could
>>>> interfere with the new data. In particular,
>>>> ?? 37 #?? there must be absolutely no changed, new or removed files
>>>> under the ${JDK_CHECKOUT}/make/data/symbols
>>>> ?? 38 #?? directory.
>>>>
>>>> That seems like a simple check that could be incorporated into the
>>>> script itself.
>>>>
>>>> But, it also seems reasonable to separate enhancements like that from
>>>> the specific issue here, to add historical data for 12.
>>>
>>> Ok. Sent as:
>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012879.html 
>>>
>>>
>>>
>>>
>>> And limited this patch to the historical data only:
>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.03/
>>>
>>> Thanks,
>>> ??? Jan
>>>
>>>>
>>>> -- Jon
>>>>
>>>> On 1/17/19 8:51 AM, Jan Lahoda wrote:
>>>>> Hi Joe,
>>>>>
>>>>> On 17.1.2019 02:13, Joseph D. Darcy wrote:
>>>>>> Hi Jan,
>>>>>>
>>>>>> On 1/8/2019 2:13 AM, Jan Lahoda wrote:
>>>>>>> Hi Joe,
>>>>>>>
>>>>>>> Thanks for the comments, some responses inline. Updated webrev:
>>>>>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.01/
>>>>>>>
>>>>>>> On 7.1.2019 23:51, Joseph D. Darcy wrote:
>>>>>>>> Hi Jan,
>>>>>>>>
>>>>>>>> On 1/7/2019 4:48 AM, Jan Lahoda wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> To make --release 12 work, we need to add historical data for JDK
>>>>>>>>> 12.
>>>>>>>>> The current historical data is based on:
>>>>>>>>> $ javac? -fullversion
>>>>>>>>> javac full version "12-ea+26"
>>>>>>>>>
>>>>>>>>> We may need to update the data once JDK 12 is out to cover any
>>>>>>>>> changes
>>>>>>>>> to the APIs that might happen.
>>>>>>>>>
>>>>>>>>> The patch also adds a simple (shell) script to generate the
>>>>>>>>> data, so
>>>>>>>>> all that was needed to generate the data was:
>>>>>>>>> $ cd make/data/symbols
>>>>>>>>> $ sh generate-data <path-to-JDK-12>
>>>>>>>>>
>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8216263
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/
>>>>>>>>>
>>>>>>>>> How does this look?
>>>>>>>>
>>>>>>>> If the overhead is small enough and we don't mind a few updates to
>>>>>>>> the
>>>>>>>> JDK N+1 data, than perhaps the generation of this information
>>>>>>>> could be
>>>>>>>> included as part of the start of JDK N+1 activities.
>>>>>>>
>>>>>>> That would be perfect!
>>>>>>>
>>>>>>>>
>>>>>>>> I suggest a more extensive description of how to
>>>>>>>> make/data/symbols/generate-data. For example, this builds the data
>>>>>>>> for
>>>>>>>> the current release independent of whether or not the current
>>>>>>>> release
>>>>>>>> has already had its data generated, correct?
>>>>>>>
>>>>>>> Yes.
>>>>>>>
>>>>>>>>
>>>>>>>> Concretely, if JDK N+1 has already forked, what is the proper way
>>>>>>>> to get
>>>>>>>> data for JDK N? Likewise, how should a re-build of the data for 
>>>>>>>> JDK
>>>>>>>> N be
>>>>>>>> done?
>>>>>>>
>>>>>>> What exactly should be there? To the existing description:
>>>>>>> # to generate (add) data for JDK N, do:
>>>>>>> # cd make/data/symbols
>>>>>>> # sh generate-data <path-to-JDK-N>
>>>>>>>
>>>>>>> I've added (in .01):
>>>>>>> # to regenerate the data for JDK N, run the above commands again
>>>>>>>
>>>>>>> What more should be there?
>>>>>>>
>>>>>>
>>>>>> I'd appreciate somewhere to have a textual discussion of how
>>>>>> make/data/symbols/symbols should be updated, the A = 10, B = 11, 
>>>>>> etc.
>>>>>> convention, what else need to be done to generate the contents of 
>>>>>> this
>>>>>> changeset.
>>>>>>
>>>>>> The <patch-to-JDK-N> is the contents of the build directory?
>>>>>>
>>>>>> In general, a description of how the data of JDK N should be 
>>>>>> added to
>>>>>> JDK (N+1).
>>>>>
>>>>> I've added more textual description to the script, an updated webrev
>>>>> is here:
>>>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.02/
>>>>>
>>>>> Jan
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Joe
>>>>>>
>>>>>>

From GROEGES at uk.ibm.com  Mon Feb 11 11:30:44 2019
From: GROEGES at uk.ibm.com (Steve Groeger)
Date: Mon, 11 Feb 2019 11:30:44 +0000
Subject: RFR: [8218152] javac fails and exits with no error if a bad
 annotation processor is on the classpath
In-Reply-To: <OF7F83CFD9.F0F7295C-ON80258394.0045435B-80258394.004621E7@notes.na.collabserv.com>
References: <OFF593C632.E3B4428B-ON80258391.003BB8A6-80258391.003E18A6@notes.na.collabserv.com>
 <c1cf308a-86d6-1222-9244-54c2fa45d8b9@oracle.com>
 <OFEE1EB4EE.D5ADB174-ON80258393.005BD593-80258393.005C6191@notes.na.collabserv.com>
 <c6f78065-0cb2-c4ea-8d31-bd5b0a1cc379@oracle.com>
 <OF7F83CFD9.F0F7295C-ON80258394.0045435B-80258394.004621E7@notes.na.collabserv.com>
Message-ID: <OFC787EC92.FB281DC0-ON8025839E.003F1622-8025839E.003F3D00@notes.na.collabserv.com>

Hi all, 

Is there anyone out there that would be able to review the webrevs 
mentioned in the earlier post.
Jonathan Gibbons has agreed to sponsor these changes but we need 2 
reviewers. Anyone?

Thanks
Steve Groeger
IBM Runtime Technologies
Hursley, Winchester
Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
Fax (44) 1962 816800
Lotus Notes: Steve Groeger/UK/IBM
Internet: groeges at uk.ibm.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



From:   Steve Groeger <GROEGES at uk.ibm.com>
To:     compiler-dev at openjdk.java.net
Date:   01/02/2019 12:47
Subject:        RFR: [8218152] javac fails and exits with no error if a 
bad annotation processor is on the classpath
Sent by:        "compiler-dev" <compiler-dev-bounces at openjdk.java.net>



Hi all, 

I have made some changes to the code for issue [1] for both jdk8u and jdk 
(jdk13) 
The latest webrevs have a few extra changes suggested by  Jonathan Gibbons 
mentioned in an earlier mailing [2] 
The webrevs are for jdk8u [3] and for jdk [4]. 
Please could someone review these changes and let me know if there are any 
issues. 

[1] https://bugs.openjdk.java.net/browse/JDK-8218152 
[2] 
https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012920.html 

[3] http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.01/ 
[4] http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.01/ 

Thanks
Steve Groeger
IBM Runtime Technologies
Hursley, Winchester
Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
Fax (44) 1962 816800
Lotus Notes: Steve Groeger/UK/IBM
Internet: groeges at uk.ibm.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 




From:        Jonathan Gibbons <jonathan.gibbons at oracle.com> 
To:        Steve Groeger <GROEGES at uk.ibm.com> 
Cc:        compiler-dev at openjdk.java.net 
Date:        31/01/2019 16:56 
Subject:        Re: [NEW_BUG] javac fails and exits with no error if a bad 
annotation processor is on the classpath 



Steve, 
When you post the new webrevs, can I suggest that you change the Subject 
line of this thread to something like 
RFR: 8218152 [javac] fails and exits with no error if a bad annotation 
processor provided 
That will help get attention from reviewers, and help any subsequent 
bug-archaeology. 
I can sponsor the changes for you once they have been reviewed. 
-- Jon 
On 1/31/19 8:49 AM, Steve Groeger wrote: 
Hi Jonathan, 

Thanks for responding. 

I have created a couple of webrevs for jdk8u [1] and jdk [2] which also 
include some JTReg tests. 
I would be grateful if you, or someone else could review these just to 
ensure I am doing the right thing. 
I will update the code with the additional 'throw FatalError' that you 
mentioned and will then create some new webrevs 

If you are able to sponsor these changes for me I would be very grateful. 

PS. As you saw I have created a JBS issue for this here [3] 

[1] http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.00/ 
[2] http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.00/ 
[3https://bugs.openjdk.java.net/browse/JDK-8218152 

Thanks
Steve Groeger
IBM Runtime Technologies
Hursley, Winchester
Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
Fax (44) 1962 816800
Lotus Notes: Steve Groeger/UK/IBM
Internet: groeges at uk.ibm.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 




From:        Jonathan Gibbons <jonathan.gibbons at oracle.com> 
To:        Steve Groeger <GROEGES at uk.ibm.com>, 
compiler-dev at openjdk.java.net 
Date:        31/01/2019 16:33 
Subject:        Re: [NEW_BUG] javac fails and exits with no error if a bad 
annotation processor is on the classpath 



Steve, 
Your fix is generally good: Abort should only be used after a suitable 
message has been reported. 
There's a `catch (Throwable t)` in the same set of catch blocks that you 
did not update. Rather than add yet another message for that case, it 
might be better to throw FatalError, to provoke the standard "javac crash" 
output for the unknown exception. 
You should provide a test case ... i.e. as a jtreg test. 
-- Jon 
On 1/29/19 3:18 AM, Steve Groeger wrote: 
Hi all, 

I have identified a potential issue where javac fails and exits with no 
error if a bad annotation processor is on the classpath. 

Background: an Annotation Processor class can be packaged in a jar file 
and is identified by a special text file inside the jar named: 
META-INF/services/javax.annotation.processing.Processor. This text file 
has only one line, specifying the class name of the annotation process 
class to run. When javac runs, it checks all jars on the classpath and if 
it finds the special text file in any jar file, then it attempts to run 
the class listed there. 

The issue here is that when the annotation processor class can't be 
executed, javac catches the exception and exits without reporting on the 
reason for the exit. Examples of reasons why the annotation processor 
can't be executed include: 
the annotation processor class is compiled for a higher version of Java 
than the javac is running, giving UnsupportedClassVersionError. 
the annotation processor class file is corrupt so can't be loaded.

In either of the above cases javac will swallow the error and exit without 
telling the user why it failed to compile the java source code as 
expected. 

Testcase 
   put HelloWorld.java in current directory, edit <path_to_jar> and run: 
         javac -cp .:<path_to_jar>/bad.annotation.processor.jar 
HelloWorld.java 

Instead of producing HelloWorld.class as expected, javac exits silently. 

Here, bad.annotation.processor.jar is a file that I created to contain: 
      META-INF/services/javax.annotation.processing.Processor <<-- text 
file to list bad class
     bad/notaclass.class <<-- dummy file, can't be loaded as a java class 

Does anyone know whether this is a bug and that this should throw an error 
in these cases? 
If so, I will raise a bug for this. 

I have looked at the code and seen where javac Aborts the processing, and 
if I make the following changes the javac detects the issue and reports an 
error before Aborting. 

diff -r 5178e4b58b17 
src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
--- 
a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 
     Mon Jan 28 09:56:00 2019 +0100 
+++ 
b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 
     Tue Jan 29 11:14:57 2019 +0000 
@@ -1,5 +1,5 @@ 
 /* 
- * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights 
reserved. 
+ * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights 
reserved. 
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 
  * 
  * This code is free software; you can redistribute it and/or modify it 
@@ -436,6 +436,12 @@ 
             } catch(ServiceConfigurationError sce) { 
 log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); 
                 throw new Abort(sce); 
+            } catch (UnsupportedClassVersionError ucve) { 
+ log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage())); 
+                throw new Abort(ucve); 
+            } catch (ClassFormatError cfe) { 
+ log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage())); 
+                throw new Abort(cfe); 
             } catch (Throwable t) { 
                 throw new Abort(t); 
             } 

and to add a new message there is this change 

diff -r 5178e4b58b17 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
--- 
a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties 
     Mon Jan 28 09:56:00 2019 +0100 
+++ 
b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties 
     Tue Jan 29 11:16:03 2019 +0000 
@@ -1,5 +1,5 @@ 
 # 
-# Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights 
reserved. 
+# Copyright (c) 1999, 2019, Oracle and/or its affiliates. All rights 
reserved. 
 # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 
 # 
 # This code is free software; you can redistribute it and/or modify it 
@@ -1051,6 +1051,10 @@ 
 compiler.err.proc.cant.find.class=\ 
     Could not find class file for ''{0}''. 

+# 0: string 
+compiler.err.proc.cant.load.class=\ 
+    Could not load processor class file due to ''{0}''. 
+ 
 # Print a client-generated error message; assumed to be localized, no 
translation required 
 # 0: string 
 compiler.err.proc.messager=\ 


If this is deemed a bug and the change seems OK, please could someone 
sponsor this for me and I will create a proper webrev for the change for a 
full review. 

Thanks
Steve Groeger
IBM Runtime Technologies
Hursley, Winchester
Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
Fax (44) 1962 816800
Lotus Notes: Steve Groeger/UK/IBM
Internet: groeges at uk.ibm.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190211/c93cb4ad/attachment-0001.html>

From jan.lahoda at oracle.com  Mon Feb 11 12:45:28 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 11 Feb 2019 13:45:28 +0100
Subject: RFR: [8218152] javac fails and exits with no error if a bad
 annotation processor is on the classpath
In-Reply-To: <OFC787EC92.FB281DC0-ON8025839E.003F1622-8025839E.003F3D00@notes.na.collabserv.com>
References: <OFF593C632.E3B4428B-ON80258391.003BB8A6-80258391.003E18A6@notes.na.collabserv.com>
 <c1cf308a-86d6-1222-9244-54c2fa45d8b9@oracle.com>
 <OFEE1EB4EE.D5ADB174-ON80258393.005BD593-80258393.005C6191@notes.na.collabserv.com>
 <c6f78065-0cb2-c4ea-8d31-bd5b0a1cc379@oracle.com>
 <OF7F83CFD9.F0F7295C-ON80258394.0045435B-80258394.004621E7@notes.na.collabserv.com>
 <OFC787EC92.FB281DC0-ON8025839E.003F1622-8025839E.003F3D00@notes.na.collabserv.com>
Message-ID: <5C616E68.5050103@oracle.com>

Hi Steve,

I apologize for a late reply.

One thing to note is that according to the ServiceLoader spec, the 
LinkageErrors shouldn't be thrown out of the Iterator. That is my 
reading at least. Please see:
https://bugs.openjdk.java.net/browse/JDK-8196182

Given there are some issues associated with that, I don't see a problem 
with workarounding that in javac. But I guess I'd personally rather kept 
it simple. Would there be an issue with simply changing the "catch 
(Throwable)" to also report the same error as "catch 
(ServiceConfigurationError)"? I.e. something like:
---
> diff -r 4ef401769c36 src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java     Fri Feb 08 14:06:35 2019 +0100
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java     Mon Feb 11 13:33:50 2019 +0100
> @@ -437,6 +437,7 @@
>                  log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>                  throw new Abort(sce);
>              } catch (Throwable t) {
> +                log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
>                  throw new Abort(t);
>              }
>          }
> @@ -453,6 +454,7 @@
>                  log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>                  throw new Abort(sce);
>              } catch (Throwable t) {
> +                log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
>                  throw new Abort(t);
>              }
>          }
---

Looking at the tests, one thing to note is that binary files are 
generally not allowed in the repository. I wonder if a test that would 
run javac programmaticaly wouldn't be easier to do, see e.g.:
test/langtools/tools/javac/processing/rounds/GetElementsAnnotatedWithOnMissing.java

This should allow arbitrary changes to the classfiles, so that binaries 
don't need to be in the repository.

Thanks,
     Jan

On 11.2.2019 12:30, Steve Groeger wrote:
> Hi all,
>
> Is there anyone out there that would be able to review the webrevs
> mentioned in the earlier post.
> Jonathan Gibbons has agreed to sponsor these changes but we need 2
> reviewers. Anyone?
>
> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, Winchester
> Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: groeges at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
> From: Steve Groeger <GROEGES at uk.ibm.com>
> To: compiler-dev at openjdk.java.net
> Date: 01/02/2019 12:47
> Subject: RFR: [8218152] javac fails and exits with no error if a bad
> annotation processor is on the classpath
> Sent by: "compiler-dev" <compiler-dev-bounces at openjdk.java.net>
> ------------------------------------------------------------------------
>
>
>
> Hi all,
>
> I have made some changes to the code for issue [1] for both jdk8u and
> jdk (jdk13)
> The latest webrevs have a few extra changes suggested by  Jonathan
> Gibbons mentioned in an earlier mailing [2]
> The webrevs are for jdk8u [3] and for jdk [4].
> Please could someone review these changes and let me know if there are
> any issues.
>
> [1] _https://bugs.openjdk.java.net/browse/JDK-8218152_
> [2]
> _https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012920.html_
> [3] _http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.01/_
> [4] _http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.01/_
>
> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, Winchester
> Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: groeges at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
> From: Jonathan Gibbons <jonathan.gibbons at oracle.com>
> To: Steve Groeger <GROEGES at uk.ibm.com>
> Cc: compiler-dev at openjdk.java.net
> Date: 31/01/2019 16:56
> Subject: Re: [NEW_BUG] javac fails and exits with no error if a bad
> annotation processor is on the classpath
> ------------------------------------------------------------------------
>
>
>
> Steve,
>
> When you post the new webrevs, can I suggest that you change the Subject
> line of this thread to something like
>
> RFR: 8218152 [javac] fails and exits with no error if a bad annotation
> processor provided
>
> That will help get attention from reviewers, and help any subsequent
> bug-archaeology.
>
> I can sponsor the changes for you once they have been reviewed.
>
> -- Jon
>
> On 1/31/19 8:49 AM, Steve Groeger wrote:
> Hi Jonathan,
>
> Thanks for responding.
>
> I have created a couple of webrevs for jdk8u [1] and jdk [2] which also
> include some JTReg tests.
> I would be grateful if you, or someone else could review these just to
> ensure I am doing the right thing.
> I will update the code with the additional 'throw FatalError' that you
> mentioned and will then create some new webrevs
>
> If you are able to sponsor these changes for me I would be very grateful.
>
> PS. As you saw I have created a JBS issue for this here [3]
>
> [1] _http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.00/_
> [2] _http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.00/_
> [3_https://bugs.openjdk.java.net/browse/JDK-8218152_
>
> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, Winchester
> Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: _groeges at uk.ibm.com_ <mailto:groeges at uk.ibm.com>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
> From: Jonathan Gibbons _<jonathan.gibbons at oracle.com>_
> <mailto:jonathan.gibbons at oracle.com>
> To: Steve Groeger _<GROEGES at uk.ibm.com>_ <mailto:GROEGES at uk.ibm.com>,
> _compiler-dev at openjdk.java.net_ <mailto:compiler-dev at openjdk.java.net>
> Date: 31/01/2019 16:33
> Subject: Re: [NEW_BUG] javac fails and exits with no error if a bad
> annotation processor is on the classpath
>
> ------------------------------------------------------------------------
>
>
>
> Steve,
>
> Your fix is generally good: Abort should only be used after a suitable
> message has been reported.
>
> There's a `catch (Throwable t)` in the same set of catch blocks that you
> did not update. Rather than add yet another message for that case, it
> might be better to throw FatalError, to provoke the standard "javac
> crash" output for the unknown exception.
>
> You should provide a test case ... i.e. as a jtreg test.
>
> -- Jon
>
> On 1/29/19 3:18 AM, Steve Groeger wrote:
> Hi all,
>
> I have identified a potential issue where javac fails and exits with no
> error if a bad annotation processor is on the classpath.
>
> Background: an Annotation Processor class can be packaged in a jar file
> and is identified by a special text file inside the jar named:
> META-INF/services/javax.annotation.processing.Processor. This text file
> has only one line, specifying the class name of the annotation process
> class to run. When javac runs, it checks all jars on the classpath and
> if it finds the special text file in any jar file, then it attempts to
> run the class listed there.
>
> The issue here is that when the annotation processor class can't be
> executed, javac catches the exception and exits without reporting on the
> reason for the exit. Examples of reasons why the annotation processor
> can't be executed include:
>
>   * the annotation processor class is compiled for a higher version of
>     Java than the javac is running, giving UnsupportedClassVersionError.
>   * the annotation processor class file is corrupt so can't be loaded.
>
>
> In either of the above cases javac will swallow the error and exit
> without telling the user why it failed to compile the java source code
> as expected.
>
> Testcase
>    put HelloWorld.java in current directory, edit <path_to_jar> and run:
>          javac -cp .:<path_to_jar>/bad.annotation.processor.jar
> HelloWorld.java
>
> Instead of producing HelloWorld.class as expected, javac exits silently.
>
> Here, bad.annotation.processor.jar is a file that I created to contain:
>       META-INF/services/javax.annotation.processing.Processor <<-- text
> file to list bad class
>      bad/notaclass.class <<-- dummy file, can't be loaded as a java class
>
> Does anyone know whether this is a bug and that this should throw an
> error in these cases?
> If so, I will raise a bug for this.
>
> I have looked at the code and seen where javac Aborts the processing,
> and if I make the following changes the javac detects the issue and
> reports an error before Aborting.
>
> diff -r 5178e4b58b17
> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
> ---
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>       Mon Jan 28 09:56:00 2019 +0100
> +++
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>       Tue Jan 29 11:14:57 2019 +0000
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -436,6 +436,12 @@
>              } catch(ServiceConfigurationError sce) {
>
> log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>                  throw new Abort(sce);
> +            } catch (UnsupportedClassVersionError ucve) {
> +
>   log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage()));
> +                throw new Abort(ucve);
> +            } catch (ClassFormatError cfe) {
> +
>   log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage()));
> +                throw new Abort(cfe);
>              } catch (Throwable t) {
>                  throw new Abort(t);
>              }
>
> and to add a new message there is this change
>
> diff -r 5178e4b58b17
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
> ---
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>       Mon Jan 28 09:56:00 2019 +0100
> +++
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>       Tue Jan 29 11:16:03 2019 +0000
> @@ -1,5 +1,5 @@
> #
> -# Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights
> reserved.
> +# Copyright (c) 1999, 2019, Oracle and/or its affiliates. All rights
> reserved.
> # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> #
> # This code is free software; you can redistribute it and/or modify it
> @@ -1051,6 +1051,10 @@
> compiler.err.proc.cant.find.class=\
>      Could not find class file for ''{0}''.
>
> +# 0: string
> +compiler.err.proc.cant.load.class=\
> +    Could not load processor class file due to ''{0}''.
> +
> # Print a client-generated error message; assumed to be localized, no
> translation required
> # 0: string
> compiler.err.proc.messager=\
>
>
> If this is deemed a bug and the change seems OK, please could someone
> sponsor this for me and I will create a proper webrev for the change for
> a full review.
>
> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, Winchester
> Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: _groeges at uk.ibm.com_ <mailto:groeges at uk.ibm.com>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From jonathan.gibbons at oracle.com  Tue Feb 12 01:01:58 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 11 Feb 2019 17:01:58 -0800
Subject: RFR: JDK-8217381: Inconvenient errors reported when annotation
 processor generates source file and errors in the same round
In-Reply-To: <5C471DF6.9030707@oracle.com>
References: <5C471DF6.9030707@oracle.com>
Message-ID: <6d18e3f9-789b-4799-0a29-fb63331cf37d@oracle.com>

Functionally OK, just minor nits

The rename in JCDiagnostic is OK, but the comment is a little obscure 
and could be clarified.

In Log.java, the name `acceptor` is a little clunky. That being said, 
it's in the dictionary, although the alternative spelling, accepter, 
looks better.

No need to re-review.

-- Jon

On 01/22/2019 05:43 AM, Jan Lahoda wrote:
> Hi,
>
> When an annotation processor generates a source and an error in the 
> same round, javac (may) print errors saying it cannot find the types 
> from the generated source.
>
> The proposal here is to improve the errors by deferring recoverable 
> error until the newly generated source is analyzed.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8217381
> Webrev: http://cr.openjdk.java.net/~jlahoda/8217381/webrev.00/
>
> How does this look?
>
> Thanks,
> ??? Jan


From jonathan.gibbons at oracle.com  Tue Feb 12 01:27:29 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 11 Feb 2019 17:27:29 -0800
Subject: RFR: JDK-8217868: Crash for overlap between source path and patch
 module path
In-Reply-To: <5C5C5FE7.3050406@oracle.com>
References: <5C5C5FE7.3050406@oracle.com>
Message-ID: <338d17e8-7430-fca1-c550-32671fc04c23@oracle.com>

Why the call of modules.newRound() in JavadocTool line 202?

As I read it, nothing much should have happened to the modules up to 
this point ... the code has just been parsing files, hasn't it?

The use case looks interesting, because it does look like a 
configuration error and so I was expecting more conflict detection, but 
maybe that's a different separable problem.? I guess if ever we had a 
patch path for a module mX that pointed to a directory containing a 
module-info.java containing mY, and we needed mX, we would get some sort 
of "wrong module found" error. Here, we have the patch path matching the 
sourcepath, but presumably we can't go round pairwise checking paths for 
silly combinations.

-- Jon


On 02/07/2019 08:42 AM, Jan Lahoda wrote:
> Hi,
>
> Consider code like this:
> ---src/module-info.java
> module m { uses test.Test; }
> ---src/test/Test.java
> package test; public class Test { }
>
> And javac invocation like:
> javac -sourcepath src --patch-module m2=src module-info.java
>
> While analysing the module-info, javac will try to lazily/implicitly 
> load the test.Test class. And when Modules.setCompilationUnitModules 
> is called for test.Test, it will eventually call singleModuleOverride, 
> which will look at --patch-module to find if the given source is on 
> any module patch. And it will find out it is a module patch for m2, 
> but as javac never heard about m2 before, it will crash.
>
> Seems that the biggest underlying problem is that even though javac 
> knows which modules owns the class, it will try to look for the owner 
> on the patch path. The proposed patch fixes that, and uses the correct 
> owning module. This requires also a little cleanup in javadoc.
>
> Webrev: cr.openjdk.java.net/~jlahoda/8217868/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8217868
>
> How does this look?
>
> Thanks,
> ??? Jan


From srinivas.dama at oracle.com  Tue Feb 12 10:17:07 2019
From: srinivas.dama at oracle.com (srinivas.dama at oracle.com)
Date: Tue, 12 Feb 2019 15:47:07 +0530
Subject: RFR: 8201544: Improve javac command line parsing and error reporting
Message-ID: <a5745d73-a949-7f1e-0493-c3b8a36fa4c5@oracle.com>

Hi,

Please review http://cr.openjdk.java.net/~sdama/8201544/webrev.02/

for https://bugs.openjdk.java.net/browse/JDK-8201544.

This issue is specific to windows.

Currently when * character is present in filename passed through API 
call, javac throws weird exception message. With the fix, it is now 
modified to throw an error instead of exception.

Regards,

Srinivas



From jan.lahoda at oracle.com  Tue Feb 12 13:52:14 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 12 Feb 2019 14:52:14 +0100
Subject: RFR: JDK-8217868: Crash for overlap between source path and patch
 module path
In-Reply-To: <338d17e8-7430-fca1-c550-32671fc04c23@oracle.com>
References: <5C5C5FE7.3050406@oracle.com>
 <338d17e8-7430-fca1-c550-32671fc04c23@oracle.com>
Message-ID: <5C62CF8E.5010107@oracle.com>

Hi Jon,

Thanks for the comments!

On 12.2.2019 02:27, Jonathan Gibbons wrote:
> Why the call of modules.newRound() in JavadocTool line 202?
>
> As I read it, nothing much should have happened to the modules up to
> this point ... the code has just been parsing files, hasn't it?

ElementsTable.scanSpecifiedItems is calling initModules at the end, and 
is invoked from:

             etable.packages(packageNames)
                     .classTrees(classTrees.toList())
                     .scanSpecifiedItems();


I tried to remove that, but it turned out 
ElementsTable.findModuleOfPackageName needs the module system to be 
set-up, and is (eventually) called from ElementsTable.getFilesToParse. 
So I've incline to let the module system set-up and then set it up 
again, using newRound() to clear it between.

(If needed, we could keep the javadoc tool(s) untouched, by having one 
more check in Modules.)

>
> The use case looks interesting, because it does look like a
> configuration error and so I was expecting more conflict detection, but
> maybe that's a different separable problem.  I guess if ever we had a
> patch path for a module mX that pointed to a directory containing a
> module-info.java containing mY, and we needed mX, we would get some sort
> of "wrong module found" error. Here, we have the patch path matching the
> sourcepath, but presumably we can't go round pairwise checking paths for
> silly combinations.

I guess we could (and maybe should) have a task to introduce a warning 
for cases like this. But javac knows from which module it was reading 
the file from, so seemed more reliable to simply reuse that knowledge.

Jan

>
> -- Jon
>
>
> On 02/07/2019 08:42 AM, Jan Lahoda wrote:
>> Hi,
>>
>> Consider code like this:
>> ---src/module-info.java
>> module m { uses test.Test; }
>> ---src/test/Test.java
>> package test; public class Test { }
>>
>> And javac invocation like:
>> javac -sourcepath src --patch-module m2=src module-info.java
>>
>> While analysing the module-info, javac will try to lazily/implicitly
>> load the test.Test class. And when Modules.setCompilationUnitModules
>> is called for test.Test, it will eventually call singleModuleOverride,
>> which will look at --patch-module to find if the given source is on
>> any module patch. And it will find out it is a module patch for m2,
>> but as javac never heard about m2 before, it will crash.
>>
>> Seems that the biggest underlying problem is that even though javac
>> knows which modules owns the class, it will try to look for the owner
>> on the patch path. The proposed patch fixes that, and uses the correct
>> owning module. This requires also a little cleanup in javadoc.
>>
>> Webrev: cr.openjdk.java.net/~jlahoda/8217868/webrev.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217868
>>
>> How does this look?
>>
>> Thanks,
>>     Jan
>

From GROEGES at uk.ibm.com  Wed Feb 13 09:58:05 2019
From: GROEGES at uk.ibm.com (Steve Groeger)
Date: Wed, 13 Feb 2019 09:58:05 +0000
Subject: RFR: [8218152] javac fails and exits with no error if a bad
 annotation processor is on the classpath
In-Reply-To: <5C616E68.5050103@oracle.com>
References: <OFF593C632.E3B4428B-ON80258391.003BB8A6-80258391.003E18A6@notes.na.collabserv.com>
 <c1cf308a-86d6-1222-9244-54c2fa45d8b9@oracle.com>
 <OFEE1EB4EE.D5ADB174-ON80258393.005BD593-80258393.005C6191@notes.na.collabserv.com>
 <c6f78065-0cb2-c4ea-8d31-bd5b0a1cc379@oracle.com>
 <OF7F83CFD9.F0F7295C-ON80258394.0045435B-80258394.004621E7@notes.na.collabserv.com>
 <OFC787EC92.FB281DC0-ON8025839E.003F1622-8025839E.003F3D00@notes.na.collabserv.com>
 <5C616E68.5050103@oracle.com>
Message-ID: <OF05AD88C8.5056BCAA-ON802583A0.00362FFF-802583A0.0036C19B@notes.na.collabserv.com>

Hi Jan, 

Thanks for the response.

With regards to your comments re:

>But I guess I'd personally rather kept 
>it simple. Would there be an issue with simply changing the "catch 
>(Throwable)" to also report the same error as "catch 
>(ServiceConfigurationError)"? I.e. something like:
>>---
>> diff -r 4ef401769c36 
src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>> --- 
a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 
    Fri Feb 08 14:06:35 2019 +0100
>> +++ 
b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 
    Mon Feb 11 13:33:50 2019 +0100
>> @@ -437,6 +437,7 @@
>> log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>>                  throw new Abort(sce);
>>              } catch (Throwable t) {
>> + log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
>>                  throw new Abort(t);
>>              }
>>          }
>> @@ -453,6 +454,7 @@
>> log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>>                  throw new Abort(sce);
>>              } catch (Throwable t) {
>> + log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
>>                  throw new Abort(t);
>>              }
>>          }
>---

I can do it the waty you sugegsted but I had done it this way because 
Jonathan Gibbons had stated:

>> There's a `catch (Throwable t)` in the same set of catch blocks that 
you
>> did not update. Rather than add yet another message for that case, it
>> might be better to throw FatalError, to provoke the standard "javac
>> crash" output for the unknown exception.

Either way is OK with me. We just need to make a decision on which is the 
preferred way - then I can update the webrevs.

>Looking at the tests, one thing to note is that binary files are 
>generally not allowed in the repository. I wonder if a test that would 
>run javac programmaticaly wouldn't be easier to do

I will take yopur advice on the tests and see if I can do this 
programtically rather than havng the binary files in the repository.

Will post again in the mailing list when I have updated webrevs that are 
suitable for being reviewed.

Thanks
Steve Groeger
IBM Runtime Technologies
Hursley, Winchester
Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
Fax (44) 1962 816800
Lotus Notes: Steve Groeger/UK/IBM
Internet: groeges at uk.ibm.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



From:   Jan Lahoda <jan.lahoda at oracle.com>
To:     Steve Groeger <GROEGES at uk.ibm.com>, compiler-dev at openjdk.java.net
Date:   11/02/2019 12:45
Subject:        Re: RFR: [8218152] javac fails and exits with no error if 
a bad annotation processor is on the classpath



Hi Steve,

I apologize for a late reply.

One thing to note is that according to the ServiceLoader spec, the 
LinkageErrors shouldn't be thrown out of the Iterator. That is my 
reading at least. Please see:
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8196182&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=mtVljMuzQaGWDLF3MWIp9x8aotlYKRR0DpRI9BjDwuI&e=


Given there are some issues associated with that, I don't see a problem 
with workarounding that in javac. But I guess I'd personally rather kept 
it simple. Would there be an issue with simply changing the "catch 
(Throwable)" to also report the same error as "catch 
(ServiceConfigurationError)"? I.e. something like:
---
> diff -r 4ef401769c36 
src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
> --- 
a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 
    Fri Feb 08 14:06:35 2019 +0100
> +++ 
b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 
    Mon Feb 11 13:33:50 2019 +0100
> @@ -437,6 +437,7 @@
> log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>                  throw new Abort(sce);
>              } catch (Throwable t) {
> + log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
>                  throw new Abort(t);
>              }
>          }
> @@ -453,6 +454,7 @@
> log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>                  throw new Abort(sce);
>              } catch (Throwable t) {
> + log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
>                  throw new Abort(t);
>              }
>          }
---

Looking at the tests, one thing to note is that binary files are 
generally not allowed in the repository. I wonder if a test that would 
run javac programmaticaly wouldn't be easier to do, see e.g.:
test/langtools/tools/javac/processing/rounds/GetElementsAnnotatedWithOnMissing.java

This should allow arbitrary changes to the classfiles, so that binaries 
don't need to be in the repository.

Thanks,
     Jan

On 11.2.2019 12:30, Steve Groeger wrote:
> Hi all,
>
> Is there anyone out there that would be able to review the webrevs
> mentioned in the earlier post.
> Jonathan Gibbons has agreed to sponsor these changes but we need 2
> reviewers. Anyone?
>
> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, Winchester
> Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: groeges at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
>
>
>
> From: Steve Groeger <GROEGES at uk.ibm.com>
> To: compiler-dev at openjdk.java.net
> Date: 01/02/2019 12:47
> Subject: RFR: [8218152] javac fails and exits with no error if a bad
> annotation processor is on the classpath
> Sent by: "compiler-dev" <compiler-dev-bounces at openjdk.java.net>
> ------------------------------------------------------------------------
>
>
>
> Hi all,
>
> I have made some changes to the code for issue [1] for both jdk8u and
> jdk (jdk13)
> The latest webrevs have a few extra changes suggested by  Jonathan
> Gibbons mentioned in an earlier mailing [2]
> The webrevs are for jdk8u [3] and for jdk [4].
> Please could someone review these changes and let me know if there are
> any issues.
>
> [1] 
_https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8218152-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=GXmb6NEDC3BhXyEw8uaNod2uN_hYX-9HpHkoiGhEujY&e=
> [2]
> 
_https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openjdk.java.net_pipermail_compiler-2Ddev_2019-2DJanuary_012920.html-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=AhWE854aM6al5na1Eo9sxF4IoWBZC3jfvLHRo2a2ETo&e=
> [3] 
_https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.01_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=OM__1ZIlBCUXiHNLfltEv9c_6a8k8nspR0KnKjRT8II&e=
> [4] 
_https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.01_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=HrpL5tvveJrGX0ABN9uGRn0bZV1nsiNxzuLOAVem3Z0&e=
>
> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, Winchester
> Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: groeges at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
>
>
>
> From: Jonathan Gibbons <jonathan.gibbons at oracle.com>
> To: Steve Groeger <GROEGES at uk.ibm.com>
> Cc: compiler-dev at openjdk.java.net
> Date: 31/01/2019 16:56
> Subject: Re: [NEW_BUG] javac fails and exits with no error if a bad
> annotation processor is on the classpath
> ------------------------------------------------------------------------
>
>
>
> Steve,
>
> When you post the new webrevs, can I suggest that you change the Subject
> line of this thread to something like
>
> RFR: 8218152 [javac] fails and exits with no error if a bad annotation
> processor provided
>
> That will help get attention from reviewers, and help any subsequent
> bug-archaeology.
>
> I can sponsor the changes for you once they have been reviewed.
>
> -- Jon
>
> On 1/31/19 8:49 AM, Steve Groeger wrote:
> Hi Jonathan,
>
> Thanks for responding.
>
> I have created a couple of webrevs for jdk8u [1] and jdk [2] which also
> include some JTReg tests.
> I would be grateful if you, or someone else could review these just to
> ensure I am doing the right thing.
> I will update the code with the additional 'throw FatalError' that you
> mentioned and will then create some new webrevs
>
> If you are able to sponsor these changes for me I would be very 
grateful.
>
> PS. As you saw I have created a JBS issue for this here [3]
>
> [1] 
_https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.00_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=JoEgW12V0tuoZvuG9GDF7g5YmXhjGolWyibAYlifWME&e=
> [2] 
_https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.00_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=NeM6uUrEq-vcqXQ5uHonCor_ChwsY20notpASJS4is8&e=
> 
[3_https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8218152-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=GXmb6NEDC3BhXyEw8uaNod2uN_hYX-9HpHkoiGhEujY&e=
>
> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, Winchester
> Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: _groeges at uk.ibm.com_ <mailto:groeges at uk.ibm.com>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
>
>
>
> From: Jonathan Gibbons _<jonathan.gibbons at oracle.com>_
> <mailto:jonathan.gibbons at oracle.com>
> To: Steve Groeger _<GROEGES at uk.ibm.com>_ <mailto:GROEGES at uk.ibm.com>,
> _compiler-dev at openjdk.java.net_ <mailto:compiler-dev at openjdk.java.net>
> Date: 31/01/2019 16:33
> Subject: Re: [NEW_BUG] javac fails and exits with no error if a bad
> annotation processor is on the classpath
>
> ------------------------------------------------------------------------
>
>
>
> Steve,
>
> Your fix is generally good: Abort should only be used after a suitable
> message has been reported.
>
> There's a `catch (Throwable t)` in the same set of catch blocks that you
> did not update. Rather than add yet another message for that case, it
> might be better to throw FatalError, to provoke the standard "javac
> crash" output for the unknown exception.
>
> You should provide a test case ... i.e. as a jtreg test.
>
> -- Jon
>
> On 1/29/19 3:18 AM, Steve Groeger wrote:
> Hi all,
>
> I have identified a potential issue where javac fails and exits with no
> error if a bad annotation processor is on the classpath.
>
> Background: an Annotation Processor class can be packaged in a jar file
> and is identified by a special text file inside the jar named:
> META-INF/services/javax.annotation.processing.Processor. This text file
> has only one line, specifying the class name of the annotation process
> class to run. When javac runs, it checks all jars on the classpath and
> if it finds the special text file in any jar file, then it attempts to
> run the class listed there.
>
> The issue here is that when the annotation processor class can't be
> executed, javac catches the exception and exits without reporting on the
> reason for the exit. Examples of reasons why the annotation processor
> can't be executed include:
>
>   * the annotation processor class is compiled for a higher version of
>     Java than the javac is running, giving UnsupportedClassVersionError.
>   * the annotation processor class file is corrupt so can't be loaded.
>
>
> In either of the above cases javac will swallow the error and exit
> without telling the user why it failed to compile the java source code
> as expected.
>
> Testcase
>    put HelloWorld.java in current directory, edit <path_to_jar> and run:
>          javac -cp .:<path_to_jar>/bad.annotation.processor.jar
> HelloWorld.java
>
> Instead of producing HelloWorld.class as expected, javac exits silently.
>
> Here, bad.annotation.processor.jar is a file that I created to contain:
>       META-INF/services/javax.annotation.processing.Processor <<-- text
> file to list bad class
>      bad/notaclass.class <<-- dummy file, can't be loaded as a java 
class
>
> Does anyone know whether this is a bug and that this should throw an
> error in these cases?
> If so, I will raise a bug for this.
>
> I have looked at the code and seen where javac Aborts the processing,
> and if I make the following changes the javac detects the issue and
> reports an error before Aborting.
>
> diff -r 5178e4b58b17
> 
src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
> ---
> 
a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>       Mon Jan 28 09:56:00 2019 +0100
> +++
> 
b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>       Tue Jan 29 11:14:57 2019 +0000
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -436,6 +436,12 @@
>              } catch(ServiceConfigurationError sce) {
>
> log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>                  throw new Abort(sce);
> +            } catch (UnsupportedClassVersionError ucve) {
> +
>   log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage()));
> +                throw new Abort(ucve);
> +            } catch (ClassFormatError cfe) {
> +
>   log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage()));
> +                throw new Abort(cfe);
>              } catch (Throwable t) {
>                  throw new Abort(t);
>              }
>
> and to add a new message there is this change
>
> diff -r 5178e4b58b17
> 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
> ---
> 
a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>       Mon Jan 28 09:56:00 2019 +0100
> +++
> 
b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>       Tue Jan 29 11:16:03 2019 +0000
> @@ -1,5 +1,5 @@
> #
> -# Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights
> reserved.
> +# Copyright (c) 1999, 2019, Oracle and/or its affiliates. All rights
> reserved.
> # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> #
> # This code is free software; you can redistribute it and/or modify it
> @@ -1051,6 +1051,10 @@
> compiler.err.proc.cant.find.class=\
>      Could not find class file for ''{0}''.
>
> +# 0: string
> +compiler.err.proc.cant.load.class=\
> +    Could not load processor class file due to ''{0}''.
> +
> # Print a client-generated error message; assumed to be localized, no
> translation required
> # 0: string
> compiler.err.proc.messager=\
>
>
> If this is deemed a bug and the change seems OK, please could someone
> sponsor this for me and I will create a proper webrev for the change for
> a full review.
>
> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, Winchester
> Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: _groeges at uk.ibm.com_ <mailto:groeges at uk.ibm.com>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190213/0cdbc40c/attachment-0001.html>

From jan.lahoda at oracle.com  Wed Feb 13 14:24:00 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 13 Feb 2019 15:24:00 +0100
Subject: RFR(13): JDK-8217047: Provide a way to inject missing parameter
 names
In-Reply-To: <5C45BBE5.6030007@oracle.com>
References: <5C45BBE5.6030007@oracle.com>
Message-ID: <5C642880.9030609@oracle.com>

Hi,

Based on feedback, I've updated the javadoc. Also, when 
ParameterNameProvider.getParameterName returns null, the javac's default 
name will be returned from VariableElement.getSimpleName(), so I've made 
this explicit in the javadoc and added a test for that.

Updated webrev: http://cr.openjdk.java.net/~jlahoda/8217047/webrev.02/
Updated specdiff:
http://cr.openjdk.java.net/~jlahoda/8217047/specdiff.02/overview-summary.html

How does this look?

Thanks,
     Jan

On 21.1.2019 13:32, Jan Lahoda wrote:
> Hi,
>
> When a type is load from a classfile, and some or all of its methods
> have neither the MethodParameters or LocalVariableTable attributes, then
> the parameters of the methods have an artificial synthesized name, which
> is visible through VariableElement.getSimpleName().
>
> The proposal here is to allow to plug in an external provider that could
> provide more user-friendly names lazily/on demand. These could originate
> e.g. in adjacent sources.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8217437
> Webrev: http://cr.openjdk.java.net/~jlahoda/8217047/webrev.01/
> Specdiff:
> http://cr.openjdk.java.net/~jlahoda/8217047/specdiff.01/overview-summary.html
>
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8217437
>
> What do you think?
>
> Thanks,
>      Jan

From jan.lahoda at oracle.com  Wed Feb 13 15:08:11 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 13 Feb 2019 16:08:11 +0100
Subject: RFR: [8218152] javac fails and exits with no error if a bad
 annotation processor is on the classpath
In-Reply-To: <OF05AD88C8.5056BCAA-ON802583A0.00362FFF-802583A0.0036C19B@notes.na.collabserv.com>
References: <OFF593C632.E3B4428B-ON80258391.003BB8A6-80258391.003E18A6@notes.na.collabserv.com>
 <c1cf308a-86d6-1222-9244-54c2fa45d8b9@oracle.com>
 <OFEE1EB4EE.D5ADB174-ON80258393.005BD593-80258393.005C6191@notes.na.collabserv.com>
 <c6f78065-0cb2-c4ea-8d31-bd5b0a1cc379@oracle.com>
 <OF7F83CFD9.F0F7295C-ON80258394.0045435B-80258394.004621E7@notes.na.collabserv.com>
 <OFC787EC92.FB281DC0-ON8025839E.003F1622-8025839E.003F3D00@notes.na.collabserv.com>
 <5C616E68.5050103@oracle.com>
 <OF05AD88C8.5056BCAA-ON802583A0.00362FFF-802583A0.0036C19B@notes.na.collabserv.com>
Message-ID: <5C6432DB.7070208@oracle.com>

On 13.2.2019 10:58, Steve Groeger wrote:
> Hi Jan,
>
> Thanks for the response.
>
> With regards to your comments re:
>
>  >But I guess I'd personally rather kept
>  >it simple. Would there be an issue with simply changing the "catch
>  >(Throwable)" to also report the same error as "catch
>  >(ServiceConfigurationError)"? I.e. something like:
>  >>---
>  >> diff -r 4ef401769c36
> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  >> ---
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>      Fri Feb 08 14:06:35 2019 +0100
>  >> +++
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>      Mon Feb 11 13:33:50 2019 +0100
>  >> @@ -437,6 +437,7 @@
>  >>
>   log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>  >>                  throw new Abort(sce);
>  >>              } catch (Throwable t) {
>  >> +
>   log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
>  >>                  throw new Abort(t);
>  >>              }
>  >>          }
>  >> @@ -453,6 +454,7 @@
>  >>
>   log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>  >>                  throw new Abort(sce);
>  >>              } catch (Throwable t) {
>  >> +
>   log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
>  >>                  throw new Abort(t);
>  >>              }
>  >>          }
>  >---
>
> I can do it the waty you sugegsted but I had done it this way because
> Jonathan Gibbons had stated:
>
>  >> There's a `catch (Throwable t)` in the same set of catch blocks that you
>  >> did not update. Rather than add yet another message for that case, it
>  >> might be better to throw FatalError, to provoke the standard "javac
>  >> crash" output for the unknown exception.
>
> Either way is OK with me. We just need to make a decision on which is
> the preferred way - then I can update the webrevs.

To me personally, FatalError feels a little bit harsh. But I agree we 
should try to avoid adding new error messages for this if possible. I'll 
leave it up to Jon.

(If we wanted to always print a stack trace for these problems, we could 
change to code to simply throw AnnotationProcessingError, which always 
prints the stacktrace - some tweaking to make the errors look good might 
be needed, though.)

Jan

>
>  >Looking at the tests, one thing to note is that binary files are
>  >generally not allowed in the repository. I wonder if a test that would
>  >run javac programmaticaly wouldn't be easier to do
>
> I will take yopur advice on the tests and see if I can do this
> programtically rather than havng the binary files in the repository.
>
> Will post again in the mailing list when I have updated webrevs that are
> suitable for being reviewed.
>
> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, Winchester
> Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: groeges at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
> From: Jan Lahoda <jan.lahoda at oracle.com>
> To: Steve Groeger <GROEGES at uk.ibm.com>, compiler-dev at openjdk.java.net
> Date: 11/02/2019 12:45
> Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad
> annotation processor is on the classpath
> ------------------------------------------------------------------------
>
>
>
> Hi Steve,
>
> I apologize for a late reply.
>
> One thing to note is that according to the ServiceLoader spec, the
> LinkageErrors shouldn't be thrown out of the Iterator. That is my
> reading at least. Please see:
> https://bugs.openjdk.java.net/browse/JDK-8196182
>
> Given there are some issues associated with that, I don't see a problem
> with workarounding that in javac. But I guess I'd personally rather kept
> it simple. Would there be an issue with simply changing the "catch
> (Throwable)" to also report the same error as "catch
> (ServiceConfigurationError)"? I.e. something like:
> ---
>  > diff -r 4ef401769c36
> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  > ---
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>      Fri Feb 08 14:06:35 2019 +0100
>  > +++
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>      Mon Feb 11 13:33:50 2019 +0100
>  > @@ -437,6 +437,7 @@
>  >
>   log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>  >                  throw new Abort(sce);
>  >              } catch (Throwable t) {
>  > +
>   log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
>  >                  throw new Abort(t);
>  >              }
>  >          }
>  > @@ -453,6 +454,7 @@
>  >
>   log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>  >                  throw new Abort(sce);
>  >              } catch (Throwable t) {
>  > +
>   log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
>  >                  throw new Abort(t);
>  >              }
>  >          }
> ---
>
> Looking at the tests, one thing to note is that binary files are
> generally not allowed in the repository. I wonder if a test that would
> run javac programmaticaly wouldn't be easier to do, see e.g.:
> test/langtools/tools/javac/processing/rounds/GetElementsAnnotatedWithOnMissing.java
>
> This should allow arbitrary changes to the classfiles, so that binaries
> don't need to be in the repository.
>
> Thanks,
>      Jan
>
> On 11.2.2019 12:30, Steve Groeger wrote:
>  > Hi all,
>  >
>  > Is there anyone out there that would be able to review the webrevs
>  > mentioned in the earlier post.
>  > Jonathan Gibbons has agreed to sponsor these changes but we need 2
>  > reviewers. Anyone?
>  >
>  > Thanks
>  > Steve Groeger
>  > IBM Runtime Technologies
>  > Hursley, Winchester
>  > Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
>  > Fax (44) 1962 816800
>  > Lotus Notes: Steve Groeger/UK/IBM
>  > Internet: groeges at uk.ibm.com
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>  >
>  >
>  >
>  > From: Steve Groeger <GROEGES at uk.ibm.com>
>  > To: compiler-dev at openjdk.java.net
>  > Date: 01/02/2019 12:47
>  > Subject: RFR: [8218152] javac fails and exits with no error if a bad
>  > annotation processor is on the classpath
>  > Sent by: "compiler-dev" <compiler-dev-bounces at openjdk.java.net>
>  > ------------------------------------------------------------------------
>  >
>  >
>  >
>  > Hi all,
>  >
>  > I have made some changes to the code for issue [1] for both jdk8u and
>  > jdk (jdk13)
>  > The latest webrevs have a few extra changes suggested by  Jonathan
>  > Gibbons mentioned in an earlier mailing [2]
>  > The webrevs are for jdk8u [3] and for jdk [4].
>  > Please could someone review these changes and let me know if there are
>  > any issues.
>  >
>  > [1]
> _https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8218152-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=GXmb6NEDC3BhXyEw8uaNod2uN_hYX-9HpHkoiGhEujY&e=
>  > [2]
>  >
> _https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openjdk.java.net_pipermail_compiler-2Ddev_2019-2DJanuary_012920.html-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=AhWE854aM6al5na1Eo9sxF4IoWBZC3jfvLHRo2a2ETo&e=
>  > [3]
> _https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.01_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=OM__1ZIlBCUXiHNLfltEv9c_6a8k8nspR0KnKjRT8II&e=
>  > [4]
> _https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.01_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=HrpL5tvveJrGX0ABN9uGRn0bZV1nsiNxzuLOAVem3Z0&e=
>  >
>  > Thanks
>  > Steve Groeger
>  > IBM Runtime Technologies
>  > Hursley, Winchester
>  > Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
>  > Fax (44) 1962 816800
>  > Lotus Notes: Steve Groeger/UK/IBM
>  > Internet: groeges at uk.ibm.com
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>  >
>  >
>  >
>  > From: Jonathan Gibbons <jonathan.gibbons at oracle.com>
>  > To: Steve Groeger <GROEGES at uk.ibm.com>
>  > Cc: compiler-dev at openjdk.java.net
>  > Date: 31/01/2019 16:56
>  > Subject: Re: [NEW_BUG] javac fails and exits with no error if a bad
>  > annotation processor is on the classpath
>  > ------------------------------------------------------------------------
>  >
>  >
>  >
>  > Steve,
>  >
>  > When you post the new webrevs, can I suggest that you change the Subject
>  > line of this thread to something like
>  >
>  > RFR: 8218152 [javac] fails and exits with no error if a bad annotation
>  > processor provided
>  >
>  > That will help get attention from reviewers, and help any subsequent
>  > bug-archaeology.
>  >
>  > I can sponsor the changes for you once they have been reviewed.
>  >
>  > -- Jon
>  >
>  > On 1/31/19 8:49 AM, Steve Groeger wrote:
>  > Hi Jonathan,
>  >
>  > Thanks for responding.
>  >
>  > I have created a couple of webrevs for jdk8u [1] and jdk [2] which also
>  > include some JTReg tests.
>  > I would be grateful if you, or someone else could review these just to
>  > ensure I am doing the right thing.
>  > I will update the code with the additional 'throw FatalError' that you
>  > mentioned and will then create some new webrevs
>  >
>  > If you are able to sponsor these changes for me I would be very grateful.
>  >
>  > PS. As you saw I have created a JBS issue for this here [3]
>  >
>  > [1]
> _https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.00_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=JoEgW12V0tuoZvuG9GDF7g5YmXhjGolWyibAYlifWME&e=
>  > [2]
> _https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.00_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=NeM6uUrEq-vcqXQ5uHonCor_ChwsY20notpASJS4is8&e=
>  >
> [3_https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8218152-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=GXmb6NEDC3BhXyEw8uaNod2uN_hYX-9HpHkoiGhEujY&e=
>  >
>  > Thanks
>  > Steve Groeger
>  > IBM Runtime Technologies
>  > Hursley, Winchester
>  > Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
>  > Fax (44) 1962 816800
>  > Lotus Notes: Steve Groeger/UK/IBM
>  > Internet: _groeges at uk.ibm.com_ <mailto:groeges at uk.ibm.com>
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>  >
>  >
>  >
>  > From: Jonathan Gibbons _<jonathan.gibbons at oracle.com>_
>  > <mailto:jonathan.gibbons at oracle.com>
>  > To: Steve Groeger _<GROEGES at uk.ibm.com>_ <mailto:GROEGES at uk.ibm.com>,
>  > _compiler-dev at openjdk.java.net_ <mailto:compiler-dev at openjdk.java.net>
>  > Date: 31/01/2019 16:33
>  > Subject: Re: [NEW_BUG] javac fails and exits with no error if a bad
>  > annotation processor is on the classpath
>  >
>  > ------------------------------------------------------------------------
>  >
>  >
>  >
>  > Steve,
>  >
>  > Your fix is generally good: Abort should only be used after a suitable
>  > message has been reported.
>  >
>  > There's a `catch (Throwable t)` in the same set of catch blocks that you
>  > did not update. Rather than add yet another message for that case, it
>  > might be better to throw FatalError, to provoke the standard "javac
>  > crash" output for the unknown exception.
>  >
>  > You should provide a test case ... i.e. as a jtreg test.
>  >
>  > -- Jon
>  >
>  > On 1/29/19 3:18 AM, Steve Groeger wrote:
>  > Hi all,
>  >
>  > I have identified a potential issue where javac fails and exits with no
>  > error if a bad annotation processor is on the classpath.
>  >
>  > Background: an Annotation Processor class can be packaged in a jar file
>  > and is identified by a special text file inside the jar named:
>  > META-INF/services/javax.annotation.processing.Processor. This text file
>  > has only one line, specifying the class name of the annotation process
>  > class to run. When javac runs, it checks all jars on the classpath and
>  > if it finds the special text file in any jar file, then it attempts to
>  > run the class listed there.
>  >
>  > The issue here is that when the annotation processor class can't be
>  > executed, javac catches the exception and exits without reporting on the
>  > reason for the exit. Examples of reasons why the annotation processor
>  > can't be executed include:
>  >
>  >   * the annotation processor class is compiled for a higher version of
>  >     Java than the javac is running, giving UnsupportedClassVersionError.
>  >   * the annotation processor class file is corrupt so can't be loaded.
>  >
>  >
>  > In either of the above cases javac will swallow the error and exit
>  > without telling the user why it failed to compile the java source code
>  > as expected.
>  >
>  > Testcase
>  >    put HelloWorld.java in current directory, edit <path_to_jar> and run:
>  >          javac -cp .:<path_to_jar>/bad.annotation.processor.jar
>  > HelloWorld.java
>  >
>  > Instead of producing HelloWorld.class as expected, javac exits silently.
>  >
>  > Here, bad.annotation.processor.jar is a file that I created to contain:
>  >       META-INF/services/javax.annotation.processing.Processor <<-- text
>  > file to list bad class
>  >      bad/notaclass.class <<-- dummy file, can't be loaded as a java class
>  >
>  > Does anyone know whether this is a bug and that this should throw an
>  > error in these cases?
>  > If so, I will raise a bug for this.
>  >
>  > I have looked at the code and seen where javac Aborts the processing,
>  > and if I make the following changes the javac detects the issue and
>  > reports an error before Aborting.
>  >
>  > diff -r 5178e4b58b17
>  >
> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  > ---
>  >
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  >       Mon Jan 28 09:56:00 2019 +0100
>  > +++
>  >
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>  >       Tue Jan 29 11:14:57 2019 +0000
>  > @@ -1,5 +1,5 @@
>  > /*
>  > - * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights
>  > reserved.
>  > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights
>  > reserved.
>  >   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  >   *
>  >   * This code is free software; you can redistribute it and/or modify it
>  > @@ -436,6 +436,12 @@
>  >              } catch(ServiceConfigurationError sce) {
>  >
>  > log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>  >                  throw new Abort(sce);
>  > +            } catch (UnsupportedClassVersionError ucve) {
>  > +
>  >   log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage()));
>  > +                throw new Abort(ucve);
>  > +            } catch (ClassFormatError cfe) {
>  > +
>  >   log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage()));
>  > +                throw new Abort(cfe);
>  >              } catch (Throwable t) {
>  >                  throw new Abort(t);
>  >              }
>  >
>  > and to add a new message there is this change
>  >
>  > diff -r 5178e4b58b17
>  >
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>  > ---
>  >
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>  >       Mon Jan 28 09:56:00 2019 +0100
>  > +++
>  >
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
>  >       Tue Jan 29 11:16:03 2019 +0000
>  > @@ -1,5 +1,5 @@
>  > #
>  > -# Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights
>  > reserved.
>  > +# Copyright (c) 1999, 2019, Oracle and/or its affiliates. All rights
>  > reserved.
>  > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  > #
>  > # This code is free software; you can redistribute it and/or modify it
>  > @@ -1051,6 +1051,10 @@
>  > compiler.err.proc.cant.find.class=\
>  >      Could not find class file for ''{0}''.
>  >
>  > +# 0: string
>  > +compiler.err.proc.cant.load.class=\
>  > +    Could not load processor class file due to ''{0}''.
>  > +
>  > # Print a client-generated error message; assumed to be localized, no
>  > translation required
>  > # 0: string
>  > compiler.err.proc.messager=\
>  >
>  >
>  > If this is deemed a bug and the change seems OK, please could someone
>  > sponsor this for me and I will create a proper webrev for the change for
>  > a full review.
>  >
>  > Thanks
>  > Steve Groeger
>  > IBM Runtime Technologies
>  > Hursley, Winchester
>  > Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
>  > Fax (44) 1962 816800
>  > Lotus Notes: Steve Groeger/UK/IBM
>  > Internet: _groeges at uk.ibm.com_ <mailto:groeges at uk.ibm.com>
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>  >
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>  >
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>  >
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From vicente.romero at oracle.com  Wed Feb 13 16:24:27 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 13 Feb 2019 11:24:27 -0500
Subject: RFR: 8201544: Improve javac command line parsing and error
 reporting
In-Reply-To: <a5745d73-a949-7f1e-0493-c3b8a36fa4c5@oracle.com>
References: <a5745d73-a949-7f1e-0493-c3b8a36fa4c5@oracle.com>
Message-ID: <ac087d82-4932-ffd5-b6b5-96a167fe922f@oracle.com>

looks good to me,
Vicente

On 2/12/19 5:17 AM, srinivas.dama at oracle.com wrote:
> Hi,
>
> Please review http://cr.openjdk.java.net/~sdama/8201544/webrev.02/
>
> for https://bugs.openjdk.java.net/browse/JDK-8201544.
>
> This issue is specific to windows.
>
> Currently when * character is present in filename passed through API 
> call, javac throws weird exception message. With the fix, it is now 
> modified to throw an error instead of exception.
>
> Regards,
>
> Srinivas
>
>


From jonathan.gibbons at oracle.com  Wed Feb 13 16:42:52 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 13 Feb 2019 08:42:52 -0800
Subject: RFR: 8201544: Improve javac command line parsing and error
 reporting
In-Reply-To: <a5745d73-a949-7f1e-0493-c3b8a36fa4c5@oracle.com>
References: <a5745d73-a949-7f1e-0493-c3b8a36fa4c5@oracle.com>
Message-ID: <ddeb2727-aa9e-1db4-f855-a76fe8261155@oracle.com>

In Option.java

765: Add a space between "}" and "catch".

766-768: I would remove the comment. It's not necessary, and doesn't add 
anything that isn't present via the metadata.? If you keep the comment, 
"windows" should be capitalized. "For ex" should be spelt in full, "For 
example".?? But better to just remove the comment. The code stands for 
itself.

-- Jon

On 2/12/19 2:17 AM, srinivas.dama at oracle.com wrote:
> Hi,
>
> Please review http://cr.openjdk.java.net/~sdama/8201544/webrev.02/
>
> for https://bugs.openjdk.java.net/browse/JDK-8201544.
>
> This issue is specific to windows.
>
> Currently when * character is present in filename passed through API 
> call, javac throws weird exception message. With the fix, it is now 
> modified to throw an error instead of exception.
>
> Regards,
>
> Srinivas
>
>

From eaftan at google.com  Sat Feb 16 01:37:07 2019
From: eaftan at google.com (Eddie Aftandilian)
Date: Fri, 15 Feb 2019 17:37:07 -0800
Subject: RFR - JDK-8218650: LineNumberTable records for method invocations
 with arguments
Message-ID: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>

Hi,

I have attached a patch for JDK-8218650, in which there are missing line
number table entries for field accesses.  This is my first attempt to
contribute to OpenJDK, so I'm happy to take feedback.  Please see the
attached patch.

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

Thanks,
Eddie Aftandilian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190215/678893d7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8218650.patch
Type: text/x-patch
Size: 8420 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190215/678893d7/8218650.patch>

From vicente.romero at oracle.com  Sat Feb 16 02:46:35 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Fri, 15 Feb 2019 21:46:35 -0500
Subject: RFR - JDK-8218650: LineNumberTable records for method invocations
 with arguments
In-Reply-To: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
Message-ID: <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>

Hi Eddie,

Thanks for the patch. But first I'm not sure that there is a bug in the 
LNT. There is an entry in the LNT, I'm talking about the example at [1], 
for the invocation of method `id`. What we need to understand is why the 
stack trace is not referring to that line and is referring to line 12. 
In any case I don't think that the LNT should contain entries for 
accesses to fields.

Thanks,
Vicente

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

On 2/15/19 8:37 PM, Eddie Aftandilian wrote:
> Hi,
>
> I have attached a patch for JDK-8218650, in which there are missing 
> line number table entries for field accesses. This is my first attempt 
> to contribute to OpenJDK, so I'm happy to take feedback.? Please see 
> the attached patch.
>
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8218650
>
> Thanks,
> Eddie Aftandilian


From amaembo at gmail.com  Sat Feb 16 08:59:22 2019
From: amaembo at gmail.com (Tagir Valeev)
Date: Sat, 16 Feb 2019 15:59:22 +0700
Subject: Eager enum class initialization with enum switch
Message-ID: <CAE+3fjZZmbWkxcbWh9BDZD_u1i_rsUTzdYCuAZmfSE5Ri0-Q_Q@mail.gmail.com>

Hello!

Consider the following program (Test.java):

class Test {
  enum A{
    X;
    static { System.out.println("A is initialized!"); }
  }
  enum B{
    Y;
    static { System.out.println("B is initialized!"); }
  }

  static void testA(A a) { switch(a) {} }

  static void testB(B b) { switch(b) {} }

  public static void main(String[] args) {
    testA(A.X);
  }
}

When I compile it via javac and run it I see:
A is initialized!
B is initialized!

Despite the fact that testB is never called, and no references to the
B enum actually used during the program execution. According to JLS
12.4.1 B should not be initialized. Am I missing something?

If I use the Eclipse compiler, I got the expected result

A is initialized!

This occurs because javac spins an additional class Test$1 which holds
enum constant mapping and its static initializer initializes mappings
for all the enums used. In contrast, Eclipse creates synthetic static
methods (one per enum) in the same Test class which lazily initialize
the corresponding fields. Such approach better follows the spec, to my
opinion.

So is this javac problem or I don't understand the spec?

With best regards,
Tagir Valeev.

From joe.darcy at oracle.com  Tue Feb 19 18:23:24 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 19 Feb 2019 10:23:24 -0800
Subject: JDK 12 RFR of JDK-8219254: Update explicit uses of latest
 source/target in langtools tests to a property
Message-ID: <465e331c-71ec-b3a9-2b0d-5fcc5e27921b@oracle.com>

Hello,

Please review the changes to address:

 ??? JDK-8219254: Update explicit uses of latest source/target in 
langtools tests to a property
 ??? https://bugs.openjdk.java.net/browse/JDK-8219254
 ??? http://cr.openjdk.java.net/~darcy/8219254.0/

Some background, dozens of langtools tests are written to have an 
explicit use of the latest -source or -target value, currently primarily 
in support of enable preview features where an explicit -source value 
needs to be passed in to turn on the language feature. (The langtools 
tests over the years have generally been written or updated to assume 
the latest source/target and not need an explicit option.)

Needing to update dozens of these tests cause a maintenance hassle when 
a new release comes around (JDK-8205626), especially as a new release 
now comes around every six months and a preview language feature is 
likely to stay in preview for more than one release cycle (JDK-8214825).

To improve this situation, the tests in question are refactored to take 
advantage of the new jtreg capability to pass in named properties in the 
test definition tags (CODETOOLS-7902352). Separately, the diags/messages 
testing subsystem can be updated analogously (JDK-8219256: Update javac 
diags tests to use properties).

A few notes on the updates:

The minimum jtreg needed for langtools tests is bumped up in 
test/langtools/TEST.ROOT. Before this change is pushed, I'll 
double-check to make sure the new jtreg is installed on the various CI 
systems.

The file tools/javac/6330997/T6330997.java didn't actually seem to need 
-source/-target values and I've therefore just removed them.

The most straightforward change to a file is something like:

--- old/test/langtools/tools/javac/ConditionalWithVoid.java 2019-02-18 
11:36:51.028460917 -0800
+++ new/test/langtools/tools/javac/ConditionalWithVoid.java 2019-02-18 
11:36:50.720460917 -0800
@@ -4,7 +4,7 @@
 ? * @summary The compiler was allowing void types in its parsing of 
conditional expressions.
 ? * @author tball
 ? *
- * @compile/fail/ref=ConditionalWithVoid.out --enable-preview -source 
13 -XDrawDiagnostics ConditionalWithVoid.java
+ * @compile/fail/ref=ConditionalWithVoid.out --enable-preview -source 
${jdk.version} -XDrawDiagnostics ConditionalWithVoid.java
 ? */
 ?public class ConditionalWithVoid {

Other tests had to add in explicit @build and @run tags since the 
default implicit ones are not sufficient:

--- old/test/langtools/tools/javac/parser/JavacParserTest.java 
2019-02-18 11:36:52.240460917 -0800
+++ new/test/langtools/tools/javac/parser/JavacParserTest.java 
2019-02-18 11:36:51.928460917 -0800
@@ -29,6 +29,8 @@
 ? * @modules jdk.compiler/com.sun.tools.javac.api
 ? *????????? jdk.compiler/com.sun.tools.javac.main
 ? *????????? jdk.compiler/com.sun.tools.javac.tree
+ * @build JavacParserTest
+ * @run main JavacParserTest ${jdk.version}
 ? */

Additionally, in such a test the version information then has to be 
threaded through to internal programmatic calls to javac.

I looked for candidate files to update running commands like:

 ??? find . -name "*.java" | xargs grep "\-source" | grep 13

Besides the future work files under diags/examples, after the changes in 
the webrev, the remaining uses of "-source 13" are in

 ??? ./tools/javac/expswitch/ExpSwitchNestingTest.java

This is a testng test with its own test root. I wasn't sure how to add 
the necessary tags to pass the information in, but would be happy to do so.

Before the changes are pushed, I'll update the copyrights, etc.

Thanks,

-Joe


From joe.darcy at oracle.com  Tue Feb 19 18:26:48 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 19 Feb 2019 10:26:48 -0800
Subject: JDK 13 RFR of JDK-8219254: Update explicit uses of latest
 source/target in langtools tests to a property
In-Reply-To: <465e331c-71ec-b3a9-2b0d-5fcc5e27921b@oracle.com>
References: <465e331c-71ec-b3a9-2b0d-5fcc5e27921b@oracle.com>
Message-ID: <6df83789-0755-4484-b6e2-74f1614ca8fe@oracle.com>

PS A quick correction: this change is intended for JDK *13* and *not* 
JDK 12.

-Joe



From jonathan.gibbons at oracle.com  Tue Feb 19 18:40:52 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 19 Feb 2019 10:40:52 -0800
Subject: JDK 12 RFR of JDK-8219254: Update explicit uses of latest
 source/target in langtools tests to a property
In-Reply-To: <465e331c-71ec-b3a9-2b0d-5fcc5e27921b@oracle.com>
References: <465e331c-71ec-b3a9-2b0d-5fcc5e27921b@oracle.com>
Message-ID: <64814110-bad0-5e48-0ad2-afcdd27cdc34@oracle.com>



On 02/19/2019 10:23 AM, Joe Darcy wrote:
>
> Besides the future work files under diags/examples, after the changes 
> in the webrev, the remaining uses of "-source 13" are in
>
> ??? ./tools/javac/expswitch/ExpSwitchNestingTest.java

Because this is a singleton file, it might be easiest to convert it to a 
"normal" jtreg test -- still using TestNG of course -- by removing the 
TEST.properties file, and using the standard test description tags, 
ending with `@run testng ...` to run the test.

-- Jon

From joe.darcy at oracle.com  Tue Feb 19 19:28:10 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 19 Feb 2019 11:28:10 -0800
Subject: JDK 12 RFR of JDK-8219254: Update explicit uses of latest
 source/target in langtools tests to a property
In-Reply-To: <64814110-bad0-5e48-0ad2-afcdd27cdc34@oracle.com>
References: <465e331c-71ec-b3a9-2b0d-5fcc5e27921b@oracle.com>
 <64814110-bad0-5e48-0ad2-afcdd27cdc34@oracle.com>
Message-ID: <f21e1549-141a-7d10-2196-9fc5bda684a1@oracle.com>

Hi Jon,

As a general note, it occurred to me that when the current release 
number is referred to inside the source of a test, rather than passing 
it through the command line, it can instead be gotten programmatically 
using code like:

 ??? Integer.toString(Runtime.version().feature())

The start of JDK 12 updates included changes like this for the libraries 
tests.

If you agree this is preferable, I can revise the webrev to use this 
technique where appropriate in the langtools tests.

Thanks,

-Joe

On 2/19/2019 10:40 AM, Jonathan Gibbons wrote:
>
>
> On 02/19/2019 10:23 AM, Joe Darcy wrote:
>>
>> Besides the future work files under diags/examples, after the changes 
>> in the webrev, the remaining uses of "-source 13" are in
>>
>> ??? ./tools/javac/expswitch/ExpSwitchNestingTest.java
>
> Because this is a singleton file, it might be easiest to convert it to 
> a "normal" jtreg test -- still using TestNG of course -- by removing 
> the TEST.properties file, and using the standard test description 
> tags, ending with `@run testng ...` to run the test.
>
> -- Jon

From jonathan.gibbons at oracle.com  Tue Feb 19 19:51:20 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 19 Feb 2019 11:51:20 -0800
Subject: JDK 12 RFR of JDK-8219254: Update explicit uses of latest
 source/target in langtools tests to a property
In-Reply-To: <f21e1549-141a-7d10-2196-9fc5bda684a1@oracle.com>
References: <465e331c-71ec-b3a9-2b0d-5fcc5e27921b@oracle.com>
 <64814110-bad0-5e48-0ad2-afcdd27cdc34@oracle.com>
 <f21e1549-141a-7d10-2196-9fc5bda684a1@oracle.com>
Message-ID: <37fe1260-d64f-b3a4-bab8-068239549eb0@oracle.com>

Joe,

I agree that seems preferable when it is reasonable to do so.

You may still need the ${jdk.version} on the command line when using 
jtreg @compile.

We will still need to update the diags/examples mechanisms.

-- Jon


On 02/19/2019 11:28 AM, Joe Darcy wrote:
> Hi Jon,
>
> As a general note, it occurred to me that when the current release 
> number is referred to inside the source of a test, rather than passing 
> it through the command line, it can instead be gotten programmatically 
> using code like:
>
> ??? Integer.toString(Runtime.version().feature())
>
> The start of JDK 12 updates included changes like this for the 
> libraries tests.
>
> If you agree this is preferable, I can revise the webrev to use this 
> technique where appropriate in the langtools tests.
>
> Thanks,
>
> -Joe
>
> On 2/19/2019 10:40 AM, Jonathan Gibbons wrote:
>>
>>
>> On 02/19/2019 10:23 AM, Joe Darcy wrote:
>>>
>>> Besides the future work files under diags/examples, after the 
>>> changes in the webrev, the remaining uses of "-source 13" are in
>>>
>>> ??? ./tools/javac/expswitch/ExpSwitchNestingTest.java
>>
>> Because this is a singleton file, it might be easiest to convert it 
>> to a "normal" jtreg test -- still using TestNG of course -- by 
>> removing the TEST.properties file, and using the standard test 
>> description tags, ending with `@run testng ...` to run the test.
>>
>> -- Jon


From joe.darcy at oracle.com  Tue Feb 19 20:18:18 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 19 Feb 2019 12:18:18 -0800
Subject: JDK 12 RFR of JDK-8219254: Update explicit uses of latest
 source/target in langtools tests to a property
In-Reply-To: <37fe1260-d64f-b3a4-bab8-068239549eb0@oracle.com>
References: <465e331c-71ec-b3a9-2b0d-5fcc5e27921b@oracle.com>
 <64814110-bad0-5e48-0ad2-afcdd27cdc34@oracle.com>
 <f21e1549-141a-7d10-2196-9fc5bda684a1@oracle.com>
 <37fe1260-d64f-b3a4-bab8-068239549eb0@oracle.com>
Message-ID: <ccae4d02-c82a-0f89-4efe-11b2c73dabca@oracle.com>

Hi Jon,

Revised webrev:

 ??? http://cr.openjdk.java.net/~darcy/8219254.1/

The ${jdk.version} idiom is still used for the @compile lines, which 
cover most of the file updates.

Thanks,

-Joe

On 2/19/2019 11:51 AM, Jonathan Gibbons wrote:
> Joe,
>
> I agree that seems preferable when it is reasonable to do so.
>
> You may still need the ${jdk.version} on the command line when using 
> jtreg @compile.
>
> We will still need to update the diags/examples mechanisms.
>
> -- Jon
>
>
> On 02/19/2019 11:28 AM, Joe Darcy wrote:
>> Hi Jon,
>>
>> As a general note, it occurred to me that when the current release 
>> number is referred to inside the source of a test, rather than 
>> passing it through the command line, it can instead be gotten 
>> programmatically using code like:
>>
>> ??? Integer.toString(Runtime.version().feature())
>>
>> The start of JDK 12 updates included changes like this for the 
>> libraries tests.
>>
>> If you agree this is preferable, I can revise the webrev to use this 
>> technique where appropriate in the langtools tests.
>>
>> Thanks,
>>
>> -Joe
>>
>> On 2/19/2019 10:40 AM, Jonathan Gibbons wrote:
>>>
>>>
>>> On 02/19/2019 10:23 AM, Joe Darcy wrote:
>>>>
>>>> Besides the future work files under diags/examples, after the 
>>>> changes in the webrev, the remaining uses of "-source 13" are in
>>>>
>>>> ??? ./tools/javac/expswitch/ExpSwitchNestingTest.java
>>>
>>> Because this is a singleton file, it might be easiest to convert it 
>>> to a "normal" jtreg test -- still using TestNG of course -- by 
>>> removing the TEST.properties file, and using the standard test 
>>> description tags, ending with `@run testng ...` to run the test.
>>>
>>> -- Jon
>

From alex.buckley at oracle.com  Tue Feb 19 21:22:16 2019
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 19 Feb 2019 13:22:16 -0800
Subject: Indicating the javac version (Re: Eager enum class initialization
 with enum switch)
In-Reply-To: <CAE+3fjZZmbWkxcbWh9BDZD_u1i_rsUTzdYCuAZmfSE5Ri0-Q_Q@mail.gmail.com>
References: <CAE+3fjZZmbWkxcbWh9BDZD_u1i_rsUTzdYCuAZmfSE5Ri0-Q_Q@mail.gmail.com>
Message-ID: <5C6C7388.1050801@oracle.com>

Anyone on this list has a good chance of contributing to multiple 
versions of javac, not just the version in the current JDK GA release. 
(GA: General Availability)  So, when raising questions about javac, 
please indicate the version of javac that you're using. `javac -version` 
should be enough. `java -version` is fine too.

Also, please indicate the edition of the JLS or JVMS that you're 
referring to.

Alex

On 2/16/2019 12:59 AM, Tagir Valeev wrote:
> Hello!
>
> Consider the following program (Test.java):
>
> class Test {
>    enum A{
>      X;
>      static { System.out.println("A is initialized!"); }
>    }
>    enum B{
>      Y;
>      static { System.out.println("B is initialized!"); }
>    }
>
>    static void testA(A a) { switch(a) {} }
>
>    static void testB(B b) { switch(b) {} }
>
>    public static void main(String[] args) {
>      testA(A.X);
>    }
> }
>
> When I compile it via javac and run it I see:
> A is initialized!
> B is initialized!
>
> Despite the fact that testB is never called, and no references to the
> B enum actually used during the program execution. According to JLS
> 12.4.1 B should not be initialized. Am I missing something?
>
> If I use the Eclipse compiler, I got the expected result
>
> A is initialized!
>
> This occurs because javac spins an additional class Test$1 which holds
> enum constant mapping and its static initializer initializes mappings
> for all the enums used. In contrast, Eclipse creates synthetic static
> methods (one per enum) in the same Test class which lazily initialize
> the corresponding fields. Such approach better follows the spec, to my
> opinion.
>
> So is this javac problem or I don't understand the spec?
>
> With best regards,
> Tagir Valeev.
>

From antoniocortes at google.com  Tue Feb 19 21:21:24 2019
From: antoniocortes at google.com (Antonio Cortes Perez)
Date: Tue, 19 Feb 2019 13:21:24 -0800
Subject: Patching package-info.java files
Message-ID: <CAN4Le55zRpJxJ4z7_aEwUgCUgkiSSE_FAWCg3EbN=qQGAEcp8A@mail.gmail.com>

Hi,

I am able to patch system module files using these instructions (I am using
jdk-11.0.1).
https://openjdk.java.net/projects/jigsaw/quick-start#xoverride

When trying the same command to patch a package-info.java, the
package-info.class file is not generated if the patched version has the
same contents as the version in the module. But this behavior does not
apply to non-package-info files. Is this by design?

javac --patch-module java.base=src -d mypatches/java.base \
        src/java.base/java/util/concurrent/package-info.java

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190219/c49cb990/attachment.html>

From jonathan.gibbons at oracle.com  Tue Feb 19 21:35:24 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 19 Feb 2019 13:35:24 -0800
Subject: Indicating the javac version (Re: Eager enum class initialization
 with enum switch)
In-Reply-To: <5C6C7388.1050801@oracle.com>
References: <CAE+3fjZZmbWkxcbWh9BDZD_u1i_rsUTzdYCuAZmfSE5Ri0-Q_Q@mail.gmail.com>
 <5C6C7388.1050801@oracle.com>
Message-ID: <5a43fafb-09d9-c6f1-ce59-2e4b667fbd24@oracle.com>

+1 to good practice when writing any bug report.

In the case of the original message, it would also be pertinent to note 
the versions of any other tools that were involved.

-- Jon

On 2/19/19 1:22 PM, Alex Buckley wrote:
> Anyone on this list has a good chance of contributing to multiple 
> versions of javac, not just the version in the current JDK GA release. 
> (GA: General Availability)? So, when raising questions about javac, 
> please indicate the version of javac that you're using. `javac 
> -version` should be enough. `java -version` is fine too.
>
> Also, please indicate the edition of the JLS or JVMS that you're 
> referring to.
>
> Alex
>
> On 2/16/2019 12:59 AM, Tagir Valeev wrote:
>> Hello!
>>
>> Consider the following program (Test.java):
>>
>> class Test {
>> ?? enum A{
>> ???? X;
>> ???? static { System.out.println("A is initialized!"); }
>> ?? }
>> ?? enum B{
>> ???? Y;
>> ???? static { System.out.println("B is initialized!"); }
>> ?? }
>>
>> ?? static void testA(A a) { switch(a) {} }
>>
>> ?? static void testB(B b) { switch(b) {} }
>>
>> ?? public static void main(String[] args) {
>> ???? testA(A.X);
>> ?? }
>> }
>>
>> When I compile it via javac and run it I see:
>> A is initialized!
>> B is initialized!
>>
>> Despite the fact that testB is never called, and no references to the
>> B enum actually used during the program execution. According to JLS
>> 12.4.1 B should not be initialized. Am I missing something?
>>
>> If I use the Eclipse compiler, I got the expected result
>>
>> A is initialized!
>>
>> This occurs because javac spins an additional class Test$1 which holds
>> enum constant mapping and its static initializer initializes mappings
>> for all the enums used. In contrast, Eclipse creates synthetic static
>> methods (one per enum) in the same Test class which lazily initialize
>> the corresponding fields. Such approach better follows the spec, to my
>> opinion.
>>
>> So is this javac problem or I don't understand the spec?
>>
>> With best regards,
>> Tagir Valeev.
>>

From alex.buckley at oracle.com  Tue Feb 19 21:38:40 2019
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 19 Feb 2019 13:38:40 -0800
Subject: Eager enum class initialization with enum switch
In-Reply-To: <CAE+3fjZZmbWkxcbWh9BDZD_u1i_rsUTzdYCuAZmfSE5Ri0-Q_Q@mail.gmail.com>
References: <CAE+3fjZZmbWkxcbWh9BDZD_u1i_rsUTzdYCuAZmfSE5Ri0-Q_Q@mail.gmail.com>
Message-ID: <5C6C7760.3030906@oracle.com>

On 2/16/2019 12:59 AM, Tagir Valeev wrote:
> Consider the following program (Test.java):
>
> class Test {
>    enum A{
>      X;
>      static { System.out.println("A is initialized!"); }
>    }
>    enum B{
>      Y;
>      static { System.out.println("B is initialized!"); }
>    }
>
>    static void testA(A a) { switch(a) {} }
>
>    static void testB(B b) { switch(b) {} }
>
>    public static void main(String[] args) {
>      testA(A.X);
>    }
> }
>
> When I compile it via javac and run it I see:
> A is initialized!
> B is initialized!
>
> Despite the fact that testB is never called, and no references to the
> B enum actually used during the program execution. According to JLS
> 12.4.1 B should not be initialized. Am I missing something?

Using JDK 11, I agree that compiling and running Test produces the 
results you say.

It's not valid to initialize the enum type B when no reference to B's 
constants or methods is made at run time. I vaguely recall prior 
discussions of this unfortunate aspect of javac's translation.

I notice that the presence of the `testB(B)` method is what triggers 
javac's overly eager initialization of B. Without that method 
declaration, only "A is initialized!" is printed.

Alex

From jonathan.gibbons at oracle.com  Tue Feb 19 21:53:40 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 19 Feb 2019 13:53:40 -0800
Subject: Patching package-info.java files
In-Reply-To: <CAN4Le55zRpJxJ4z7_aEwUgCUgkiSSE_FAWCg3EbN=qQGAEcp8A@mail.gmail.com>
References: <CAN4Le55zRpJxJ4z7_aEwUgCUgkiSSE_FAWCg3EbN=qQGAEcp8A@mail.gmail.com>
Message-ID: <7c48cd5c-521e-75b2-98f9-372674da78fd@oracle.com>

Have you tried using the -XpkgInfo option?? If so, did that fix the issue?

 ? -Xpkginfo:{always,legacy,nonempty}
 ??????? Specify handling of package-info files

Can you provide a simple test case?

-- Jon

On 02/19/2019 01:21 PM, Antonio Cortes Perez wrote:
> Hi,
>
> I am able to patch system module files using these instructions (I am 
> using jdk-11.0.1).
> https://openjdk.java.net/projects/jigsaw/quick-start#xoverride
>
> When trying the same command to patch a package-info.java, the 
> package-info.class file is not generated if the patched version has 
> the same contents as the version in the module. But this behavior does 
> not apply to non-package-info files. Is this by design?
>
> javac --patch-module java.base=src -d mypatches/java.base \
> src/java.base/java/util/concurrent/package-info.java
>
> Thanks!


From antoniocortes at google.com  Tue Feb 19 22:58:54 2019
From: antoniocortes at google.com (Antonio Cortes Perez)
Date: Tue, 19 Feb 2019 14:58:54 -0800
Subject: Patching package-info.java files
In-Reply-To: <7c48cd5c-521e-75b2-98f9-372674da78fd@oracle.com>
References: <CAN4Le55zRpJxJ4z7_aEwUgCUgkiSSE_FAWCg3EbN=qQGAEcp8A@mail.gmail.com>
 <7c48cd5c-521e-75b2-98f9-372674da78fd@oracle.com>
Message-ID: <CAN4Le54J9-9Gf7U34SfKJFE0Wj4W39YiSvMHfSPd9Nt3jX6nOg@mail.gmail.com>

Perfect! -XpkgInfo explains this behavior. The package-info does not have
any annotations with runtime or class retention policy. Thanks!

Test case:
$ mkdir -p src/java.base/java/util/
download
https://raw.githubusercontent.com/AdoptOpenJDK/openjdk-jdk11/master/src/java.base/share/classes/java/util/package-info.java
$ mv package-info.java src/java.base/java/util/
$ javac --patch-module java.base=src -d out
src/java.base/java/util/package-info.java
No class file generated.
$ javac --patch-module java.base=src -d out -Xpkginfo:always
src/java.base/java/util/package-info.java
Class file generated.

On Tue, Feb 19, 2019 at 1:53 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Have you tried using the -XpkgInfo option?  If so, did that fix the issue?
>
>    -Xpkginfo:{always,legacy,nonempty}
>          Specify handling of package-info files
>
> Can you provide a simple test case?
>
> -- Jon
>
> On 02/19/2019 01:21 PM, Antonio Cortes Perez wrote:
> > Hi,
> >
> > I am able to patch system module files using these instructions (I am
> > using jdk-11.0.1).
> > https://openjdk.java.net/projects/jigsaw/quick-start#xoverride
> >
> > When trying the same command to patch a package-info.java, the
> > package-info.class file is not generated if the patched version has
> > the same contents as the version in the module. But this behavior does
> > not apply to non-package-info files. Is this by design?
> >
> > javac --patch-module java.base=src -d mypatches/java.base \
> > src/java.base/java/util/concurrent/package-info.java
> >
> > Thanks!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190219/e3e826ca/attachment-0001.html>

From eaftan at google.com  Wed Feb 20 01:27:04 2019
From: eaftan at google.com (Eddie Aftandilian)
Date: Tue, 19 Feb 2019 17:27:04 -0800
Subject: RFR - JDK-8218650: LineNumberTable records for method invocations
 with arguments
In-Reply-To: <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
 <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
Message-ID: <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>

Hi Vicente,

Thanks for the reply.  Can I ask why you don't think the LNT should contain
entries for accesses to fields?  It seems that results in incorrect line
numbers in certain cases.  For example, consider the following code:

1: class LineNumbers {
2:
3:   static class T {
4:     boolean b;
5:   }
6:
7:   static void doIt(boolean... values) {}
8:
9:   public static void main(String[] args) {
10:     T a = new T();
11:     T b = null;
12:
13:     doIt(
14:         a.b,
15:         b.b);
16:   }
17: }

$ javac LineNumbers.java
$ java LineNumbers
Exception in thread "main" java.lang.NullPointerException
at LineNumbers.main(LineNumbers.java:13)

I would expect the exception to be at line 15, not 13.

Thanks,
Eddie



On Fri, Feb 15, 2019 at 6:46 PM Vicente Romero <vicente.romero at oracle.com>
wrote:

> Hi Eddie,
>
> Thanks for the patch. But first I'm not sure that there is a bug in the
> LNT. There is an entry in the LNT, I'm talking about the example at [1],
> for the invocation of method `id`. What we need to understand is why the
> stack trace is not referring to that line and is referring to line 12.
> In any case I don't think that the LNT should contain entries for
> accesses to fields.
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8218650
>
> On 2/15/19 8:37 PM, Eddie Aftandilian wrote:
> > Hi,
> >
> > I have attached a patch for JDK-8218650, in which there are missing
> > line number table entries for field accesses. This is my first attempt
> > to contribute to OpenJDK, so I'm happy to take feedback.  Please see
> > the attached patch.
> >
> > Bug report: https://bugs.openjdk.java.net/browse/JDK-8218650
> >
> > Thanks,
> > Eddie Aftandilian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190219/bb409a15/attachment.html>

From amaembo at gmail.com  Wed Feb 20 03:33:46 2019
From: amaembo at gmail.com (Tagir Valeev)
Date: Wed, 20 Feb 2019 10:33:46 +0700
Subject: Indicating the javac version (Re: Eager enum class initialization
 with enum switch)
In-Reply-To: <5C6C7388.1050801@oracle.com>
References: <CAE+3fjZZmbWkxcbWh9BDZD_u1i_rsUTzdYCuAZmfSE5Ri0-Q_Q@mail.gmail.com>
 <5C6C7388.1050801@oracle.com>
Message-ID: <CAE+3fjYvLtwg5rbEx++5rA1AMYnwnic9vychURav2_DyT-90cg@mail.gmail.com>

Hello!

This problem seems to exist always. At least I observe the same
behavior in all javac version I have starting from javac 1.6.0_45 up
until the latest javac 13-ea+8. The relevant part of spec seems not to
be changed much between versions as well. Nevertheless I agree that I
should have been more specific. Sorry for this.

With best regards,
Tagir Valeev.

On Wed, Feb 20, 2019 at 4:24 AM Alex Buckley <alex.buckley at oracle.com> wrote:
>
> Anyone on this list has a good chance of contributing to multiple
> versions of javac, not just the version in the current JDK GA release.
> (GA: General Availability)  So, when raising questions about javac,
> please indicate the version of javac that you're using. `javac -version`
> should be enough. `java -version` is fine too.
>
> Also, please indicate the edition of the JLS or JVMS that you're
> referring to.
>
> Alex
>
> On 2/16/2019 12:59 AM, Tagir Valeev wrote:
> > Hello!
> >
> > Consider the following program (Test.java):
> >
> > class Test {
> >    enum A{
> >      X;
> >      static { System.out.println("A is initialized!"); }
> >    }
> >    enum B{
> >      Y;
> >      static { System.out.println("B is initialized!"); }
> >    }
> >
> >    static void testA(A a) { switch(a) {} }
> >
> >    static void testB(B b) { switch(b) {} }
> >
> >    public static void main(String[] args) {
> >      testA(A.X);
> >    }
> > }
> >
> > When I compile it via javac and run it I see:
> > A is initialized!
> > B is initialized!
> >
> > Despite the fact that testB is never called, and no references to the
> > B enum actually used during the program execution. According to JLS
> > 12.4.1 B should not be initialized. Am I missing something?
> >
> > If I use the Eclipse compiler, I got the expected result
> >
> > A is initialized!
> >
> > This occurs because javac spins an additional class Test$1 which holds
> > enum constant mapping and its static initializer initializes mappings
> > for all the enums used. In contrast, Eclipse creates synthetic static
> > methods (one per enum) in the same Test class which lazily initialize
> > the corresponding fields. Such approach better follows the spec, to my
> > opinion.
> >
> > So is this javac problem or I don't understand the spec?
> >
> > With best regards,
> > Tagir Valeev.
> >

From amaembo at gmail.com  Wed Feb 20 05:24:23 2019
From: amaembo at gmail.com (Tagir Valeev)
Date: Wed, 20 Feb 2019 12:24:23 +0700
Subject: Eager enum class initialization with enum switch
In-Reply-To: <5C6C7760.3030906@oracle.com>
References: <CAE+3fjZZmbWkxcbWh9BDZD_u1i_rsUTzdYCuAZmfSE5Ri0-Q_Q@mail.gmail.com>
 <5C6C7760.3030906@oracle.com>
Message-ID: <CAE+3fjaM4ErxfOm4c8eP-sdTU4ZQV-5j6AqLBkGqNxqvDiG0cA@mail.gmail.com>

Hello, Alex!

Thanks for reply. I filed an issue:
https://bugs.openjdk.java.net/browse/JDK-8219412

It would be great were the lookup table created using condy bootstrap.
This would not only fix the reported problem,
but also reduce the amount of produced code. In particular, no
additional class file would be necessary:
bootstrap methods could be generated in the same class (one bootstrap
and one constant per enum; the same constant
could be reused for several switches over the same enum).

With best regards,
Tagir Valeev

On Wed, Feb 20, 2019 at 5:09 AM Alex Buckley <alex.buckley at oracle.com> wrote:
>
> On 2/16/2019 12:59 AM, Tagir Valeev wrote:
> > Consider the following program (Test.java):
> >
> > class Test {
> >    enum A{
> >      X;
> >      static { System.out.println("A is initialized!"); }
> >    }
> >    enum B{
> >      Y;
> >      static { System.out.println("B is initialized!"); }
> >    }
> >
> >    static void testA(A a) { switch(a) {} }
> >
> >    static void testB(B b) { switch(b) {} }
> >
> >    public static void main(String[] args) {
> >      testA(A.X);
> >    }
> > }
> >
> > When I compile it via javac and run it I see:
> > A is initialized!
> > B is initialized!
> >
> > Despite the fact that testB is never called, and no references to the
> > B enum actually used during the program execution. According to JLS
> > 12.4.1 B should not be initialized. Am I missing something?
>
> Using JDK 11, I agree that compiling and running Test produces the
> results you say.
>
> It's not valid to initialize the enum type B when no reference to B's
> constants or methods is made at run time. I vaguely recall prior
> discussions of this unfortunate aspect of javac's translation.
>
> I notice that the presence of the `testB(B)` method is what triggers
> javac's overly eager initialization of B. Without that method
> declaration, only "A is initialized!" is printed.
>
> Alex

From jan.lahoda at oracle.com  Wed Feb 20 09:09:15 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 20 Feb 2019 10:09:15 +0100
Subject: JDK 12 RFR of JDK-8219254: Update explicit uses of latest
 source/target in langtools tests to a property
In-Reply-To: <ccae4d02-c82a-0f89-4efe-11b2c73dabca@oracle.com>
References: <465e331c-71ec-b3a9-2b0d-5fcc5e27921b@oracle.com>
 <64814110-bad0-5e48-0ad2-afcdd27cdc34@oracle.com>
 <f21e1549-141a-7d10-2196-9fc5bda684a1@oracle.com>
 <37fe1260-d64f-b3a4-bab8-068239549eb0@oracle.com>
 <ccae4d02-c82a-0f89-4efe-11b2c73dabca@oracle.com>
Message-ID: <5C6D193B.70108@oracle.com>

Hi Joe,

Looks good to me.

Thanks!

Jan

On 19.2.2019 21:18, Joe Darcy wrote:
> Hi Jon,
>
> Revised webrev:
>
>      http://cr.openjdk.java.net/~darcy/8219254.1/
>
> The ${jdk.version} idiom is still used for the @compile lines, which
> cover most of the file updates.
>
> Thanks,
>
> -Joe
>
> On 2/19/2019 11:51 AM, Jonathan Gibbons wrote:
>> Joe,
>>
>> I agree that seems preferable when it is reasonable to do so.
>>
>> You may still need the ${jdk.version} on the command line when using
>> jtreg @compile.
>>
>> We will still need to update the diags/examples mechanisms.
>>
>> -- Jon
>>
>>
>> On 02/19/2019 11:28 AM, Joe Darcy wrote:
>>> Hi Jon,
>>>
>>> As a general note, it occurred to me that when the current release
>>> number is referred to inside the source of a test, rather than
>>> passing it through the command line, it can instead be gotten
>>> programmatically using code like:
>>>
>>>     Integer.toString(Runtime.version().feature())
>>>
>>> The start of JDK 12 updates included changes like this for the
>>> libraries tests.
>>>
>>> If you agree this is preferable, I can revise the webrev to use this
>>> technique where appropriate in the langtools tests.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> On 2/19/2019 10:40 AM, Jonathan Gibbons wrote:
>>>>
>>>>
>>>> On 02/19/2019 10:23 AM, Joe Darcy wrote:
>>>>>
>>>>> Besides the future work files under diags/examples, after the
>>>>> changes in the webrev, the remaining uses of "-source 13" are in
>>>>>
>>>>>     ./tools/javac/expswitch/ExpSwitchNestingTest.java
>>>>
>>>> Because this is a singleton file, it might be easiest to convert it
>>>> to a "normal" jtreg test -- still using TestNG of course -- by
>>>> removing the TEST.properties file, and using the standard test
>>>> description tags, ending with `@run testng ...` to run the test.
>>>>
>>>> -- Jon
>>

From maurizio.cimadamore at oracle.com  Wed Feb 20 11:23:57 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 20 Feb 2019 11:23:57 +0000
Subject: Eager enum class initialization with enum switch
In-Reply-To: <CAE+3fjaM4ErxfOm4c8eP-sdTU4ZQV-5j6AqLBkGqNxqvDiG0cA@mail.gmail.com>
References: <CAE+3fjZZmbWkxcbWh9BDZD_u1i_rsUTzdYCuAZmfSE5Ri0-Q_Q@mail.gmail.com>
 <5C6C7760.3030906@oracle.com>
 <CAE+3fjaM4ErxfOm4c8eP-sdTU4ZQV-5j6AqLBkGqNxqvDiG0cA@mail.gmail.com>
Message-ID: <4625bd55-d46f-7068-bd55-1287e82f88de@oracle.com>

Hi Tagir,
as you might know, we have plans to overhaul switch translation strategy:

https://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-April/000522.html

Which, I think, should take care of fixing this particular issue. I 
think aiming for that plan is better than coming up with a point fix for 
this specific corner case.

Cheers
Maurizio


On 20/02/2019 05:24, Tagir Valeev wrote:
> Hello, Alex!
>
> Thanks for reply. I filed an issue:
> https://bugs.openjdk.java.net/browse/JDK-8219412
>
> It would be great were the lookup table created using condy bootstrap.
> This would not only fix the reported problem,
> but also reduce the amount of produced code. In particular, no
> additional class file would be necessary:
> bootstrap methods could be generated in the same class (one bootstrap
> and one constant per enum; the same constant
> could be reused for several switches over the same enum).
>
> With best regards,
> Tagir Valeev
>
> On Wed, Feb 20, 2019 at 5:09 AM Alex Buckley <alex.buckley at oracle.com> wrote:
>> On 2/16/2019 12:59 AM, Tagir Valeev wrote:
>>> Consider the following program (Test.java):
>>>
>>> class Test {
>>>     enum A{
>>>       X;
>>>       static { System.out.println("A is initialized!"); }
>>>     }
>>>     enum B{
>>>       Y;
>>>       static { System.out.println("B is initialized!"); }
>>>     }
>>>
>>>     static void testA(A a) { switch(a) {} }
>>>
>>>     static void testB(B b) { switch(b) {} }
>>>
>>>     public static void main(String[] args) {
>>>       testA(A.X);
>>>     }
>>> }
>>>
>>> When I compile it via javac and run it I see:
>>> A is initialized!
>>> B is initialized!
>>>
>>> Despite the fact that testB is never called, and no references to the
>>> B enum actually used during the program execution. According to JLS
>>> 12.4.1 B should not be initialized. Am I missing something?
>> Using JDK 11, I agree that compiling and running Test produces the
>> results you say.
>>
>> It's not valid to initialize the enum type B when no reference to B's
>> constants or methods is made at run time. I vaguely recall prior
>> discussions of this unfortunate aspect of javac's translation.
>>
>> I notice that the presence of the `testB(B)` method is what triggers
>> javac's overly eager initialization of B. Without that method
>> declaration, only "A is initialized!" is printed.
>>
>> Alex

From forax at univ-mlv.fr  Wed Feb 20 11:48:36 2019
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 20 Feb 2019 12:48:36 +0100 (CET)
Subject: Eager enum class initialization with enum switch
In-Reply-To: <4625bd55-d46f-7068-bd55-1287e82f88de@oracle.com>
References: <CAE+3fjZZmbWkxcbWh9BDZD_u1i_rsUTzdYCuAZmfSE5Ri0-Q_Q@mail.gmail.com>
 <5C6C7760.3030906@oracle.com>
 <CAE+3fjaM4ErxfOm4c8eP-sdTU4ZQV-5j6AqLBkGqNxqvDiG0cA@mail.gmail.com>
 <4625bd55-d46f-7068-bd55-1287e82f88de@oracle.com>
Message-ID: <448527628.736999.1550663316711.JavaMail.zimbra@u-pem.fr>

yes !
we can also fix the fact that shuffling the enum constants is currently a non compatible change.

Tagir,
you can have one bootstrap method for all enums (somewhere in the JDK) given that it will be called with a Lookup that reference the enum class and you can not use a condy directly because the ldc instruction has to be in the same classfile (not the same compilation unit) as the constant pool that defines the condy.

R?mi

----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> ?: "Tagir Valeev" <amaembo at gmail.com>, "Alex Buckley" <alex.buckley at oracle.com>
> Cc: "compiler-dev" <compiler-dev at openjdk.java.net>
> Envoy?: Mercredi 20 F?vrier 2019 12:23:57
> Objet: Re: Eager enum class initialization with enum switch

> Hi Tagir,
> as you might know, we have plans to overhaul switch translation strategy:
> 
> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-April/000522.html
> 
> Which, I think, should take care of fixing this particular issue. I
> think aiming for that plan is better than coming up with a point fix for
> this specific corner case.
> 
> Cheers
> Maurizio
> 
> 
> On 20/02/2019 05:24, Tagir Valeev wrote:
>> Hello, Alex!
>>
>> Thanks for reply. I filed an issue:
>> https://bugs.openjdk.java.net/browse/JDK-8219412
>>
>> It would be great were the lookup table created using condy bootstrap.
>> This would not only fix the reported problem,
>> but also reduce the amount of produced code. In particular, no
>> additional class file would be necessary:
>> bootstrap methods could be generated in the same class (one bootstrap
>> and one constant per enum; the same constant
>> could be reused for several switches over the same enum).
>>
>> With best regards,
>> Tagir Valeev
>>
>> On Wed, Feb 20, 2019 at 5:09 AM Alex Buckley <alex.buckley at oracle.com> wrote:
>>> On 2/16/2019 12:59 AM, Tagir Valeev wrote:
>>>> Consider the following program (Test.java):
>>>>
>>>> class Test {
>>>>     enum A{
>>>>       X;
>>>>       static { System.out.println("A is initialized!"); }
>>>>     }
>>>>     enum B{
>>>>       Y;
>>>>       static { System.out.println("B is initialized!"); }
>>>>     }
>>>>
>>>>     static void testA(A a) { switch(a) {} }
>>>>
>>>>     static void testB(B b) { switch(b) {} }
>>>>
>>>>     public static void main(String[] args) {
>>>>       testA(A.X);
>>>>     }
>>>> }
>>>>
>>>> When I compile it via javac and run it I see:
>>>> A is initialized!
>>>> B is initialized!
>>>>
>>>> Despite the fact that testB is never called, and no references to the
>>>> B enum actually used during the program execution. According to JLS
>>>> 12.4.1 B should not be initialized. Am I missing something?
>>> Using JDK 11, I agree that compiling and running Test produces the
>>> results you say.
>>>
>>> It's not valid to initialize the enum type B when no reference to B's
>>> constants or methods is made at run time. I vaguely recall prior
>>> discussions of this unfortunate aspect of javac's translation.
>>>
>>> I notice that the presence of the `testB(B)` method is what triggers
>>> javac's overly eager initialization of B. Without that method
>>> declaration, only "A is initialized!" is printed.
>>>
> >> Alex

From vicente.romero at oracle.com  Wed Feb 20 13:38:45 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 20 Feb 2019 08:38:45 -0500
Subject: RFR - JDK-8218650: LineNumberTable records for method invocations
 with arguments
In-Reply-To: <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
 <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
 <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>
Message-ID: <bd836c1c-dd75-2844-ea72-5ba502854c6d@oracle.com>



On 2/19/19 8:27 PM, Eddie Aftandilian wrote:
> Hi Vicente,
>
> Thanks for the reply.? Can I ask why you don't think the LNT should 
> contain entries for accesses to fields?? It seems that results in 
> incorrect line numbers in certain cases.? For example, consider the 
> following code:
>
> 1: class LineNumbers {
> 2:
> 3:? ?static class T {
> 4:? ? ?boolean b;
> 5:? ?}
> 6:
> 7:? ?static void doIt(boolean... values) {}
> 8:
> 9:? ?public static void main(String[] args) {
> 10:? ? ?T a = new T();
> 11:? ? ?T b = null;
> 12:
> 13:? ? ?doIt(
> 14:? ? ? ? ?a.b,
> 15:? ? ? ? ?b.b);
> 16:? ?}
> 17: }
>
> $ javac LineNumbers.java
> $ java LineNumbers
> Exception in thread "main" java.lang.NullPointerException
> at LineNumbers.main(LineNumbers.java:13)
>
> I would expect the exception to be at line 15, not 13.

having the exception at 13 is plain bad or good enough? It seems to me 
that you want to do some automation based on the exact line where the 
exception was produced. I'm just worried that generating LNT entries for 
every expression would produce, probably unnecessarily, fluffier class 
files.

>
> Thanks,
> Eddie

Thanks,
Vicente

>
>
>
> On Fri, Feb 15, 2019 at 6:46 PM Vicente Romero 
> <vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>> wrote:
>
>     Hi Eddie,
>
>     Thanks for the patch. But first I'm not sure that there is a bug
>     in the
>     LNT. There is an entry in the LNT, I'm talking about the example
>     at [1],
>     for the invocation of method `id`. What we need to understand is
>     why the
>     stack trace is not referring to that line and is referring to line
>     12.
>     In any case I don't think that the LNT should contain entries for
>     accesses to fields.
>
>     Thanks,
>     Vicente
>
>     [1] https://bugs.openjdk.java.net/browse/JDK-8218650
>
>     On 2/15/19 8:37 PM, Eddie Aftandilian wrote:
>     > Hi,
>     >
>     > I have attached a patch for JDK-8218650, in which there are missing
>     > line number table entries for field accesses. This is my first
>     attempt
>     > to contribute to OpenJDK, so I'm happy to take feedback. Please see
>     > the attached patch.
>     >
>     > Bug report: https://bugs.openjdk.java.net/browse/JDK-8218650
>     >
>     > Thanks,
>     > Eddie Aftandilian
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190220/af89fd80/attachment.html>

From forax at univ-mlv.fr  Wed Feb 20 14:20:45 2019
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 20 Feb 2019 15:20:45 +0100 (CET)
Subject: RFR - JDK-8218650: LineNumberTable records for method
 invocations with arguments
In-Reply-To: <bd836c1c-dd75-2844-ea72-5ba502854c6d@oracle.com>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
 <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
 <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>
 <bd836c1c-dd75-2844-ea72-5ba502854c6d@oracle.com>
Message-ID: <192583974.778153.1550672445854.JavaMail.zimbra@u-pem.fr>

I don't think you need to bloat the line number table for this case because soon the NPE error message will be more precise [1]. 

R?mi 

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

> De: "Vicente Romero" <vicente.romero at oracle.com>
> ?: "Eddie Aftandilian" <eaftan at google.com>
> Cc: "compiler-dev" <compiler-dev at openjdk.java.net>
> Envoy?: Mercredi 20 F?vrier 2019 14:38:45
> Objet: Re: RFR - JDK-8218650: LineNumberTable records for method invocations
> with arguments

> On 2/19/19 8:27 PM, Eddie Aftandilian wrote:

>> Hi Vicente,

>> Thanks for the reply. Can I ask why you don't think the LNT should contain
>> entries for accesses to fields? It seems that results in incorrect line numbers
>> in certain cases. For example, consider the following code:

>> 1: class LineNumbers {
>> 2:
>> 3: static class T {
>> 4: boolean b;
>> 5: }
>> 6:
>> 7: static void doIt(boolean... values) {}
>> 8:
>> 9: public static void main(String[] args) {
>> 10: T a = new T();
>> 11: T b = null;
>> 12:
>> 13: doIt(
>> 14: a.b,
>> 15: b.b);
>> 16: }
>> 17: }

>> $ javac LineNumbers.java
>> $ java LineNumbers
>> Exception in thread "main" java.lang.NullPointerException
>> at LineNumbers.main(LineNumbers.java:13)

>> I would expect the exception to be at line 15, not 13.

> having the exception at 13 is plain bad or good enough? It seems to me that you
> want to do some automation based on the exact line where the exception was
> produced. I'm just worried that generating LNT entries for every expression
> would produce, probably unnecessarily, fluffier class files.

>> Thanks,
>> Eddie

> Thanks,
> Vicente

>> On Fri, Feb 15, 2019 at 6:46 PM Vicente Romero < [
>> mailto:vicente.romero at oracle.com | vicente.romero at oracle.com ] > wrote:

>>> Hi Eddie,

>>> Thanks for the patch. But first I'm not sure that there is a bug in the
>>> LNT. There is an entry in the LNT, I'm talking about the example at [1],
>>> for the invocation of method `id`. What we need to understand is why the
>>> stack trace is not referring to that line and is referring to line 12.
>>> In any case I don't think that the LNT should contain entries for
>>> accesses to fields.

>>> Thanks,
>>> Vicente

>>> [1] [ https://bugs.openjdk.java.net/browse/JDK-8218650 |
>>> https://bugs.openjdk.java.net/browse/JDK-8218650 ]

>>> On 2/15/19 8:37 PM, Eddie Aftandilian wrote:
>>> > Hi,

>>> > I have attached a patch for JDK-8218650, in which there are missing
>>> > line number table entries for field accesses. This is my first attempt
>>> > to contribute to OpenJDK, so I'm happy to take feedback. Please see
>>> > the attached patch.

>>>> Bug report: [ https://bugs.openjdk.java.net/browse/JDK-8218650 |
>>> > https://bugs.openjdk.java.net/browse/JDK-8218650 ]

>>> > Thanks,
>>> > Eddie Aftandilian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190220/baeabf0f/attachment.html>

From joe.darcy at oracle.com  Wed Feb 20 21:17:49 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 20 Feb 2019 13:17:49 -0800
Subject: JDK 12 RFR of JDK-8219254: Update explicit uses of latest
 source/target in langtools tests to a property
In-Reply-To: <5C6D193B.70108@oracle.com>
References: <465e331c-71ec-b3a9-2b0d-5fcc5e27921b@oracle.com>
 <64814110-bad0-5e48-0ad2-afcdd27cdc34@oracle.com>
 <f21e1549-141a-7d10-2196-9fc5bda684a1@oracle.com>
 <37fe1260-d64f-b3a4-bab8-068239549eb0@oracle.com>
 <ccae4d02-c82a-0f89-4efe-11b2c73dabca@oracle.com> <5C6D193B.70108@oracle.com>
Message-ID: <e496b709-d9e6-b781-9d08-42e8024ca829@oracle.com>

Hello,

Re-revised webrev:

 ??? http://cr.openjdk.java.net/~darcy/8219254.3/

This one leaves out the update to bump the jtreg used in 
make/conf/jib-profiles.js since that bump was recently pushed under 
another bug id. Also, the .3 version of webrev includes changes from Jon 
to address JDK-8219256: "Update javac diags tests to use properties."

I'll list both 8219254 and 8219256 in the changeset comment.

Thanks,

-Joe

On 2/20/2019 1:09 AM, Jan Lahoda wrote:
> Hi Joe,
>
> Looks good to me.
>
> Thanks!
>
> Jan
>
> On 19.2.2019 21:18, Joe Darcy wrote:
>> Hi Jon,
>>
>> Revised webrev:
>>
>> ???? http://cr.openjdk.java.net/~darcy/8219254.1/
>>
>> The ${jdk.version} idiom is still used for the @compile lines, which
>> cover most of the file updates.
>>
>> Thanks,
>>
>> -Joe
>>
>> On 2/19/2019 11:51 AM, Jonathan Gibbons wrote:
>>> Joe,
>>>
>>> I agree that seems preferable when it is reasonable to do so.
>>>
>>> You may still need the ${jdk.version} on the command line when using
>>> jtreg @compile.
>>>
>>> We will still need to update the diags/examples mechanisms.
>>>
>>> -- Jon
>>>
>>>
>>> On 02/19/2019 11:28 AM, Joe Darcy wrote:
>>>> Hi Jon,
>>>>
>>>> As a general note, it occurred to me that when the current release
>>>> number is referred to inside the source of a test, rather than
>>>> passing it through the command line, it can instead be gotten
>>>> programmatically using code like:
>>>>
>>>> ??? Integer.toString(Runtime.version().feature())
>>>>
>>>> The start of JDK 12 updates included changes like this for the
>>>> libraries tests.
>>>>
>>>> If you agree this is preferable, I can revise the webrev to use this
>>>> technique where appropriate in the langtools tests.
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>>
>>>> On 2/19/2019 10:40 AM, Jonathan Gibbons wrote:
>>>>>
>>>>>
>>>>> On 02/19/2019 10:23 AM, Joe Darcy wrote:
>>>>>>
>>>>>> Besides the future work files under diags/examples, after the
>>>>>> changes in the webrev, the remaining uses of "-source 13" are in
>>>>>>
>>>>>> ??? ./tools/javac/expswitch/ExpSwitchNestingTest.java
>>>>>
>>>>> Because this is a singleton file, it might be easiest to convert it
>>>>> to a "normal" jtreg test -- still using TestNG of course -- by
>>>>> removing the TEST.properties file, and using the standard test
>>>>> description tags, ending with `@run testng ...` to run the test.
>>>>>
>>>>> -- Jon
>>>

From maurizio.cimadamore at oracle.com  Thu Feb 21 13:43:30 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 21 Feb 2019 13:43:30 +0000
Subject: RFR - JDK-8218650: LineNumberTable records for method invocations
 with arguments
In-Reply-To: <192583974.778153.1550672445854.JavaMail.zimbra@u-pem.fr>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
 <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
 <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>
 <bd836c1c-dd75-2844-ea72-5ba502854c6d@oracle.com>
 <192583974.778153.1550672445854.JavaMail.zimbra@u-pem.fr>
Message-ID: <4ca2c222-c76d-dc00-f766-99f30735a1d6@oracle.com>

Hate to be the party pooper :-)

What happens with method calls?

class Test {
public static void main(String[] args) {
 ?? Object o = null;
 ?? o.
 ??? toString(); <-- NPE here
}

}

So, while at some level I sympathize with the argument of not making LNT 
more bloated, I can't help noting the asymmetry between field and method 
access.

Maurizio


On 20/02/2019 14:20, Remi Forax wrote:
> I don't think you need to bloat the line number table for this case 
> because soon the NPE error message will be more precise [1].
>
> R?mi
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8218628
>
> ------------------------------------------------------------------------
>
>     *De: *"Vicente Romero" <vicente.romero at oracle.com>
>     *?: *"Eddie Aftandilian" <eaftan at google.com>
>     *Cc: *"compiler-dev" <compiler-dev at openjdk.java.net>
>     *Envoy?: *Mercredi 20 F?vrier 2019 14:38:45
>     *Objet: *Re: RFR - JDK-8218650: LineNumberTable records for method
>     invocations with arguments
>
>
>
>     On 2/19/19 8:27 PM, Eddie Aftandilian wrote:
>
>         Hi Vicente,
>
>         Thanks for the reply.? Can I ask why you don't think the LNT
>         should contain entries for accesses to fields?? It seems that
>         results in incorrect line numbers in certain cases.? For
>         example, consider the following code:
>
>         1: class LineNumbers {
>         2:
>         3:? ?static class T {
>         4:? ? ?boolean b;
>         5:? ?}
>         6:
>         7:? ?static void doIt(boolean... values) {}
>         8:
>         9:? ?public static void main(String[] args) {
>         10:? ? ?T a = new T();
>         11:? ? ?T b = null;
>         12:
>         13:? ? ?doIt(
>         14:? ? ? ? ?a.b,
>         15:? ? ? ? ?b.b);
>         16:? ?}
>         17: }
>
>         $ javac LineNumbers.java
>         $ java LineNumbers
>         Exception in thread "main" java.lang.NullPointerException
>         at LineNumbers.main(LineNumbers.java:13)
>
>         I would expect the exception to be at line 15, not 13.
>
>
>     having the exception at 13 is plain bad or good enough? It seems
>     to me that you want to do some automation based on the exact line
>     where the exception was produced. I'm just worried that generating
>     LNT entries for every expression would produce, probably
>     unnecessarily, fluffier class files.
>
>
>         Thanks,
>         Eddie
>
>
>     Thanks,
>     Vicente
>
>
>
>
>         On Fri, Feb 15, 2019 at 6:46 PM Vicente Romero
>         <vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>>
>         wrote:
>
>             Hi Eddie,
>
>             Thanks for the patch. But first I'm not sure that there is
>             a bug in the
>             LNT. There is an entry in the LNT, I'm talking about the
>             example at [1],
>             for the invocation of method `id`. What we need to
>             understand is why the
>             stack trace is not referring to that line and is referring
>             to line 12.
>             In any case I don't think that the LNT should contain
>             entries for
>             accesses to fields.
>
>             Thanks,
>             Vicente
>
>             [1] https://bugs.openjdk.java.net/browse/JDK-8218650
>
>             On 2/15/19 8:37 PM, Eddie Aftandilian wrote:
>             > Hi,
>             >
>             > I have attached a patch for JDK-8218650, in which there
>             are missing
>             > line number table entries for field accesses. This is my
>             first attempt
>             > to contribute to OpenJDK, so I'm happy to take
>             feedback.? Please see
>             > the attached patch.
>             >
>             > Bug report: https://bugs.openjdk.java.net/browse/JDK-8218650
>             >
>             > Thanks,
>             > Eddie Aftandilian
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190221/c72a8af2/attachment.html>

From vicente.romero at oracle.com  Thu Feb 21 15:22:36 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 21 Feb 2019 10:22:36 -0500
Subject: RFR - JDK-8218650: LineNumberTable records for method invocations
 with arguments
In-Reply-To: <4ca2c222-c76d-dc00-f766-99f30735a1d6@oracle.com>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
 <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
 <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>
 <bd836c1c-dd75-2844-ea72-5ba502854c6d@oracle.com>
 <192583974.778153.1550672445854.JavaMail.zimbra@u-pem.fr>
 <4ca2c222-c76d-dc00-f766-99f30735a1d6@oracle.com>
Message-ID: <2480d3a6-3a8d-9828-4bd9-975603e95aa4@oracle.com>



On 2/21/19 8:43 AM, Maurizio Cimadamore wrote:
>
> Hate to be the party pooper :-)
>
> What happens with method calls?
>
> class Test {
> public static void main(String[] args) {
> ?? Object o = null;
> ?? o.
> ??? toString(); <-- NPE here
> }
>
> }
>
> So, while at some level I sympathize with the argument of not making 
> LNT more bloated, I can't help noting the asymmetry between field and 
> method access.
>

yep that's a difference but shouldn't we wait and see if the bug 
referred by Remi solves the problem of the stack trace not being exact 
in some cases?

> Maurizio

Vicente

>
> On 20/02/2019 14:20, Remi Forax wrote:
>> I don't think you need to bloat the line number table for this case 
>> because soon the NPE error message will be more precise [1].
>>
>> R?mi
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8218628
>>
>> ------------------------------------------------------------------------
>>
>>     *De: *"Vicente Romero" <vicente.romero at oracle.com>
>>     *?: *"Eddie Aftandilian" <eaftan at google.com>
>>     *Cc: *"compiler-dev" <compiler-dev at openjdk.java.net>
>>     *Envoy?: *Mercredi 20 F?vrier 2019 14:38:45
>>     *Objet: *Re: RFR - JDK-8218650: LineNumberTable records for
>>     method invocations with arguments
>>
>>
>>
>>     On 2/19/19 8:27 PM, Eddie Aftandilian wrote:
>>
>>         Hi Vicente,
>>
>>         Thanks for the reply.? Can I ask why you don't think the LNT
>>         should contain entries for accesses to fields?? It seems that
>>         results in incorrect line numbers in certain cases.? For
>>         example, consider the following code:
>>
>>         1: class LineNumbers {
>>         2:
>>         3:? ?static class T {
>>         4:? ? ?boolean b;
>>         5:? ?}
>>         6:
>>         7:? ?static void doIt(boolean... values) {}
>>         8:
>>         9:? ?public static void main(String[] args) {
>>         10:? ? ?T a = new T();
>>         11:? ? ?T b = null;
>>         12:
>>         13:? ? ?doIt(
>>         14:? ? ? ? ?a.b,
>>         15:? ? ? ? ?b.b);
>>         16:? ?}
>>         17: }
>>
>>         $ javac LineNumbers.java
>>         $ java LineNumbers
>>         Exception in thread "main" java.lang.NullPointerException
>>         at LineNumbers.main(LineNumbers.java:13)
>>
>>         I would expect the exception to be at line 15, not 13.
>>
>>
>>     having the exception at 13 is plain bad or good enough? It seems
>>     to me that you want to do some automation based on the exact line
>>     where the exception was produced. I'm just worried that
>>     generating LNT entries for every expression would produce,
>>     probably unnecessarily, fluffier class files.
>>
>>
>>         Thanks,
>>         Eddie
>>
>>
>>     Thanks,
>>     Vicente
>>
>>
>>
>>
>>         On Fri, Feb 15, 2019 at 6:46 PM Vicente Romero
>>         <vicente.romero at oracle.com
>>         <mailto:vicente.romero at oracle.com>> wrote:
>>
>>             Hi Eddie,
>>
>>             Thanks for the patch. But first I'm not sure that there
>>             is a bug in the
>>             LNT. There is an entry in the LNT, I'm talking about the
>>             example at [1],
>>             for the invocation of method `id`. What we need to
>>             understand is why the
>>             stack trace is not referring to that line and is
>>             referring to line 12.
>>             In any case I don't think that the LNT should contain
>>             entries for
>>             accesses to fields.
>>
>>             Thanks,
>>             Vicente
>>
>>             [1] https://bugs.openjdk.java.net/browse/JDK-8218650
>>
>>             On 2/15/19 8:37 PM, Eddie Aftandilian wrote:
>>             > Hi,
>>             >
>>             > I have attached a patch for JDK-8218650, in which there
>>             are missing
>>             > line number table entries for field accesses. This is
>>             my first attempt
>>             > to contribute to OpenJDK, so I'm happy to take
>>             feedback.? Please see
>>             > the attached patch.
>>             >
>>             > Bug report:
>>             https://bugs.openjdk.java.net/browse/JDK-8218650
>>             >
>>             > Thanks,
>>             > Eddie Aftandilian
>>
>>
>>

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

From maurizio.cimadamore at oracle.com  Thu Feb 21 15:54:23 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 21 Feb 2019 15:54:23 +0000
Subject: RFR - JDK-8218650: LineNumberTable records for method invocations
 with arguments
In-Reply-To: <2480d3a6-3a8d-9828-4bd9-975603e95aa4@oracle.com>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
 <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
 <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>
 <bd836c1c-dd75-2844-ea72-5ba502854c6d@oracle.com>
 <192583974.778153.1550672445854.JavaMail.zimbra@u-pem.fr>
 <4ca2c222-c76d-dc00-f766-99f30735a1d6@oracle.com>
 <2480d3a6-3a8d-9828-4bd9-975603e95aa4@oracle.com>
Message-ID: <7867bc71-01a2-9fed-9547-21b8be0363eb@oracle.com>


On 21/02/2019 15:22, Vicente Romero wrote:
>
>
> On 2/21/19 8:43 AM, Maurizio Cimadamore wrote:
>>
>> Hate to be the party pooper :-)
>>
>> What happens with method calls?
>>
>> class Test {
>> public static void main(String[] args) {
>> ?? Object o = null;
>> ?? o.
>> ??? toString(); <-- NPE here
>> }
>>
>> }
>>
>> So, while at some level I sympathize with the argument of not making 
>> LNT more bloated, I can't help noting the asymmetry between field and 
>> method access.
>>
>
> yep that's a difference but shouldn't we wait and see if the bug 
> referred by Remi solves the problem of the stack trace not being exact 
> in some cases?

I think that bug refers mostly to the message associated with the NPE, 
not with the *line* at which it is reported. At least that's my 
understanding.

Maurizio

>
>> Maurizio
>
> Vicente
>
>>
>> On 20/02/2019 14:20, Remi Forax wrote:
>>> I don't think you need to bloat the line number table for this case 
>>> because soon the NPE error message will be more precise [1].
>>>
>>> R?mi
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8218628
>>>
>>> ------------------------------------------------------------------------
>>>
>>>     *De: *"Vicente Romero" <vicente.romero at oracle.com>
>>>     *?: *"Eddie Aftandilian" <eaftan at google.com>
>>>     *Cc: *"compiler-dev" <compiler-dev at openjdk.java.net>
>>>     *Envoy?: *Mercredi 20 F?vrier 2019 14:38:45
>>>     *Objet: *Re: RFR - JDK-8218650: LineNumberTable records for
>>>     method invocations with arguments
>>>
>>>
>>>
>>>     On 2/19/19 8:27 PM, Eddie Aftandilian wrote:
>>>
>>>         Hi Vicente,
>>>
>>>         Thanks for the reply.? Can I ask why you don't think the LNT
>>>         should contain entries for accesses to fields?? It seems
>>>         that results in incorrect line numbers in certain cases.?
>>>         For example, consider the following code:
>>>
>>>         1: class LineNumbers {
>>>         2:
>>>         3:? ?static class T {
>>>         4:? ? ?boolean b;
>>>         5:? ?}
>>>         6:
>>>         7:? ?static void doIt(boolean... values) {}
>>>         8:
>>>         9:? ?public static void main(String[] args) {
>>>         10:? ? ?T a = new T();
>>>         11:? ? ?T b = null;
>>>         12:
>>>         13:? ? ?doIt(
>>>         14:? ? ? ? ?a.b,
>>>         15:? ? ? ? ?b.b);
>>>         16:? ?}
>>>         17: }
>>>
>>>         $ javac LineNumbers.java
>>>         $ java LineNumbers
>>>         Exception in thread "main" java.lang.NullPointerException
>>>         at LineNumbers.main(LineNumbers.java:13)
>>>
>>>         I would expect the exception to be at line 15, not 13.
>>>
>>>
>>>     having the exception at 13 is plain bad or good enough? It seems
>>>     to me that you want to do some automation based on the exact
>>>     line where the exception was produced. I'm just worried that
>>>     generating LNT entries for every expression would produce,
>>>     probably unnecessarily, fluffier class files.
>>>
>>>
>>>         Thanks,
>>>         Eddie
>>>
>>>
>>>     Thanks,
>>>     Vicente
>>>
>>>
>>>
>>>
>>>         On Fri, Feb 15, 2019 at 6:46 PM Vicente Romero
>>>         <vicente.romero at oracle.com
>>>         <mailto:vicente.romero at oracle.com>> wrote:
>>>
>>>             Hi Eddie,
>>>
>>>             Thanks for the patch. But first I'm not sure that there
>>>             is a bug in the
>>>             LNT. There is an entry in the LNT, I'm talking about the
>>>             example at [1],
>>>             for the invocation of method `id`. What we need to
>>>             understand is why the
>>>             stack trace is not referring to that line and is
>>>             referring to line 12.
>>>             In any case I don't think that the LNT should contain
>>>             entries for
>>>             accesses to fields.
>>>
>>>             Thanks,
>>>             Vicente
>>>
>>>             [1] https://bugs.openjdk.java.net/browse/JDK-8218650
>>>
>>>             On 2/15/19 8:37 PM, Eddie Aftandilian wrote:
>>>             > Hi,
>>>             >
>>>             > I have attached a patch for JDK-8218650, in which
>>>             there are missing
>>>             > line number table entries for field accesses. This is
>>>             my first attempt
>>>             > to contribute to OpenJDK, so I'm happy to take
>>>             feedback.? Please see
>>>             > the attached patch.
>>>             >
>>>             > Bug report:
>>>             https://bugs.openjdk.java.net/browse/JDK-8218650
>>>             >
>>>             > Thanks,
>>>             > Eddie Aftandilian
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190221/f88f6aed/attachment.html>

From vicente.romero at oracle.com  Thu Feb 21 16:30:35 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 21 Feb 2019 11:30:35 -0500
Subject: RFR - JDK-8218650: LineNumberTable records for method invocations
 with arguments
In-Reply-To: <7867bc71-01a2-9fed-9547-21b8be0363eb@oracle.com>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
 <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
 <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>
 <bd836c1c-dd75-2844-ea72-5ba502854c6d@oracle.com>
 <192583974.778153.1550672445854.JavaMail.zimbra@u-pem.fr>
 <4ca2c222-c76d-dc00-f766-99f30735a1d6@oracle.com>
 <2480d3a6-3a8d-9828-4bd9-975603e95aa4@oracle.com>
 <7867bc71-01a2-9fed-9547-21b8be0363eb@oracle.com>
Message-ID: <6d961d82-0e83-3c5c-fbaa-6216bb949fa0@oracle.com>



On 2/21/19 10:54 AM, Maurizio Cimadamore wrote:
>
>
> On 21/02/2019 15:22, Vicente Romero wrote:
>>
>>
>> On 2/21/19 8:43 AM, Maurizio Cimadamore wrote:
>>>
>>> Hate to be the party pooper :-)
>>>
>>> What happens with method calls?
>>>
>>> class Test {
>>> public static void main(String[] args) {
>>> ?? Object o = null;
>>> ?? o.
>>> ??? toString(); <-- NPE here
>>> }
>>>
>>> }
>>>
>>> So, while at some level I sympathize with the argument of not making 
>>> LNT more bloated, I can't help noting the asymmetry between field 
>>> and method access.
>>>
>>
>> yep that's a difference but shouldn't we wait and see if the bug 
>> referred by Remi solves the problem of the stack trace not being 
>> exact in some cases?
>
> I think that bug refers mostly to the message associated with the NPE, 
> not with the *line* at which it is reported. At least that's my 
> understanding.
>

I'm not opposed to adding more lines to the LNT if that's what you are 
proposing, but I wonder about the benefit. I mean how bad it is to miss 
for one, two lines vs having bigger class files. Actually, this is an 
interesting experiment @Eddie could you please run an experiment to see 
how bigger would the class files for the whole JDK be with your patch? 
I'm also interested in redundant lines, it could be that this code adds 
redundant lines to the LNT and we should avoid that

> Maurizio
>

Vicente

>>
>>> Maurizio
>>
>> Vicente
>>
>>>
>>> On 20/02/2019 14:20, Remi Forax wrote:
>>>> I don't think you need to bloat the line number table for this case 
>>>> because soon the NPE error message will be more precise [1].
>>>>
>>>> R?mi
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8218628
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>     *De: *"Vicente Romero" <vicente.romero at oracle.com>
>>>>     *?: *"Eddie Aftandilian" <eaftan at google.com>
>>>>     *Cc: *"compiler-dev" <compiler-dev at openjdk.java.net>
>>>>     *Envoy?: *Mercredi 20 F?vrier 2019 14:38:45
>>>>     *Objet: *Re: RFR - JDK-8218650: LineNumberTable records for
>>>>     method invocations with arguments
>>>>
>>>>
>>>>
>>>>     On 2/19/19 8:27 PM, Eddie Aftandilian wrote:
>>>>
>>>>         Hi Vicente,
>>>>
>>>>         Thanks for the reply.? Can I ask why you don't think the
>>>>         LNT should contain entries for accesses to fields?? It
>>>>         seems that results in incorrect line numbers in certain
>>>>         cases.? For example, consider the following code:
>>>>
>>>>         1: class LineNumbers {
>>>>         2:
>>>>         3:? ?static class T {
>>>>         4:? ? ?boolean b;
>>>>         5:? ?}
>>>>         6:
>>>>         7:? ?static void doIt(boolean... values) {}
>>>>         8:
>>>>         9:? ?public static void main(String[] args) {
>>>>         10:? ? ?T a = new T();
>>>>         11:? ? ?T b = null;
>>>>         12:
>>>>         13:? ? ?doIt(
>>>>         14:? ? ? ? ?a.b,
>>>>         15:? ? ? ? ?b.b);
>>>>         16:? ?}
>>>>         17: }
>>>>
>>>>         $ javac LineNumbers.java
>>>>         $ java LineNumbers
>>>>         Exception in thread "main" java.lang.NullPointerException
>>>>         at LineNumbers.main(LineNumbers.java:13)
>>>>
>>>>         I would expect the exception to be at line 15, not 13.
>>>>
>>>>
>>>>     having the exception at 13 is plain bad or good enough? It
>>>>     seems to me that you want to do some automation based on the
>>>>     exact line where the exception was produced. I'm just worried
>>>>     that generating LNT entries for every expression would produce,
>>>>     probably unnecessarily, fluffier class files.
>>>>
>>>>
>>>>         Thanks,
>>>>         Eddie
>>>>
>>>>
>>>>     Thanks,
>>>>     Vicente
>>>>
>>>>
>>>>
>>>>
>>>>         On Fri, Feb 15, 2019 at 6:46 PM Vicente Romero
>>>>         <vicente.romero at oracle.com
>>>>         <mailto:vicente.romero at oracle.com>> wrote:
>>>>
>>>>             Hi Eddie,
>>>>
>>>>             Thanks for the patch. But first I'm not sure that there
>>>>             is a bug in the
>>>>             LNT. There is an entry in the LNT, I'm talking about
>>>>             the example at [1],
>>>>             for the invocation of method `id`. What we need to
>>>>             understand is why the
>>>>             stack trace is not referring to that line and is
>>>>             referring to line 12.
>>>>             In any case I don't think that the LNT should contain
>>>>             entries for
>>>>             accesses to fields.
>>>>
>>>>             Thanks,
>>>>             Vicente
>>>>
>>>>             [1] https://bugs.openjdk.java.net/browse/JDK-8218650
>>>>
>>>>             On 2/15/19 8:37 PM, Eddie Aftandilian wrote:
>>>>             > Hi,
>>>>             >
>>>>             > I have attached a patch for JDK-8218650, in which
>>>>             there are missing
>>>>             > line number table entries for field accesses. This is
>>>>             my first attempt
>>>>             > to contribute to OpenJDK, so I'm happy to take
>>>>             feedback.? Please see
>>>>             > the attached patch.
>>>>             >
>>>>             > Bug report:
>>>>             https://bugs.openjdk.java.net/browse/JDK-8218650
>>>>             >
>>>>             > Thanks,
>>>>             > Eddie Aftandilian
>>>>
>>>>
>>>>
>>

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

From maurizio.cimadamore at oracle.com  Thu Feb 21 16:49:03 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 21 Feb 2019 16:49:03 +0000
Subject: RFR - JDK-8218650: LineNumberTable records for method invocations
 with arguments
In-Reply-To: <6d961d82-0e83-3c5c-fbaa-6216bb949fa0@oracle.com>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
 <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
 <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>
 <bd836c1c-dd75-2844-ea72-5ba502854c6d@oracle.com>
 <192583974.778153.1550672445854.JavaMail.zimbra@u-pem.fr>
 <4ca2c222-c76d-dc00-f766-99f30735a1d6@oracle.com>
 <2480d3a6-3a8d-9828-4bd9-975603e95aa4@oracle.com>
 <7867bc71-01a2-9fed-9547-21b8be0363eb@oracle.com>
 <6d961d82-0e83-3c5c-fbaa-6216bb949fa0@oracle.com>
Message-ID: <fb5488b0-12a0-0d4f-a4cb-8720cb694eed@oracle.com>


On 21/02/2019 16:30, Vicente Romero wrote:
>
>
> On 2/21/19 10:54 AM, Maurizio Cimadamore wrote:
>>
>>
>> On 21/02/2019 15:22, Vicente Romero wrote:
>>>
>>>
>>> On 2/21/19 8:43 AM, Maurizio Cimadamore wrote:
>>>>
>>>> Hate to be the party pooper :-)
>>>>
>>>> What happens with method calls?
>>>>
>>>> class Test {
>>>> public static void main(String[] args) {
>>>> ?? Object o = null;
>>>> ?? o.
>>>> ??? toString(); <-- NPE here
>>>> }
>>>>
>>>> }
>>>>
>>>> So, while at some level I sympathize with the argument of not 
>>>> making LNT more bloated, I can't help noting the asymmetry between 
>>>> field and method access.
>>>>
>>>
>>> yep that's a difference but shouldn't we wait and see if the bug 
>>> referred by Remi solves the problem of the stack trace not being 
>>> exact in some cases?
>>
>> I think that bug refers mostly to the message associated with the 
>> NPE, not with the *line* at which it is reported. At least that's my 
>> understanding.
>>
>
> I'm not opposed to adding more lines to the LNT if that's what you are 
> proposing, but I wonder about the benefit. I mean how bad it is to 
> miss for one, two lines vs having bigger class files. Actually, this 
> is an interesting experiment @Eddie could you please run an experiment 
> to see how bigger would the class files for the whole JDK be with your 
> patch? I'm also interested in redundant lines, it could be that this 
> code adds redundant lines to the LNT and we should avoid that

I guess what I'm arguing is not that we should add LNT - but that I see 
no solid basis for doing this for methods, but not for field access. If 
8218628 will cure us from all sins :-) then the same argument surely 
could be applied to method access?

Maurizio

>
>> Maurizio
>>
>
> Vicente
>
>>>
>>>> Maurizio
>>>
>>> Vicente
>>>
>>>>
>>>> On 20/02/2019 14:20, Remi Forax wrote:
>>>>> I don't think you need to bloat the line number table for this 
>>>>> case because soon the NPE error message will be more precise [1].
>>>>>
>>>>> R?mi
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8218628
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>     *De: *"Vicente Romero" <vicente.romero at oracle.com>
>>>>>     *?: *"Eddie Aftandilian" <eaftan at google.com>
>>>>>     *Cc: *"compiler-dev" <compiler-dev at openjdk.java.net>
>>>>>     *Envoy?: *Mercredi 20 F?vrier 2019 14:38:45
>>>>>     *Objet: *Re: RFR - JDK-8218650: LineNumberTable records for
>>>>>     method invocations with arguments
>>>>>
>>>>>
>>>>>
>>>>>     On 2/19/19 8:27 PM, Eddie Aftandilian wrote:
>>>>>
>>>>>         Hi Vicente,
>>>>>
>>>>>         Thanks for the reply.? Can I ask why you don't think the
>>>>>         LNT should contain entries for accesses to fields?? It
>>>>>         seems that results in incorrect line numbers in certain
>>>>>         cases.? For example, consider the following code:
>>>>>
>>>>>         1: class LineNumbers {
>>>>>         2:
>>>>>         3:? ?static class T {
>>>>>         4:? ? ?boolean b;
>>>>>         5:? ?}
>>>>>         6:
>>>>>         7:? ?static void doIt(boolean... values) {}
>>>>>         8:
>>>>>         9:? ?public static void main(String[] args) {
>>>>>         10:? ? ?T a = new T();
>>>>>         11:? ? ?T b = null;
>>>>>         12:
>>>>>         13:? ? ?doIt(
>>>>>         14:? ? ? ? ?a.b,
>>>>>         15:? ? ? ? ?b.b);
>>>>>         16:? ?}
>>>>>         17: }
>>>>>
>>>>>         $ javac LineNumbers.java
>>>>>         $ java LineNumbers
>>>>>         Exception in thread "main" java.lang.NullPointerException
>>>>>         at LineNumbers.main(LineNumbers.java:13)
>>>>>
>>>>>         I would expect the exception to be at line 15, not 13.
>>>>>
>>>>>
>>>>>     having the exception at 13 is plain bad or good enough? It
>>>>>     seems to me that you want to do some automation based on the
>>>>>     exact line where the exception was produced. I'm just worried
>>>>>     that generating LNT entries for every expression would
>>>>>     produce, probably unnecessarily, fluffier class files.
>>>>>
>>>>>
>>>>>         Thanks,
>>>>>         Eddie
>>>>>
>>>>>
>>>>>     Thanks,
>>>>>     Vicente
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>         On Fri, Feb 15, 2019 at 6:46 PM Vicente Romero
>>>>>         <vicente.romero at oracle.com
>>>>>         <mailto:vicente.romero at oracle.com>> wrote:
>>>>>
>>>>>             Hi Eddie,
>>>>>
>>>>>             Thanks for the patch. But first I'm not sure that
>>>>>             there is a bug in the
>>>>>             LNT. There is an entry in the LNT, I'm talking about
>>>>>             the example at [1],
>>>>>             for the invocation of method `id`. What we need to
>>>>>             understand is why the
>>>>>             stack trace is not referring to that line and is
>>>>>             referring to line 12.
>>>>>             In any case I don't think that the LNT should contain
>>>>>             entries for
>>>>>             accesses to fields.
>>>>>
>>>>>             Thanks,
>>>>>             Vicente
>>>>>
>>>>>             [1] https://bugs.openjdk.java.net/browse/JDK-8218650
>>>>>
>>>>>             On 2/15/19 8:37 PM, Eddie Aftandilian wrote:
>>>>>             > Hi,
>>>>>             >
>>>>>             > I have attached a patch for JDK-8218650, in which
>>>>>             there are missing
>>>>>             > line number table entries for field accesses. This
>>>>>             is my first attempt
>>>>>             > to contribute to OpenJDK, so I'm happy to take
>>>>>             feedback.? Please see
>>>>>             > the attached patch.
>>>>>             >
>>>>>             > Bug report:
>>>>>             https://bugs.openjdk.java.net/browse/JDK-8218650
>>>>>             >
>>>>>             > Thanks,
>>>>>             > Eddie Aftandilian
>>>>>
>>>>>
>>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190221/ccb094ea/attachment.html>

From maurizio.cimadamore at oracle.com  Thu Feb 21 17:02:51 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 21 Feb 2019 17:02:51 +0000
Subject: RFR - JDK-8218650: LineNumberTable records for method invocations
 with arguments
In-Reply-To: <fb5488b0-12a0-0d4f-a4cb-8720cb694eed@oracle.com>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
 <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
 <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>
 <bd836c1c-dd75-2844-ea72-5ba502854c6d@oracle.com>
 <192583974.778153.1550672445854.JavaMail.zimbra@u-pem.fr>
 <4ca2c222-c76d-dc00-f766-99f30735a1d6@oracle.com>
 <2480d3a6-3a8d-9828-4bd9-975603e95aa4@oracle.com>
 <7867bc71-01a2-9fed-9547-21b8be0363eb@oracle.com>
 <6d961d82-0e83-3c5c-fbaa-6216bb949fa0@oracle.com>
 <fb5488b0-12a0-0d4f-a4cb-8720cb694eed@oracle.com>
Message-ID: <5e645555-a300-11ab-dd67-abc8a58c8b92@oracle.com>


On 21/02/2019 16:49, Maurizio Cimadamore wrote:
>
> I guess what I'm arguing is not that we should add LNT - but that I 
> see no solid basis for doing this for methods, but not for field 
> access. If 8218628 will cure us from all sins :-) then the same 
> argument surely could be applied to method access?
>
Where I'm truly going with this is - we never really collected a list of 
use cases as to when it would be nice to have a LNT generated; there are 
many use cases out there, from debuggers to static analysis tools (code 
coverage, findbugs...) and each of these might be affected in subtle 
ways. Heck, once we've even stumbled upon a bug where missing LNT entry 
was causing the JRockit VM to crash ;-)

So, I think that, stepping back from this specific issue, we should try 
(with the help of the community :-)) to identify the conditions under 
which it would be desirable to have a LNT entry, and come up with some 
sort of informal javac spec for that.

Maurizio



From jonathan.gibbons at oracle.com  Thu Feb 21 17:30:40 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 21 Feb 2019 09:30:40 -0800
Subject: JDK 12 RFR of JDK-8219254: Update explicit uses of latest
 source/target in langtools tests to a property
In-Reply-To: <e496b709-d9e6-b781-9d08-42e8024ca829@oracle.com>
References: <465e331c-71ec-b3a9-2b0d-5fcc5e27921b@oracle.com>
 <64814110-bad0-5e48-0ad2-afcdd27cdc34@oracle.com>
 <f21e1549-141a-7d10-2196-9fc5bda684a1@oracle.com>
 <37fe1260-d64f-b3a4-bab8-068239549eb0@oracle.com>
 <ccae4d02-c82a-0f89-4efe-11b2c73dabca@oracle.com> <5C6D193B.70108@oracle.com>
 <e496b709-d9e6-b781-9d08-42e8024ca829@oracle.com>
Message-ID: <ef938550-7d39-d328-cb90-e90dd76f02e9@oracle.com>

Mostly OK, but I think you've nullified/broken the test

http://cr.openjdk.java.net/~darcy/8219254.3/test/langtools/tools/javac/6330997/T6330997.java.sdiff.html

The test specifically comments:

   27  * @summary javac should accept class files with major version of the next release

And you've changed that behavior.

-- Jon

On 2/20/19 1:17 PM, Joe Darcy wrote:
> Hello,
>
> Re-revised webrev:
>
> ??? http://cr.openjdk.java.net/~darcy/8219254.3/
>
> This one leaves out the update to bump the jtreg used in 
> make/conf/jib-profiles.js since that bump was recently pushed under 
> another bug id. Also, the .3 version of webrev includes changes from 
> Jon to address JDK-8219256: "Update javac diags tests to use properties."
>
> I'll list both 8219254 and 8219256 in the changeset comment.
>
> Thanks,
>
> -Joe
>
> On 2/20/2019 1:09 AM, Jan Lahoda wrote:
>> Hi Joe,
>>
>> Looks good to me.
>>
>> Thanks!
>>
>> Jan
>>
>> On 19.2.2019 21:18, Joe Darcy wrote:
>>> Hi Jon,
>>>
>>> Revised webrev:
>>>
>>> ???? http://cr.openjdk.java.net/~darcy/8219254.1/
>>>
>>> The ${jdk.version} idiom is still used for the @compile lines, which
>>> cover most of the file updates.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> On 2/19/2019 11:51 AM, Jonathan Gibbons wrote:
>>>> Joe,
>>>>
>>>> I agree that seems preferable when it is reasonable to do so.
>>>>
>>>> You may still need the ${jdk.version} on the command line when using
>>>> jtreg @compile.
>>>>
>>>> We will still need to update the diags/examples mechanisms.
>>>>
>>>> -- Jon
>>>>
>>>>
>>>> On 02/19/2019 11:28 AM, Joe Darcy wrote:
>>>>> Hi Jon,
>>>>>
>>>>> As a general note, it occurred to me that when the current release
>>>>> number is referred to inside the source of a test, rather than
>>>>> passing it through the command line, it can instead be gotten
>>>>> programmatically using code like:
>>>>>
>>>>> ??? Integer.toString(Runtime.version().feature())
>>>>>
>>>>> The start of JDK 12 updates included changes like this for the
>>>>> libraries tests.
>>>>>
>>>>> If you agree this is preferable, I can revise the webrev to use this
>>>>> technique where appropriate in the langtools tests.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Joe
>>>>>
>>>>> On 2/19/2019 10:40 AM, Jonathan Gibbons wrote:
>>>>>>
>>>>>>
>>>>>> On 02/19/2019 10:23 AM, Joe Darcy wrote:
>>>>>>>
>>>>>>> Besides the future work files under diags/examples, after the
>>>>>>> changes in the webrev, the remaining uses of "-source 13" are in
>>>>>>>
>>>>>>> ??? ./tools/javac/expswitch/ExpSwitchNestingTest.java
>>>>>>
>>>>>> Because this is a singleton file, it might be easiest to convert it
>>>>>> to a "normal" jtreg test -- still using TestNG of course -- by
>>>>>> removing the TEST.properties file, and using the standard test
>>>>>> description tags, ending with `@run testng ...` to run the test.
>>>>>>
>>>>>> -- Jon
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190221/bd8b7a89/attachment.html>

From vicente.romero at oracle.com  Thu Feb 21 17:38:46 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 21 Feb 2019 12:38:46 -0500
Subject: RFR - JDK-8218650: LineNumberTable records for method invocations
 with arguments
In-Reply-To: <fb5488b0-12a0-0d4f-a4cb-8720cb694eed@oracle.com>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
 <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
 <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>
 <bd836c1c-dd75-2844-ea72-5ba502854c6d@oracle.com>
 <192583974.778153.1550672445854.JavaMail.zimbra@u-pem.fr>
 <4ca2c222-c76d-dc00-f766-99f30735a1d6@oracle.com>
 <2480d3a6-3a8d-9828-4bd9-975603e95aa4@oracle.com>
 <7867bc71-01a2-9fed-9547-21b8be0363eb@oracle.com>
 <6d961d82-0e83-3c5c-fbaa-6216bb949fa0@oracle.com>
 <fb5488b0-12a0-0d4f-a4cb-8720cb694eed@oracle.com>
Message-ID: <b45c4699-1490-dd6a-bdb3-751355e90027@oracle.com>



On 2/21/19 11:49 AM, Maurizio Cimadamore wrote:
>
>
> On 21/02/2019 16:30, Vicente Romero wrote:
>>
>>
>> On 2/21/19 10:54 AM, Maurizio Cimadamore wrote:
>>>
>>>
>>> On 21/02/2019 15:22, Vicente Romero wrote:
>>>>
>>>>
>>>> On 2/21/19 8:43 AM, Maurizio Cimadamore wrote:
>>>>>
>>>>> Hate to be the party pooper :-)
>>>>>
>>>>> What happens with method calls?
>>>>>
>>>>> class Test {
>>>>> public static void main(String[] args) {
>>>>> ?? Object o = null;
>>>>> ?? o.
>>>>> ??? toString(); <-- NPE here
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>> So, while at some level I sympathize with the argument of not 
>>>>> making LNT more bloated, I can't help noting the asymmetry between 
>>>>> field and method access.
>>>>>
>>>>
>>>> yep that's a difference but shouldn't we wait and see if the bug 
>>>> referred by Remi solves the problem of the stack trace not being 
>>>> exact in some cases?
>>>
>>> I think that bug refers mostly to the message associated with the 
>>> NPE, not with the *line* at which it is reported. At least that's my 
>>> understanding.
>>>
>>
>> I'm not opposed to adding more lines to the LNT if that's what you 
>> are proposing, but I wonder about the benefit. I mean how bad it is 
>> to miss for one, two lines vs having bigger class files. Actually, 
>> this is an interesting experiment @Eddie could you please run an 
>> experiment to see how bigger would the class files for the whole JDK 
>> be with your patch? I'm also interested in redundant lines, it could 
>> be that this code adds redundant lines to the LNT and we should avoid 
>> that
>
> I guess what I'm arguing is not that we should add LNT - but that I 
> see no solid basis for doing this for methods, but not for field 
> access. If 8218628 will cure us from all sins :-) then the same 
> argument surely could be applied to method access?
>

I have executed:

1: class LineNumbers {
2:
3:? ?static class T {
4:? ? ?boolean b;
5:? ?}
6:
7:? ?static void doIt(boolean... values) {}
8:
9:? ?public static void main(String[] args) {
10:? ? ?T a = new T();
11:? ? ?T b = null;
12:
13:? ? ?doIt(
14:? ? ? ? ?a.b,
15:? ? ? ? ?b.b);
16:? ?}
17: }

with and without the last version of the patch for JDK-8218628, 
http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/04-RogerRiggs/, 
the message is more detailed:

Exception in thread "main" java.lang.NullPointerException: while trying 
to read the field 'b' of a null object loaded from a local variable at 
slot 2
 ??? at LineNumbers.main(LineNumbers.java:13)

vs:
Exception in thread "main" java.lang.NullPointerException
 ??? at LineNumbers.main(LineNumbers.java:13)

but it still refers to line 13, so it doesn't seem like it will produce 
an exact reference to the actual line where the NPE happened


> Maurizio
>

Vicente

>>
>>> Maurizio
>>>
>>
>> Vicente
>>
>>>>
>>>>> Maurizio
>>>>
>>>> Vicente
>>>>
>>>>>
>>>>> On 20/02/2019 14:20, Remi Forax wrote:
>>>>>> I don't think you need to bloat the line number table for this 
>>>>>> case because soon the NPE error message will be more precise [1].
>>>>>>
>>>>>> R?mi
>>>>>>
>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8218628
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>>     *De: *"Vicente Romero" <vicente.romero at oracle.com>
>>>>>>     *?: *"Eddie Aftandilian" <eaftan at google.com>
>>>>>>     *Cc: *"compiler-dev" <compiler-dev at openjdk.java.net>
>>>>>>     *Envoy?: *Mercredi 20 F?vrier 2019 14:38:45
>>>>>>     *Objet: *Re: RFR - JDK-8218650: LineNumberTable records for
>>>>>>     method invocations with arguments
>>>>>>
>>>>>>
>>>>>>
>>>>>>     On 2/19/19 8:27 PM, Eddie Aftandilian wrote:
>>>>>>
>>>>>>         Hi Vicente,
>>>>>>
>>>>>>         Thanks for the reply.? Can I ask why you don't think the
>>>>>>         LNT should contain entries for accesses to fields?? It
>>>>>>         seems that results in incorrect line numbers in certain
>>>>>>         cases.? For example, consider the following code:
>>>>>>
>>>>>>         1: class LineNumbers {
>>>>>>         2:
>>>>>>         3:? ?static class T {
>>>>>>         4:? ? ?boolean b;
>>>>>>         5:? ?}
>>>>>>         6:
>>>>>>         7:? ?static void doIt(boolean... values) {}
>>>>>>         8:
>>>>>>         9:? ?public static void main(String[] args) {
>>>>>>         10:? ? ?T a = new T();
>>>>>>         11:? ? ?T b = null;
>>>>>>         12:
>>>>>>         13:? ? ?doIt(
>>>>>>         14:? ? ? ? ?a.b,
>>>>>>         15:? ? ? ? ?b.b);
>>>>>>         16:? ?}
>>>>>>         17: }
>>>>>>
>>>>>>         $ javac LineNumbers.java
>>>>>>         $ java LineNumbers
>>>>>>         Exception in thread "main" java.lang.NullPointerException
>>>>>>         at LineNumbers.main(LineNumbers.java:13)
>>>>>>
>>>>>>         I would expect the exception to be at line 15, not 13.
>>>>>>
>>>>>>
>>>>>>     having the exception at 13 is plain bad or good enough? It
>>>>>>     seems to me that you want to do some automation based on the
>>>>>>     exact line where the exception was produced. I'm just worried
>>>>>>     that generating LNT entries for every expression would
>>>>>>     produce, probably unnecessarily, fluffier class files.
>>>>>>
>>>>>>
>>>>>>         Thanks,
>>>>>>         Eddie
>>>>>>
>>>>>>
>>>>>>     Thanks,
>>>>>>     Vicente
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>         On Fri, Feb 15, 2019 at 6:46 PM Vicente Romero
>>>>>>         <vicente.romero at oracle.com
>>>>>>         <mailto:vicente.romero at oracle.com>> wrote:
>>>>>>
>>>>>>             Hi Eddie,
>>>>>>
>>>>>>             Thanks for the patch. But first I'm not sure that
>>>>>>             there is a bug in the
>>>>>>             LNT. There is an entry in the LNT, I'm talking about
>>>>>>             the example at [1],
>>>>>>             for the invocation of method `id`. What we need to
>>>>>>             understand is why the
>>>>>>             stack trace is not referring to that line and is
>>>>>>             referring to line 12.
>>>>>>             In any case I don't think that the LNT should contain
>>>>>>             entries for
>>>>>>             accesses to fields.
>>>>>>
>>>>>>             Thanks,
>>>>>>             Vicente
>>>>>>
>>>>>>             [1] https://bugs.openjdk.java.net/browse/JDK-8218650
>>>>>>
>>>>>>             On 2/15/19 8:37 PM, Eddie Aftandilian wrote:
>>>>>>             > Hi,
>>>>>>             >
>>>>>>             > I have attached a patch for JDK-8218650, in which
>>>>>>             there are missing
>>>>>>             > line number table entries for field accesses. This
>>>>>>             is my first attempt
>>>>>>             > to contribute to OpenJDK, so I'm happy to take
>>>>>>             feedback.? Please see
>>>>>>             > the attached patch.
>>>>>>             >
>>>>>>             > Bug report:
>>>>>>             https://bugs.openjdk.java.net/browse/JDK-8218650
>>>>>>             >
>>>>>>             > Thanks,
>>>>>>             > Eddie Aftandilian
>>>>>>
>>>>>>
>>>>>>
>>>>
>>

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

From joe.darcy at oracle.com  Thu Feb 21 17:38:40 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 21 Feb 2019 09:38:40 -0800
Subject: JDK 12 RFR of JDK-8219254: Update explicit uses of latest
 source/target in langtools tests to a property
In-Reply-To: <ef938550-7d39-d328-cb90-e90dd76f02e9@oracle.com>
References: <465e331c-71ec-b3a9-2b0d-5fcc5e27921b@oracle.com>
 <64814110-bad0-5e48-0ad2-afcdd27cdc34@oracle.com>
 <f21e1549-141a-7d10-2196-9fc5bda684a1@oracle.com>
 <37fe1260-d64f-b3a4-bab8-068239549eb0@oracle.com>
 <ccae4d02-c82a-0f89-4efe-11b2c73dabca@oracle.com> <5C6D193B.70108@oracle.com>
 <e496b709-d9e6-b781-9d08-42e8024ca829@oracle.com>
 <ef938550-7d39-d328-cb90-e90dd76f02e9@oracle.com>
Message-ID: <c7884e90-5cdc-59ed-a9a8-cafce1e6df0f@oracle.com>

Hi Jon,

On 2/21/2019 9:30 AM, Jonathan Gibbons wrote:
>
> Mostly OK, but I think you've nullified/broken the test
>
> http://cr.openjdk.java.net/~darcy/8219254.3/test/langtools/tools/javac/6330997/T6330997.java.sdiff.html
>
> The test specifically comments:
>
>    27  * @summary javac should accept class files with major version of the next release
>
> And you've changed that behavior.
>
As briefly noted earlier in the review thread, when I looked at 
T6330997.java more closely, it doesn't actually need the -source/-target 
values being set. The class files for minimal source files are written 
out and then modified to bump the version number. So all that is needed 
is that the files are compiled under the current target, which can be 
implemented implicitly without -source/-target options.

(I and others have updated this file without much consideration for the 
last few version updates; better to leave it be if possible!)

Thanks,

-Joe


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

From jonathan.gibbons at oracle.com  Thu Feb 21 17:53:07 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 21 Feb 2019 09:53:07 -0800
Subject: JDK 12 RFR of JDK-8219254: Update explicit uses of latest
 source/target in langtools tests to a property
In-Reply-To: <c7884e90-5cdc-59ed-a9a8-cafce1e6df0f@oracle.com>
References: <465e331c-71ec-b3a9-2b0d-5fcc5e27921b@oracle.com>
 <64814110-bad0-5e48-0ad2-afcdd27cdc34@oracle.com>
 <f21e1549-141a-7d10-2196-9fc5bda684a1@oracle.com>
 <37fe1260-d64f-b3a4-bab8-068239549eb0@oracle.com>
 <ccae4d02-c82a-0f89-4efe-11b2c73dabca@oracle.com> <5C6D193B.70108@oracle.com>
 <e496b709-d9e6-b781-9d08-42e8024ca829@oracle.com>
 <ef938550-7d39-d328-cb90-e90dd76f02e9@oracle.com>
 <c7884e90-5cdc-59ed-a9a8-cafce1e6df0f@oracle.com>
Message-ID: <6cfe3141-14cd-1bb4-bf19-52f1d10c2624@oracle.com>

OK, I now better understand the weirdness of that test. Review approved.

-- Jon

On 2/21/19 9:38 AM, Joe Darcy wrote:
>
> Hi Jon,
>
> On 2/21/2019 9:30 AM, Jonathan Gibbons wrote:
>>
>> Mostly OK, but I think you've nullified/broken the test
>>
>> http://cr.openjdk.java.net/~darcy/8219254.3/test/langtools/tools/javac/6330997/T6330997.java.sdiff.html
>>
>> The test specifically comments:
>>
>>    27  * @summary javac should accept class files with major version of the next release
>>
>> And you've changed that behavior.
>>
> As briefly noted earlier in the review thread, when I looked at 
> T6330997.java more closely, it doesn't actually need the 
> -source/-target values being set. The class files for minimal source 
> files are written out and then modified to bump the version number. So 
> all that is needed is that the files are compiled under the current 
> target, which can be implemented implicitly without -source/-target 
> options.
>
> (I and others have updated this file without much consideration for 
> the last few version updates; better to leave it be if possible!)
>
> Thanks,
>
> -Joe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190221/433f70f2/attachment.html>

From jan.lahoda at oracle.com  Thu Feb 21 18:17:45 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 21 Feb 2019 19:17:45 +0100
Subject: JDK 12 RFR of JDK-8219254: Update explicit uses of latest
 source/target in langtools tests to a property
In-Reply-To: <6cfe3141-14cd-1bb4-bf19-52f1d10c2624@oracle.com>
References: <465e331c-71ec-b3a9-2b0d-5fcc5e27921b@oracle.com>
 <64814110-bad0-5e48-0ad2-afcdd27cdc34@oracle.com>
 <f21e1549-141a-7d10-2196-9fc5bda684a1@oracle.com>
 <37fe1260-d64f-b3a4-bab8-068239549eb0@oracle.com>
 <ccae4d02-c82a-0f89-4efe-11b2c73dabca@oracle.com> <5C6D193B.70108@oracle.com>
 <e496b709-d9e6-b781-9d08-42e8024ca829@oracle.com>
 <ef938550-7d39-d328-cb90-e90dd76f02e9@oracle.com>
 <c7884e90-5cdc-59ed-a9a8-cafce1e6df0f@oracle.com>
 <6cfe3141-14cd-1bb4-bf19-52f1d10c2624@oracle.com>
Message-ID: <5C6EEB49.8040303@oracle.com>

+1 from me as well.

Jan

On 21.2.2019 18:53, Jonathan Gibbons wrote:
> OK, I now better understand the weirdness of that test. Review approved.
>
> -- Jon
>
> On 2/21/19 9:38 AM, Joe Darcy wrote:
>>
>> Hi Jon,
>>
>> On 2/21/2019 9:30 AM, Jonathan Gibbons wrote:
>>>
>>> Mostly OK, but I think you've nullified/broken the test
>>>
>>> http://cr.openjdk.java.net/~darcy/8219254.3/test/langtools/tools/javac/6330997/T6330997.java.sdiff.html
>>>
>>> The test specifically comments:
>>>
>>>    27  * @summary javac should accept class files with major version of the next release
>>>
>>> And you've changed that behavior.
>>>
>> As briefly noted earlier in the review thread, when I looked at
>> T6330997.java more closely, it doesn't actually need the
>> -source/-target values being set. The class files for minimal source
>> files are written out and then modified to bump the version number. So
>> all that is needed is that the files are compiled under the current
>> target, which can be implemented implicitly without -source/-target
>> options.
>>
>> (I and others have updated this file without much consideration for
>> the last few version updates; better to leave it be if possible!)
>>
>> Thanks,
>>
>> -Joe
>>
>>

From vicente.romero at oracle.com  Thu Feb 21 18:22:56 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 21 Feb 2019 13:22:56 -0500
Subject: RFR - JDK-8218650: LineNumberTable records for method invocations
 with arguments
In-Reply-To: <5e645555-a300-11ab-dd67-abc8a58c8b92@oracle.com>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
 <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
 <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>
 <bd836c1c-dd75-2844-ea72-5ba502854c6d@oracle.com>
 <192583974.778153.1550672445854.JavaMail.zimbra@u-pem.fr>
 <4ca2c222-c76d-dc00-f766-99f30735a1d6@oracle.com>
 <2480d3a6-3a8d-9828-4bd9-975603e95aa4@oracle.com>
 <7867bc71-01a2-9fed-9547-21b8be0363eb@oracle.com>
 <6d961d82-0e83-3c5c-fbaa-6216bb949fa0@oracle.com>
 <fb5488b0-12a0-0d4f-a4cb-8720cb694eed@oracle.com>
 <5e645555-a300-11ab-dd67-abc8a58c8b92@oracle.com>
Message-ID: <17e37353-333b-f211-ceed-9ff0da0772a5@oracle.com>



On 2/21/19 12:02 PM, Maurizio Cimadamore wrote:
>
> On 21/02/2019 16:49, Maurizio Cimadamore wrote:
>>
>> I guess what I'm arguing is not that we should add LNT - but that I 
>> see no solid basis for doing this for methods, but not for field 
>> access. If 8218628 will cure us from all sins :-) then the same 
>> argument surely could be applied to method access?
>>
> Where I'm truly going with this is - we never really collected a list 
> of use cases as to when it would be nice to have a LNT generated; 
> there are many use cases out there, from debuggers to static analysis 
> tools (code coverage, findbugs...) and each of these might be affected 
> in subtle ways. Heck, once we've even stumbled upon a bug where 
> missing LNT entry was causing the JRockit VM to crash ;-)
>
> So, I think that, stepping back from this specific issue, we should 
> try (with the help of the community :-)) to identify the conditions 
> under which it would be desirable to have a LNT entry, and come up 
> with some sort of informal javac spec for that.
+1
>
> Maurizio
>
>


From jonathan.gibbons at oracle.com  Thu Feb 21 18:39:44 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 21 Feb 2019 10:39:44 -0800
Subject: javac spec?
In-Reply-To: <17e37353-333b-f211-ceed-9ff0da0772a5@oracle.com>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
 <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
 <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>
 <bd836c1c-dd75-2844-ea72-5ba502854c6d@oracle.com>
 <192583974.778153.1550672445854.JavaMail.zimbra@u-pem.fr>
 <4ca2c222-c76d-dc00-f766-99f30735a1d6@oracle.com>
 <2480d3a6-3a8d-9828-4bd9-975603e95aa4@oracle.com>
 <7867bc71-01a2-9fed-9547-21b8be0363eb@oracle.com>
 <6d961d82-0e83-3c5c-fbaa-6216bb949fa0@oracle.com>
 <fb5488b0-12a0-0d4f-a4cb-8720cb694eed@oracle.com>
 <5e645555-a300-11ab-dd67-abc8a58c8b92@oracle.com>
 <17e37353-333b-f211-ceed-9ff0da0772a5@oracle.com>
Message-ID: <66f35db4-d5f9-9d8d-0ab5-5e6e0b63309a@oracle.com>


On 2/21/19 10:22 AM, Vicente Romero wrote:
>>
>> So, I think that, stepping back from this specific issue, we should 
>> try (with the help of the community :-)) to identify the conditions 
>> under which it would be desirable to have a LNT entry, and come up 
>> with some sort of informal javac spec for that.
> +1 


I think this deserves follow-up.

In the past, some javac folk have joked about "The Mythical Compiler 
Spec", which specifies javac behavior, especially as it pertains to 
linking the language specification (JLS) to the VM specification (JVMS).

I'm realistic enough to admit that we'll never have the time and 
resources to sit down and write a full formal spec for javac's code 
translation strategy, nor do I think we would actually want it. But it 
does seem to me that when we deep-dive into specific issues, it would be 
worth writing up the conclusions and putting the write-up somewhere 
where it can easily be found and referred to in the future. (Meaning, 
something better than email and Google-search.)

-- Jon

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

From maurizio.cimadamore at oracle.com  Thu Feb 21 18:56:30 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 21 Feb 2019 18:56:30 +0000
Subject: RFR - JDK-8218650: LineNumberTable records for method invocations
 with arguments
In-Reply-To: <b45c4699-1490-dd6a-bdb3-751355e90027@oracle.com>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
 <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
 <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>
 <bd836c1c-dd75-2844-ea72-5ba502854c6d@oracle.com>
 <192583974.778153.1550672445854.JavaMail.zimbra@u-pem.fr>
 <4ca2c222-c76d-dc00-f766-99f30735a1d6@oracle.com>
 <2480d3a6-3a8d-9828-4bd9-975603e95aa4@oracle.com>
 <7867bc71-01a2-9fed-9547-21b8be0363eb@oracle.com>
 <6d961d82-0e83-3c5c-fbaa-6216bb949fa0@oracle.com>
 <fb5488b0-12a0-0d4f-a4cb-8720cb694eed@oracle.com>
 <b45c4699-1490-dd6a-bdb3-751355e90027@oracle.com>
Message-ID: <a25683a4-a0d6-a60c-de9c-5ebf98c6d23d@oracle.com>

Yeah - I was afraid that will be the case.

And I'm wondering what happens in cases where you have stuff like

b.
 ? b.
 ???? b.

e.g. access to fields in different classes with same name :-)

Of course a corner case, but...

Maurizio


On 21/02/2019 17:38, Vicente Romero wrote:
> but it still refers to line 13, so it doesn't seem like it will 
> produce an exact reference to the actual line where the NPE happened

From cushon at google.com  Thu Feb 21 19:27:31 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 21 Feb 2019 11:27:31 -0800
Subject: RFR - JDK-8218650: LineNumberTable records for method invocations
 with arguments
In-Reply-To: <a25683a4-a0d6-a60c-de9c-5ebf98c6d23d@oracle.com>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
 <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
 <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>
 <bd836c1c-dd75-2844-ea72-5ba502854c6d@oracle.com>
 <192583974.778153.1550672445854.JavaMail.zimbra@u-pem.fr>
 <4ca2c222-c76d-dc00-f766-99f30735a1d6@oracle.com>
 <2480d3a6-3a8d-9828-4bd9-975603e95aa4@oracle.com>
 <7867bc71-01a2-9fed-9547-21b8be0363eb@oracle.com>
 <6d961d82-0e83-3c5c-fbaa-6216bb949fa0@oracle.com>
 <fb5488b0-12a0-0d4f-a4cb-8720cb694eed@oracle.com>
 <b45c4699-1490-dd6a-bdb3-751355e90027@oracle.com>
 <a25683a4-a0d6-a60c-de9c-5ebf98c6d23d@oracle.com>
Message-ID: <CAL4QsgtW6xjj8vSYgRi0Aj_xgd7NNTXS59jog45FqWiVvgt=RA@mail.gmail.com>

For what it's worth I filed JDK-8218650 after a real debugging session
where I spent a while trying to understand an 'impossible' NPE before
realizing it was actually happening on the next line. So anecdotally at
leave one moderately savvy consumer of debug info would have benefited from
the extra LNT entries :)

The approach in JDK-8218628 sounds very promising, though. That information
would have been sufficient in the example that motivated JDK-8218650.

> e.g. access to fields in different classes with same name :-)

Won't that be an issue even if javac starts emitting LNT entries for field
accesses *and* the NPE messages get more detailed?

i.e. you could also have `b.b.b` and even if we know the line and that `b`
was involved it's ambiguous which dereference failed. (If the NPE message
included a qualified name of `b` that would be sufficient except for some
really pathological cases.)

Another option for improving the message for `b.b.b` would be to include a
column number, which was discussed in JDK-8020204.

On Thu, Feb 21, 2019 at 10:59 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Yeah - I was afraid that will be the case.
>
> And I'm wondering what happens in cases where you have stuff like
>
> b.
>    b.
>       b.
>
> e.g. access to fields in different classes with same name :-)
>
> Of course a corner case, but...
>
> Maurizio
>
>
> On 21/02/2019 17:38, Vicente Romero wrote:
> > but it still refers to line 13, so it doesn't seem like it will
> > produce an exact reference to the actual line where the NPE happened
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190221/898cbba6/attachment.html>

From maurizio.cimadamore at oracle.com  Thu Feb 21 23:37:32 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 21 Feb 2019 23:37:32 +0000
Subject: RFR - JDK-8218650: LineNumberTable records for method invocations
 with arguments
In-Reply-To: <CAL4QsgtW6xjj8vSYgRi0Aj_xgd7NNTXS59jog45FqWiVvgt=RA@mail.gmail.com>
References: <CA+7OGVpimOH4QotpcyR6AZ+fQftn-JqE1XBhXA9yLcZrxc01vA@mail.gmail.com>
 <d6ca9d61-c075-9dcd-70bb-c7cf126c3a0f@oracle.com>
 <CA+7OGVrzuVBe5zr6hyYOdMZ6sU-V4wTAx+MGNC1YPu7ehq2q0Q@mail.gmail.com>
 <bd836c1c-dd75-2844-ea72-5ba502854c6d@oracle.com>
 <192583974.778153.1550672445854.JavaMail.zimbra@u-pem.fr>
 <4ca2c222-c76d-dc00-f766-99f30735a1d6@oracle.com>
 <2480d3a6-3a8d-9828-4bd9-975603e95aa4@oracle.com>
 <7867bc71-01a2-9fed-9547-21b8be0363eb@oracle.com>
 <6d961d82-0e83-3c5c-fbaa-6216bb949fa0@oracle.com>
 <fb5488b0-12a0-0d4f-a4cb-8720cb694eed@oracle.com>
 <b45c4699-1490-dd6a-bdb3-751355e90027@oracle.com>
 <a25683a4-a0d6-a60c-de9c-5ebf98c6d23d@oracle.com>
 <CAL4QsgtW6xjj8vSYgRi0Aj_xgd7NNTXS59jog45FqWiVvgt=RA@mail.gmail.com>
Message-ID: <ad46feee-82ed-eedc-89cd-e1671a5bc27f@oracle.com>


On 21/02/2019 19:27, Liam Miller-Cushon wrote:
> For what it's worth I filed?JDK-8218650 after a real debugging session 
> where I spent a while trying to understand an 'impossible' NPE before 
> realizing it was actually happening on the next line. So anecdotally 
> at leave one moderately savvy consumer of debug info would have 
> benefited from the extra LNT entries :)
>
> The approach in JDK-8218628 sounds very promising, though. That 
> information would have been sufficient in the example that motivated 
> JDK-8218650.
>
> > e.g. access to fields in different classes with same name :-)
>
> Won't that be an issue even if javac starts emitting LNT entries for 
> field accesses *and* the NPE messages get more detailed?
>
> i.e. you could also have `b.b.b` and even if we know the line and that 
> `b` was involved it's ambiguous which dereference failed. (If the NPE 
> message included a qualified name of `b` that would be sufficient 
> except for some really pathological cases.)
>
Yes - in that case not much can be done - unless we add column info too :-)
> Another option for improving the message for `b.b.b` would be to 
> include a column number, which was discussed in JDK-8020204.

Ah :-)

Maurizio

>
> On Thu, Feb 21, 2019 at 10:59 AM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     Yeah - I was afraid that will be the case.
>
>     And I'm wondering what happens in cases where you have stuff like
>
>     b.
>     ?? b.
>     ????? b.
>
>     e.g. access to fields in different classes with same name :-)
>
>     Of course a corner case, but...
>
>     Maurizio
>
>
>     On 21/02/2019 17:38, Vicente Romero wrote:
>     > but it still refers to line 13, so it doesn't seem like it will
>     > produce an exact reference to the actual line where the NPE happened
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190221/2bab4c38/attachment.html>

From joe.darcy at oracle.com  Wed Feb 27 02:11:08 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 26 Feb 2019 18:11:08 -0800
Subject: JDK 13 RFR of JDK-8219805: Cross-link javax.lang.model.{type,
 element} packages to utility interfaces
Message-ID: <af3e7b98-6613-16fd-b1b0-f6c2e17baf94@oracle.com>

Hello,

As suggested by Jon, please review the patch below to add @see links 
between the package-info files for javax.lang.model.{type, element} and 
the corresponding utility interfaces in in javax.lang.model.util.{Types, 
Elements}.

Thanks,

-Joe

diff -r ca23d3475af0 
src/java.compiler/share/classes/javax/lang/model/element/package-info.java
--- 
a/src/java.compiler/share/classes/javax/lang/model/element/package-info.java 
Tue Feb 26 15:29:08 2019 -0800
+++ 
b/src/java.compiler/share/classes/javax/lang/model/element/package-info.java 
Tue Feb 26 18:08:48 2019 -0800
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 2005, 2017, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights 
reserved.
 ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 ? *
 ? * This code is free software; you can redistribute it and/or modify it
@@ -107,6 +107,7 @@
 ? * @author Joseph D. Darcy
 ? * @author Scott Seligman
 ? * @author Peter von der Ah&eacute;
+ * @see javax.lang.model.util.Elements
 ? * @since 1.6
 ? */
 ?package javax.lang.model.element;
diff -r ca23d3475af0 
src/java.compiler/share/classes/javax/lang/model/type/package-info.java
--- 
a/src/java.compiler/share/classes/javax/lang/model/type/package-info.java 
Tue Feb 26 15:29:08 2019 -0800
+++ 
b/src/java.compiler/share/classes/javax/lang/model/type/package-info.java 
Tue Feb 26 18:08:48 2019 -0800
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 2005, 2006, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights 
reserved.
 ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 ? *
 ? * This code is free software; you can redistribute it and/or modify it
@@ -36,6 +36,7 @@
 ? * @author Joseph D. Darcy
 ? * @author Scott Seligman
 ? * @author Peter von der Ah&eacute;
+ * @see javax.lang.model.util.Types
 ? * @since 1.6
 ? */
 ?package javax.lang.model.type;


From vicente.romero at oracle.com  Wed Feb 27 13:22:15 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 27 Feb 2019 08:22:15 -0500
Subject: JDK 13 RFR of JDK-8219805: Cross-link javax.lang.model.{type,
 element} packages to utility interfaces
In-Reply-To: <af3e7b98-6613-16fd-b1b0-f6c2e17baf94@oracle.com>
References: <af3e7b98-6613-16fd-b1b0-f6c2e17baf94@oracle.com>
Message-ID: <cacc8037-1713-54b9-e94b-e992a8674712@oracle.com>

looks good,
Vicente

On 2/26/19 9:11 PM, Joe Darcy wrote:
> Hello,
>
> As suggested by Jon, please review the patch below to add @see links 
> between the package-info files for javax.lang.model.{type, element} 
> and the corresponding utility interfaces in in 
> javax.lang.model.util.{Types, Elements}.
>
> Thanks,
>
> -Joe
>
> diff -r ca23d3475af0 
> src/java.compiler/share/classes/javax/lang/model/element/package-info.java
> --- 
> a/src/java.compiler/share/classes/javax/lang/model/element/package-info.java 
> Tue Feb 26 15:29:08 2019 -0800
> +++ 
> b/src/java.compiler/share/classes/javax/lang/model/element/package-info.java 
> Tue Feb 26 18:08:48 2019 -0800
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 2005, 2017, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights 
> reserved.
> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> ? *
> ? * This code is free software; you can redistribute it and/or modify it
> @@ -107,6 +107,7 @@
> ? * @author Joseph D. Darcy
> ? * @author Scott Seligman
> ? * @author Peter von der Ah&eacute;
> + * @see javax.lang.model.util.Elements
> ? * @since 1.6
> ? */
> ?package javax.lang.model.element;
> diff -r ca23d3475af0 
> src/java.compiler/share/classes/javax/lang/model/type/package-info.java
> --- 
> a/src/java.compiler/share/classes/javax/lang/model/type/package-info.java 
> Tue Feb 26 15:29:08 2019 -0800
> +++ 
> b/src/java.compiler/share/classes/javax/lang/model/type/package-info.java 
> Tue Feb 26 18:08:48 2019 -0800
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 2005, 2006, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights 
> reserved.
> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> ? *
> ? * This code is free software; you can redistribute it and/or modify it
> @@ -36,6 +36,7 @@
> ? * @author Joseph D. Darcy
> ? * @author Scott Seligman
> ? * @author Peter von der Ah&eacute;
> + * @see javax.lang.model.util.Types
> ? * @since 1.6
> ? */
> ?package javax.lang.model.type;
>


From christoph.langer at sap.com  Thu Feb 28 11:01:10 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 28 Feb 2019 11:01:10 +0000
Subject: RFR(S): 8219915: [TESTBUG] Fix test
 langtools/tools/javac/processing/model/completionfailure/SymbolsDontCumulate.java
 in standalone mode
Message-ID: <21c841fdd64a41748168d7fa5052aaf6@sap.com>

Hi,

I have a little test fix to contribute.

Bug: https://bugs.openjdk.java.net/browse/JDK-8219915
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8219915.0/

If you run the test standalone on a scratched directory, it'll fail due to inability to compile toolbox test library. The jtreg directive @modules jdk.compiler/com.sun.tools.javac.main needs to be added. I also took the opportunity for a few cleanups.

Thanks
Christoph

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

From jan.lahoda at oracle.com  Thu Feb 28 13:58:36 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 28 Feb 2019 14:58:36 +0100
Subject: RFR(S): 8219915: [TESTBUG] Fix test
 langtools/tools/javac/processing/model/completionfailure/SymbolsDontCumulate.java
 in standalone mode
In-Reply-To: <21c841fdd64a41748168d7fa5052aaf6@sap.com>
References: <21c841fdd64a41748168d7fa5052aaf6@sap.com>
Message-ID: <5C77E90C.1060409@oracle.com>

Looks good to me. Thanks for fixing this!

Jan

On 28.2.2019 12:01, Langer, Christoph wrote:
> Hi,
>
> I have a little test fix to contribute.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8219915
>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8219915.0/
>
> If you run the test standalone on a scratched directory, it?ll fail due
> to inability to compile toolbox test library. The jtreg directive
> @modules jdk.compiler/com.sun.tools.javac.main needs to be added. I also
> took the opportunity for a few cleanups.
>
> Thanks
>
> Christoph
>

From jonathan.gibbons at oracle.com  Thu Feb 28 21:47:24 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 28 Feb 2019 13:47:24 -0800
Subject: RFR: JDK-8217868: Crash for overlap between source path and patch
 module path
In-Reply-To: <5C62CF8E.5010107@oracle.com>
References: <5C5C5FE7.3050406@oracle.com>
 <338d17e8-7430-fca1-c550-32671fc04c23@oracle.com>
 <5C62CF8E.5010107@oracle.com>
Message-ID: <44bd8713-13a3-365e-0faa-fe4e1aacb30b@oracle.com>

I'm not a big fan on initializing the module system twice, but in the 
overall scheme of things, it's not the worst that can happen.

At some point, it may be worth revisiting this, but for now, this looks OK.

You'll have (trivial) merge conflicts; one of the files (for the old 
doclet world) has gone away.

-- Jon


On 02/12/2019 05:52 AM, Jan Lahoda wrote:
> Hi Jon,
>
> Thanks for the comments!
>
> On 12.2.2019 02:27, Jonathan Gibbons wrote:
>> Why the call of modules.newRound() in JavadocTool line 202?
>>
>> As I read it, nothing much should have happened to the modules up to
>> this point ... the code has just been parsing files, hasn't it?
>
> ElementsTable.scanSpecifiedItems is calling initModules at the end, 
> and is invoked from:
>
> ??????????? etable.packages(packageNames)
> ??????????????????? .classTrees(classTrees.toList())
> ??????????????????? .scanSpecifiedItems();
>
>
> I tried to remove that, but it turned out 
> ElementsTable.findModuleOfPackageName needs the module system to be 
> set-up, and is (eventually) called from ElementsTable.getFilesToParse. 
> So I've incline to let the module system set-up and then set it up 
> again, using newRound() to clear it between.
>
> (If needed, we could keep the javadoc tool(s) untouched, by having one 
> more check in Modules.)
>
>>
>> The use case looks interesting, because it does look like a
>> configuration error and so I was expecting more conflict detection, but
>> maybe that's a different separable problem.? I guess if ever we had a
>> patch path for a module mX that pointed to a directory containing a
>> module-info.java containing mY, and we needed mX, we would get some sort
>> of "wrong module found" error. Here, we have the patch path matching the
>> sourcepath, but presumably we can't go round pairwise checking paths for
>> silly combinations.
>
> I guess we could (and maybe should) have a task to introduce a warning 
> for cases like this. But javac knows from which module it was reading 
> the file from, so seemed more reliable to simply reuse that knowledge.
>
> Jan
>
>>
>> -- Jon
>>
>>
>> On 02/07/2019 08:42 AM, Jan Lahoda wrote:
>>> Hi,
>>>
>>> Consider code like this:
>>> ---src/module-info.java
>>> module m { uses test.Test; }
>>> ---src/test/Test.java
>>> package test; public class Test { }
>>>
>>> And javac invocation like:
>>> javac -sourcepath src --patch-module m2=src module-info.java
>>>
>>> While analysing the module-info, javac will try to lazily/implicitly
>>> load the test.Test class. And when Modules.setCompilationUnitModules
>>> is called for test.Test, it will eventually call singleModuleOverride,
>>> which will look at --patch-module to find if the given source is on
>>> any module patch. And it will find out it is a module patch for m2,
>>> but as javac never heard about m2 before, it will crash.
>>>
>>> Seems that the biggest underlying problem is that even though javac
>>> knows which modules owns the class, it will try to look for the owner
>>> on the patch path. The proposed patch fixes that, and uses the correct
>>> owning module. This requires also a little cleanup in javadoc.
>>>
>>> Webrev: cr.openjdk.java.net/~jlahoda/8217868/webrev.00/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217868
>>>
>>> How does this look?
>>>
>>> Thanks,
>>> ??? Jan
>>