From maurizio.cimadamore at oracle.com  Mon Oct  3 09:50:23 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 3 Oct 2016 10:50:23 +0100
Subject: Clarification about accessibility of private members
In-Reply-To: <CA+7OGVoBJ-j3yuf5NQms+5tiOT-O6p_Rb5pzJcO5f1urYfK9mg@mail.gmail.com>
References: <CA+7OGVoBJ-j3yuf5NQms+5tiOT-O6p_Rb5pzJcO5f1urYfK9mg@mail.gmail.com>
Message-ID: <80e82160-97af-c5c2-68b2-3b42a9f6c0d6@oracle.com>



On 30/09/16 22:31, Eddie Aftandilian wrote:
> JLS 6.6.1 says, "Otherwise, the member or constructor is declared 
> private, and access is permitted if and only if it occurs within the 
> body of the top level class (?7.6) that encloses the declaration of 
> the member or constructor."  Under that definition, I believe the 
> following code should be legal:
>
> class Holder {
>   class Super {
>     private String s1;
>   }
>   class Sub extends Super {
>     private String doIt() {
>       return s1;
>     }
>   }
> }
>
> Holder is the top level class that encloses the declaration of s1, and 
> the "return s1" statement occurs inside Holder's body.  However, javac 
> 1.8.0 issues an error on this code:
>
> Holder.java:7: error: s1 has private access in Holder.Super
>       return s1;
>              ^
> 1 error
>
> What am I missing?
I think there's another aspect at stake here: interplay between 
inheritance and scoping. But let's start from the beginning: the rules 
for checking that 's1' is a valid field identifier are defined in 6.5.6.1:

"If an expression name consists of a single Identifier, then there must 
be exactly one declaration denoting either a local variable, parameter, 
or field *visible* (?6.4.1) at the point at which the Identifier occurs. 
Otherwise, a compile-time error occurs."

What does 'visible' mean? Let's expand 6.4.1:

"A declaration d is said to be visible at point p in a program if the 
scope of d includes p, and d is not shadowed by any other declaration at p."

Ok, so the question we need to ask is: does the scope of 's1' includes 
the instance method doIt() ?

The scope of a field is defined as follows in JLS 6.3:

"The scope of a declaration of a member |m| declared in or inherited by 
a class type C (?8.1.6 
<https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.1.6>) 
is the entire body of C, including any nested type declarations."

So, from the perspective of 'Sub' the only way for it to have a field 
's1' in scope is:

* if it declares the field 's1'
* if it inherits a field 's1'

In your example, the first bullet clearly does not apply: 'Sub' doesn't 
declare any fields. So the question is, does 'Sub' inherits 's1' from 
'Super' ? The answer is again no, this time because of JLS 8.2. (Class 
Members):

"Members of a class that are declared |private| are not inherited by 
subclasses of that class."

That is, 's1' is not inherited because it is declared private in 'Sup'. 
Popping back, this means that 's1' is not visible inside 'doIt()' and 
therefore the error message you get is expected.

Maurizio
> Thanks,
> Eddie

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

From rafael.wth at gmail.com  Mon Oct  3 10:13:29 2016
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Mon, 3 Oct 2016 12:13:29 +0200
Subject: Why does javac use "invokespecial" for diamond inheritance?
Message-ID: <CA+DM0AkcgPikh3HRRVUZwJiZTsqS8Gq+OQxVeVActc1BE-JZog@mail.gmail.com>

I am wondering why javac is using an invokespecial instruction for a bridge
method in the following case. Considering the following refactoring
starting from:

class A {
  public void m(String s) {
    System.out.println("foo");
  }
}

class B extends A { }

class C extends B {
  public void m(String s) {
    System.out.println("bar");
  }
}

I would change the implementing of B to implement an additional interface:

interface I<T> {
  void m(T t);
}

class B extends A implements I<String> { }

C would live in its own module that is not recompiled upon changing B. I do
however not consider this a problem as the change of B is binary
compatible. However, B ends up with the following bridge method:

class B extends A implements I<String> {
  public bridge void m(Object o) {
    Foo.special.m((String) o);
  }
}

If a program does now invoke I::m on an instance of C, "foo" is printed
instead of "bar". This violates the intended virtual dispatch for C. In my
opinion, this should not happen. Bridge methods, unless "visibility
bridges" should always use invokevirtual as an override in C, should make
it impossible to invoke A::m directly from outside the class.

Did I miss something here or is this a bug?

Thank you for the clarification,
Best regards, Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161003/d687e9a3/attachment-0001.html>

From forax at univ-mlv.fr  Mon Oct  3 13:42:52 2016
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 3 Oct 2016 15:42:52 +0200 (CEST)
Subject: Why does javac use "invokespecial" for diamond inheritance?
In-Reply-To: <CA+DM0AkcgPikh3HRRVUZwJiZTsqS8Gq+OQxVeVActc1BE-JZog@mail.gmail.com>
References: <CA+DM0AkcgPikh3HRRVUZwJiZTsqS8Gq+OQxVeVActc1BE-JZog@mail.gmail.com>
Message-ID: <126526629.325590.1475502172744.JavaMail.zimbra@u-pem.fr>

Hi Rafael, 
it's not a binary compatible change. 

if the compiler emits an invokevirtual instead of an invokespecial, you can create an infinite loop between the bridges 
https://bugs.openjdk.java.net/browse/JDK-6996415 

R?mi 

> De: "Rafael Winterhalter" <rafael.wth at gmail.com>
> ?: compiler-dev at openjdk.java.net
> Envoy?: Lundi 3 Octobre 2016 12:13:29
> Objet: Why does javac use "invokespecial" for diamond inheritance?

> I am wondering why javac is using an invokespecial instruction for a bridge
> method in the following case. Considering the following refactoring starting
> from:

> class A {
> public void m(String s) {
> System.out.println("foo");
> }
> }

> class B extends A { }

> class C extends B {
> public void m(String s) {
> System.out.println("bar");
> }
> }

> I would change the implementing of B to implement an additional interface:

> interface I<T> {
> void m(T t);
> }

> class B extends A implements I<String> { }

> C would live in its own module that is not recompiled upon changing B. I do
> however not consider this a problem as the change of B is binary compatible.
> However, B ends up with the following bridge method:

> class B extends A implements I<String> {
> public bridge void m(Object o) {
> Foo.special.m((String) o);
> }
> }

> If a program does now invoke I::m on an instance of C, "foo" is printed instead
> of "bar". This violates the intended virtual dispatch for C. In my opinion,
> this should not happen. Bridge methods, unless "visibility bridges" should
> always use invokevirtual as an override in C, should make it impossible to
> invoke A::m directly from outside the class.

> Did I miss something here or is this a bug?

> Thank you for the clarification,
> Best regards, Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161003/02c95375/attachment.html>

From maurizio.cimadamore at oracle.com  Mon Oct  3 14:30:37 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 3 Oct 2016 15:30:37 +0100
Subject: Why does javac use "invokespecial" for diamond inheritance?
In-Reply-To: <126526629.325590.1475502172744.JavaMail.zimbra@u-pem.fr>
References: <CA+DM0AkcgPikh3HRRVUZwJiZTsqS8Gq+OQxVeVActc1BE-JZog@mail.gmail.com>
	<126526629.325590.1475502172744.JavaMail.zimbra@u-pem.fr>
Message-ID: <d0426792-921a-a0cc-640b-43f23fa9a785@oracle.com>

Hi,
I had the same reaction as Remi when first reading this thread. In 
principle, yes, replacing invokespecial with invokevirtual can cause 
bridge calls to go up and down the hierarchy and has more potential for 
generating infinite loops. That said, I have not been able to come up 
with a reasonable test case that would introduce an infinite loop should 
javac implement the proposed change. While 6996415 is definitively 
related, I believe that the loop in that example is started by a bad 
descriptor ending up in the explicit supercall (see bug evaluation) 
rather than by a problem between invokevirtual vs. invokespecial.

I also note that ECJ already generates an invokevirtual in the reported 
example. Again, I could not find any clue of a bridge-related loop that 
shows up in ECJ but not in javac (but I'd be happy to know if something 
like that exists),.

So, maybe it's a safe move after all?

Maurizio



On 03/10/16 14:42, Remi Forax wrote:
> Hi Rafael,
> it's not a binary compatible change.
>
> if the compiler emits an invokevirtual instead of an invokespecial, 
> you can create an infinite loop between the bridges
> https://bugs.openjdk.java.net/browse/JDK-6996415
>
> R?mi
>
> ------------------------------------------------------------------------
>
>     *De: *"Rafael Winterhalter" <rafael.wth at gmail.com>
>     *?: *compiler-dev at openjdk.java.net
>     *Envoy?: *Lundi 3 Octobre 2016 12:13:29
>     *Objet: *Why does javac use "invokespecial" for diamond inheritance?
>
>     I am wondering why javac is using an invokespecial instruction for
>     a bridge method in the following case. Considering the following
>     refactoring starting from:
>
>     class A {
>       public void m(String s) {
>         System.out.println("foo");
>       }
>     }
>
>     class B extends A { }
>
>     class C extends B {
>       public void m(String s) {
>         System.out.println("bar");
>       }
>     }
>
>     I would change the implementing of B to implement an additional
>     interface:
>
>     interface I<T> {
>       void m(T t);
>     }
>
>     class B extends A implements I<String> { }
>
>     C would live in its own module that is not recompiled upon
>     changing B. I do however not consider this a problem as the change
>     of B is binary compatible. However, B ends up with the following
>     bridge method:
>
>     class B extends A implements I<String> {
>       public bridge void m(Object o) {
>         Foo.special.m((String) o);
>       }
>     }
>
>     If a program does now invoke I::m on an instance of C, "foo" is
>     printed instead of "bar". This violates the intended virtual
>     dispatch for C. In my opinion, this should not happen. Bridge
>     methods, unless "visibility bridges" should always use
>     invokevirtual as an override in C, should make it impossible to
>     invoke A::m directly from outside the class.
>
>     Did I miss something here or is this a bug?
>
>     Thank you for the clarification,
>     Best regards, Rafael
>

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

From maurizio.cimadamore at oracle.com  Mon Oct  3 15:18:13 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 3 Oct 2016 16:18:13 +0100
Subject: Why does javac use "invokespecial" for diamond inheritance?
In-Reply-To: <d0426792-921a-a0cc-640b-43f23fa9a785@oracle.com>
References: <CA+DM0AkcgPikh3HRRVUZwJiZTsqS8Gq+OQxVeVActc1BE-JZog@mail.gmail.com>
	<126526629.325590.1475502172744.JavaMail.zimbra@u-pem.fr>
	<d0426792-921a-a0cc-640b-43f23fa9a785@oracle.com>
Message-ID: <5a719d3a-fce7-c02b-727f-f2467ec8b693@oracle.com>

Ah - finally found an example where things would regress (inspired from 
this old thread [1]). Consider this example:

interface Foo {
    Object m();
}

class Sup {
    public Object m() { return null; }
}


class Parent extends Sup implements Foo  { }

class Child extends Parent {
    public Parent m() { return (Parent)super.m(); }


    public static void main(String[] args) {
       new Child().m();
    }
}


Let's compile all classes, and then tweak Sup as follows:

class Sup {
    public *Parent* m() { return null; }
}

And then just recompile Sup.

This refactoring works - and running Child after the change to Sup still 
works.

But if the bridge generation logic is tweaked so that invokevirtual is 
used instead of invokespecial, you end up with a loop (because Child.m() 
and the bridge method for Parent.m() keep calling each other). In the 
current world, the bridge in Parent uses invokespecial to target Sup.m 
which doesn't cause infinite looping (but, as observed in this thread, 
is more prone to problems when subclasses happen to override m()).

Concluding, this seems mostly a matter of picking your poison. There's 
no (static) scheme that could guarantee perfect binary compatibility and 
absence of spurious loops in the face of code motion. One could argue 
that the problem outlined in this email already exists, so the proposed 
bridge generation change would not introduce a new problem, but make an 
existing one bigger. That said, I don' think there's enough basis here 
to go and change what javac does today.

[1] - 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-February/009119.html

Maurizio





On 03/10/16 15:30, Maurizio Cimadamore wrote:
>
> Hi,
> I had the same reaction as Remi when first reading this thread. In 
> principle, yes, replacing invokespecial with invokevirtual can cause 
> bridge calls to go up and down the hierarchy and has more potential 
> for generating infinite loops. That said, I have not been able to come 
> up with a reasonable test case that would introduce an infinite loop 
> should javac implement the proposed change. While 6996415 is 
> definitively related, I believe that the loop in that example is 
> started by a bad descriptor ending up in the explicit supercall (see 
> bug evaluation) rather than by a problem between invokevirtual vs. 
> invokespecial.
>
> I also note that ECJ already generates an invokevirtual in the 
> reported example. Again, I could not find any clue of a bridge-related 
> loop that shows up in ECJ but not in javac (but I'd be happy to know 
> if something like that exists),.
>
> So, maybe it's a safe move after all?
>
> Maurizio
>
>
>
> On 03/10/16 14:42, Remi Forax wrote:
>> Hi Rafael,
>> it's not a binary compatible change.
>>
>> if the compiler emits an invokevirtual instead of an invokespecial, 
>> you can create an infinite loop between the bridges
>> https://bugs.openjdk.java.net/browse/JDK-6996415
>>
>> R?mi
>>
>> ------------------------------------------------------------------------
>>
>>     *De: *"Rafael Winterhalter" <rafael.wth at gmail.com>
>>     *?: *compiler-dev at openjdk.java.net
>>     *Envoy?: *Lundi 3 Octobre 2016 12:13:29
>>     *Objet: *Why does javac use "invokespecial" for diamond inheritance?
>>
>>     I am wondering why javac is using an invokespecial instruction
>>     for a bridge method in the following case. Considering the
>>     following refactoring starting from:
>>
>>     class A {
>>       public void m(String s) {
>>         System.out.println("foo");
>>       }
>>     }
>>
>>     class B extends A { }
>>
>>     class C extends B {
>>       public void m(String s) {
>>         System.out.println("bar");
>>       }
>>     }
>>
>>     I would change the implementing of B to implement an additional
>>     interface:
>>
>>     interface I<T> {
>>       void m(T t);
>>     }
>>
>>     class B extends A implements I<String> { }
>>
>>     C would live in its own module that is not recompiled upon
>>     changing B. I do however not consider this a problem as the
>>     change of B is binary compatible. However, B ends up with the
>>     following bridge method:
>>
>>     class B extends A implements I<String> {
>>       public bridge void m(Object o) {
>>         Foo.special.m((String) o);
>>       }
>>     }
>>
>>     If a program does now invoke I::m on an instance of C, "foo" is
>>     printed instead of "bar". This violates the intended virtual
>>     dispatch for C. In my opinion, this should not happen. Bridge
>>     methods, unless "visibility bridges" should always use
>>     invokevirtual as an override in C, should make it impossible to
>>     invoke A::m directly from outside the class.
>>
>>     Did I miss something here or is this a bug?
>>
>>     Thank you for the clarification,
>>     Best regards, Rafael
>>
>

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

From rafael.wth at gmail.com  Mon Oct  3 15:52:14 2016
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Mon, 3 Oct 2016 17:52:14 +0200
Subject: Why does javac use "invokespecial" for diamond inheritance?
In-Reply-To: <5a719d3a-fce7-c02b-727f-f2467ec8b693@oracle.com>
References: <CA+DM0AkcgPikh3HRRVUZwJiZTsqS8Gq+OQxVeVActc1BE-JZog@mail.gmail.com>
	<126526629.325590.1475502172744.JavaMail.zimbra@u-pem.fr>
	<d0426792-921a-a0cc-640b-43f23fa9a785@oracle.com>
	<5a719d3a-fce7-c02b-727f-f2467ec8b693@oracle.com>
Message-ID: <CA+DM0A=duPA_SQ+u9vbwdw4a=vGK=pYFTRKrthdikZrFhaSoXA@mail.gmail.com>

Thank you both for the clarification. Given your example, it makes sense to
me. But I am still a bit surpised of the behavior since, as you say, its a
matter of picking your poison. Personally, I must say that I would prefer
the infite loop as an outcome as this at least crashes the application.
This accidental super method invocation might instead get my application
into a bad state or even offer an exploit when allowing some security
circumvention or corrupting a data base.

Best regards, Rafael

2016-10-03 17:18 GMT+02:00 Maurizio Cimadamore <
maurizio.cimadamore at oracle.com>:

> Ah - finally found an example where things would regress (inspired from
> this old thread [1]). Consider this example:
>
> interface Foo {
>    Object m();
> }
>
> class Sup {
>    public Object m() { return null; }
> }
>
>
> class Parent extends Sup implements Foo  { }
>
> class Child extends Parent {
>    public Parent m() { return (Parent)super.m(); }
>
>
>    public static void main(String[] args) {
>       new Child().m();
>    }
> }
>
>
> Let's compile all classes, and then tweak Sup as follows:
>
> class Sup {
>    public *Parent* m() { return null; }
> }
>
> And then just recompile Sup.
>
> This refactoring works - and running Child after the change to Sup still
> works.
>
> But if the bridge generation logic is tweaked so that invokevirtual is
> used instead of invokespecial, you end up with a loop (because Child.m()
> and the bridge method for Parent.m() keep calling each other). In the
> current world, the bridge in Parent uses invokespecial to target Sup.m
> which doesn't cause infinite looping (but, as observed in this thread, is
> more prone to problems when subclasses happen to override m()).
> Concluding, this seems mostly a matter of picking your poison. There's no
> (static) scheme that could guarantee perfect binary compatibility and
> absence of spurious loops in the face of code motion. One could argue that
> the problem outlined in this email already exists, so the proposed bridge
> generation change would not introduce a new problem, but make an existing
> one bigger. That said, I don' think there's enough basis here to go and
> change what javac does today.
>
> [1] - http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-
> February/009119.html
>
> Maurizio
>
>
>
>
>
> On 03/10/16 15:30, Maurizio Cimadamore wrote:
>
> Hi,
> I had the same reaction as Remi when first reading this thread. In
> principle, yes, replacing invokespecial with invokevirtual can cause bridge
> calls to go up and down the hierarchy and has more potential for generating
> infinite loops. That said, I have not been able to come up with a
> reasonable test case that would introduce an infinite loop should javac
> implement the proposed change. While 6996415 is definitively related, I
> believe that the loop in that example is started by a bad descriptor ending
> up in the explicit supercall (see bug evaluation) rather than by a problem
> between invokevirtual vs. invokespecial.
>
> I also note that ECJ already generates an invokevirtual in the reported
> example. Again, I could not find any clue of a bridge-related loop that
> shows up in ECJ but not in javac (but I'd be happy to know if something
> like that exists),.
>
> So, maybe it's a safe move after all?
>
> Maurizio
>
>
>
> On 03/10/16 14:42, Remi Forax wrote:
>
> Hi Rafael,
> it's not a binary compatible change.
>
> if the compiler emits an invokevirtual instead of an invokespecial, you
> can create an infinite loop between the bridges
> https://bugs.openjdk.java.net/browse/JDK-6996415
>
> R?mi
>
> ------------------------------
>
> *De: *"Rafael Winterhalter" <rafael.wth at gmail.com> <rafael.wth at gmail.com>
> *?: *compiler-dev at openjdk.java.net
> *Envoy?: *Lundi 3 Octobre 2016 12:13:29
> *Objet: *Why does javac use "invokespecial" for diamond inheritance?
>
> I am wondering why javac is using an invokespecial instruction for a
> bridge method in the following case. Considering the following refactoring
> starting from:
>
> class A {
>   public void m(String s) {
>     System.out.println("foo");
>   }
> }
>
> class B extends A { }
>
> class C extends B {
>   public void m(String s) {
>     System.out.println("bar");
>   }
> }
>
> I would change the implementing of B to implement an additional interface:
>
> interface I<T> {
>   void m(T t);
> }
>
> class B extends A implements I<String> { }
>
> C would live in its own module that is not recompiled upon changing B. I
> do however not consider this a problem as the change of B is binary
> compatible. However, B ends up with the following bridge method:
>
> class B extends A implements I<String> {
>   public bridge void m(Object o) {
>     Foo.special.m((String) o);
>   }
> }
>
> If a program does now invoke I::m on an instance of C, "foo" is printed
> instead of "bar". This violates the intended virtual dispatch for C. In my
> opinion, this should not happen. Bridge methods, unless "visibility
> bridges" should always use invokevirtual as an override in C, should make
> it impossible to invoke A::m directly from outside the class.
>
> Did I miss something here or is this a bug?
>
> Thank you for the clarification,
> Best regards, Rafael
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161003/cb1f9e60/attachment.html>

From bsrbnd at gmail.com  Tue Oct  4 13:08:19 2016
From: bsrbnd at gmail.com (bsrbnd)
Date: Tue, 4 Oct 2016 15:08:19 +0200
Subject: [PATCH] 8164327: Attr should implement method visitCase
Message-ID: <CAEgw74DTFQK79cbZtWj1QqDnsYVRaC3n7ba+wgrskZxMO6i2uQ@mail.gmail.com>

Hi,

Next is a suggestion for the refactoring of Attr.visitSwitch() using a
visitor method for the case statement conforming to issue 8164327
description.

The labels' handling still belongs to visitSwitch() while the case
statements are handled by the new visitCase() method.

All javac tests have been run and nothing seems to be broken...

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
@@ -1320,14 +1320,7 @@
                 } else {
                     hasDefault = true;
                 }
-                Env<AttrContext> caseEnv =
-                    switchEnv.dup(c, env.info.dup(switchEnv.info.scope.dup()));
-                try {
-                    attribStats(c.stats, caseEnv);
-                } finally {
-                    caseEnv.info.scope.leave();
-                    addVars(c.stats, switchEnv.info.scope);
-                }
+                attribTree(c, switchEnv, statInfo);
             }

             result = null;
@@ -1336,6 +1329,18 @@
             switchEnv.info.scope.leave();
         }
     }
+
+    @Override
+    public void visitCase(JCCase tree) {
+        Env<AttrContext> caseEnv =
+                env.dup(tree, env.info.dup(env.info.scope.dup()));
+        try {
+            attribStats(tree.stats, caseEnv);
+        } finally {
+            caseEnv.info.scope.leave();
+            addVars(tree.stats, env.info.scope);
+        }
+    }
     // where
         /** Add any variables defined in stats to the switch scope. */
         private static void addVars(List<JCStatement> stats,
WriteableScope switchScope) {

From vicente.romero at oracle.com  Tue Oct  4 13:58:36 2016
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Tue, 4 Oct 2016 09:58:36 -0400
Subject: [PATCH] 8164327: Attr should implement method visitCase
In-Reply-To: <CAEgw74DTFQK79cbZtWj1QqDnsYVRaC3n7ba+wgrskZxMO6i2uQ@mail.gmail.com>
References: <CAEgw74DTFQK79cbZtWj1QqDnsYVRaC3n7ba+wgrskZxMO6i2uQ@mail.gmail.com>
Message-ID: <ec371950-12fb-2242-533a-cdd65e343d37@oracle.com>

Hi Bernard,

Thanks for the patch. The issue is assigned to me and I already provided 
a patch. It's not closed yet because we are waiting for other bigger 
refactoring in the area.

Thanks,
Vicente

On 10/04/2016 09:08 AM, bsrbnd wrote:
> Hi,
>
> Next is a suggestion for the refactoring of Attr.visitSwitch() using a
> visitor method for the case statement conforming to issue 8164327
> description.
>
> The labels' handling still belongs to visitSwitch() while the case
> statements are handled by the new visitCase() method.
>
> All javac tests have been run and nothing seems to be broken...
>
> 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
> @@ -1320,14 +1320,7 @@
>                   } else {
>                       hasDefault = true;
>                   }
> -                Env<AttrContext> caseEnv =
> -                    switchEnv.dup(c, env.info.dup(switchEnv.info.scope.dup()));
> -                try {
> -                    attribStats(c.stats, caseEnv);
> -                } finally {
> -                    caseEnv.info.scope.leave();
> -                    addVars(c.stats, switchEnv.info.scope);
> -                }
> +                attribTree(c, switchEnv, statInfo);
>               }
>
>               result = null;
> @@ -1336,6 +1329,18 @@
>               switchEnv.info.scope.leave();
>           }
>       }
> +
> +    @Override
> +    public void visitCase(JCCase tree) {
> +        Env<AttrContext> caseEnv =
> +                env.dup(tree, env.info.dup(env.info.scope.dup()));
> +        try {
> +            attribStats(tree.stats, caseEnv);
> +        } finally {
> +            caseEnv.info.scope.leave();
> +            addVars(tree.stats, env.info.scope);
> +        }
> +    }
>       // where
>           /** Add any variables defined in stats to the switch scope. */
>           private static void addVars(List<JCStatement> stats,
> WriteableScope switchScope) {



From stuart.marks at oracle.com  Tue Oct  4 18:12:01 2016
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 4 Oct 2016 11:12:01 -0700
Subject: RFR(s): 8161338 (jdeprscan) remove JEP 293 non-conforming -cp option
Message-ID: <a48bb758-2368-32d2-7ac5-226a8f466e4e@oracle.com>

Hi all,

Please review this small patch to remove the "-cp" option from jdeprscan. This 
is unfortunate, but it doesn't conform to the JEP 293 (GNU style) options 
conventions. The -cp option is retained for existing tools, but jdeprscan is 
new, and it should be fully conformant.

To specify a classpath, use the long form --class-path.

This change also clears out a couple bits of dead code.

Webrev:
	http://cr.openjdk.java.net/~smarks/reviews/8161338/webrev.0/

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

JEP 293:
	http://openjdk.java.net/jeps/293


Thanks,

s'marks

From jonathan.gibbons at oracle.com  Tue Oct  4 18:15:02 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 4 Oct 2016 11:15:02 -0700
Subject: RFR(s): 8161338 (jdeprscan) remove JEP 293 non-conforming -cp
	option
In-Reply-To: <a48bb758-2368-32d2-7ac5-226a8f466e4e@oracle.com>
References: <a48bb758-2368-32d2-7ac5-226a8f466e4e@oracle.com>
Message-ID: <18d9842d-cf9f-f388-ced4-4793a7197180@oracle.com>

Looks OK to me.

-- Jon


On 10/4/16 11:12 AM, Stuart Marks wrote:
> Hi all,
>
> Please review this small patch to remove the "-cp" option from 
> jdeprscan. This is unfortunate, but it doesn't conform to the JEP 293 
> (GNU style) options conventions. The -cp option is retained for 
> existing tools, but jdeprscan is new, and it should be fully conformant.
>
> To specify a classpath, use the long form --class-path.
>
> This change also clears out a couple bits of dead code.
>
> Webrev:
>     http://cr.openjdk.java.net/~smarks/reviews/8161338/webrev.0/
>
> Bug:
>     https://bugs.openjdk.java.net/browse/JDK-8161338
>
> JEP 293:
>     http://openjdk.java.net/jeps/293
>
>
> Thanks,
>
> s'marks


From jonathan.gibbons at oracle.com  Tue Oct  4 23:39:47 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 04 Oct 2016 16:39:47 -0700
Subject: RFR: 8159855
Message-ID: <57F43DC3.8040905@oracle.com>

Core-libs folk,

Please review the following change to add a new service provider class
     java.util.spi.ToolProvider

which can be used provide simple "command-line" access to select JDK
tools, without starting a new JVM.

The following tools are updated to provide access through the new SPI:
     javac, javadoc, javap, jdeps

It is expected that additional tools will also be updated to provide access,
but that will be done separately.

Compiler-dev folk may wish to review the changes to the langtools 
repository.

JBS: https://bugs.openjdk.java.net/browse/JDK-8159855
Webrev: http://cr.openjdk.java.net/~jjg/8159855/webrev.03/
API: 
http://cr.openjdk.java.net/~jjg/8159855/api.02/java/util/spi/ToolProvider.html

-- Jon

From jonathan.gibbons at oracle.com  Tue Oct  4 23:46:11 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 04 Oct 2016 16:46:11 -0700
Subject: RFR: 8159855: Create an SPI for tools
In-Reply-To: <57F43DC3.8040905@oracle.com>
References: <57F43DC3.8040905@oracle.com>
Message-ID: <57F43F43.3080707@oracle.com>

Resend with non-mostly-empty subject line!

-- Jon

On 10/04/2016 04:39 PM, Jonathan Gibbons wrote:
> Core-libs folk,
>
> Please review the following change to add a new service provider class
>     java.util.spi.ToolProvider
>
> which can be used provide simple "command-line" access to select JDK
> tools, without starting a new JVM.
>
> The following tools are updated to provide access through the new SPI:
>     javac, javadoc, javap, jdeps
>
> It is expected that additional tools will also be updated to provide 
> access,
> but that will be done separately.
>
> Compiler-dev folk may wish to review the changes to the langtools 
> repository.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8159855
> Webrev: http://cr.openjdk.java.net/~jjg/8159855/webrev.03/
> API: 
> http://cr.openjdk.java.net/~jjg/8159855/api.02/java/util/spi/ToolProvider.html
>
> -- Jon


From robert.field at oracle.com  Wed Oct  5 01:37:46 2016
From: robert.field at oracle.com (Robert Field)
Date: Tue, 04 Oct 2016 18:37:46 -0700
Subject: RFR: 8159855: Create an SPI for tools
In-Reply-To: <57F43F43.3080707@oracle.com>
References: <57F43DC3.8040905@oracle.com> <57F43F43.3080707@oracle.com>
Message-ID: <57F4596A.3030204@oracle.com>

I like the idea of this SPI.  And I'd like the jshell tool to launchable 
in this manner,

Unfortunately the shape of the SPI would not allow for this.  The 
current entry-point (which is in an internal package) is --

     /**
      * The constructor for the tool (used by tool launch via main and 
by test
      * harnesses to capture ins and outs.
      * @param cmdin command line input -- snippets and commands
      * @param cmdout command line output, feedback including errors
      * @param cmderr start-up errors and debugging info
      * @param console console control interaction
      * @param userin code execution input, or null to use IOContext
      * @param userout code execution output  -- System.out.printf("hi")
      * @param usererr code execution error stream  -- 
System.err.printf("Oops")
      * @param prefs preferences to use
      * @param locale locale to use
      */
     public JShellTool(InputStream cmdin, PrintStream cmdout, 
PrintStream cmderr,
             PrintStream console,
             InputStream userin, PrintStream userout, PrintStream usererr,
             Preferences prefs, Locale locale)

Some of these could defaulted, but not all.

Any ideas?

Thanks,
Robert



On 10/04/16 16:46, Jonathan Gibbons wrote:
> Resend with non-mostly-empty subject line!
>
> -- Jon
>
> On 10/04/2016 04:39 PM, Jonathan Gibbons wrote:
>> Core-libs folk,
>>
>> Please review the following change to add a new service provider class
>>     java.util.spi.ToolProvider
>>
>> which can be used provide simple "command-line" access to select JDK
>> tools, without starting a new JVM.
>>
>> The following tools are updated to provide access through the new SPI:
>>     javac, javadoc, javap, jdeps
>>
>> It is expected that additional tools will also be updated to provide 
>> access,
>> but that will be done separately.
>>
>> Compiler-dev folk may wish to review the changes to the langtools 
>> repository.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8159855
>> Webrev: http://cr.openjdk.java.net/~jjg/8159855/webrev.03/
>> API: 
>> http://cr.openjdk.java.net/~jjg/8159855/api.02/java/util/spi/ToolProvider.html
>>
>> -- Jon
>


From jonathan.gibbons at oracle.com  Wed Oct  5 03:24:12 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 4 Oct 2016 20:24:12 -0700
Subject: RFR: 8159855: Create an SPI for tools
In-Reply-To: <57F4596A.3030204@oracle.com>
References: <57F43DC3.8040905@oracle.com> <57F43F43.3080707@oracle.com>
	<57F4596A.3030204@oracle.com>
Message-ID: <d283f046-1f2b-b124-5c2b-483e325d01d5@oracle.com>

Hi Robert,

When you invoke jshell from the command line through the command line 
launcher, there must surely be a simpler entry point that is invoked.  
Command line entry points don't provide Java Preferences objects, for 
example. That being said, I agree that jshell does require an input 
stream, and that is not supported by this SPI.

If you want a richer API, why do you not export a public API for others 
to access and use?

-- Jon



On 10/4/16 6:37 PM, Robert Field wrote:
> I like the idea of this SPI.  And I'd like the jshell tool to 
> launchable in this manner,
>
> Unfortunately the shape of the SPI would not allow for this.  The 
> current entry-point (which is in an internal package) is --
>
>     /**
>      * The constructor for the tool (used by tool launch via main and 
> by test
>      * harnesses to capture ins and outs.
>      * @param cmdin command line input -- snippets and commands
>      * @param cmdout command line output, feedback including errors
>      * @param cmderr start-up errors and debugging info
>      * @param console console control interaction
>      * @param userin code execution input, or null to use IOContext
>      * @param userout code execution output  -- System.out.printf("hi")
>      * @param usererr code execution error stream  -- 
> System.err.printf("Oops")
>      * @param prefs preferences to use
>      * @param locale locale to use
>      */
>     public JShellTool(InputStream cmdin, PrintStream cmdout, 
> PrintStream cmderr,
>             PrintStream console,
>             InputStream userin, PrintStream userout, PrintStream usererr,
>             Preferences prefs, Locale locale)
>
> Some of these could defaulted, but not all.
>
> Any ideas?
>
> Thanks,
> Robert
>
>
>
> On 10/04/16 16:46, Jonathan Gibbons wrote:
>> Resend with non-mostly-empty subject line!
>>
>> -- Jon
>>
>> On 10/04/2016 04:39 PM, Jonathan Gibbons wrote:
>>> Core-libs folk,
>>>
>>> Please review the following change to add a new service provider class
>>>     java.util.spi.ToolProvider
>>>
>>> which can be used provide simple "command-line" access to select JDK
>>> tools, without starting a new JVM.
>>>
>>> The following tools are updated to provide access through the new SPI:
>>>     javac, javadoc, javap, jdeps
>>>
>>> It is expected that additional tools will also be updated to provide 
>>> access,
>>> but that will be done separately.
>>>
>>> Compiler-dev folk may wish to review the changes to the langtools 
>>> repository.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8159855
>>> Webrev: http://cr.openjdk.java.net/~jjg/8159855/webrev.03/
>>> API: 
>>> http://cr.openjdk.java.net/~jjg/8159855/api.02/java/util/spi/ToolProvider.html
>>>
>>> -- Jon
>>
>


From robert.field at oracle.com  Wed Oct  5 03:42:26 2016
From: robert.field at oracle.com (Robert Field)
Date: Tue, 04 Oct 2016 20:42:26 -0700
Subject: RFR: 8159855: Create an SPI for tools
In-Reply-To: <d283f046-1f2b-b124-5c2b-483e325d01d5@oracle.com>
References: <57F43DC3.8040905@oracle.com>
	<57F43F43.3080707@oracle.com>	<57F4596A.3030204@oracle.com>
	<d283f046-1f2b-b124-5c2b-483e325d01d5@oracle.com>
Message-ID: <57F476A2.9090203@oracle.com>


On 10/04/16 20:24, Jonathan Gibbons wrote:
> Hi Robert,
>
> When you invoke jshell from the command line through the command line 
> launcher, there must surely be a simpler entry point that is invoked.  
> Command line entry points don't provide Java Preferences objects, for 
> example. That being said, I agree that jshell does require an input 
> stream, and that is not supported by this SPI.

This is how main calls that entry-point --

     public static void main(String[] args) throws Exception {
         new JShellTool(System.in, System.out, System.err, System.out,
                  System.out, System.err,
                  Preferences.userRoot().node("tool/JShell"),
                  Locale.getDefault())
                 .start(args);
     }

The only additional parameter needed to match this form of use would be: 
InputStream in.

>
> If you want a richer API, why do you not export a public API for 
> others to access and use?

The tool is currently in: jdk.internal.jshell.tool

We don't want the tool to be an API.

We could change the package to not be internal and then have one class 
with one method -- but that seems overkill.

I'd much rather find a way that it could fit with what you are developing.

-Robert



>
> -- Jon
>
>
>
> On 10/4/16 6:37 PM, Robert Field wrote:
>> I like the idea of this SPI.  And I'd like the jshell tool to 
>> launchable in this manner,
>>
>> Unfortunately the shape of the SPI would not allow for this. The 
>> current entry-point (which is in an internal package) is --
>>
>>     /**
>>      * The constructor for the tool (used by tool launch via main and 
>> by test
>>      * harnesses to capture ins and outs.
>>      * @param cmdin command line input -- snippets and commands
>>      * @param cmdout command line output, feedback including errors
>>      * @param cmderr start-up errors and debugging info
>>      * @param console console control interaction
>>      * @param userin code execution input, or null to use IOContext
>>      * @param userout code execution output  -- System.out.printf("hi")
>>      * @param usererr code execution error stream  -- 
>> System.err.printf("Oops")
>>      * @param prefs preferences to use
>>      * @param locale locale to use
>>      */
>>     public JShellTool(InputStream cmdin, PrintStream cmdout, 
>> PrintStream cmderr,
>>             PrintStream console,
>>             InputStream userin, PrintStream userout, PrintStream 
>> usererr,
>>             Preferences prefs, Locale locale)
>>
>> Some of these could defaulted, but not all.
>>
>> Any ideas?
>>
>> Thanks,
>> Robert
>>
>>
>>
>> On 10/04/16 16:46, Jonathan Gibbons wrote:
>>> Resend with non-mostly-empty subject line!
>>>
>>> -- Jon
>>>
>>> On 10/04/2016 04:39 PM, Jonathan Gibbons wrote:
>>>> Core-libs folk,
>>>>
>>>> Please review the following change to add a new service provider class
>>>>     java.util.spi.ToolProvider
>>>>
>>>> which can be used provide simple "command-line" access to select JDK
>>>> tools, without starting a new JVM.
>>>>
>>>> The following tools are updated to provide access through the new SPI:
>>>>     javac, javadoc, javap, jdeps
>>>>
>>>> It is expected that additional tools will also be updated to 
>>>> provide access,
>>>> but that will be done separately.
>>>>
>>>> Compiler-dev folk may wish to review the changes to the langtools 
>>>> repository.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8159855
>>>> Webrev: http://cr.openjdk.java.net/~jjg/8159855/webrev.03/
>>>> API: 
>>>> http://cr.openjdk.java.net/~jjg/8159855/api.02/java/util/spi/ToolProvider.html
>>>>
>>>> -- Jon
>>>
>>
>


From jonathan.gibbons at oracle.com  Wed Oct  5 04:06:01 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 4 Oct 2016 21:06:01 -0700
Subject: RFR: 8159855: Create an SPI for tools
In-Reply-To: <57F476A2.9090203@oracle.com>
References: <57F43DC3.8040905@oracle.com> <57F43F43.3080707@oracle.com>
	<57F4596A.3030204@oracle.com>
	<d283f046-1f2b-b124-5c2b-483e325d01d5@oracle.com>
	<57F476A2.9090203@oracle.com>
Message-ID: <15e1e5e9-55a3-24b2-96be-0ee71966a934@oracle.com>

I don't understand: on the one hand you say you don't want the tool to 
be an API, but then you say you want to fit in with the proposed new 
ToolProvider SPI.

If you want to expose some tool-like API, you clearly can do so, and it 
can take whatever stream and other parameters you want to expose.  But 
doesn't JShell already expose a richer API that clients can use? Can you 
not provide an easy entry point in that package?

-- Jon


On 10/4/16 8:42 PM, Robert Field wrote:
>
> On 10/04/16 20:24, Jonathan Gibbons wrote:
>> Hi Robert,
>>
>> When you invoke jshell from the command line through the command line 
>> launcher, there must surely be a simpler entry point that is 
>> invoked.  Command line entry points don't provide Java Preferences 
>> objects, for example. That being said, I agree that jshell does 
>> require an input stream, and that is not supported by this SPI.
>
> This is how main calls that entry-point --
>
>     public static void main(String[] args) throws Exception {
>         new JShellTool(System.in, System.out, System.err, System.out,
>                  System.out, System.err,
>                  Preferences.userRoot().node("tool/JShell"),
>                  Locale.getDefault())
>                 .start(args);
>     }
>
> The only additional parameter needed to match this form of use would 
> be: InputStream in.
>
>>
>> If you want a richer API, why do you not export a public API for 
>> others to access and use?
>
> The tool is currently in: jdk.internal.jshell.tool
>
> We don't want the tool to be an API.
>
> We could change the package to not be internal and then have one class 
> with one method -- but that seems overkill.
>
> I'd much rather find a way that it could fit with what you are 
> developing.
>
> -Robert
>
>
>
>>
>> -- Jon
>>
>>
>>
>> On 10/4/16 6:37 PM, Robert Field wrote:
>>> I like the idea of this SPI.  And I'd like the jshell tool to 
>>> launchable in this manner,
>>>
>>> Unfortunately the shape of the SPI would not allow for this. The 
>>> current entry-point (which is in an internal package) is --
>>>
>>>     /**
>>>      * The constructor for the tool (used by tool launch via main 
>>> and by test
>>>      * harnesses to capture ins and outs.
>>>      * @param cmdin command line input -- snippets and commands
>>>      * @param cmdout command line output, feedback including errors
>>>      * @param cmderr start-up errors and debugging info
>>>      * @param console console control interaction
>>>      * @param userin code execution input, or null to use IOContext
>>>      * @param userout code execution output  -- System.out.printf("hi")
>>>      * @param usererr code execution error stream  -- 
>>> System.err.printf("Oops")
>>>      * @param prefs preferences to use
>>>      * @param locale locale to use
>>>      */
>>>     public JShellTool(InputStream cmdin, PrintStream cmdout, 
>>> PrintStream cmderr,
>>>             PrintStream console,
>>>             InputStream userin, PrintStream userout, PrintStream 
>>> usererr,
>>>             Preferences prefs, Locale locale)
>>>
>>> Some of these could defaulted, but not all.
>>>
>>> Any ideas?
>>>
>>> Thanks,
>>> Robert
>>>
>>>
>>>
>>> On 10/04/16 16:46, Jonathan Gibbons wrote:
>>>> Resend with non-mostly-empty subject line!
>>>>
>>>> -- Jon
>>>>
>>>> On 10/04/2016 04:39 PM, Jonathan Gibbons wrote:
>>>>> Core-libs folk,
>>>>>
>>>>> Please review the following change to add a new service provider 
>>>>> class
>>>>>     java.util.spi.ToolProvider
>>>>>
>>>>> which can be used provide simple "command-line" access to select JDK
>>>>> tools, without starting a new JVM.
>>>>>
>>>>> The following tools are updated to provide access through the new 
>>>>> SPI:
>>>>>     javac, javadoc, javap, jdeps
>>>>>
>>>>> It is expected that additional tools will also be updated to 
>>>>> provide access,
>>>>> but that will be done separately.
>>>>>
>>>>> Compiler-dev folk may wish to review the changes to the langtools 
>>>>> repository.
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8159855
>>>>> Webrev: http://cr.openjdk.java.net/~jjg/8159855/webrev.03/
>>>>> API: 
>>>>> http://cr.openjdk.java.net/~jjg/8159855/api.02/java/util/spi/ToolProvider.html
>>>>>
>>>>> -- Jon
>>>>
>>>
>>
>


From robert.field at oracle.com  Wed Oct  5 04:14:21 2016
From: robert.field at oracle.com (Robert Field)
Date: Tue, 04 Oct 2016 21:14:21 -0700
Subject: RFR: 8159855: Create an SPI for tools
In-Reply-To: <15e1e5e9-55a3-24b2-96be-0ee71966a934@oracle.com>
References: <57F43DC3.8040905@oracle.com>
	<57F43F43.3080707@oracle.com>	<57F4596A.3030204@oracle.com>	<d283f046-1f2b-b124-5c2b-483e325d01d5@oracle.com>	<57F476A2.9090203@oracle.com>
	<15e1e5e9-55a3-24b2-96be-0ee71966a934@oracle.com>
Message-ID: <57F47E1D.70802@oracle.com>


On 10/04/16 21:06, Jonathan Gibbons wrote:
> I don't understand: on the one hand you say you don't want the tool to 
> be an API, but then you say you want to fit in with the proposed new 
> ToolProvider SPI.

Sorry, I was unclear.  We don't want to turn the code of the tool into a 
tool component API.  There is an API the tool is built on, we want that 
as the only API.

I do want access somewhere to launch the existing tool.

>
> If you want to expose some tool-like API, you clearly can do so, and 
> it can take whatever stream and other parameters you want to expose.  
> But doesn't JShell already expose a richer API that clients can use? 
> Can you not provide an easy entry point in that package?

In theory, we could put it there -- but they are very very different 
unrelated levels -- I'd certainly rather not mix them up.

-Robert

>
> -- Jon
>
>
> On 10/4/16 8:42 PM, Robert Field wrote:
>>
>> On 10/04/16 20:24, Jonathan Gibbons wrote:
>>> Hi Robert,
>>>
>>> When you invoke jshell from the command line through the command 
>>> line launcher, there must surely be a simpler entry point that is 
>>> invoked.  Command line entry points don't provide Java Preferences 
>>> objects, for example. That being said, I agree that jshell does 
>>> require an input stream, and that is not supported by this SPI.
>>
>> This is how main calls that entry-point --
>>
>>     public static void main(String[] args) throws Exception {
>>         new JShellTool(System.in, System.out, System.err, System.out,
>>                  System.out, System.err,
>>                  Preferences.userRoot().node("tool/JShell"),
>>                  Locale.getDefault())
>>                 .start(args);
>>     }
>>
>> The only additional parameter needed to match this form of use would 
>> be: InputStream in.
>>
>>>
>>> If you want a richer API, why do you not export a public API for 
>>> others to access and use?
>>
>> The tool is currently in: jdk.internal.jshell.tool
>>
>> We don't want the tool to be an API.
>>
>> We could change the package to not be internal and then have one 
>> class with one method -- but that seems overkill.
>>
>> I'd much rather find a way that it could fit with what you are 
>> developing.
>>
>> -Robert
>>
>>
>>
>>>
>>> -- Jon
>>>
>>>
>>>
>>> On 10/4/16 6:37 PM, Robert Field wrote:
>>>> I like the idea of this SPI.  And I'd like the jshell tool to 
>>>> launchable in this manner,
>>>>
>>>> Unfortunately the shape of the SPI would not allow for this. The 
>>>> current entry-point (which is in an internal package) is --
>>>>
>>>>     /**
>>>>      * The constructor for the tool (used by tool launch via main 
>>>> and by test
>>>>      * harnesses to capture ins and outs.
>>>>      * @param cmdin command line input -- snippets and commands
>>>>      * @param cmdout command line output, feedback including errors
>>>>      * @param cmderr start-up errors and debugging info
>>>>      * @param console console control interaction
>>>>      * @param userin code execution input, or null to use IOContext
>>>>      * @param userout code execution output  -- 
>>>> System.out.printf("hi")
>>>>      * @param usererr code execution error stream  -- 
>>>> System.err.printf("Oops")
>>>>      * @param prefs preferences to use
>>>>      * @param locale locale to use
>>>>      */
>>>>     public JShellTool(InputStream cmdin, PrintStream cmdout, 
>>>> PrintStream cmderr,
>>>>             PrintStream console,
>>>>             InputStream userin, PrintStream userout, PrintStream 
>>>> usererr,
>>>>             Preferences prefs, Locale locale)
>>>>
>>>> Some of these could defaulted, but not all.
>>>>
>>>> Any ideas?
>>>>
>>>> Thanks,
>>>> Robert
>>>>
>>>>
>>>>
>>>> On 10/04/16 16:46, Jonathan Gibbons wrote:
>>>>> Resend with non-mostly-empty subject line!
>>>>>
>>>>> -- Jon
>>>>>
>>>>> On 10/04/2016 04:39 PM, Jonathan Gibbons wrote:
>>>>>> Core-libs folk,
>>>>>>
>>>>>> Please review the following change to add a new service provider 
>>>>>> class
>>>>>>     java.util.spi.ToolProvider
>>>>>>
>>>>>> which can be used provide simple "command-line" access to select JDK
>>>>>> tools, without starting a new JVM.
>>>>>>
>>>>>> The following tools are updated to provide access through the new 
>>>>>> SPI:
>>>>>>     javac, javadoc, javap, jdeps
>>>>>>
>>>>>> It is expected that additional tools will also be updated to 
>>>>>> provide access,
>>>>>> but that will be done separately.
>>>>>>
>>>>>> Compiler-dev folk may wish to review the changes to the langtools 
>>>>>> repository.
>>>>>>
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8159855
>>>>>> Webrev: http://cr.openjdk.java.net/~jjg/8159855/webrev.03/
>>>>>> API: 
>>>>>> http://cr.openjdk.java.net/~jjg/8159855/api.02/java/util/spi/ToolProvider.html
>>>>>>
>>>>>> -- Jon
>>>>>
>>>>
>>>
>>
>


From mandy.chung at oracle.com  Wed Oct  5 04:19:48 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 4 Oct 2016 21:19:48 -0700
Subject: RFR: 8159855: Create an SPI for tools
In-Reply-To: <57F43F43.3080707@oracle.com>
References: <57F43DC3.8040905@oracle.com> <57F43F43.3080707@oracle.com>
Message-ID: <9C464F0F-5295-45E4-972D-2511EC937534@oracle.com>

This SPI is useful and provides as a replacement to existing use of internal APIs to launch some of our tools.  We will get jar, jmod, jlink and possibly other tools to convert to this SPI.

ToolProvider::findFirst(String name) can find tool providers on classpath.  I think it needs to wrap the for-loop (specifically iterating on providers) with doPrivileged due to the stack-based permission check.

Otherwise, looks good.

Mandy

> On Oct 4, 2016, at 4:46 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Resend with non-mostly-empty subject line!
> 
> -- Jon
> 
> On 10/04/2016 04:39 PM, Jonathan Gibbons wrote:
>> Core-libs folk,
>> 
>> Please review the following change to add a new service provider class
>>    java.util.spi.ToolProvider
>> 
>> which can be used provide simple "command-line" access to select JDK
>> tools, without starting a new JVM.
>> 
>> The following tools are updated to provide access through the new SPI:
>>    javac, javadoc, javap, jdeps
>> 
>> It is expected that additional tools will also be updated to provide access,
>> but that will be done separately.
>> 
>> Compiler-dev folk may wish to review the changes to the langtools repository.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8159855
>> Webrev: http://cr.openjdk.java.net/~jjg/8159855/webrev.03/
>> API: http://cr.openjdk.java.net/~jjg/8159855/api.02/java/util/spi/ToolProvider.html
>> 
>> -- Jon
> 


From mandy.chung at oracle.com  Wed Oct  5 04:19:48 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 4 Oct 2016 21:19:48 -0700
Subject: RFR: 8159855: Create an SPI for tools
In-Reply-To: <57F43F43.3080707@oracle.com>
References: <57F43DC3.8040905@oracle.com> <57F43F43.3080707@oracle.com>
Message-ID: <250C708F-AF40-45C0-A075-5BBDFA41F0A9@oracle.com>

This SPI is useful and provides as a replacement to existing use of internal APIs to launch some of our tools.  We will get jar, jmod, jlink and possibly other tools to convert to this SPI.

ToolProvider::findFirst(String name) can find tool providers on classpath.  I think it needs to wrap the for-loop (specifically iterating on providers) with doPrivileged due to the stack-based permission check.

Otherwise, looks good.

Mandy

> On Oct 4, 2016, at 4:46 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Resend with non-mostly-empty subject line!
> 
> -- Jon
> 
> On 10/04/2016 04:39 PM, Jonathan Gibbons wrote:
>> Core-libs folk,
>> 
>> Please review the following change to add a new service provider class
>>    java.util.spi.ToolProvider
>> 
>> which can be used provide simple "command-line" access to select JDK
>> tools, without starting a new JVM.
>> 
>> The following tools are updated to provide access through the new SPI:
>>    javac, javadoc, javap, jdeps
>> 
>> It is expected that additional tools will also be updated to provide access,
>> but that will be done separately.
>> 
>> Compiler-dev folk may wish to review the changes to the langtools repository.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8159855
>> Webrev: http://cr.openjdk.java.net/~jjg/8159855/webrev.03/
>> API: http://cr.openjdk.java.net/~jjg/8159855/api.02/java/util/spi/ToolProvider.html
>> 
>> -- Jon
> 


From Alan.Bateman at oracle.com  Wed Oct  5 10:34:17 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 5 Oct 2016 11:34:17 +0100
Subject: RFR: 8159855: Create an SPI for tools
In-Reply-To: <CACzrW9Ak7fxKrWYH_5HivN7LNDi-EtzoGHRG4ayyhUcz64WBJA@mail.gmail.com>
References: <57F43DC3.8040905@oracle.com>
	<CACzrW9Ak7fxKrWYH_5HivN7LNDi-EtzoGHRG4ayyhUcz64WBJA@mail.gmail.com>
Message-ID: <54f7ed03-11b5-72fe-45bc-f6e7019014a5@oracle.com>

On 05/10/2016 10:54, Stephen Colebourne wrote:

> Interesting.
>
> How likely is it that there will be more than one tool of a given name
> available? The method name findFirst() seems relatively odd for the
> lookup operation.
>
> I'd also note that the name string to pass in are "magic". There are
> no constants defined for callers to use. Since there is no obvious way
> in the API to find the vendor, this could get tricky across JDKs. Plus
> how would a caller know what arguments to pass if each vendors tool
> differs?
>
> Just being cautious about the use case being solved.
Many command line tools don't define an API and so not unheard of to 
find code that uses sun.tools.jar.Main.main or the main method of other 
tools. Also common to see code using ProcessBuilder or Runtime.exec to 
launch tools like jar. If the commonly used tools (jar, jdeps, ...) 
document their tool names in their module description then it will make 
it easier to run these tools in the same VM. It does mean that some 
tools will have both an API and a documented tool name but that 
shouldn't be an issue. I'm sure Jon has a lot to say on this topic, esp. 
with linking usage documentation and man pages.

As regards constants then not clear where something like this would live 
as it amounts to a registry. Also many of the tools are JDK or library 
specific and so wouldn't have a place in the standard/Java SE docs.

The firstFirst(String) method limits itself to tools that are visible 
via the system class loader. Sure, someone might decide to deploy lots 
of libraries that all claim to be the "hammer" tool but this is no 
different to many of the service providers mechanisms. One could have 
the ToolProvider define methods with the tool capabilities that would 
aid selection but that would complicate the API.

-Alan

From forax at univ-mlv.fr  Wed Oct  5 11:10:13 2016
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 5 Oct 2016 13:10:13 +0200 (CEST)
Subject: RFR: 8159855
In-Reply-To: <57F43DC3.8040905@oracle.com>
References: <57F43DC3.8040905@oracle.com>
Message-ID: <489906237.1277782.1475665813824.JavaMail.zimbra@u-pem.fr>

Very nice,
it will greatly help gradle, maven, etc.

in com/sun/tools/javac/main/Main.java,
the other constructor should delegate its initialization to the constructor you just add,
     public Main(String name, PrintWriter out) {
         this(name, out, out);
     }

I wonder if findFirst() in ToolProvider should not take a ClassLoader as parameter instead of being restricted to the system classloader.

regards,
R?mi

----- Mail original -----
> De: "Jonathan Gibbons" <jonathan.gibbons at oracle.com>
> ?: "OpenJDK Dev list" <core-libs-dev at openjdk.java.net>
> Cc: compiler-dev at openjdk.java.net
> Envoy?: Mercredi 5 Octobre 2016 01:39:47
> Objet: RFR: 8159855

> Core-libs folk,
> 
> Please review the following change to add a new service provider class
>     java.util.spi.ToolProvider
> 
> which can be used provide simple "command-line" access to select JDK
> tools, without starting a new JVM.
> 
> The following tools are updated to provide access through the new SPI:
>     javac, javadoc, javap, jdeps
> 
> It is expected that additional tools will also be updated to provide access,
> but that will be done separately.
> 
> Compiler-dev folk may wish to review the changes to the langtools
> repository.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8159855
> Webrev: http://cr.openjdk.java.net/~jjg/8159855/webrev.03/
> API:
> http://cr.openjdk.java.net/~jjg/8159855/api.02/java/util/spi/ToolProvider.html
> 
> -- Jon

From Alan.Bateman at oracle.com  Wed Oct  5 11:39:02 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 5 Oct 2016 12:39:02 +0100
Subject: RFR: 8159855
In-Reply-To: <489906237.1277782.1475665813824.JavaMail.zimbra@u-pem.fr>
References: <57F43DC3.8040905@oracle.com>
	<489906237.1277782.1475665813824.JavaMail.zimbra@u-pem.fr>
Message-ID: <b2dcf1fa-a8d1-838a-3afe-ac8039e4acf2@oracle.com>



On 05/10/2016 12:10, Remi Forax wrote:
> Very nice,
> it will greatly help gradle, maven, etc.
>
> in com/sun/tools/javac/main/Main.java,
> the other constructor should delegate its initialization to the constructor you just add,
>       public Main(String name, PrintWriter out) {
>           this(name, out, out);
>       }
>
> I wonder if findFirst() in ToolProvider should not take a ClassLoader as parameter instead of being restricted to the system classloader.
>
The findFirst(tool) method just a convenience, the intention is that if 
you want to use other contexts then you just invoke ServiceLoader to 
locate it.

-Alan.

From forax at univ-mlv.fr  Wed Oct  5 12:20:09 2016
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 5 Oct 2016 14:20:09 +0200 (CEST)
Subject: RFR: 8159855
In-Reply-To: <b2dcf1fa-a8d1-838a-3afe-ac8039e4acf2@oracle.com>
References: <57F43DC3.8040905@oracle.com>
	<489906237.1277782.1475665813824.JavaMail.zimbra@u-pem.fr>
	<b2dcf1fa-a8d1-838a-3afe-ac8039e4acf2@oracle.com>
Message-ID: <1167030149.1309621.1475670009250.JavaMail.zimbra@u-pem.fr>

It seems to be a little to JDK centric to me.

R?mi

----- Mail original -----
> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>, "Jonathan Gibbons" <jonathan.gibbons at oracle.com>
> Cc: compiler-dev at openjdk.java.net, "OpenJDK Dev list" <core-libs-dev at openjdk.java.net>
> Envoy?: Mercredi 5 Octobre 2016 13:39:02
> Objet: Re: RFR: 8159855

> On 05/10/2016 12:10, Remi Forax wrote:
>> Very nice,
>> it will greatly help gradle, maven, etc.
>>
>> in com/sun/tools/javac/main/Main.java,
>> the other constructor should delegate its initialization to the constructor you
>> just add,
>>       public Main(String name, PrintWriter out) {
>>           this(name, out, out);
>>       }
>>
>> I wonder if findFirst() in ToolProvider should not take a ClassLoader as
>> parameter instead of being restricted to the system classloader.
>>
> The findFirst(tool) method just a convenience, the intention is that if
> you want to use other contexts then you just invoke ServiceLoader to
> locate it.
> 
> -Alan.

From Alan.Bateman at oracle.com  Wed Oct  5 14:10:50 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 5 Oct 2016 15:10:50 +0100
Subject: RFR: 8159855
In-Reply-To: <1167030149.1309621.1475670009250.JavaMail.zimbra@u-pem.fr>
References: <57F43DC3.8040905@oracle.com>
	<489906237.1277782.1475665813824.JavaMail.zimbra@u-pem.fr>
	<b2dcf1fa-a8d1-838a-3afe-ac8039e4acf2@oracle.com>
	<1167030149.1309621.1475670009250.JavaMail.zimbra@u-pem.fr>
Message-ID: <e423c6e5-a50e-e0d4-27b6-71b73627c8b5@oracle.com>

On 05/10/2016 13:20, forax at univ-mlv.fr wrote:

> It seems to be a little to JDK centric to me.
>
It supports the common case, making the advanced cases possible. Also 
it's consistent with the javax.tools API. So overall then I think Jon 
has this right.

-Alan

From Alan.Bateman at oracle.com  Wed Oct  5 14:34:26 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 5 Oct 2016 15:34:26 +0100
Subject: RFR: 8159855: Create an SPI for tools
In-Reply-To: <9C464F0F-5295-45E4-972D-2511EC937534@oracle.com>
References: <57F43DC3.8040905@oracle.com> <57F43F43.3080707@oracle.com>
	<9C464F0F-5295-45E4-972D-2511EC937534@oracle.com>
Message-ID: <a4fbba01-ef17-3a2a-33a4-deb964855f0f@oracle.com>

On 05/10/2016 05:19, Mandy Chung wrote:

> :
>
> ToolProvider::findFirst(String name) can find tool providers on classpath.  I think it needs to wrap the for-loop (specifically iterating on providers) with doPrivileged due to the stack-based permission check.
>
Yes, that will be needed, otherwise the caller will need permission to 
get the system class loader and whatever other permissions are needed to 
locate and and load the tools.

The rest looks okay to me. Personally I would space out the javadoc tags 
more, and indent the second/third lines more than one space but that is 
just minor stuff.

-Alan

From jonathan.gibbons at oracle.com  Wed Oct  5 15:19:51 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 5 Oct 2016 08:19:51 -0700
Subject: RFR: 8159855: Create an SPI for tools
In-Reply-To: <54f7ed03-11b5-72fe-45bc-f6e7019014a5@oracle.com>
References: <57F43DC3.8040905@oracle.com>
	<CACzrW9Ak7fxKrWYH_5HivN7LNDi-EtzoGHRG4ayyhUcz64WBJA@mail.gmail.com>
	<54f7ed03-11b5-72fe-45bc-f6e7019014a5@oracle.com>
Message-ID: <8de4a83d-18e3-1cd4-ee7b-a54c413ce3a7@oracle.com>

On 10/5/16 3:34 AM, Alan Bateman wrote:
> On 05/10/2016 10:54, Stephen Colebourne wrote:
>
>> Interesting.
>>
>> How likely is it that there will be more than one tool of a given name
>> available? The method name findFirst() seems relatively odd for the
>> lookup operation.
>>
>> I'd also note that the name string to pass in are "magic". There are
>> no constants defined for callers to use. Since there is no obvious way
>> in the API to find the vendor, this could get tricky across JDKs. Plus
>> how would a caller know what arguments to pass if each vendors tool
>> differs?
>>
>> Just being cautious about the use case being solved.
> Many command line tools don't define an API and so not unheard of to 
> find code that uses sun.tools.jar.Main.main or the main method of 
> other tools. Also common to see code using ProcessBuilder or 
> Runtime.exec to launch tools like jar. If the commonly used tools 
> (jar, jdeps, ...) document their tool names in their module 
> description then it will make it easier to run these tools in the same 
> VM. It does mean that some tools will have both an API and a 
> documented tool name but that shouldn't be an issue. I'm sure Jon has 
> a lot to say on this topic, esp. with linking usage documentation and 
> man pages.
>
> As regards constants then not clear where something like this would 
> live as it amounts to a registry. Also many of the tools are JDK or 
> library specific and so wouldn't have a place in the standard/Java SE 
> docs.
>
> The firstFirst(String) method limits itself to tools that are visible 
> via the system class loader. Sure, someone might decide to deploy lots 
> of libraries that all claim to be the "hammer" tool but this is no 
> different to many of the service providers mechanisms. One could have 
> the ToolProvider define methods with the tool capabilities that would 
> aid selection but that would complicate the API.
>
> -Alan

Informally, I think the common use case for this API is to get "same VM" 
access to tools in the bin/ directory of the product image. That implies 
there is an obvious name for each tool, and that there will be 
documentation for the arguments that each tool that is available.

Also, in general, the doc comments for a module should contain details 
of any services for general use, including details of how to access the 
service (e.g. what name to use, in this case) and how to use it (info 
about arguments, etc, in this case.)  We are working on updating the 
javadoc tool to better support the provision of such information.

-- Jon

From christian.beikov at gmail.com  Thu Oct  6 15:08:42 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 6 Oct 2016 17:08:42 +0200
Subject: Fwd: Re: Compilation error with JDK9-ea+138
In-Reply-To: <57F53819.6050605@oracle.com>
References: <57F53819.6050605@oracle.com>
Message-ID: <396253d0-74a8-b044-cfba-af302e050bc7@gmail.com>

I have been directed to this mailing list for this error.

Is this a known issue?



-------- Weitergeleitete Nachricht --------
Betreff: 	Re: Compilation error with JDK9-ea+138
Datum: 	Wed, 05 Oct 2016 10:27:53 -0700
Von: 	Alex Buckley <alex.buckley at oracle.com>
Organisation: 	Oracle Corporation
An: 	jigsaw-dev at openjdk.java.net



This isn't a Jigsaw issue, please mail compiler-dev instead, being sure
to note which JDK 9 build you are compiling with.

On 10/5/2016 12:55 AM, Christian Beikov wrote:
> The following used to compile just fine on JDKs < 9
>
>      @Override
>      public <C, R> SimpleCase<C, R> selectCase(Expression<? extends C>
> expression) {
>          return selectCase((Class<R>) null, expression);
>      }
>
>      public <C, R> SimpleCase<C, R> selectCase(Class<R> type,
> Expression<? extends C> expression) {
>          return new SimpleCaseExpression<C, R>(this, type, expression);
>      }
>
> but now fails with:
>      error: incompatible types: SimpleCase<CAP#1,R> cannot be converted
> to SimpleCase<C,R>
>
> The error is in the first selectCase method.
>
> Is that a bug in the compiler?
>
> Regards,
> Christian

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

From jonathan.gibbons at oracle.com  Thu Oct  6 15:17:57 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 6 Oct 2016 08:17:57 -0700
Subject: Fwd: Re: Compilation error with JDK9-ea+138
In-Reply-To: <396253d0-74a8-b044-cfba-af302e050bc7@gmail.com>
References: <57F53819.6050605@oracle.com>
	<396253d0-74a8-b044-cfba-af302e050bc7@gmail.com>
Message-ID: <745740e0-d9c1-5431-b220-98ec62c6a161@oracle.com>

Christian,

As a general rule, it is better if you can post complete but reduced 
test cases, and post all the messages from the compiler. It is often 
hard to properly diagnose cases where someone posts some fragment of 
code and asks what's wrong.

-- Jon


On 10/6/16 8:08 AM, Christian Beikov wrote:
>
> I have been directed to this mailing list for this error.
>
> Is this a known issue?
>
>
>
> -------- Weitergeleitete Nachricht --------
> Betreff: 	Re: Compilation error with JDK9-ea+138
> Datum: 	Wed, 05 Oct 2016 10:27:53 -0700
> Von: 	Alex Buckley <alex.buckley at oracle.com>
> Organisation: 	Oracle Corporation
> An: 	jigsaw-dev at openjdk.java.net
>
>
>
> This isn't a Jigsaw issue, please mail compiler-dev instead, being sure
> to note which JDK 9 build you are compiling with.
>
> On 10/5/2016 12:55 AM, Christian Beikov wrote:
> > The following used to compile just fine on JDKs < 9
> >
> >      @Override
> >      public <C, R> SimpleCase<C, R> selectCase(Expression<? extends C>
> > expression) {
> >          return selectCase((Class<R>) null, expression);
> >      }
> >
> >      public <C, R> SimpleCase<C, R> selectCase(Class<R> type,
> > Expression<? extends C> expression) {
> >          return new SimpleCaseExpression<C, R>(this, type, expression);
> >      }
> >
> > but now fails with:
> >      error: incompatible types: SimpleCase<CAP#1,R> cannot be converted
> > to SimpleCase<C,R>
> >
> > The error is in the first selectCase method.
> >
> > Is that a bug in the compiler?
> >
> > Regards,
> > Christian

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

From maurizio.cimadamore at oracle.com  Thu Oct  6 15:30:16 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 6 Oct 2016 16:30:16 +0100
Subject: Fwd: Re: Compilation error with JDK9-ea+138
In-Reply-To: <745740e0-d9c1-5431-b220-98ec62c6a161@oracle.com>
References: <57F53819.6050605@oracle.com>
	<396253d0-74a8-b044-cfba-af302e050bc7@gmail.com>
	<745740e0-d9c1-5431-b220-98ec62c6a161@oracle.com>
Message-ID: <19c74e5c-8bb4-c6e5-1b73-d5a7f60ce37d@oracle.com>

What Jon says. I;ve tried to give this a try using this example:

class Test {

interface Expression<T> { }

interface SimpleCase<A, B> { }

<C, R> SimpleCase<C, R> selectCase(Expression<? extends C> expression) {
           return selectCase((Class<R>) null, expression);
}

<C, R> SimpleCase<C, R> selectCase(Class<R> type, Expression<? extends 
C> expression) {
           return null;
       }
}


But this passes with latest compiler. So I'm probably missing something 
(i.e. some bounds in the type-variable decl for Expression or SimpleCase?)

Maurizio


On 06/10/16 16:17, Jonathan Gibbons wrote:
>
> Christian,
>
> As a general rule, it is better if you can post complete but reduced 
> test cases, and post all the messages from the compiler. It is often 
> hard to properly diagnose cases where someone posts some fragment of 
> code and asks what's wrong.
>
> -- Jon
>
>
> On 10/6/16 8:08 AM, Christian Beikov wrote:
>>
>> I have been directed to this mailing list for this error.
>>
>> Is this a known issue?
>>
>>
>>
>> -------- Weitergeleitete Nachricht --------
>> Betreff: 	Re: Compilation error with JDK9-ea+138
>> Datum: 	Wed, 05 Oct 2016 10:27:53 -0700
>> Von: 	Alex Buckley <alex.buckley at oracle.com>
>> Organisation: 	Oracle Corporation
>> An: 	jigsaw-dev at openjdk.java.net
>>
>>
>>
>> This isn't a Jigsaw issue, please mail compiler-dev instead, being sure
>> to note which JDK 9 build you are compiling with.
>>
>> On 10/5/2016 12:55 AM, Christian Beikov wrote:
>> > The following used to compile just fine on JDKs < 9
>> >
>> >      @Override
>> >      public <C, R> SimpleCase<C, R> selectCase(Expression<? extends C>
>> > expression) {
>> >          return selectCase((Class<R>) null, expression);
>> >      }
>> >
>> >      public <C, R> SimpleCase<C, R> selectCase(Class<R> type,
>> > Expression<? extends C> expression) {
>> >          return new SimpleCaseExpression<C, R>(this, type, expression);
>> >      }
>> >
>> > but now fails with:
>> >      error: incompatible types: SimpleCase<CAP#1,R> cannot be converted
>> > to SimpleCase<C,R>
>> >
>> > The error is in the first selectCase method.
>> >
>> > Is that a bug in the compiler?
>> >
>> > Regards,
>> > Christian
>

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

From christian.beikov at gmail.com  Thu Oct  6 15:53:48 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 6 Oct 2016 17:53:48 +0200
Subject: Fwd: Re: Compilation error with JDK9-ea+138
In-Reply-To: <19c74e5c-8bb4-c6e5-1b73-d5a7f60ce37d@oracle.com>
References: <57F53819.6050605@oracle.com>
	<396253d0-74a8-b044-cfba-af302e050bc7@gmail.com>
	<745740e0-d9c1-5431-b220-98ec62c6a161@oracle.com>
	<19c74e5c-8bb4-c6e5-1b73-d5a7f60ce37d@oracle.com>
Message-ID: <9c8d658c-36f6-a9a3-62cb-77ef18176def@gmail.com>

I am having trouble to create a small example that shows the problem too.
Since the project is open source you can try that yourselves on that 
project.

URL: https://github.com/Blazebit/blaze-persistence.git

export MAVEN_OPTS="--add-modules=java.se.ee"
mvn -pl jpa-criteria/impl -am clean compile

Then you will get the error message:
BlazeCriteriaBuilderImpl.java:[997,48] error: incompatible types: 
SimpleCase<CAP#1,R> cannot be converted to SimpleCase<C,R>

Regards,
Christian

Am 06.10.2016 um 17:30 schrieb Maurizio Cimadamore:
>
> What Jon says. I;ve tried to give this a try using this example:
>
> class Test {
>
> interface Expression<T> { }
>
> interface SimpleCase<A, B> { }
>
> <C, R> SimpleCase<C, R> selectCase(Expression<? extends C> expression) {
>           return selectCase((Class<R>) null, expression);
> }
>
> <C, R> SimpleCase<C, R> selectCase(Class<R> type, Expression<? extends 
> C> expression) {
>           return null;
>       }
> }
>
>
> But this passes with latest compiler. So I'm probably missing 
> something (i.e. some bounds in the type-variable decl for Expression 
> or SimpleCase?)
>
> Maurizio
>
>
> On 06/10/16 16:17, Jonathan Gibbons wrote:
>>
>> Christian,
>>
>> As a general rule, it is better if you can post complete but reduced 
>> test cases, and post all the messages from the compiler. It is often 
>> hard to properly diagnose cases where someone posts some fragment of 
>> code and asks what's wrong.
>>
>> -- Jon
>>
>>
>> On 10/6/16 8:08 AM, Christian Beikov wrote:
>>>
>>> I have been directed to this mailing list for this error.
>>>
>>> Is this a known issue?
>>>
>>>
>>>
>>> -------- Weitergeleitete Nachricht --------
>>> Betreff: 	Re: Compilation error with JDK9-ea+138
>>> Datum: 	Wed, 05 Oct 2016 10:27:53 -0700
>>> Von: 	Alex Buckley <alex.buckley at oracle.com>
>>> Organisation: 	Oracle Corporation
>>> An: 	jigsaw-dev at openjdk.java.net
>>>
>>>
>>>
>>> This isn't a Jigsaw issue, please mail compiler-dev instead, being sure
>>> to note which JDK 9 build you are compiling with.
>>>
>>> On 10/5/2016 12:55 AM, Christian Beikov wrote:
>>> > The following used to compile just fine on JDKs < 9
>>> >
>>> >      @Override
>>> >      public <C, R> SimpleCase<C, R> selectCase(Expression<? extends C>
>>> > expression) {
>>> >          return selectCase((Class<R>) null, expression);
>>> >      }
>>> >
>>> >      public <C, R> SimpleCase<C, R> selectCase(Class<R> type,
>>> > Expression<? extends C> expression) {
>>> >          return new SimpleCaseExpression<C, R>(this, type, expression);
>>> >      }
>>> >
>>> > but now fails with:
>>> >      error: incompatible types: SimpleCase<CAP#1,R> cannot be converted
>>> > to SimpleCase<C,R>
>>> >
>>> > The error is in the first selectCase method.
>>> >
>>> > Is that a bug in the compiler?
>>> >
>>> > Regards,
>>> > Christian
>>
>

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

From jonathan.gibbons at oracle.com  Thu Oct  6 16:11:51 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 6 Oct 2016 09:11:51 -0700
Subject: Fwd: Re: Compilation error with JDK9-ea+138
In-Reply-To: <9c8d658c-36f6-a9a3-62cb-77ef18176def@gmail.com>
References: <57F53819.6050605@oracle.com>
	<396253d0-74a8-b044-cfba-af302e050bc7@gmail.com>
	<745740e0-d9c1-5431-b220-98ec62c6a161@oracle.com>
	<19c74e5c-8bb4-c6e5-1b73-d5a7f60ce37d@oracle.com>
	<9c8d658c-36f6-a9a3-62cb-77ef18176def@gmail.com>
Message-ID: <c97b9abb-12c1-03cc-c8d6-2f33fc56f478@oracle.com>

Christian,

Since the output does not look like a standard message from javac, I 
have to ask, what compiler are you using?

-- Jon


On 10/6/16 8:53 AM, Christian Beikov wrote:
> I am having trouble to create a small example that shows the problem too.
> Since the project is open source you can try that yourselves on that 
> project.
>
> URL: https://github.com/Blazebit/blaze-persistence.git
>
> export MAVEN_OPTS="--add-modules=java.se.ee"
> mvn -pl jpa-criteria/impl -am clean compile
>
> Then you will get the error message:
> BlazeCriteriaBuilderImpl.java:[997,48] error: incompatible types: 
> SimpleCase<CAP#1,R> cannot be converted to SimpleCase<C,R>
>
> Regards,
> Christian
>
> Am 06.10.2016 um 17:30 schrieb Maurizio Cimadamore:
>>
>> What Jon says. I;ve tried to give this a try using this example:
>>
>> class Test {
>>
>> interface Expression<T> { }
>>
>> interface SimpleCase<A, B> { }
>>
>> <C, R> SimpleCase<C, R> selectCase(Expression<? extends C> expression) {
>>           return selectCase((Class<R>) null, expression);
>> }
>>
>> <C, R> SimpleCase<C, R> selectCase(Class<R> type, Expression<? 
>> extends C> expression) {
>>           return null;
>>       }
>> }
>>
>>
>> But this passes with latest compiler. So I'm probably missing 
>> something (i.e. some bounds in the type-variable decl for Expression 
>> or SimpleCase?)
>>
>> Maurizio
>>
>>
>> On 06/10/16 16:17, Jonathan Gibbons wrote:
>>>
>>> Christian,
>>>
>>> As a general rule, it is better if you can post complete but reduced 
>>> test cases, and post all the messages from the compiler. It is often 
>>> hard to properly diagnose cases where someone posts some fragment of 
>>> code and asks what's wrong.
>>>
>>> -- Jon
>>>
>>>
>>> On 10/6/16 8:08 AM, Christian Beikov wrote:
>>>>
>>>> I have been directed to this mailing list for this error.
>>>>
>>>> Is this a known issue?
>>>>
>>>>
>>>>
>>>> -------- Weitergeleitete Nachricht --------
>>>> Betreff: 	Re: Compilation error with JDK9-ea+138
>>>> Datum: 	Wed, 05 Oct 2016 10:27:53 -0700
>>>> Von: 	Alex Buckley <alex.buckley at oracle.com>
>>>> Organisation: 	Oracle Corporation
>>>> An: 	jigsaw-dev at openjdk.java.net
>>>>
>>>>
>>>>
>>>> This isn't a Jigsaw issue, please mail compiler-dev instead, being sure
>>>> to note which JDK 9 build you are compiling with.
>>>>
>>>> On 10/5/2016 12:55 AM, Christian Beikov wrote:
>>>> > The following used to compile just fine on JDKs < 9
>>>> >
>>>> >      @Override
>>>> >      public <C, R> SimpleCase<C, R> selectCase(Expression<? extends C>
>>>> > expression) {
>>>> >          return selectCase((Class<R>) null, expression);
>>>> >      }
>>>> >
>>>> >      public <C, R> SimpleCase<C, R> selectCase(Class<R> type,
>>>> > Expression<? extends C> expression) {
>>>> >          return new SimpleCaseExpression<C, R>(this, type, expression);
>>>> >      }
>>>> >
>>>> > but now fails with:
>>>> >      error: incompatible types: SimpleCase<CAP#1,R> cannot be converted
>>>> > to SimpleCase<C,R>
>>>> >
>>>> > The error is in the first selectCase method.
>>>> >
>>>> > Is that a bug in the compiler?
>>>> >
>>>> > Regards,
>>>> > Christian
>>>
>>
>

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

From christian.beikov at gmail.com  Thu Oct  6 16:18:51 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 6 Oct 2016 18:18:51 +0200
Subject: Fwd: Re: Compilation error with JDK9-ea+138
In-Reply-To: <c97b9abb-12c1-03cc-c8d6-2f33fc56f478@oracle.com>
References: <57F53819.6050605@oracle.com>
	<396253d0-74a8-b044-cfba-af302e050bc7@gmail.com>
	<745740e0-d9c1-5431-b220-98ec62c6a161@oracle.com>
	<19c74e5c-8bb4-c6e5-1b73-d5a7f60ce37d@oracle.com>
	<9c8d658c-36f6-a9a3-62cb-77ef18176def@gmail.com>
	<c97b9abb-12c1-03cc-c8d6-2f33fc56f478@oracle.com>
Message-ID: <2732aec8-f367-4470-980b-ceeac2e3457f@gmail.com>

I am using javac through maven-compiler-plugin, but since I posted the 
instructions you can try to invoke that yourself and see with your own 
eyes. I don't know if maven post-processes the compiler messages, but 
according the output, it says javac is used.


Regards,
Christian

Am 06.10.2016 um 18:11 schrieb Jonathan Gibbons:
>
> Christian,
>
> Since the output does not look like a standard message from javac, I 
> have to ask, what compiler are you using?
>
> -- Jon
>
>
> On 10/6/16 8:53 AM, Christian Beikov wrote:
>> I am having trouble to create a small example that shows the problem too.
>> Since the project is open source you can try that yourselves on that 
>> project.
>>
>> URL: https://github.com/Blazebit/blaze-persistence.git
>>
>> export MAVEN_OPTS="--add-modules=java.se.ee"
>> mvn -pl jpa-criteria/impl -am clean compile
>>
>> Then you will get the error message:
>> BlazeCriteriaBuilderImpl.java:[997,48] error: incompatible types: 
>> SimpleCase<CAP#1,R> cannot be converted to SimpleCase<C,R>
>>
>> Regards,
>> Christian
>>
>> Am 06.10.2016 um 17:30 schrieb Maurizio Cimadamore:
>>>
>>> What Jon says. I;ve tried to give this a try using this example:
>>>
>>> class Test {
>>>
>>> interface Expression<T> { }
>>>
>>> interface SimpleCase<A, B> { }
>>>
>>> <C, R> SimpleCase<C, R> selectCase(Expression<? extends C> expression) {
>>>           return selectCase((Class<R>) null, expression);
>>> }
>>>
>>> <C, R> SimpleCase<C, R> selectCase(Class<R> type, Expression<? 
>>> extends C> expression) {
>>>           return null;
>>>       }
>>> }
>>>
>>>
>>> But this passes with latest compiler. So I'm probably missing 
>>> something (i.e. some bounds in the type-variable decl for Expression 
>>> or SimpleCase?)
>>>
>>> Maurizio
>>>
>>>
>>> On 06/10/16 16:17, Jonathan Gibbons wrote:
>>>>
>>>> Christian,
>>>>
>>>> As a general rule, it is better if you can post complete but 
>>>> reduced test cases, and post all the messages from the compiler. It 
>>>> is often hard to properly diagnose cases where someone posts some 
>>>> fragment of code and asks what's wrong.
>>>>
>>>> -- Jon
>>>>
>>>>
>>>> On 10/6/16 8:08 AM, Christian Beikov wrote:
>>>>>
>>>>> I have been directed to this mailing list for this error.
>>>>>
>>>>> Is this a known issue?
>>>>>
>>>>>
>>>>>
>>>>> -------- Weitergeleitete Nachricht --------
>>>>> Betreff: 	Re: Compilation error with JDK9-ea+138
>>>>> Datum: 	Wed, 05 Oct 2016 10:27:53 -0700
>>>>> Von: 	Alex Buckley <alex.buckley at oracle.com>
>>>>> Organisation: 	Oracle Corporation
>>>>> An: 	jigsaw-dev at openjdk.java.net
>>>>>
>>>>>
>>>>>
>>>>> This isn't a Jigsaw issue, please mail compiler-dev instead, being sure
>>>>> to note which JDK 9 build you are compiling with.
>>>>>
>>>>> On 10/5/2016 12:55 AM, Christian Beikov wrote:
>>>>> > The following used to compile just fine on JDKs < 9
>>>>> >
>>>>> >      @Override
>>>>> >      public <C, R> SimpleCase<C, R> selectCase(Expression<? extends C>
>>>>> > expression) {
>>>>> >          return selectCase((Class<R>) null, expression);
>>>>> >      }
>>>>> >
>>>>> >      public <C, R> SimpleCase<C, R> selectCase(Class<R> type,
>>>>> > Expression<? extends C> expression) {
>>>>> >          return new SimpleCaseExpression<C, R>(this, type, expression);
>>>>> >      }
>>>>> >
>>>>> > but now fails with:
>>>>> >      error: incompatible types: SimpleCase<CAP#1,R> cannot be converted
>>>>> > to SimpleCase<C,R>
>>>>> >
>>>>> > The error is in the first selectCase method.
>>>>> >
>>>>> > Is that a bug in the compiler?
>>>>> >
>>>>> > Regards,
>>>>> > Christian
>>>>
>>>
>>
>

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

From maurizio.cimadamore at oracle.com  Thu Oct  6 17:06:33 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 6 Oct 2016 18:06:33 +0100
Subject: Fwd: Re: Compilation error with JDK9-ea+138
In-Reply-To: <2732aec8-f367-4470-980b-ceeac2e3457f@gmail.com>
References: <57F53819.6050605@oracle.com>
	<396253d0-74a8-b044-cfba-af302e050bc7@gmail.com>
	<745740e0-d9c1-5431-b220-98ec62c6a161@oracle.com>
	<19c74e5c-8bb4-c6e5-1b73-d5a7f60ce37d@oracle.com>
	<9c8d658c-36f6-a9a3-62cb-77ef18176def@gmail.com>
	<c97b9abb-12c1-03cc-c8d6-2f33fc56f478@oracle.com>
	<2732aec8-f367-4470-980b-ceeac2e3457f@gmail.com>
Message-ID: <f0e68c88-9b09-578d-b318-67620fb36586@oracle.com>

Ok - my test case was correct, but I was missing the -source 1.6. This 
is a duplicate of this:

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

Maurizio


On 06/10/16 17:18, Christian Beikov wrote:
> I am using javac through maven-compiler-plugin, but since I posted the 
> instructions you can try to invoke that yourself and see with your own 
> eyes. I don't know if maven post-processes the compiler messages, but 
> according the output, it says javac is used.
>
>
> Regards,
> Christian
>
> Am 06.10.2016 um 18:11 schrieb Jonathan Gibbons:
>>
>> Christian,
>>
>> Since the output does not look like a standard message from javac, I 
>> have to ask, what compiler are you using?
>>
>> -- Jon
>>
>>
>> On 10/6/16 8:53 AM, Christian Beikov wrote:
>>> I am having trouble to create a small example that shows the problem 
>>> too.
>>> Since the project is open source you can try that yourselves on that 
>>> project.
>>>
>>> URL: https://github.com/Blazebit/blaze-persistence.git
>>>
>>> export MAVEN_OPTS="--add-modules=java.se.ee"
>>> mvn -pl jpa-criteria/impl -am clean compile
>>>
>>> Then you will get the error message:
>>> BlazeCriteriaBuilderImpl.java:[997,48] error: incompatible types: 
>>> SimpleCase<CAP#1,R> cannot be converted to SimpleCase<C,R>
>>>
>>> Regards,
>>> Christian
>>>
>>> Am 06.10.2016 um 17:30 schrieb Maurizio Cimadamore:
>>>>
>>>> What Jon says. I;ve tried to give this a try using this example:
>>>>
>>>> class Test {
>>>>
>>>> interface Expression<T> { }
>>>>
>>>> interface SimpleCase<A, B> { }
>>>>
>>>> <C, R> SimpleCase<C, R> selectCase(Expression<? extends C> 
>>>> expression) {
>>>>           return selectCase((Class<R>) null, expression);
>>>> }
>>>>
>>>> <C, R> SimpleCase<C, R> selectCase(Class<R> type, Expression<? 
>>>> extends C> expression) {
>>>>           return null;
>>>>       }
>>>> }
>>>>
>>>>
>>>> But this passes with latest compiler. So I'm probably missing 
>>>> something (i.e. some bounds in the type-variable decl for 
>>>> Expression or SimpleCase?)
>>>>
>>>> Maurizio
>>>>
>>>>
>>>> On 06/10/16 16:17, Jonathan Gibbons wrote:
>>>>>
>>>>> Christian,
>>>>>
>>>>> As a general rule, it is better if you can post complete but 
>>>>> reduced test cases, and post all the messages from the compiler. 
>>>>> It is often hard to properly diagnose cases where someone posts 
>>>>> some fragment of code and asks what's wrong.
>>>>>
>>>>> -- Jon
>>>>>
>>>>>
>>>>> On 10/6/16 8:08 AM, Christian Beikov wrote:
>>>>>>
>>>>>> I have been directed to this mailing list for this error.
>>>>>>
>>>>>> Is this a known issue?
>>>>>>
>>>>>>
>>>>>>
>>>>>> -------- Weitergeleitete Nachricht --------
>>>>>> Betreff: 	Re: Compilation error with JDK9-ea+138
>>>>>> Datum: 	Wed, 05 Oct 2016 10:27:53 -0700
>>>>>> Von: 	Alex Buckley <alex.buckley at oracle.com>
>>>>>> Organisation: 	Oracle Corporation
>>>>>> An: 	jigsaw-dev at openjdk.java.net
>>>>>>
>>>>>>
>>>>>>
>>>>>> This isn't a Jigsaw issue, please mail compiler-dev instead, being sure
>>>>>> to note which JDK 9 build you are compiling with.
>>>>>>
>>>>>> On 10/5/2016 12:55 AM, Christian Beikov wrote:
>>>>>> > The following used to compile just fine on JDKs < 9
>>>>>> >
>>>>>> >      @Override
>>>>>> >      public <C, R> SimpleCase<C, R> selectCase(Expression<? extends C>
>>>>>> > expression) {
>>>>>> >          return selectCase((Class<R>) null, expression);
>>>>>> >      }
>>>>>> >
>>>>>> >      public <C, R> SimpleCase<C, R> selectCase(Class<R> type,
>>>>>> > Expression<? extends C> expression) {
>>>>>> >          return new SimpleCaseExpression<C, R>(this, type, expression);
>>>>>> >      }
>>>>>> >
>>>>>> > but now fails with:
>>>>>> >      error: incompatible types: SimpleCase<CAP#1,R> cannot be converted
>>>>>> > to SimpleCase<C,R>
>>>>>> >
>>>>>> > The error is in the first selectCase method.
>>>>>> >
>>>>>> > Is that a bug in the compiler?
>>>>>> >
>>>>>> > Regards,
>>>>>> > Christian
>>>>>
>>>>
>>>
>>
>

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

From jonathan.gibbons at oracle.com  Fri Oct  7 21:40:11 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 07 Oct 2016 14:40:11 -0700
Subject: RFR: 8159855: Create an SPI for tools
In-Reply-To: <250C708F-AF40-45C0-A075-5BBDFA41F0A9@oracle.com>
References: <57F43DC3.8040905@oracle.com> <57F43F43.3080707@oracle.com>
	<250C708F-AF40-45C0-A075-5BBDFA41F0A9@oracle.com>
Message-ID: <57F8163B.3030701@oracle.com>

Updated webrev with feedback from comments:

* use doPrivileged within ToolProvider.findFIrst  (includes adding new test)
* improve whitespace in doc comments

Webrev: http://cr.openjdk.java.net/~jjg/8159855/webrev.05/

-- Jon



On 10/04/2016 09:19 PM, Mandy Chung wrote:
> This SPI is useful and provides as a replacement to existing use of internal APIs to launch some of our tools.  We will get jar, jmod, jlink and possibly other tools to convert to this SPI.
>
> ToolProvider::findFirst(String name) can find tool providers on classpath.  I think it needs to wrap the for-loop (specifically iterating on providers) with doPrivileged due to the stack-based permission check.
>
> Otherwise, looks good.
>
> Mandy
>
>> On Oct 4, 2016, at 4:46 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>>
>> Resend with non-mostly-empty subject line!
>>
>> -- Jon
>>
>> On 10/04/2016 04:39 PM, Jonathan Gibbons wrote:
>>> Core-libs folk,
>>>
>>> Please review the following change to add a new service provider class
>>>     java.util.spi.ToolProvider
>>>
>>> which can be used provide simple "command-line" access to select JDK
>>> tools, without starting a new JVM.
>>>
>>> The following tools are updated to provide access through the new SPI:
>>>     javac, javadoc, javap, jdeps
>>>
>>> It is expected that additional tools will also be updated to provide access,
>>> but that will be done separately.
>>>
>>> Compiler-dev folk may wish to review the changes to the langtools repository.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8159855
>>> Webrev: http://cr.openjdk.java.net/~jjg/8159855/webrev.03/
>>> API: http://cr.openjdk.java.net/~jjg/8159855/api.02/java/util/spi/ToolProvider.html
>>>
>>> -- Jon


From mandy.chung at oracle.com  Fri Oct  7 22:00:39 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 7 Oct 2016 15:00:39 -0700
Subject: RFR: 8159855: Create an SPI for tools
In-Reply-To: <57F8163B.3030701@oracle.com>
References: <57F43DC3.8040905@oracle.com> <57F43F43.3080707@oracle.com>
	<250C708F-AF40-45C0-A075-5BBDFA41F0A9@oracle.com>
	<57F8163B.3030701@oracle.com>
Message-ID: <3DDACF4B-5E40-4D84-A0AB-7CDF186BC054@oracle.com>


> On Oct 7, 2016, at 2:40 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Updated webrev with feedback from comments:
> 
> * use doPrivileged within ToolProvider.findFIrst  (includes adding new test)
> * improve whitespace in doc comments
> 
> Webrev: http://cr.openjdk.java.net/~jjg/8159855/webrev.05/

Looks good.  Thanks for adding the new test.

Nit: line 68: s/nonzero/non-zero

Mandy


From bsrbnd at gmail.com  Mon Oct 10 11:45:19 2016
From: bsrbnd at gmail.com (bsrbnd)
Date: Mon, 10 Oct 2016 13:45:19 +0200
Subject: [PATCH] 8147527: Non-optimal code generated for postfix unary
	operators
Message-ID: <CAEgw74A6RLjAH0knfYwmqWx_CrLpR8xQBuy+c4ucC6SaAPXqog@mail.gmail.com>

Hi,

Consider the following example slightly modified from issue 8147527
description to incorporate an assignment operator and an inner class
which are both of them involved in the optimization process:

class Issue8147527 {
    Integer i=0;
    private Integer test() {
        this.i += 3;
        for (; i<5; this.i++);
        return this.i++;
    }

    Integer j=10;
    class Inner {
        private Integer test() {
            return Issue8147527.this.j++;
        }
    }

    public static void main(String[] args) {
        Issue8147527 self = new Issue8147527();
        System.out.println(self.test());
        System.out.println(self.i);

        Inner in = self.new Inner();
        System.out.println(in.test());
        System.out.println(self.j);
    }
}

The following patch omits "this" for the special case of a
select-expression used as an lvalue.
Thus we had before optimization:

  private java.lang.Integer test();
    Code:
       0: aload_0
       1: astore_1
       2: aload_1
       3: aload_1
       4: getfield      #3                  // Field i:Ljava/lang/Integer;
       7: invokevirtual #5                  // Method
java/lang/Integer.intValue:()I
      10: iconst_3
      11: iadd
      12: invokestatic  #2                  // Method
java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
      15: dup_x1
      16: putfield      #3                  // Field i:Ljava/lang/Integer;

And after optimization, we have:

  private java.lang.Integer test();
    Code:
       0: aload_0
       1: aload_0
       2: getfield      #3                  // Field i:Ljava/lang/Integer;
       5: invokevirtual #5                  // Method
java/lang/Integer.intValue:()I
       8: iconst_3
       9: iadd
      10: invokestatic  #2                  // Method
java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
      13: putfield      #3                  // Field i:Ljava/lang/Integer;

I've run all javac tests and it seems quite good.
Notice that I haven't checked the "super" case yet, waiting for any
feedback about the first optimization.

Regards,
Bernard

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
@@ -2253,6 +2253,7 @@
         case SELECT: {
             final JCFieldAccess s = (JCFieldAccess)lval;
             Symbol lid = TreeInfo.symbol(s.selected);
+            if (lid != null && lid.name.equals(names._this)) return
builder.build(make.Ident(s.sym));
             if (lid != null && lid.kind == TYP) return builder.build(lval);
             return abstractRval(s.selected, new TreeBuilder() {
                     public JCExpression build(final JCExpression selected) {

From jan.lahoda at oracle.com  Mon Oct 10 16:37:39 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 10 Oct 2016 18:37:39 +0200
Subject: RFR JDK-8167442: Langtools ant build not working after addition of
	-Xlint:exports
Message-ID: <57FBC3D3.9000400@oracle.com>

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

Proposed solution is to disable the exports lint when compiling the 
langtools sources (the lint is disabled for the jdk.jshell module when 
building using the make buildsystem).

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

Any feedback is welcome.

Thanks,
     Jan

From maurizio.cimadamore at oracle.com  Mon Oct 10 16:40:13 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 10 Oct 2016 17:40:13 +0100
Subject: RFR JDK-8167442: Langtools ant build not working after addition
	of -Xlint:exports
In-Reply-To: <57FBC3D3.9000400@oracle.com>
References: <57FBC3D3.9000400@oracle.com>
Message-ID: <86fbd0c8-3fe4-6a52-6faa-f66847a37e8e@oracle.com>

Looks good


Maurizio


On 10/10/16 17:37, Jan Lahoda wrote:
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8167442
>
> Proposed solution is to disable the exports lint when compiling the 
> langtools sources (the lint is disabled for the jdk.jshell module when 
> building using the make buildsystem).
>
> Webrev:
> http://cr.openjdk.java.net/~jlahoda/8167442/webrev.00/
>
> Any feedback is welcome.
>
> Thanks,
>     Jan


From forax at univ-mlv.fr  Tue Oct 11 06:11:05 2016
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 11 Oct 2016 06:11:05 +0000
Subject: RFR JDK-8167442: Langtools ant build not working after addition
	of	-Xlint:exports
In-Reply-To: <57FBC3D3.9000400@oracle.com>
References: <57FBC3D3.9000400@oracle.com>
Message-ID: <C10F7D36-DE82-4E03-B138-236D68113921@univ-mlv.fr>

I don't think it's a good idea to try to hide these kind of warning under the carpet. 

It means that the methods are public or the class is in an exported package but it should not.

Hiding this kind of info is harmful IMO. 

R?mi 

On October 10, 2016 6:37:39 PM GMT+02:00, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>Bug:
>https://bugs.openjdk.java.net/browse/JDK-8167442
>
>Proposed solution is to disable the exports lint when compiling the 
>langtools sources (the lint is disabled for the jdk.jshell module when 
>building using the make buildsystem).
>
>Webrev:
>http://cr.openjdk.java.net/~jlahoda/8167442/webrev.00/
>
>Any feedback is welcome.
>
>Thanks,
>     Jan

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161011/e77ac0bb/attachment.html>

From jan.lahoda at oracle.com  Tue Oct 11 06:55:34 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 11 Oct 2016 08:55:34 +0200
Subject: RFR JDK-8167442: Langtools ant build not working after addition
	of -Xlint:exports
In-Reply-To: <C10F7D36-DE82-4E03-B138-236D68113921@univ-mlv.fr>
References: <57FBC3D3.9000400@oracle.com>
	<C10F7D36-DE82-4E03-B138-236D68113921@univ-mlv.fr>
Message-ID: <57FC8CE6.3090908@oracle.com>

On 11.10.2016 08:11, Remi Forax wrote:
> I don't think it's a good idea to try to hide these kind of warning
> under the carpet.

Bugs have been filled to every module in OpenJDK for which this warning 
is reported:
https://bugs.openjdk.java.net/browse/JDK-8167176
https://bugs.openjdk.java.net/browse/JDK-8167178
https://bugs.openjdk.java.net/browse/JDK-8167180
https://bugs.openjdk.java.net/browse/JDK-8167181
https://bugs.openjdk.java.net/browse/JDK-8167182
https://bugs.openjdk.java.net/browse/JDK-8167185
https://bugs.openjdk.java.net/browse/JDK-8167187

The warnings have been disabled in the make buildsystem so that the lint 
can be integrated (I suspect that first trying to fix each and every 
violation and then introduce the lint could prove to be too difficult).

>
> It means that the methods are public or the class is in an exported
> package but it should not.

In the specific jdk.jshell case (which we are discussing here), the 
warning is even more strict: in jdk.jshell there are methods like:
JDIExecutionControl.vm()com.sun.jdi.VirtualMachine

com.sun.jdi.VirtualMachine is a public exported type, but in jdk.jdi 
module which the jdk.jshell module does not "re-export" (i.e. the 
jdk.jshell module does not requires public jdk.jdi). So every client of 
this method needs to require jdk.jdi themselves. Whether that is a 
problem in this specific case, I am not sure (I am personally not sure 
if the use of the offending classes in jdk.jshell will be mainstream 
enough to push jdk.jdi to each client of the API).

>
> Hiding this kind of info is harmful IMO.

In this specific case, we are discussing disabling the lint in the 
developer-only ant build script for langtools. The current state blocks 
everyone using the developer-only ant build script (or forces them to 
use private workaround), and I am not sure we should rush some decision 
on whether jdk.jshell should requires public jdk.jdi just to unblock 
people that are using ant.

Jan

>
> R?mi
>
> On October 10, 2016 6:37:39 PM GMT+02:00, Jan Lahoda
> <jan.lahoda at oracle.com> wrote:
>
>     Bug:
>     https://bugs.openjdk.java.net/browse/JDK-8167442
>
>     Proposed solution is to disable the exports lint when compiling the
>     langtools sources (the lint is disabled for the jdk.jshell module when
>     building using the make buildsystem).
>
>     Webrev:
>     http://cr.openjdk.java.net/~jlahoda/8167442/webrev.00/
>
>     Any feedback is welcome.
>
>     Thanks,
>           Jan
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

From forax at univ-mlv.fr  Tue Oct 11 07:46:31 2016
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 11 Oct 2016 09:46:31 +0200 (CEST)
Subject: RFR JDK-8167442: Langtools ant build not working after addition
	of -Xlint:exports
In-Reply-To: <57FC8CE6.3090908@oracle.com>
References: <57FBC3D3.9000400@oracle.com>
	<C10F7D36-DE82-4E03-B138-236D68113921@univ-mlv.fr>
	<57FC8CE6.3090908@oracle.com>
Message-ID: <1567001480.691719.1476171991216.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Jan Lahoda" <jan.lahoda at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>, "compiler-dev" <compiler-dev at openjdk.java.net>
> Envoy?: Mardi 11 Octobre 2016 08:55:34
> Objet: Re: RFR JDK-8167442: Langtools ant build not working after addition of -Xlint:exports

Hi Jan,

> On 11.10.2016 08:11, Remi Forax wrote:
>> I don't think it's a good idea to try to hide these kind of warning
>> under the carpet.
> 
> Bugs have been filled to every module in OpenJDK for which this warning
> is reported:
> https://bugs.openjdk.java.net/browse/JDK-8167176
> https://bugs.openjdk.java.net/browse/JDK-8167178
> https://bugs.openjdk.java.net/browse/JDK-8167180
> https://bugs.openjdk.java.net/browse/JDK-8167181
> https://bugs.openjdk.java.net/browse/JDK-8167182
> https://bugs.openjdk.java.net/browse/JDK-8167185
> https://bugs.openjdk.java.net/browse/JDK-8167187
> 
> The warnings have been disabled in the make buildsystem so that the lint
> can be integrated (I suspect that first trying to fix each and every
> violation and then introduce the lint could prove to be too difficult).

ok,
+1 if it's a temporary fix.

> 
>>
>> It means that the methods are public or the class is in an exported
>> package but it should not.
> 
> In the specific jdk.jshell case (which we are discussing here), the
> warning is even more strict: in jdk.jshell there are methods like:
> JDIExecutionControl.vm()com.sun.jdi.VirtualMachine
> 
> com.sun.jdi.VirtualMachine is a public exported type, but in jdk.jdi
> module which the jdk.jshell module does not "re-export" (i.e. the
> jdk.jshell module does not requires public jdk.jdi). So every client of
> this method needs to require jdk.jdi themselves. Whether that is a
> problem in this specific case, I am not sure (I am personally not sure
> if the use of the offending classes in jdk.jshell will be mainstream
> enough to push jdk.jdi to each client of the API).

Using require transitive is one way to solve the warnings,
but i agree with you that this is not the good way to solve that issue.
Here, i think the API should either not be public or put in a non exported package, even if it means creating a non exported package for things like Util.

> 
>>
>> Hiding this kind of info is harmful IMO.
> 
> In this specific case, we are discussing disabling the lint in the
> developer-only ant build script for langtools. The current state blocks
> everyone using the developer-only ant build script (or forces them to
> use private workaround), and I am not sure we should rush some decision
> on whether jdk.jshell should requires public jdk.jdi just to unblock
> people that are using ant.
> 
> Jan

R?mi

> 
>>
>> R?mi
>>
>> On October 10, 2016 6:37:39 PM GMT+02:00, Jan Lahoda
>> <jan.lahoda at oracle.com> wrote:
>>
>>     Bug:
>>     https://bugs.openjdk.java.net/browse/JDK-8167442
>>
>>     Proposed solution is to disable the exports lint when compiling the
>>     langtools sources (the lint is disabled for the jdk.jshell module when
>>     building using the make buildsystem).
>>
>>     Webrev:
>>     http://cr.openjdk.java.net/~jlahoda/8167442/webrev.00/
>>
>>     Any feedback is welcome.
>>
>>     Thanks,
>>           Jan
>>
>>
>> --
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.

From jan.lahoda at oracle.com  Tue Oct 11 08:56:24 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 11 Oct 2016 10:56:24 +0200
Subject: RFR JDK-8167442: Langtools ant build not working after addition
	of -Xlint:exports
In-Reply-To: <1567001480.691719.1476171991216.JavaMail.zimbra@u-pem.fr>
References: <57FBC3D3.9000400@oracle.com>
	<C10F7D36-DE82-4E03-B138-236D68113921@univ-mlv.fr>
	<57FC8CE6.3090908@oracle.com>
	<1567001480.691719.1476171991216.JavaMail.zimbra@u-pem.fr>
Message-ID: <57FCA938.7060408@oracle.com>

On 11.10.2016 09:46, forax at univ-mlv.fr wrote:
> ----- Mail original -----
>> De: "Jan Lahoda" <jan.lahoda at oracle.com>
>> ?: "Remi Forax" <forax at univ-mlv.fr>, "compiler-dev" <compiler-dev at openjdk.java.net>
>> Envoy?: Mardi 11 Octobre 2016 08:55:34
>> Objet: Re: RFR JDK-8167442: Langtools ant build not working after addition of -Xlint:exports
>
> Hi Jan,
>
>> On 11.10.2016 08:11, Remi Forax wrote:
>>> I don't think it's a good idea to try to hide these kind of warning
>>> under the carpet.
>>
>> Bugs have been filled to every module in OpenJDK for which this warning
>> is reported:
>> https://bugs.openjdk.java.net/browse/JDK-8167176
>> https://bugs.openjdk.java.net/browse/JDK-8167178
>> https://bugs.openjdk.java.net/browse/JDK-8167180
>> https://bugs.openjdk.java.net/browse/JDK-8167181
>> https://bugs.openjdk.java.net/browse/JDK-8167182
>> https://bugs.openjdk.java.net/browse/JDK-8167185
>> https://bugs.openjdk.java.net/browse/JDK-8167187
>>
>> The warnings have been disabled in the make buildsystem so that the lint
>> can be integrated (I suspect that first trying to fix each and every
>> violation and then introduce the lint could prove to be too difficult).
>
> ok,
> +1 if it's a temporary fix.

Thanks.

>
>>
>>>
>>> It means that the methods are public or the class is in an exported
>>> package but it should not.
>>
>> In the specific jdk.jshell case (which we are discussing here), the
>> warning is even more strict: in jdk.jshell there are methods like:
>> JDIExecutionControl.vm()com.sun.jdi.VirtualMachine
>>
>> com.sun.jdi.VirtualMachine is a public exported type, but in jdk.jdi
>> module which the jdk.jshell module does not "re-export" (i.e. the
>> jdk.jshell module does not requires public jdk.jdi). So every client of
>> this method needs to require jdk.jdi themselves. Whether that is a
>> problem in this specific case, I am not sure (I am personally not sure
>> if the use of the offending classes in jdk.jshell will be mainstream
>> enough to push jdk.jdi to each client of the API).
>
> Using require transitive is one way to solve the warnings,
> but i agree with you that this is not the good way to solve that issue.
> Here, i think the API should either not be public or put in a non exported package, even if it means creating a non exported package for things like Util.

Not sure if that's what should be done: the classes are intentionally 
public and exported, so that (some) clients may use them. But I am not 
sure if the use will be widespread enough to force jdk.jdi to all other 
clients of the API as well. (Esp. given those that need to use a 
JDI-related method can simply do "requires jdk.jdi" themselves.)

Jan

>
>>
>>>
>>> Hiding this kind of info is harmful IMO.
>>
>> In this specific case, we are discussing disabling the lint in the
>> developer-only ant build script for langtools. The current state blocks
>> everyone using the developer-only ant build script (or forces them to
>> use private workaround), and I am not sure we should rush some decision
>> on whether jdk.jshell should requires public jdk.jdi just to unblock
>> people that are using ant.
>>
>> Jan
>
> R?mi
>
>>
>>>
>>> R?mi
>>>
>>> On October 10, 2016 6:37:39 PM GMT+02:00, Jan Lahoda
>>> <jan.lahoda at oracle.com> wrote:
>>>
>>>      Bug:
>>>      https://bugs.openjdk.java.net/browse/JDK-8167442
>>>
>>>      Proposed solution is to disable the exports lint when compiling the
>>>      langtools sources (the lint is disabled for the jdk.jshell module when
>>>      building using the make buildsystem).
>>>
>>>      Webrev:
>>>      http://cr.openjdk.java.net/~jlahoda/8167442/webrev.00/
>>>
>>>      Any feedback is welcome.
>>>
>>>      Thanks,
>>>            Jan
>>>
>>>
>>> --
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.

From forax at univ-mlv.fr  Tue Oct 11 11:57:59 2016
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 11 Oct 2016 13:57:59 +0200 (CEST)
Subject: RFR JDK-8167442: Langtools ant build not working after addition
	of -Xlint:exports
In-Reply-To: <57FCA938.7060408@oracle.com>
References: <57FBC3D3.9000400@oracle.com>
	<C10F7D36-DE82-4E03-B138-236D68113921@univ-mlv.fr>
	<57FC8CE6.3090908@oracle.com>
	<1567001480.691719.1476171991216.JavaMail.zimbra@u-pem.fr>
	<57FCA938.7060408@oracle.com>
Message-ID: <721631888.905103.1476187079528.JavaMail.zimbra@u-pem.fr>

>>>
>>>>
>>>> It means that the methods are public or the class is in an exported
>>>> package but it should not.
>>>
>>> In the specific jdk.jshell case (which we are discussing here), the
>>> warning is even more strict: in jdk.jshell there are methods like:
>>> JDIExecutionControl.vm()com.sun.jdi.VirtualMachine
>>>
>>> com.sun.jdi.VirtualMachine is a public exported type, but in jdk.jdi
>>> module which the jdk.jshell module does not "re-export" (i.e. the
>>> jdk.jshell module does not requires public jdk.jdi). So every client of
>>> this method needs to require jdk.jdi themselves. Whether that is a
>>> problem in this specific case, I am not sure (I am personally not sure
>>> if the use of the offending classes in jdk.jshell will be mainstream
>>> enough to push jdk.jdi to each client of the API).
>>
>> Using require transitive is one way to solve the warnings,
>> but i agree with you that this is not the good way to solve that issue.
>> Here, i think the API should either not be public or put in a non exported
>> package, even if it means creating a non exported package for things like Util.
> 
> Not sure if that's what should be done: the classes are intentionally
> public and exported, so that (some) clients may use them. But I am not
> sure if the use will be widespread enough to force jdk.jdi to all other
> clients of the API as well. (Esp. given those that need to use a
> JDI-related method can simply do "requires jdk.jdi" themselves.)
> 
> Jan

I see,
maybe another solution is to add a note in the overview of the class about the fact that some methods may require jdk.jdi and to use @SuppressWarnings to avoid the lint warnings. 

R?mi

> 
>>
>>>
>>>>
>>>> Hiding this kind of info is harmful IMO.
>>>
>>> In this specific case, we are discussing disabling the lint in the
>>> developer-only ant build script for langtools. The current state blocks
>>> everyone using the developer-only ant build script (or forces them to
>>> use private workaround), and I am not sure we should rush some decision
>>> on whether jdk.jshell should requires public jdk.jdi just to unblock
>>> people that are using ant.
>>>
>>> Jan
>>
>> R?mi
>>
>>>
>>>>
>>>> R?mi
>>>>
>>>> On October 10, 2016 6:37:39 PM GMT+02:00, Jan Lahoda
>>>> <jan.lahoda at oracle.com> wrote:
>>>>
>>>>      Bug:
>>>>      https://bugs.openjdk.java.net/browse/JDK-8167442
>>>>
>>>>      Proposed solution is to disable the exports lint when compiling the
>>>>      langtools sources (the lint is disabled for the jdk.jshell module when
>>>>      building using the make buildsystem).
>>>>
>>>>      Webrev:
>>>>      http://cr.openjdk.java.net/~jlahoda/8167442/webrev.00/
>>>>
>>>>      Any feedback is welcome.
>>>>
>>>>      Thanks,
>>>>            Jan
>>>>
>>>>
>>>> --
> >>> Sent from my Android device with K-9 Mail. Please excuse my brevity.

From jonathan.gibbons at oracle.com  Tue Oct 11 15:22:00 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 11 Oct 2016 08:22:00 -0700
Subject: RFR JDK-8167442: Langtools ant build not working after addition
	of -Xlint:exports
In-Reply-To: <57FC8CE6.3090908@oracle.com>
References: <57FBC3D3.9000400@oracle.com>
	<C10F7D36-DE82-4E03-B138-236D68113921@univ-mlv.fr>
	<57FC8CE6.3090908@oracle.com>
Message-ID: <84213045-d9b4-09d7-bc1b-97e2db358cb2@oracle.com>



On 10/10/16 11:55 PM, Jan Lahoda wrote:
> On 11.10.2016 08:11, Remi Forax wrote:
>> I don't think it's a good idea to try to hide these kind of warning
>> under the carpet.
>
> Bugs have been filled to every module in OpenJDK for which this 
> warning is reported:
> https://bugs.openjdk.java.net/browse/JDK-8167176
> https://bugs.openjdk.java.net/browse/JDK-8167178
> https://bugs.openjdk.java.net/browse/JDK-8167180
> https://bugs.openjdk.java.net/browse/JDK-8167181
> https://bugs.openjdk.java.net/browse/JDK-8167182
> https://bugs.openjdk.java.net/browse/JDK-8167185
> https://bugs.openjdk.java.net/browse/JDK-8167187
>
> The warnings have been disabled in the make buildsystem so that the 
> lint can be integrated (I suspect that first trying to fix each and 
> every violation and then introduce the lint could prove to be too 
> difficult).
>
>>
>> It means that the methods are public or the class is in an exported
>> package but it should not.
>
> In the specific jdk.jshell case (which we are discussing here), the 
> warning is even more strict: in jdk.jshell there are methods like:
> JDIExecutionControl.vm()com.sun.jdi.VirtualMachine
>
> com.sun.jdi.VirtualMachine is a public exported type, but in jdk.jdi 
> module which the jdk.jshell module does not "re-export" (i.e. the 
> jdk.jshell module does not requires public jdk.jdi). So every client 
> of this method needs to require jdk.jdi themselves. Whether that is a 
> problem in this specific case, I am not sure (I am personally not sure 
> if the use of the offending classes in jdk.jshell will be mainstream 
> enough to push jdk.jdi to each client of the API).

Why not use "requires public"?  What is the downside?

-- Jon

>
>>
>> Hiding this kind of info is harmful IMO.
>
> In this specific case, we are discussing disabling the lint in the 
> developer-only ant build script for langtools. The current state 
> blocks everyone using the developer-only ant build script (or forces 
> them to use private workaround), and I am not sure we should rush some 
> decision on whether jdk.jshell should requires public jdk.jdi just to 
> unblock people that are using ant.
>
> Jan
>
>>
>> R?mi
>>
>> On October 10, 2016 6:37:39 PM GMT+02:00, Jan Lahoda
>> <jan.lahoda at oracle.com> wrote:
>>
>>     Bug:
>>     https://bugs.openjdk.java.net/browse/JDK-8167442
>>
>>     Proposed solution is to disable the exports lint when compiling the
>>     langtools sources (the lint is disabled for the jdk.jshell module 
>> when
>>     building using the make buildsystem).
>>
>>     Webrev:
>>     http://cr.openjdk.java.net/~jlahoda/8167442/webrev.00/
>>
>>     Any feedback is welcome.
>>
>>     Thanks,
>>           Jan
>>
>>
>> -- 
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.


From jan.lahoda at oracle.com  Tue Oct 11 18:51:49 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 11 Oct 2016 20:51:49 +0200
Subject: RFR JDK-8167442: Langtools ant build not working after addition
	of -Xlint:exports
In-Reply-To: <84213045-d9b4-09d7-bc1b-97e2db358cb2@oracle.com>
References: <57FBC3D3.9000400@oracle.com>
	<C10F7D36-DE82-4E03-B138-236D68113921@univ-mlv.fr>
	<57FC8CE6.3090908@oracle.com>
	<84213045-d9b4-09d7-bc1b-97e2db358cb2@oracle.com>
Message-ID: <57FD34C5.7030707@oracle.com>

On 11.10.2016 17:22, Jonathan Gibbons wrote:
>
>
> On 10/10/16 11:55 PM, Jan Lahoda wrote:
>> On 11.10.2016 08:11, Remi Forax wrote:
>>> I don't think it's a good idea to try to hide these kind of warning
>>> under the carpet.
>>
>> Bugs have been filled to every module in OpenJDK for which this
>> warning is reported:
>> https://bugs.openjdk.java.net/browse/JDK-8167176
>> https://bugs.openjdk.java.net/browse/JDK-8167178
>> https://bugs.openjdk.java.net/browse/JDK-8167180
>> https://bugs.openjdk.java.net/browse/JDK-8167181
>> https://bugs.openjdk.java.net/browse/JDK-8167182
>> https://bugs.openjdk.java.net/browse/JDK-8167185
>> https://bugs.openjdk.java.net/browse/JDK-8167187
>>
>> The warnings have been disabled in the make buildsystem so that the
>> lint can be integrated (I suspect that first trying to fix each and
>> every violation and then introduce the lint could prove to be too
>> difficult).
>>
>>>
>>> It means that the methods are public or the class is in an exported
>>> package but it should not.
>>
>> In the specific jdk.jshell case (which we are discussing here), the
>> warning is even more strict: in jdk.jshell there are methods like:
>> JDIExecutionControl.vm()com.sun.jdi.VirtualMachine
>>
>> com.sun.jdi.VirtualMachine is a public exported type, but in jdk.jdi
>> module which the jdk.jshell module does not "re-export" (i.e. the
>> jdk.jshell module does not requires public jdk.jdi). So every client
>> of this method needs to require jdk.jdi themselves. Whether that is a
>> problem in this specific case, I am not sure (I am personally not sure
>> if the use of the offending classes in jdk.jshell will be mainstream
>> enough to push jdk.jdi to each client of the API).
>
> Why not use "requires public"?  What is the downside?

That's of course the simplest solution. My concern here is that this is 
(a small) help to a possibly smaller group of clients that will use the 
JDI-related methods, but we would also push the jdk.jdi dependency to a 
possibly larger group clients that don't need these JDI methods. I am a 
little bit on the fence on whether we should use requires public jdk.jdi 
or not. So, I was hoping we could discuss if we want the requires public 
or @SuppressWarnings for the specific methods. (Or, as I overall don't 
think this is a significant problem, we could also discuss dropping this 
particular check from the lint.)

Jan

>
> -- Jon
>
>>
>>>
>>> Hiding this kind of info is harmful IMO.
>>
>> In this specific case, we are discussing disabling the lint in the
>> developer-only ant build script for langtools. The current state
>> blocks everyone using the developer-only ant build script (or forces
>> them to use private workaround), and I am not sure we should rush some
>> decision on whether jdk.jshell should requires public jdk.jdi just to
>> unblock people that are using ant.
>>
>> Jan
>>
>>>
>>> R?mi
>>>
>>> On October 10, 2016 6:37:39 PM GMT+02:00, Jan Lahoda
>>> <jan.lahoda at oracle.com> wrote:
>>>
>>>     Bug:
>>>     https://bugs.openjdk.java.net/browse/JDK-8167442
>>>
>>>     Proposed solution is to disable the exports lint when compiling the
>>>     langtools sources (the lint is disabled for the jdk.jshell module
>>> when
>>>     building using the make buildsystem).
>>>
>>>     Webrev:
>>>     http://cr.openjdk.java.net/~jlahoda/8167442/webrev.00/
>>>
>>>     Any feedback is welcome.
>>>
>>>     Thanks,
>>>           Jan
>>>
>>>
>>> --
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

From eaftan at google.com  Thu Oct 13 20:24:23 2016
From: eaftan at google.com (Eddie Aftandilian)
Date: Thu, 13 Oct 2016 13:24:23 -0700
Subject: Clarification about accessibility of private members
In-Reply-To: <80e82160-97af-c5c2-68b2-3b42a9f6c0d6@oracle.com>
References: <CA+7OGVoBJ-j3yuf5NQms+5tiOT-O6p_Rb5pzJcO5f1urYfK9mg@mail.gmail.com>
	<80e82160-97af-c5c2-68b2-3b42a9f6c0d6@oracle.com>
Message-ID: <CA+7OGVrz_cbmqQY7-YagD-qfpizUTnMaUtFPLD=RXd71WM6mvw@mail.gmail.com>

Thanks for the clear explanation!

On Mon, Oct 3, 2016 at 2:50 AM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>
>
> On 30/09/16 22:31, Eddie Aftandilian wrote:
>
> JLS 6.6.1 says, "Otherwise, the member or constructor is declared private,
> and access is permitted if and only if it occurs within the body of the top
> level class (?7.6) that encloses the declaration of the member or
> constructor."  Under that definition, I believe the following code should
> be legal:
>
> class Holder {
>   class Super {
>     private String s1;
>   }
>   class Sub extends Super {
>     private String doIt() {
>       return s1;
>     }
>   }
> }
>
> Holder is the top level class that encloses the declaration of s1, and the
> "return s1" statement occurs inside Holder's body.  However, javac 1.8.0
> issues an error on this code:
>
> Holder.java:7: error: s1 has private access in Holder.Super
>       return s1;
>              ^
> 1 error
>
> What am I missing?
>
> I think there's another aspect at stake here: interplay between
> inheritance and scoping. But let's start from the beginning: the rules for
> checking that 's1' is a valid field identifier are defined in 6.5.6.1:
>
> "If an expression name consists of a single Identifier, then there must be
> exactly one declaration denoting either a local variable, parameter, or
> field *visible* (?6.4.1) at the point at which the Identifier occurs.
> Otherwise, a compile-time error occurs."
>
> What does 'visible' mean? Let's expand 6.4.1:
>
> "A declaration d is said to be visible at point p in a program if the
> scope of d includes p, and d is not shadowed by any other declaration at p."
>
> Ok, so the question we need to ask is: does the scope of 's1' includes the
> instance method doIt() ?
>
> The scope of a field is defined as follows in JLS 6.3:
>
> "The scope of a declaration of a member m declared in or inherited by a
> class type C (?8.1.6
> <https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.1.6>)
> is the entire body of C, including any nested type declarations."
>
> So, from the perspective of 'Sub' the only way for it to have a field 's1'
> in scope is:
>
> * if it declares the field 's1'
> * if it inherits a field 's1'
>
> In your example, the first bullet clearly does not apply: 'Sub' doesn't
> declare any fields. So the question is, does 'Sub' inherits 's1' from
> 'Super' ? The answer is again no, this time because of JLS 8.2. (Class
> Members):
>
> "Members of a class that are declared private are not inherited by
> subclasses of that class."
>
> That is, 's1' is not inherited because it is declared private in 'Sup'.
> Popping back, this means that 's1' is not visible inside 'doIt()' and
> therefore the error message you get is expected.
>
> Maurizio
>
> Thanks,
> Eddie
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161013/e04a399b/attachment.html>

From stuart.marks at oracle.com  Thu Oct 13 22:04:03 2016
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 13 Oct 2016 15:04:03 -0700
Subject: RFR(s): 8167965 (jdeprscan) using --release option with 8 or earlier
	throws exception
Message-ID: <b4497d35-5d1c-737c-df5b-f75d6401a9a6@oracle.com>

Hi all,

Please review this small fix to jdeprscan to adjust the options it passes to the 
compiler, specifically "--release" instead of "-release" which no longer works.

Bug:

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

Webrev:

	http://cr.openjdk.java.net/~smarks/reviews/8167965/webrev.0/

Thanks,

s'marks

From mandy.chung at oracle.com  Thu Oct 13 22:33:48 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 13 Oct 2016 15:33:48 -0700
Subject: RFR(s): 8167965 (jdeprscan) using --release option with 8 or
	earlier throws exception
In-Reply-To: <b4497d35-5d1c-737c-df5b-f75d6401a9a6@oracle.com>
References: <b4497d35-5d1c-737c-df5b-f75d6401a9a6@oracle.com>
Message-ID: <50C5B875-B77B-42FB-A7AC-7C8A35012170@oracle.com>


> On Oct 13, 2016, at 3:04 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> Hi all,
> 
> Please review this small fix to jdeprscan to adjust the options it passes to the compiler, specifically "--release" instead of "-release" which no longer works.
> 
> Bug:
> 
> 	https://bugs.openjdk.java.net/browse/JDK-8167965
> 
> Webrev:
> 
> 	http://cr.openjdk.java.net/~smarks/reviews/8167965/webrev.0/

+1

Mandy


From tim.bell at oracle.com  Sat Oct 15 01:23:26 2016
From: tim.bell at oracle.com (Tim Bell)
Date: Fri, 14 Oct 2016 18:23:26 -0700
Subject: RFR: 8167600 jib make run-test for langtools and intermittent
	failures on windows-x86
Message-ID: <3eff9f30-7c35-4213-cfde-9c86a7f4633c@oracle.com>

Please review this rework of the langtools/test/Makefile fix done in 
8166648. [1]  ARCH_DATA_MODEL is not set in all test scenarios, so a 
better approach is to check the VM about to be tested.

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

Webrev:
     http://cr.openjdk.java.net/~tbell/8167600/webrev.00/

Testing:
    Successful JPRT runs on all platforms.  Inspected the 
<platform>_<arch>.product-c2-langtools_jtreg.log files to verify the 
expected flag was used only on 32-bit VMs.


Thanks in advance-

Tim

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

From magnus.ihse.bursie at oracle.com  Mon Oct 17 07:48:38 2016
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 17 Oct 2016 09:48:38 +0200
Subject: RFR: 8167600 jib make run-test for langtools and intermittent
	failures on windows-x86
In-Reply-To: <3eff9f30-7c35-4213-cfde-9c86a7f4633c@oracle.com>
References: <3eff9f30-7c35-4213-cfde-9c86a7f4633c@oracle.com>
Message-ID: <8e98febd-958d-2145-9d82-baa69393881f@oracle.com>

On 2016-10-15 03:23, Tim Bell wrote:
> Please review this rework of the langtools/test/Makefile fix done in 
> 8166648. [1]  ARCH_DATA_MODEL is not set in all test scenarios, so a 
> better approach is to check the VM about to be tested.
>
> Bug report:
>     https://bugs.openjdk.java.net/browse/JDK-8167600
>
> Webrev:
>     http://cr.openjdk.java.net/~tbell/8167600/webrev.00/
>
> Testing:
>    Successful JPRT runs on all platforms.  Inspected the 
> <platform>_<arch>.product-c2-langtools_jtreg.log files to verify the 
> expected flag was used only on 32-bit VMs.

Hi Tim,

Seems a bit complicated to create a temporary javascript and execute it. 
Why not try something like:
DATA_MODEL=`${JT_JAVA}/bin/java -XshowSettings:properties -version 2>&1 
| grep sun.arch.data.model | awk '{print $3}'`
?
>
>
> Thanks in advance-
>
> Tim
>
> [1] JDK-8166648 https://bugs.openjdk.java.net/browse/JDK-8166648

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

From jan.lahoda at oracle.com  Mon Oct 17 16:08:00 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 17 Oct 2016 18:08:00 +0200
Subject: RFR 8131019: jshell tool: access javadoc from tool
Message-ID: <5804F760.5050509@oracle.com>

Hello,

This patch adds ability to show javadoc inside JShell (by showingg it on 
the second invocation of the Shift-<tab> documentation). In addition to 
jdk.jshell changes, there is a support in jdk.compiler, that is expected 
to be reused by jjs.

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

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

Any feedback is welcome!

Thanks,
     Jan

From cushon at google.com  Mon Oct 17 16:14:46 2016
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 17 Oct 2016 09:14:46 -0700
Subject: type inference regression related to JDK-8157149
Message-ID: <CAL4Qsgv6mPQWbi3VfftynR1LPTNzzn7Su0Cd5cA3C+HLJ95=Vw@mail.gmail.com>

javac started rejecting the following program between 9-ea+119 and
9-ea+120. The culprit appears to be JDK-8157149 [1][2]. Was this
intentional?

Thanks,

[1] https://bugs.openjdk.java.net/browse/JDK-8157149
[2] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/a8b7c9938b74

=== Test.java
abstract class Test {
  interface W<A> {}
  abstract <B> B f(W<B> e);
  abstract <C> C g(C b, long i);

  void h(W<Long> i) {
    g("", f(i));
  }
}
===

$ javac Test.java
...
error: method g in class Test cannot be applied to given types;
    g("", f(i));
    ^
  required: C,long
  found: String,Long
  reason: cannot infer type-variable(s) C,B
    (argument mismatch; B cannot be converted to long)
  where C,B are type-variables:
    C extends Object declared in method <C>g(C,long)
    B extends Object declared in method <B>f(W<B>)
1 error
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161017/3ca041a5/attachment.html>

From georgiy.rakov at oracle.com  Mon Oct 17 17:26:19 2016
From: georgiy.rakov at oracle.com (Georgiy Rakov)
Date: Mon, 17 Oct 2016 20:26:19 +0300
Subject: Breaking binary compatibility due to adding private method to an
	interface compiled inconsistently
Message-ID: <7241b289-b141-38ab-f088-62b7e417b698@oracle.com>

Hello Dan,

comment [1] specifies following assertion and a note:

    Adding an 'abstract', ***'private', or 'static'*** method to an
    interface does not break compatibility with preexisting binaries.

    [Note: I believe we can make this assertion because "adding a
    method" means "adding a method that will compile", presumably?
    Private and static methods can introduce errors if a reference like
    I.m()V previously resolved to an abstract/default method in a
    superinterface, and now resolves to the private/static method in I.
    But that new method won't compile if there's a method with a
    matching signature in a superinterface of I.]

Namely, the note reads:

    ... "adding a method" means "adding a method that will compile" ...

It's questionable if this is a valid point since spec should take into 
account that a method added might be resulted from inconsistent 
compilation. For instance:

1. First we compile sources A.java, B.java, Test.java presented below.

    A.java:
    interface A {
         default void same() {}
    }

    B.java:
    interface B extends A {
         //private void same() {}
    }

    Test.java:
    class Test {
         public static void main(String[] argv) {
              B i = new B(){};
              i.same();
         }
    }

2. Then we compile sources A.java, B.java presented below (toggle 
commenting 'same' method in A and B):

    A.java:
    interface A {
         //default void same() {}
    }

    B.java:
    interface B extends A {
         private void same() {}
    }


3. Then we compile source A.java presented below (returning back A class 
file as it resulted from step 1):

    A.java:
    interface A {
         default void same() {}
    }

4. Run Test.main(), this results in a run-time error:

    Exception in thread "main" java.lang.IllegalAccessError: tried to
    access method B.same()V from class Test

So adding a private method seems to cause breaking binary compatibility. 
The change between binaries resulted from step 1 and step 3 is B class 
file with a private method added, the rest of the class files are the same.

Should it be considered as a spec issue?

[1] 
https://bugs.openjdk.java.net/browse/JDK-8072872?focusedCommentId=13610992

Thank you,
Georgiy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161017/aab73f10/attachment.html>

From maurizio.cimadamore at oracle.com  Mon Oct 17 17:36:22 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 17 Oct 2016 18:36:22 +0100
Subject: type inference regression related to JDK-8157149
In-Reply-To: <CAL4Qsgv6mPQWbi3VfftynR1LPTNzzn7Su0Cd5cA3C+HLJ95=Vw@mail.gmail.com>
References: <CAL4Qsgv6mPQWbi3VfftynR1LPTNzzn7Su0Cd5cA3C+HLJ95=Vw@mail.gmail.com>
Message-ID: <c9819752-89e7-c646-6124-d8a26a335b7b@oracle.com>

I'll take a look - thanks for the report.

Maurizio

On 17/10/16 17:14, Liam Miller-Cushon wrote:
> javac started rejecting the following program between 9-ea+119 and 
> 9-ea+120. The culprit appears to be JDK-8157149 [1][2]. Was this 
> intentional?
>
> Thanks,
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8157149 
> <https://bugs.openjdk.java.net/browse/JDK-8157149>
> [2] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/a8b7c9938b74 
> <http://hg.openjdk.java.net/jdk9/dev/langtools/rev/a8b7c9938b74>
>
> === Test.java
> abstract class Test {
>   interface W<A> {}
>   abstract <B> B f(W<B> e);
>   abstract <C> C g(C b, long i);
>
>   void h(W<Long> i) {
>     g("", f(i));
>   }
> }
> ===
>
> $ javac Test.java
> ...
> error: method g in class Test cannot be applied to given types;
>     g("", f(i));
>     ^
>   required: C,long
>   found: String,Long
>   reason: cannot infer type-variable(s) C,B
>     (argument mismatch; B cannot be converted to long)
>   where C,B are type-variables:
>     C extends Object declared in method <C>g(C,long)
>     B extends Object declared in method <B>f(W<B>)
> 1 error

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

From alex.buckley at oracle.com  Mon Oct 17 18:15:06 2016
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 17 Oct 2016 11:15:06 -0700
Subject: Breaking binary compatibility due to adding private method to
	an interface compiled inconsistently
In-Reply-To: <7241b289-b141-38ab-f088-62b7e417b698@oracle.com>
References: <7241b289-b141-38ab-f088-62b7e417b698@oracle.com>
Message-ID: <5805152A.5050508@oracle.com>

The key phrase is "with preexisting binaries". Given the initial A.class 
+ B.class + Test.class, you get to make ONE change to ONE compilation 
unit that you recompile independently but inconsistently. The change you 
would like to make is adding a private method to B, but you can't make 
that change because of B's superinterface, so no independent 
recompilation is possible, and the question of whether the change is 
binary-incompatible is moot.

Alex

On 10/17/2016 10:26 AM, Georgiy Rakov wrote:
> Hello Dan,
>
> comment [1] specifies following assertion and a note:
>
>     Adding an 'abstract', ***'private', or 'static'*** method to an
>     interface does not break compatibility with preexisting binaries.
>
>     [Note: I believe we can make this assertion because "adding a
>     method" means "adding a method that will compile", presumably?
>     Private and static methods can introduce errors if a reference like
>     I.m()V previously resolved to an abstract/default method in a
>     superinterface, and now resolves to the private/static method in I.
>     But that new method won't compile if there's a method with a
>     matching signature in a superinterface of I.]
>
> Namely, the note reads:
>
>     ... "adding a method" means "adding a method that will compile" ...
>
> It's questionable if this is a valid point since spec should take into
> account that a method added might be resulted from inconsistent
> compilation. For instance:
>
> 1. First we compile sources A.java, B.java, Test.java presented below.
>
>     A.java:
>     interface A {
>          default void same() {}
>     }
>
>     B.java:
>     interface B extends A {
>          //private void same() {}
>     }
>
>     Test.java:
>     class Test {
>          public static void main(String[] argv) {
>               B i = new B(){};
>               i.same();
>          }
>     }
>
> 2. Then we compile sources A.java, B.java presented below (toggle
> commenting 'same' method in A and B):
>
>     A.java:
>     interface A {
>          //default void same() {}
>     }
>
>     B.java:
>     interface B extends A {
>          private void same() {}
>     }
>
>
> 3. Then we compile source A.java presented below (returning back A class
> file as it resulted from step 1):
>
>     A.java:
>     interface A {
>          default void same() {}
>     }
>
> 4. Run Test.main(), this results in a run-time error:
>
>     Exception in thread "main" java.lang.IllegalAccessError: tried to
>     access method B.same()V from class Test
>
> So adding a private method seems to cause breaking binary compatibility.
> The change between binaries resulted from step 1 and step 3 is B class
> file with a private method added, the rest of the class files are the same.
>
> Should it be considered as a spec issue?
>
> [1]
> https://bugs.openjdk.java.net/browse/JDK-8072872?focusedCommentId=13610992
>
> Thank you,
> Georgiy.

From jonathan.gibbons at oracle.com  Mon Oct 17 22:03:08 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 17 Oct 2016 15:03:08 -0700
Subject: RFR:
Message-ID: <58054A9C.7070003@oracle.com>

Compiler folk, build folk,

Please review this update for javac and some build files, for JEP 277.

The work supports the enhanced Deprecation attribute, and generates a 
new warning when items are referenced that are declared with 
@Deprecated(forRemoval=true), in line with the proposals in JEP 277.

The warnings are on by default, and can be suppressed with 
-Xlint:-removal or @SuppressWarnings("removal").  Because the warnings 
are on by default, and because the warnings currently show up when 
building JDK, some minor build changes are temporarily required to 
suppress the warnings that get generated during the build.

-- Jon

JEP: http://openjdk.java.net/jeps/277
JBS: https://bugs.openjdk.java.net/browse/JDK-8145471
Webrev: http://cr.openjdk.java.net/~jjg/8145471/webrev.01/

From jonathan.gibbons at oracle.com  Mon Oct 17 22:10:58 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 17 Oct 2016 15:10:58 -0700
Subject: RFR: 8145471: javac changes for enhanced deprecation
In-Reply-To: <58054A9C.7070003@oracle.com>
References: <58054A9C.7070003@oracle.com>
Message-ID: <58054C72.3040907@oracle.com>

Repeat, with subject line.

-- Jon

On 10/17/2016 03:03 PM, Jonathan Gibbons wrote:
> Compiler folk, build folk,
>
> Please review this update for javac and some build files, for JEP 277.
>
> The work supports the enhanced Deprecation attribute, and generates a 
> new warning when items are referenced that are declared with 
> @Deprecated(forRemoval=true), in line with the proposals in JEP 277.
>
> The warnings are on by default, and can be suppressed with 
> -Xlint:-removal or @SuppressWarnings("removal").  Because the warnings 
> are on by default, and because the warnings currently show up when 
> building JDK, some minor build changes are temporarily required to 
> suppress the warnings that get generated during the build.
>
> -- Jon
>
> JEP: http://openjdk.java.net/jeps/277
> JBS: https://bugs.openjdk.java.net/browse/JDK-8145471
> Webrev: http://cr.openjdk.java.net/~jjg/8145471/webrev.01/


From bangert at google.com  Tue Oct 18 00:18:40 2016
From: bangert at google.com (Julian Bangert)
Date: Tue, 18 Oct 2016 00:18:40 +0000
Subject: Question about type annotations
In-Reply-To: <CAOn4P0MW2M3b0iTnL-OeDQunT65biLTdiM6dhkS6_XSs27R21g@mail.gmail.com>
References: <CAOn4P0MW2M3b0iTnL-OeDQunT65biLTdiM6dhkS6_XSs27R21g@mail.gmail.com>
Message-ID: <CAOn4P0M82v2CoLxZeDUR9a7h6REMJHh0prPo2UTws7i8H_wK-A@mail.gmail.com>

Hello (re-sending due to moderation),

I am working on a checker based on the error-prone framework that works
with (Java 8) type annotations. The javac AST seems to be missing
annotation types for generic methods (and constructors on generic types):

// Annotation .java
package test;
import java.lang.annotation.ElementType;
import java.lang.annotation.Target;

 @Target({
    ElementType.TYPE_USE,
    ElementType.FIELD,
    ElementType.LOCAL_VARIABLE,
    ElementType.PARAMETER,
    ElementType.METHOD
  })
public interface @Annotation {}


// Generic.java
 package test;
  public class Generic {
      public static <V> void Method(V value) {
      }
  }

// Testcase.java

package test;
import java.util.List;
public class Testcase {
    void test(List<@Annotation String> list, String foo) {
        list.add(foo);
        Generic.<@Annotation String>Method(foo);
    }
}

Now call node.getMethodSelect() on the MethodInvocation AST nodes generated
by this snippet. For the first call site (list.add(foo)),
node.getMethodSelect() returns a JCFieldAccess with type

"(@test.Annotation java.lang.String)boolean" (note the annotation).

When I do the same for Generic.<@Annotation String>Method, I merely get
"(java.lang.String)void".

Is this a bug or intended behaviour? Is there a way to get annotation on
the types (besides implementing my own lookup, which might be
buggy/unelegant).

Regards,
Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161018/55fdad5a/attachment.html>

From jonathan.gibbons at oracle.com  Tue Oct 18 00:38:56 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 17 Oct 2016 17:38:56 -0700
Subject: Question about type annotations
In-Reply-To: <CAOn4P0M82v2CoLxZeDUR9a7h6REMJHh0prPo2UTws7i8H_wK-A@mail.gmail.com>
References: <CAOn4P0MW2M3b0iTnL-OeDQunT65biLTdiM6dhkS6_XSs27R21g@mail.gmail.com>
	<CAOn4P0M82v2CoLxZeDUR9a7h6REMJHh0prPo2UTws7i8H_wK-A@mail.gmail.com>
Message-ID: <58056F20.6050201@oracle.com>

As is typically the case in requests like this, it would help if you 
could post a working, stripped down example.

You're also working with javac internal objects. It would help if you 
could post an example in terms of the public API, such as is available using
     com.sun.source.*
     javax.lang.model.*

For example, if you have identified a node in an AST by a TreePath, use
     com.sun.source.util.Trees.getTypeMirror(TreePath)
and then, since TypeMirror extends AnnotatedConstruct, you can get the 
annotation mirrors.

See:
http://download.java.net/java/jdk9/docs/jdk/api/javac/tree/com/sun/source/util/Trees.html
http://download.java.net/java/jdk9/docs/api/javax/lang/model/type/TypeMirror.html
http://download.java.net/java/jdk9/docs/api/javax/lang/model/AnnotatedConstruct.html

-- Jon

On 10/17/2016 05:18 PM, Julian Bangert wrote:
> Hello (re-sending due to moderation),
>
> I am working on a checker based on the error-prone framework that 
> works with (Java 8) type annotations. The javac AST seems to be 
> missing annotation types for generic methods (and constructors on 
> generic types):
>
> // Annotation .java
> package test;
> import java.lang.annotation.ElementType;
> import java.lang.annotation.Target;
>
>  @Target({
>     ElementType.TYPE_USE,
>     ElementType.FIELD,
>     ElementType.LOCAL_VARIABLE,
>     ElementType.PARAMETER,
>     ElementType.METHOD
>   })
> public interface @Annotation {}
>
>
> // Generic.java
>  package test;
>   public class Generic {
>       public static <V> void Method(V value) {
>       }
>   }
>
> // Testcase.java
>
> package test;
> import java.util.List;
> public class Testcase {
>     void test(List<@Annotation String> list, String foo) {
>         list.add(foo);
>         Generic.<@Annotation String>Method(foo);
>     }
> }
>
> Now call node.getMethodSelect() on the MethodInvocation AST nodes 
> generated by this snippet. For the first call site (list.add(foo)),
> node.getMethodSelect() returns a JCFieldAccess with type
>
> "(@test.Annotation java.lang.String)boolean" (note the annotation).
>
> When I do the same for Generic.<@Annotation String>Method, I merely get
> "(java.lang.String)void".
>
> Is this a bug or intended behaviour? Is there a way to get annotation 
> on the types (besides implementing my own lookup, which might be 
> buggy/unelegant).
>
> Regards,
> Julian


From bangert at google.com  Tue Oct 18 00:46:28 2016
From: bangert at google.com (Julian Bangert)
Date: Tue, 18 Oct 2016 00:46:28 +0000
Subject: Question about type annotations
In-Reply-To: <58056F20.6050201@oracle.com>
References: <CAOn4P0MW2M3b0iTnL-OeDQunT65biLTdiM6dhkS6_XSs27R21g@mail.gmail.com>
	<CAOn4P0M82v2CoLxZeDUR9a7h6REMJHh0prPo2UTws7i8H_wK-A@mail.gmail.com>
	<58056F20.6050201@oracle.com>
Message-ID: <CAOn4P0MOBPDkTFc=O_0x3vsT_q2RB+u8=zh8JQj2R5DyadLWBA@mail.gmail.com>

Thanks for the quick response -- how would you prefer the stripped down
example? Should I send an error-prone testcase?

On Mon, Oct 17, 2016 at 5:38 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> As is typically the case in requests like this, it would help if you
> could post a working, stripped down example.
>
> You're also working with javac internal objects. It would help if you
> could post an example in terms of the public API, such as is available
> using
>      com.sun.source.*
>      javax.lang.model.*
>
> For example, if you have identified a node in an AST by a TreePath, use
>      com.sun.source.util.Trees.getTypeMirror(TreePath)
> and then, since TypeMirror extends AnnotatedConstruct, you can get the
> annotation mirrors.
>
> See:
>
> http://download.java.net/java/jdk9/docs/jdk/api/javac/tree/com/sun/source/util/Trees.html
>
> http://download.java.net/java/jdk9/docs/api/javax/lang/model/type/TypeMirror.html
>
> http://download.java.net/java/jdk9/docs/api/javax/lang/model/AnnotatedConstruct.html
>
> -- Jon
>
> On 10/17/2016 05:18 PM, Julian Bangert wrote:
> > Hello (re-sending due to moderation),
> >
> > I am working on a checker based on the error-prone framework that
> > works with (Java 8) type annotations. The javac AST seems to be
> > missing annotation types for generic methods (and constructors on
> > generic types):
> >
> > // Annotation .java
> > package test;
> > import java.lang.annotation.ElementType;
> > import java.lang.annotation.Target;
> >
> >  @Target({
> >     ElementType.TYPE_USE,
> >     ElementType.FIELD,
> >     ElementType.LOCAL_VARIABLE,
> >     ElementType.PARAMETER,
> >     ElementType.METHOD
> >   })
> > public interface @Annotation {}
> >
> >
> > // Generic.java
> >  package test;
> >   public class Generic {
> >       public static <V> void Method(V value) {
> >       }
> >   }
> >
> > // Testcase.java
> >
> > package test;
> > import java.util.List;
> > public class Testcase {
> >     void test(List<@Annotation String> list, String foo) {
> >         list.add(foo);
> >         Generic.<@Annotation String>Method(foo);
> >     }
> > }
> >
> > Now call node.getMethodSelect() on the MethodInvocation AST nodes
> > generated by this snippet. For the first call site (list.add(foo)),
> > node.getMethodSelect() returns a JCFieldAccess with type
> >
> > "(@test.Annotation java.lang.String)boolean" (note the annotation).
> >
> > When I do the same for Generic.<@Annotation String>Method, I merely get
> > "(java.lang.String)void".
> >
> > Is this a bug or intended behaviour? Is there a way to get annotation
> > on the types (besides implementing my own lookup, which might be
> > buggy/unelegant).
> >
> > Regards,
> > Julian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161018/4f74ab4d/attachment-0001.html>

From jonathan.gibbons at oracle.com  Tue Oct 18 01:00:51 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 17 Oct 2016 18:00:51 -0700
Subject: Question about type annotations
In-Reply-To: <CAOn4P0MOBPDkTFc=O_0x3vsT_q2RB+u8=zh8JQj2R5DyadLWBA@mail.gmail.com>
References: <CAOn4P0MW2M3b0iTnL-OeDQunT65biLTdiM6dhkS6_XSs27R21g@mail.gmail.com>
	<CAOn4P0M82v2CoLxZeDUR9a7h6REMJHh0prPo2UTws7i8H_wK-A@mail.gmail.com>
	<58056F20.6050201@oracle.com>
	<CAOn4P0MOBPDkTFc=O_0x3vsT_q2RB+u8=zh8JQj2R5DyadLWBA@mail.gmail.com>
Message-ID: <58057443.5080609@oracle.com>

A small program that parses the test case you already provided, to get 
an AST, then walks the AST, looking for selected nodes, printing out any 
relevant info.   Essentially, encapsulate this part of your message in 
demonstrable code:

 > Now call node.getMethodSelect() on the MethodInvocation AST nodes
 > generated by this snippet. For the first call site (list.add(foo)),
 > node.getMethodSelect() returns a JCFieldAccess with type
 >
 > "(@test.Annotation java.lang.String)boolean" (note the annotation).
 >
 > When I do the same for Generic.<@Annotation String>Method, I merely get
 > "(java.lang.String)void".


If (but only if) you're familiar with the javac code base, and more 
importantly, the test base, if you know of DPrinter, you might be able 
to use that to dump the AST.  In fact, something like
     java -classpath ...  DPrinter.Main -after PARSE -showTreeTypes 
source-files...

might get you pretty much all the way to a script you could post.

-- Jon


On 10/17/2016 05:46 PM, Julian Bangert wrote:
> Thanks for the quick response -- how would you prefer the stripped 
> down example? Should I send an error-prone testcase?
>
> On Mon, Oct 17, 2016 at 5:38 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     As is typically the case in requests like this, it would help if you
>     could post a working, stripped down example.
>
>     You're also working with javac internal objects. It would help if you
>     could post an example in terms of the public API, such as is
>     available using
>          com.sun.source.*
>          javax.lang.model.*
>
>     For example, if you have identified a node in an AST by a
>     TreePath, use
>          com.sun.source.util.Trees.getTypeMirror(TreePath)
>     and then, since TypeMirror extends AnnotatedConstruct, you can get the
>     annotation mirrors.
>
>     See:
>     http://download.java.net/java/jdk9/docs/jdk/api/javac/tree/com/sun/source/util/Trees.html
>     http://download.java.net/java/jdk9/docs/api/javax/lang/model/type/TypeMirror.html
>     http://download.java.net/java/jdk9/docs/api/javax/lang/model/AnnotatedConstruct.html
>
>     -- Jon
>
>     On 10/17/2016 05:18 PM, Julian Bangert wrote:
>     > Hello (re-sending due to moderation),
>     >
>     > I am working on a checker based on the error-prone framework that
>     > works with (Java 8) type annotations. The javac AST seems to be
>     > missing annotation types for generic methods (and constructors on
>     > generic types):
>     >
>     > // Annotation .java
>     > package test;
>     > import java.lang.annotation.ElementType;
>     > import java.lang.annotation.Target;
>     >
>     >  @Target({
>     >     ElementType.TYPE_USE,
>     >     ElementType.FIELD,
>     >     ElementType.LOCAL_VARIABLE,
>     >     ElementType.PARAMETER,
>     >     ElementType.METHOD
>     >   })
>     > public interface @Annotation {}
>     >
>     >
>     > // Generic.java
>     >  package test;
>     >   public class Generic {
>     >       public static <V> void Method(V value) {
>     >       }
>     >   }
>     >
>     > // Testcase.java
>     >
>     > package test;
>     > import java.util.List;
>     > public class Testcase {
>     >     void test(List<@Annotation String> list, String foo) {
>     >         list.add(foo);
>     >         Generic.<@Annotation String>Method(foo);
>     >     }
>     > }
>     >
>     > Now call node.getMethodSelect() on the MethodInvocation AST nodes
>     > generated by this snippet. For the first call site (list.add(foo)),
>     > node.getMethodSelect() returns a JCFieldAccess with type
>     >
>     > "(@test.Annotation java.lang.String)boolean" (note the annotation).
>     >
>     > When I do the same for Generic.<@Annotation String>Method, I
>     merely get
>     > "(java.lang.String)void".
>     >
>     > Is this a bug or intended behaviour? Is there a way to get
>     annotation
>     > on the types (besides implementing my own lookup, which might be
>     > buggy/unelegant).
>     >
>     > Regards,
>     > Julian
>

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

From tim.bell at oracle.com  Tue Oct 18 04:44:58 2016
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 17 Oct 2016 21:44:58 -0700
Subject: RFR: 8167600 jib make run-test for langtools and intermittent
	failures on windows-x86
In-Reply-To: <8e98febd-958d-2145-9d82-baa69393881f@oracle.com>
References: <3eff9f30-7c35-4213-cfde-9c86a7f4633c@oracle.com>
	<8e98febd-958d-2145-9d82-baa69393881f@oracle.com>
Message-ID: <b091ea51-ce71-5516-5efa-aaeda84462e3@oracle.com>

Magnus:

Thank you for the feedback.  See below:


> On 2016-10-15 03:23, Tim Bell wrote:
>> Please review this rework of the langtools/test/Makefile fix done in
>> 8166648. [1]  ARCH_DATA_MODEL is not set in all test scenarios, so a
>> better approach is to check the VM about to be tested.
>>
>> Bug report:
>>     https://bugs.openjdk.java.net/browse/JDK-8167600
>>
>> Webrev:
>>     http://cr.openjdk.java.net/~tbell/8167600/webrev.00/
>>
>> Testing:
>>    Successful JPRT runs on all platforms.  Inspected the
>> <platform>_<arch>.product-c2-langtools_jtreg.log files to verify the
>> expected flag was used only on 32-bit VMs.
>
> Hi Tim,
>
> Seems a bit complicated to create a temporary javascript and execute it.
> Why not try something like:
> DATA_MODEL=`${JT_JAVA}/bin/java -XshowSettings:properties -version 2>&1
> | grep sun.arch.data.model | awk '{print $3}'`
> ?

Excellent idea.  This is much simpler.

Here is an updated webrev.  Tested as before, by submitting a JPRT job 
and inspecting the .log files.

   http://cr.openjdk.java.net/~tbell/8167600/webrev.01/


Tim


>> Thanks in advance-
>>
>> Tim
>>
>> [1] JDK-8166648 https://bugs.openjdk.java.net/browse/JDK-8166648
>


From maurizio.cimadamore at oracle.com  Tue Oct 18 10:27:34 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 18 Oct 2016 11:27:34 +0100
Subject: type inference regression related to JDK-8157149
In-Reply-To: <c9819752-89e7-c646-6124-d8a26a335b7b@oracle.com>
References: <CAL4Qsgv6mPQWbi3VfftynR1LPTNzzn7Su0Cd5cA3C+HLJ95=Vw@mail.gmail.com>
	<c9819752-89e7-c646-6124-d8a26a335b7b@oracle.com>
Message-ID: <9dcb31aa-f965-cf35-a6ef-3f13c8e8eeb4@oracle.com>

You are right - JDK-8157149 introduced a regression in the treatment of 
propagation of poly expressions to outer contexts. This is caused by the 
fact that the propagation logic doesn't take this bullet from 18.5.2 
into account:

"Otherwise, if R ? is an inference variable ?, and one of the following 
is true:

     T is a reference type, but is not a wildcard-parameterized type, 
and either i) B2 contains a bound of one of the forms ? = S or S <: ?, 
where S is a wildcard-parameterized type, or ii) B2 contains two bounds 
of the forms S1 <: ? and S2 <: ?, where S1 and S2 have supertypes that 
are two different parameterizations of the same generic class or interface.

     T is a parameterization of a generic class or interface, G, and B2 
contains a bound of one of the forms ? = S or S <: ?, where there exists 
no type of the form G<...> that is a supertype of S, but the raw type 
|G<...>| is a supertype of S.

*    T is a primitive type, and one of the primitive wrapper classes 
mentioned in ?5.1.7 is an instantiation, upper bound, or lower bound for 
? in B2.*

then ? is resolved in B2, and where the capture of the resulting 
instantiation of ? is U, the constraint formula ?U ? T? is reduced and 
incorporated with B2. "

And as a result, javac tries to propagate the nested constraint f(i) -> 
long into the outer context, which is incorrect, because the type of 
f(i) needs to be eagerly instantiated.

Filed https://bugs.openjdk.java.net/browse/JDK-8168134

Thanks again

Maurizio

On 17/10/16 18:36, Maurizio Cimadamore wrote:
>
> I'll take a look - thanks for the report.
>
> Maurizio
>
> On 17/10/16 17:14, Liam Miller-Cushon wrote:
>> javac started rejecting the following program between 9-ea+119 and 
>> 9-ea+120. The culprit appears to be JDK-8157149 [1][2]. Was this 
>> intentional?
>>
>> Thanks,
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8157149 
>> <https://bugs.openjdk.java.net/browse/JDK-8157149>
>> [2] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/a8b7c9938b74 
>> <http://hg.openjdk.java.net/jdk9/dev/langtools/rev/a8b7c9938b74>
>>
>> === Test.java
>> abstract class Test {
>>   interface W<A> {}
>>   abstract <B> B f(W<B> e);
>>   abstract <C> C g(C b, long i);
>>
>>   void h(W<Long> i) {
>>     g("", f(i));
>>   }
>> }
>> ===
>>
>> $ javac Test.java
>> ...
>> error: method g in class Test cannot be applied to given types;
>>     g("", f(i));
>>     ^
>>   required: C,long
>>   found: String,Long
>>   reason: cannot infer type-variable(s) C,B
>>     (argument mismatch; B cannot be converted to long)
>>   where C,B are type-variables:
>>     C extends Object declared in method <C>g(C,long)
>>     B extends Object declared in method <B>f(W<B>)
>> 1 error
>

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

From jan.lahoda at oracle.com  Tue Oct 18 13:58:08 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 18 Oct 2016 15:58:08 +0200
Subject: RFR: 8145471: javac changes for enhanced deprecation
In-Reply-To: <58054C72.3040907@oracle.com>
References: <58054A9C.7070003@oracle.com> <58054C72.3040907@oracle.com>
Message-ID: <58062A70.3040208@oracle.com>

Overall, seem OK to me. Two comments:
-is the change in make/CompileJavaModules.gmk really needed given the 
adjusted JAVAC_WARNINGS in make/common/SetupJavaCompilers.gmk?

-the reliance on literal "true" in TypeEnter seems suspicious to me. 
What if the value of the attribute is a compile-time constant? I suspect 
this may be non-trivial to fix, so no strict need to fix that under this 
patch, but I think we should have a good idea how we want this fixed, 
and there should be a JBS entry filled for that.

Jan

On 18.10.2016 00:10, Jonathan Gibbons wrote:
> Repeat, with subject line.
>
> -- Jon
>
> On 10/17/2016 03:03 PM, Jonathan Gibbons wrote:
>> Compiler folk, build folk,
>>
>> Please review this update for javac and some build files, for JEP 277.
>>
>> The work supports the enhanced Deprecation attribute, and generates a
>> new warning when items are referenced that are declared with
>> @Deprecated(forRemoval=true), in line with the proposals in JEP 277.
>>
>> The warnings are on by default, and can be suppressed with
>> -Xlint:-removal or @SuppressWarnings("removal").  Because the warnings
>> are on by default, and because the warnings currently show up when
>> building JDK, some minor build changes are temporarily required to
>> suppress the warnings that get generated during the build.
>>
>> -- Jon
>>
>> JEP: http://openjdk.java.net/jeps/277
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145471
>> Webrev: http://cr.openjdk.java.net/~jjg/8145471/webrev.01/
>

From georgiy.rakov at oracle.com  Tue Oct 18 14:55:09 2016
From: georgiy.rakov at oracle.com (Georgiy Rakov)
Date: Tue, 18 Oct 2016 17:55:09 +0300
Subject: Breaking binary compatibility due to adding private method to an
	interface compiled inconsistently
In-Reply-To: <5805152A.5050508@oracle.com>
References: <7241b289-b141-38ab-f088-62b7e417b698@oracle.com>
	<5805152A.5050508@oracle.com>
Message-ID: <cb332fc3-9221-9333-0ef5-54d3eb3d6cb9@oracle.com>

I'd like to emphasize that in this case preexisting binaries supplied to 
JVM during Test.main execution doesn't change and if they don't then, 
according to my understanding, it doesn't matter how the modified B 
class-file was produced.

Thank you,
Georgiy.

On 17.10.2016 21:15, Alex Buckley wrote:
> The key phrase is "with preexisting binaries". Given the initial 
> A.class + B.class + Test.class, you get to make ONE change to ONE 
> compilation unit that you recompile independently but inconsistently. 
> The change you would like to make is adding a private method to B, but 
> you can't make that change because of B's superinterface, so no 
> independent recompilation is possible, and the question of whether the 
> change is binary-incompatible is moot.
>
> Alex
>
> On 10/17/2016 10:26 AM, Georgiy Rakov wrote:
>> Hello Dan,
>>
>> comment [1] specifies following assertion and a note:
>>
>>     Adding an 'abstract', ***'private', or 'static'*** method to an
>>     interface does not break compatibility with preexisting binaries.
>>
>>     [Note: I believe we can make this assertion because "adding a
>>     method" means "adding a method that will compile", presumably?
>>     Private and static methods can introduce errors if a reference like
>>     I.m()V previously resolved to an abstract/default method in a
>>     superinterface, and now resolves to the private/static method in I.
>>     But that new method won't compile if there's a method with a
>>     matching signature in a superinterface of I.]
>>
>> Namely, the note reads:
>>
>>     ... "adding a method" means "adding a method that will compile" ...
>>
>> It's questionable if this is a valid point since spec should take into
>> account that a method added might be resulted from inconsistent
>> compilation. For instance:
>>
>> 1. First we compile sources A.java, B.java, Test.java presented below.
>>
>>     A.java:
>>     interface A {
>>          default void same() {}
>>     }
>>
>>     B.java:
>>     interface B extends A {
>>          //private void same() {}
>>     }
>>
>>     Test.java:
>>     class Test {
>>          public static void main(String[] argv) {
>>               B i = new B(){};
>>               i.same();
>>          }
>>     }
>>
>> 2. Then we compile sources A.java, B.java presented below (toggle
>> commenting 'same' method in A and B):
>>
>>     A.java:
>>     interface A {
>>          //default void same() {}
>>     }
>>
>>     B.java:
>>     interface B extends A {
>>          private void same() {}
>>     }
>>
>>
>> 3. Then we compile source A.java presented below (returning back A class
>> file as it resulted from step 1):
>>
>>     A.java:
>>     interface A {
>>          default void same() {}
>>     }
>>
>> 4. Run Test.main(), this results in a run-time error:
>>
>>     Exception in thread "main" java.lang.IllegalAccessError: tried to
>>     access method B.same()V from class Test
>>
>> So adding a private method seems to cause breaking binary compatibility.
>> The change between binaries resulted from step 1 and step 3 is B class
>> file with a private method added, the rest of the class files are the 
>> same.
>>
>> Should it be considered as a spec issue?
>>
>> [1]
>> https://bugs.openjdk.java.net/browse/JDK-8072872?focusedCommentId=13610992 
>>
>>
>> Thank you,
>> Georgiy.


From bangert at google.com  Tue Oct 18 21:34:58 2016
From: bangert at google.com (Julian Bangert)
Date: Tue, 18 Oct 2016 21:34:58 +0000
Subject: Question about type annotations
In-Reply-To: <58057443.5080609@oracle.com>
References: <CAOn4P0MW2M3b0iTnL-OeDQunT65biLTdiM6dhkS6_XSs27R21g@mail.gmail.com>
	<CAOn4P0M82v2CoLxZeDUR9a7h6REMJHh0prPo2UTws7i8H_wK-A@mail.gmail.com>
	<58056F20.6050201@oracle.com>
	<CAOn4P0MOBPDkTFc=O_0x3vsT_q2RB+u8=zh8JQj2R5DyadLWBA@mail.gmail.com>
	<58057443.5080609@oracle.com>
Message-ID: <CAOn4P0MxvwDUNvcEOsOxTj=17wixyfCHkLKGtwxVnt-Bcfz4fg@mail.gmail.com>

Ok I hacked up something quick (see attachments). When running the tool, I
get
/usr/local/google/home/bangert/16/jdk-type-test/Annotation.java
/usr/local/google/home/bangert/16/jdk-type-test/Testcase.java
/usr/local/google/home/bangert/16/jdk-type-test/Generic.java
CompilationUnit:
/usr/local/google/home/bangert/16/jdk-type-test/Annotation.java
CompilationUnit:
/usr/local/google/home/bangert/16/jdk-type-test/Testcase.java


 MethodInvocation: super()
MethodSelect: JCTree.type: ()void
MethodSelect: Trees.type: ()void


 MethodInvocation: list.add(foo)
MethodSelect: JCTree.type: (@test.Annotation java.lang.String)boolean
MethodSelect: Trees.type: (java.lang.String)boolean


 MethodInvocation: Generic.<@Annotation() String>Method(foo)
MethodSelect: JCTree.type: (java.lang.String)void
MethodSelect: Trees.type: (java.lang.String)void
CompilationUnit:
/usr/local/google/home/bangert/16/jdk-type-test/Generic.java


 MethodInvocation: super()
MethodSelect: JCTree.type: ()void
MethodSelect: Trees.type: ()void


The trees API always strips metadata (which is unfortunate, but other parts
of error-prone already depend on JCType), so the annotations are always
gone. However, when looking at the JCTree.type field, the class method on a
generic has annotations on the substituted type parameter, whereas it
doesn't for the generic method call. The same applies to constructors.

Thanks again,
Julian
On Mon, Oct 17, 2016 at 6:00 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> A small program that parses the test case you already provided, to get an
> AST, then walks the AST, looking for selected nodes, printing out any
> relevant info.   Essentially, encapsulate this part of your message in
> demonstrable code:
>
>
> > Now call node.getMethodSelect() on the MethodInvocation AST nodes
> > generated by this snippet. For the first call site (list.add(foo)),
> > node.getMethodSelect() returns a JCFieldAccess with type
> >
> > "(@test.Annotation java.lang.String)boolean"
> <(@test.Annotationjava.lang.String)boolean> (note the annotation).
> >
> > When I do the same for Generic.<@Annotation String>Method, I merely get
> > "(java.lang.String)void".
>
>
> If (but only if) you're familiar with the javac code base, and more
> importantly, the test base, if you know of DPrinter, you might be able to
> use that to dump the AST.  In fact, something like
>     java -classpath ...  DPrinter.Main -after PARSE -showTreeTypes
> source-files...
>
> might get you pretty much all the way to a script you could post.
>
> -- Jon
>
>
>
> On 10/17/2016 05:46 PM, Julian Bangert wrote:
>
> Thanks for the quick response -- how would you prefer the stripped down
> example? Should I send an error-prone testcase?
>
> On Mon, Oct 17, 2016 at 5:38 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
> As is typically the case in requests like this, it would help if you
> could post a working, stripped down example.
>
> You're also working with javac internal objects. It would help if you
> could post an example in terms of the public API, such as is available
> using
>      com.sun.source.*
>      javax.lang.model.*
>
> For example, if you have identified a node in an AST by a TreePath, use
>      com.sun.source.util.Trees.getTypeMirror(TreePath)
> and then, since TypeMirror extends AnnotatedConstruct, you can get the
> annotation mirrors.
>
> See:
>
> http://download.java.net/java/jdk9/docs/jdk/api/javac/tree/com/sun/source/util/Trees.html
>
> http://download.java.net/java/jdk9/docs/api/javax/lang/model/type/TypeMirror.html
>
> http://download.java.net/java/jdk9/docs/api/javax/lang/model/AnnotatedConstruct.html
>
> -- Jon
>
> On 10/17/2016 05:18 PM, Julian Bangert wrote:
> > Hello (re-sending due to moderation),
> >
> > I am working on a checker based on the error-prone framework that
> > works with (Java 8) type annotations. The javac AST seems to be
> > missing annotation types for generic methods (and constructors on
> > generic types):
> >
> > // Annotation .java
> > package test;
> > import java.lang.annotation.ElementType;
> > import java.lang.annotation.Target;
> >
> >  @Target({
> >     ElementType.TYPE_USE,
> >     ElementType.FIELD,
> >     ElementType.LOCAL_VARIABLE,
> >     ElementType.PARAMETER,
> >     ElementType.METHOD
> >   })
> > public interface @Annotation {}
> >
> >
> > // Generic.java
> >  package test;
> >   public class Generic {
> >       public static <V> void Method(V value) {
> >       }
> >   }
> >
> > // Testcase.java
> >
> > package test;
> > import java.util.List;
> > public class Testcase {
> >     void test(List<@Annotation String> list, String foo) {
> >         list.add(foo);
> >         Generic.<@Annotation String>Method(foo);
> >     }
> > }
> >
> > Now call node.getMethodSelect() on the MethodInvocation AST nodes
> > generated by this snippet. For the first call site (list.add(foo)),
> > node.getMethodSelect() returns a JCFieldAccess with type
> >
> > "(@test.Annotation java.lang.String)boolean"
> <(@test.Annotationjava.lang.String)boolean> (note the annotation).
> >
> > When I do the same for Generic.<@Annotation String>Method, I merely get
> > "(java.lang.String)void".
> >
> > Is this a bug or intended behaviour? Is there a way to get annotation
> > on the types (besides implementing my own lookup, which might be
> > buggy/unelegant).
> >
> > Regards,
> > Julian
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161018/ed4be2e5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Generic.java
Type: text/x-java
Size: 114 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161018/ed4be2e5/Generic-0001.java>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Annotation.java
Type: text/x-java
Size: 332 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161018/ed4be2e5/Annotation-0001.java>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Testcase.java
Type: text/x-java
Size: 199 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161018/ed4be2e5/Testcase-0001.java>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Reproduce.java
Type: text/x-java
Size: 2125 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161018/ed4be2e5/Reproduce-0001.java>

From alex.buckley at oracle.com  Tue Oct 18 22:52:46 2016
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 18 Oct 2016 15:52:46 -0700
Subject: Breaking binary compatibility due to adding private method to
	an interface compiled inconsistently
In-Reply-To: <cb332fc3-9221-9333-0ef5-54d3eb3d6cb9@oracle.com>
References: <7241b289-b141-38ab-f088-62b7e417b698@oracle.com>
	<5805152A.5050508@oracle.com>
	<cb332fc3-9221-9333-0ef5-54d3eb3d6cb9@oracle.com>
Message-ID: <5806A7BE.5050609@oracle.com>

I understand that you're going from executing A.class + B.class + 
Test.class to executing A.class + B.class[MODIFIED] + Test.class. 
However, because B.class[MODIFIED] was produced by a non-trivial 
sequence of recompilations, it's tantamount to a hex-edited version of 
the initial B.class. Ch.13 doesn't describe the binary compatibility of 
hex edits, only the binary compatibility of a single compilable change 
to a single compilation unit. I agree with Dan that the binary 
compatibility of adding a private method to an interface inherently 
assumes you immediately compile the interface.

Alex

On 10/18/2016 7:55 AM, Georgiy Rakov wrote:
> I'd like to emphasize that in this case preexisting binaries supplied to
> JVM during Test.main execution doesn't change and if they don't then,
> according to my understanding, it doesn't matter how the modified B
> class-file was produced.
>
> Thank you,
> Georgiy.
>
> On 17.10.2016 21:15, Alex Buckley wrote:
>> The key phrase is "with preexisting binaries". Given the initial
>> A.class + B.class + Test.class, you get to make ONE change to ONE
>> compilation unit that you recompile independently but inconsistently.
>> The change you would like to make is adding a private method to B, but
>> you can't make that change because of B's superinterface, so no
>> independent recompilation is possible, and the question of whether the
>> change is binary-incompatible is moot.
>>
>> Alex
>>
>> On 10/17/2016 10:26 AM, Georgiy Rakov wrote:
>>> Hello Dan,
>>>
>>> comment [1] specifies following assertion and a note:
>>>
>>>     Adding an 'abstract', ***'private', or 'static'*** method to an
>>>     interface does not break compatibility with preexisting binaries.
>>>
>>>     [Note: I believe we can make this assertion because "adding a
>>>     method" means "adding a method that will compile", presumably?
>>>     Private and static methods can introduce errors if a reference like
>>>     I.m()V previously resolved to an abstract/default method in a
>>>     superinterface, and now resolves to the private/static method in I.
>>>     But that new method won't compile if there's a method with a
>>>     matching signature in a superinterface of I.]
>>>
>>> Namely, the note reads:
>>>
>>>     ... "adding a method" means "adding a method that will compile" ...
>>>
>>> It's questionable if this is a valid point since spec should take into
>>> account that a method added might be resulted from inconsistent
>>> compilation. For instance:
>>>
>>> 1. First we compile sources A.java, B.java, Test.java presented below.
>>>
>>>     A.java:
>>>     interface A {
>>>          default void same() {}
>>>     }
>>>
>>>     B.java:
>>>     interface B extends A {
>>>          //private void same() {}
>>>     }
>>>
>>>     Test.java:
>>>     class Test {
>>>          public static void main(String[] argv) {
>>>               B i = new B(){};
>>>               i.same();
>>>          }
>>>     }
>>>
>>> 2. Then we compile sources A.java, B.java presented below (toggle
>>> commenting 'same' method in A and B):
>>>
>>>     A.java:
>>>     interface A {
>>>          //default void same() {}
>>>     }
>>>
>>>     B.java:
>>>     interface B extends A {
>>>          private void same() {}
>>>     }
>>>
>>>
>>> 3. Then we compile source A.java presented below (returning back A class
>>> file as it resulted from step 1):
>>>
>>>     A.java:
>>>     interface A {
>>>          default void same() {}
>>>     }
>>>
>>> 4. Run Test.main(), this results in a run-time error:
>>>
>>>     Exception in thread "main" java.lang.IllegalAccessError: tried to
>>>     access method B.same()V from class Test
>>>
>>> So adding a private method seems to cause breaking binary compatibility.
>>> The change between binaries resulted from step 1 and step 3 is B class
>>> file with a private method added, the rest of the class files are the
>>> same.
>>>
>>> Should it be considered as a spec issue?
>>>
>>> [1]
>>> https://bugs.openjdk.java.net/browse/JDK-8072872?focusedCommentId=13610992
>>>
>>>
>>> Thank you,
>>> Georgiy.
>

From jonathan.gibbons at oracle.com  Wed Oct 19 00:00:02 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 18 Oct 2016 17:00:02 -0700
Subject: RFR: 8145471: javac changes for enhanced deprecation
In-Reply-To: <58062A70.3040208@oracle.com>
References: <58054A9C.7070003@oracle.com> <58054C72.3040907@oracle.com>
	<58062A70.3040208@oracle.com>
Message-ID: <5806B782.9070704@oracle.com>

Jan,

You're correct, the change in make/CompileJavaModules.gmk is not 
necessary. Well spotted.
The changes to the other make/ file are still necessary for the time 
being, to suppress warnings until the sources can be updated with 
appropriate use of @SuppressWarnings.

The use of the literal "true" in TypeEnter is definitely undesirable, 
and I think you are correct in that there does not seem to be an easy 
fix without changing how javac handles deprecation. Generally, I think 
that this would mean that we would mean we would have to defer all 
deprecation reporting until after annotation processing, when we can 
reliably determine the evaluation of the @Deprecated annotation, and 
therefore which sort of warning to generate. This is complicated by the 
fact that the conditions for deprecated warnings and removal warnings 
are slightly different. I will file a JBS entry.

-- Jon

On 10/18/2016 06:58 AM, Jan Lahoda wrote:
> Overall, seem OK to me. Two comments:
> -is the change in make/CompileJavaModules.gmk really needed given the 
> adjusted JAVAC_WARNINGS in make/common/SetupJavaCompilers.gmk?
>
> -the reliance on literal "true" in TypeEnter seems suspicious to me. 
> What if the value of the attribute is a compile-time constant? I 
> suspect this may be non-trivial to fix, so no strict need to fix that 
> under this patch, but I think we should have a good idea how we want 
> this fixed, and there should be a JBS entry filled for that.
>
> Jan
>
> On 18.10.2016 00:10, Jonathan Gibbons wrote:
>> Repeat, with subject line.
>>
>> -- Jon
>>
>> On 10/17/2016 03:03 PM, Jonathan Gibbons wrote:
>>> Compiler folk, build folk,
>>>
>>> Please review this update for javac and some build files, for JEP 277.
>>>
>>> The work supports the enhanced Deprecation attribute, and generates a
>>> new warning when items are referenced that are declared with
>>> @Deprecated(forRemoval=true), in line with the proposals in JEP 277.
>>>
>>> The warnings are on by default, and can be suppressed with
>>> -Xlint:-removal or @SuppressWarnings("removal").  Because the warnings
>>> are on by default, and because the warnings currently show up when
>>> building JDK, some minor build changes are temporarily required to
>>> suppress the warnings that get generated during the build.
>>>
>>> -- Jon
>>>
>>> JEP: http://openjdk.java.net/jeps/277
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145471
>>> Webrev: http://cr.openjdk.java.net/~jjg/8145471/webrev.01/
>>


From david.lloyd at redhat.com  Wed Oct 19 12:16:08 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 19 Oct 2016 07:16:08 -0500
Subject: Breaking binary compatibility due to adding private method to an
	interface compiled inconsistently
In-Reply-To: <5806A7BE.5050609@oracle.com>
References: <7241b289-b141-38ab-f088-62b7e417b698@oracle.com>
	<5805152A.5050508@oracle.com>
	<cb332fc3-9221-9333-0ef5-54d3eb3d6cb9@oracle.com>
	<5806A7BE.5050609@oracle.com>
Message-ID: <699713a4-4b48-d989-198b-60ed64f5c0c4@redhat.com>

Forgive me, but that's quite an incredible response.  How many 
recompilations equals a hex edit?  You can just as well say that Ch.13 
doesn't apply to any changes ever because any recompilation is 
tantamount to a hex edit, which is clearly counter to the intent of the 
chapter.

It is completely reasonable to have two separate libraries in a 
configuration that matches the description, and to have one of those 
libraries be updated to a new version, which would cause the effect 
quite trivially from the user's perspective.  This is not an obscure 
case at all.  All he did was compact this into a simple 
easy-to-understand test case, which yes might be more obscure but also 
serves to illustrate the problem more clearly.

On 10/18/2016 05:52 PM, Alex Buckley wrote:
> I understand that you're going from executing A.class + B.class +
> Test.class to executing A.class + B.class[MODIFIED] + Test.class.
> However, because B.class[MODIFIED] was produced by a non-trivial
> sequence of recompilations, it's tantamount to a hex-edited version of
> the initial B.class. Ch.13 doesn't describe the binary compatibility of
> hex edits, only the binary compatibility of a single compilable change
> to a single compilation unit. I agree with Dan that the binary
> compatibility of adding a private method to an interface inherently
> assumes you immediately compile the interface.
>
> Alex
>
> On 10/18/2016 7:55 AM, Georgiy Rakov wrote:
>> I'd like to emphasize that in this case preexisting binaries supplied to
>> JVM during Test.main execution doesn't change and if they don't then,
>> according to my understanding, it doesn't matter how the modified B
>> class-file was produced.
>>
>> Thank you,
>> Georgiy.
>>
>> On 17.10.2016 21:15, Alex Buckley wrote:
>>> The key phrase is "with preexisting binaries". Given the initial
>>> A.class + B.class + Test.class, you get to make ONE change to ONE
>>> compilation unit that you recompile independently but inconsistently.
>>> The change you would like to make is adding a private method to B, but
>>> you can't make that change because of B's superinterface, so no
>>> independent recompilation is possible, and the question of whether the
>>> change is binary-incompatible is moot.
>>>
>>> Alex
>>>
>>> On 10/17/2016 10:26 AM, Georgiy Rakov wrote:
>>>> Hello Dan,
>>>>
>>>> comment [1] specifies following assertion and a note:
>>>>
>>>>     Adding an 'abstract', ***'private', or 'static'*** method to an
>>>>     interface does not break compatibility with preexisting binaries.
>>>>
>>>>     [Note: I believe we can make this assertion because "adding a
>>>>     method" means "adding a method that will compile", presumably?
>>>>     Private and static methods can introduce errors if a reference like
>>>>     I.m()V previously resolved to an abstract/default method in a
>>>>     superinterface, and now resolves to the private/static method in I.
>>>>     But that new method won't compile if there's a method with a
>>>>     matching signature in a superinterface of I.]
>>>>
>>>> Namely, the note reads:
>>>>
>>>>     ... "adding a method" means "adding a method that will compile" ...
>>>>
>>>> It's questionable if this is a valid point since spec should take into
>>>> account that a method added might be resulted from inconsistent
>>>> compilation. For instance:
>>>>
>>>> 1. First we compile sources A.java, B.java, Test.java presented below.
>>>>
>>>>     A.java:
>>>>     interface A {
>>>>          default void same() {}
>>>>     }
>>>>
>>>>     B.java:
>>>>     interface B extends A {
>>>>          //private void same() {}
>>>>     }
>>>>
>>>>     Test.java:
>>>>     class Test {
>>>>          public static void main(String[] argv) {
>>>>               B i = new B(){};
>>>>               i.same();
>>>>          }
>>>>     }
>>>>
>>>> 2. Then we compile sources A.java, B.java presented below (toggle
>>>> commenting 'same' method in A and B):
>>>>
>>>>     A.java:
>>>>     interface A {
>>>>          //default void same() {}
>>>>     }
>>>>
>>>>     B.java:
>>>>     interface B extends A {
>>>>          private void same() {}
>>>>     }
>>>>
>>>>
>>>> 3. Then we compile source A.java presented below (returning back A
>>>> class
>>>> file as it resulted from step 1):
>>>>
>>>>     A.java:
>>>>     interface A {
>>>>          default void same() {}
>>>>     }
>>>>
>>>> 4. Run Test.main(), this results in a run-time error:
>>>>
>>>>     Exception in thread "main" java.lang.IllegalAccessError: tried to
>>>>     access method B.same()V from class Test
>>>>
>>>> So adding a private method seems to cause breaking binary
>>>> compatibility.
>>>> The change between binaries resulted from step 1 and step 3 is B class
>>>> file with a private method added, the rest of the class files are the
>>>> same.
>>>>
>>>> Should it be considered as a spec issue?
>>>>
>>>> [1]
>>>> https://bugs.openjdk.java.net/browse/JDK-8072872?focusedCommentId=13610992
>>>>
>>>>
>>>>
>>>> Thank you,
>>>> Georgiy.
>>

-- 
- DML

From magnus.ihse.bursie at oracle.com  Wed Oct 19 13:00:43 2016
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 19 Oct 2016 15:00:43 +0200
Subject: RFR: 8167600 jib make run-test for langtools and intermittent
	failures on windows-x86
In-Reply-To: <b091ea51-ce71-5516-5efa-aaeda84462e3@oracle.com>
References: <3eff9f30-7c35-4213-cfde-9c86a7f4633c@oracle.com>
	<8e98febd-958d-2145-9d82-baa69393881f@oracle.com>
	<b091ea51-ce71-5516-5efa-aaeda84462e3@oracle.com>
Message-ID: <e3e10252-4d80-e91b-98d9-c7f544668e4f@oracle.com>

On 2016-10-18 06:44, Tim Bell wrote:
> Magnus:
>
> Thank you for the feedback.  See below:
>
>
>> On 2016-10-15 03:23, Tim Bell wrote:
>>> Please review this rework of the langtools/test/Makefile fix done in
>>> 8166648. [1]  ARCH_DATA_MODEL is not set in all test scenarios, so a
>>> better approach is to check the VM about to be tested.
>>>
>>> Bug report:
>>>     https://bugs.openjdk.java.net/browse/JDK-8167600
>>>
>>> Webrev:
>>>     http://cr.openjdk.java.net/~tbell/8167600/webrev.00/
>>>
>>> Testing:
>>>    Successful JPRT runs on all platforms.  Inspected the
>>> <platform>_<arch>.product-c2-langtools_jtreg.log files to verify the
>>> expected flag was used only on 32-bit VMs.
>>
>> Hi Tim,
>>
>> Seems a bit complicated to create a temporary javascript and execute it.
>> Why not try something like:
>> DATA_MODEL=`${JT_JAVA}/bin/java -XshowSettings:properties -version 2>&1
>> | grep sun.arch.data.model | awk '{print $3}'`
>> ?
>
> Excellent idea.  This is much simpler.
>
> Here is an updated webrev.  Tested as before, by submitting a JPRT job 
> and inspecting the .log files.
>
>   http://cr.openjdk.java.net/~tbell/8167600/webrev.01/
Looks good to me.

/Magnus

>
>
> Tim
>
>
>>> Thanks in advance-
>>>
>>> Tim
>>>
>>> [1] JDK-8166648 https://bugs.openjdk.java.net/browse/JDK-8166648
>>
>

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

From alex.buckley at oracle.com  Wed Oct 19 17:54:00 2016
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 19 Oct 2016 10:54:00 -0700
Subject: Breaking binary compatibility due to adding private method to
	an interface compiled inconsistently
In-Reply-To: <699713a4-4b48-d989-198b-60ed64f5c0c4@redhat.com>
References: <7241b289-b141-38ab-f088-62b7e417b698@oracle.com>	<5805152A.5050508@oracle.com>	<cb332fc3-9221-9333-0ef5-54d3eb3d6cb9@oracle.com>	<5806A7BE.5050609@oracle.com>
	<699713a4-4b48-d989-198b-60ed64f5c0c4@redhat.com>
Message-ID: <5807B338.1090300@oracle.com>

I am uneasy about ch.13's treatment of private methods in general -- see 
JDK-8043703 -- but the particular case outlined below would never be a 
binary-compatible change because it's not a single change to a single 
compilation unit. The intent of ch.13 is to cover inconsistent separate 
compilation of one codebase where a recompilation is actually possible, 
not to cover consistent separate compilation of multiple codebases that 
are then combined.

Alex

On 10/19/2016 5:16 AM, David M. Lloyd wrote:
> Forgive me, but that's quite an incredible response.  How many
> recompilations equals a hex edit?  You can just as well say that Ch.13
> doesn't apply to any changes ever because any recompilation is
> tantamount to a hex edit, which is clearly counter to the intent of the
> chapter.
>
> It is completely reasonable to have two separate libraries in a
> configuration that matches the description, and to have one of those
> libraries be updated to a new version, which would cause the effect
> quite trivially from the user's perspective.  This is not an obscure
> case at all.  All he did was compact this into a simple
> easy-to-understand test case, which yes might be more obscure but also
> serves to illustrate the problem more clearly.
>
> On 10/18/2016 05:52 PM, Alex Buckley wrote:
>> I understand that you're going from executing A.class + B.class +
>> Test.class to executing A.class + B.class[MODIFIED] + Test.class.
>> However, because B.class[MODIFIED] was produced by a non-trivial
>> sequence of recompilations, it's tantamount to a hex-edited version of
>> the initial B.class. Ch.13 doesn't describe the binary compatibility of
>> hex edits, only the binary compatibility of a single compilable change
>> to a single compilation unit. I agree with Dan that the binary
>> compatibility of adding a private method to an interface inherently
>> assumes you immediately compile the interface.
>>
>> Alex
>>
>> On 10/18/2016 7:55 AM, Georgiy Rakov wrote:
>>> I'd like to emphasize that in this case preexisting binaries supplied to
>>> JVM during Test.main execution doesn't change and if they don't then,
>>> according to my understanding, it doesn't matter how the modified B
>>> class-file was produced.
>>>
>>> Thank you,
>>> Georgiy.
>>>
>>> On 17.10.2016 21:15, Alex Buckley wrote:
>>>> The key phrase is "with preexisting binaries". Given the initial
>>>> A.class + B.class + Test.class, you get to make ONE change to ONE
>>>> compilation unit that you recompile independently but inconsistently.
>>>> The change you would like to make is adding a private method to B, but
>>>> you can't make that change because of B's superinterface, so no
>>>> independent recompilation is possible, and the question of whether the
>>>> change is binary-incompatible is moot.
>>>>
>>>> Alex
>>>>
>>>> On 10/17/2016 10:26 AM, Georgiy Rakov wrote:
>>>>> Hello Dan,
>>>>>
>>>>> comment [1] specifies following assertion and a note:
>>>>>
>>>>>     Adding an 'abstract', ***'private', or 'static'*** method to an
>>>>>     interface does not break compatibility with preexisting binaries.
>>>>>
>>>>>     [Note: I believe we can make this assertion because "adding a
>>>>>     method" means "adding a method that will compile", presumably?
>>>>>     Private and static methods can introduce errors if a reference
>>>>> like
>>>>>     I.m()V previously resolved to an abstract/default method in a
>>>>>     superinterface, and now resolves to the private/static method
>>>>> in I.
>>>>>     But that new method won't compile if there's a method with a
>>>>>     matching signature in a superinterface of I.]
>>>>>
>>>>> Namely, the note reads:
>>>>>
>>>>>     ... "adding a method" means "adding a method that will compile"
>>>>> ...
>>>>>
>>>>> It's questionable if this is a valid point since spec should take into
>>>>> account that a method added might be resulted from inconsistent
>>>>> compilation. For instance:
>>>>>
>>>>> 1. First we compile sources A.java, B.java, Test.java presented below.
>>>>>
>>>>>     A.java:
>>>>>     interface A {
>>>>>          default void same() {}
>>>>>     }
>>>>>
>>>>>     B.java:
>>>>>     interface B extends A {
>>>>>          //private void same() {}
>>>>>     }
>>>>>
>>>>>     Test.java:
>>>>>     class Test {
>>>>>          public static void main(String[] argv) {
>>>>>               B i = new B(){};
>>>>>               i.same();
>>>>>          }
>>>>>     }
>>>>>
>>>>> 2. Then we compile sources A.java, B.java presented below (toggle
>>>>> commenting 'same' method in A and B):
>>>>>
>>>>>     A.java:
>>>>>     interface A {
>>>>>          //default void same() {}
>>>>>     }
>>>>>
>>>>>     B.java:
>>>>>     interface B extends A {
>>>>>          private void same() {}
>>>>>     }
>>>>>
>>>>>
>>>>> 3. Then we compile source A.java presented below (returning back A
>>>>> class
>>>>> file as it resulted from step 1):
>>>>>
>>>>>     A.java:
>>>>>     interface A {
>>>>>          default void same() {}
>>>>>     }
>>>>>
>>>>> 4. Run Test.main(), this results in a run-time error:
>>>>>
>>>>>     Exception in thread "main" java.lang.IllegalAccessError: tried to
>>>>>     access method B.same()V from class Test
>>>>>
>>>>> So adding a private method seems to cause breaking binary
>>>>> compatibility.
>>>>> The change between binaries resulted from step 1 and step 3 is B class
>>>>> file with a private method added, the rest of the class files are the
>>>>> same.
>>>>>
>>>>> Should it be considered as a spec issue?
>>>>>
>>>>> [1]
>>>>> https://bugs.openjdk.java.net/browse/JDK-8072872?focusedCommentId=13610992
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thank you,
>>>>> Georgiy.
>>>
>

From tim.bell at oracle.com  Wed Oct 19 21:47:43 2016
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 19 Oct 2016 14:47:43 -0700
Subject: RFR: 8145471: javac changes for enhanced deprecation
In-Reply-To: <5806B782.9070704@oracle.com>
References: <58054A9C.7070003@oracle.com> <58054C72.3040907@oracle.com>
	<58062A70.3040208@oracle.com> <5806B782.9070704@oracle.com>
Message-ID: <d75f63b0-6c8f-4381-6ba1-cfa6498e66c1@oracle.com>

Jon:

make/CompileJavaModules.gmk		no comments
make/common/SetupJavaCompilers.gmk	no comments

Thumbs up on the build changes.

Tim



On 10/18/16 17:00, Jonathan Gibbons wrote:
> Jan,
>
> You're correct, the change in make/CompileJavaModules.gmk is not
> necessary. Well spotted.
> The changes to the other make/ file are still necessary for the time
> being, to suppress warnings until the sources can be updated with
> appropriate use of @SuppressWarnings.
>
> The use of the literal "true" in TypeEnter is definitely undesirable,
> and I think you are correct in that there does not seem to be an easy
> fix without changing how javac handles deprecation. Generally, I think
> that this would mean that we would mean we would have to defer all
> deprecation reporting until after annotation processing, when we can
> reliably determine the evaluation of the @Deprecated annotation, and
> therefore which sort of warning to generate. This is complicated by the
> fact that the conditions for deprecated warnings and removal warnings
> are slightly different. I will file a JBS entry.
>
> -- Jon
>
> On 10/18/2016 06:58 AM, Jan Lahoda wrote:
>> Overall, seem OK to me. Two comments:
>> -is the change in make/CompileJavaModules.gmk really needed given the
>> adjusted JAVAC_WARNINGS in make/common/SetupJavaCompilers.gmk?
>>
>> -the reliance on literal "true" in TypeEnter seems suspicious to me.
>> What if the value of the attribute is a compile-time constant? I
>> suspect this may be non-trivial to fix, so no strict need to fix that
>> under this patch, but I think we should have a good idea how we want
>> this fixed, and there should be a JBS entry filled for that.
>>
>> Jan
>>
>> On 18.10.2016 00:10, Jonathan Gibbons wrote:
>>> Repeat, with subject line.
>>>
>>> -- Jon
>>>
>>> On 10/17/2016 03:03 PM, Jonathan Gibbons wrote:
>>>> Compiler folk, build folk,
>>>>
>>>> Please review this update for javac and some build files, for JEP 277.
>>>>
>>>> The work supports the enhanced Deprecation attribute, and generates a
>>>> new warning when items are referenced that are declared with
>>>> @Deprecated(forRemoval=true), in line with the proposals in JEP 277.
>>>>
>>>> The warnings are on by default, and can be suppressed with
>>>> -Xlint:-removal or @SuppressWarnings("removal").  Because the warnings
>>>> are on by default, and because the warnings currently show up when
>>>> building JDK, some minor build changes are temporarily required to
>>>> suppress the warnings that get generated during the build.
>>>>
>>>> -- Jon
>>>>
>>>> JEP: http://openjdk.java.net/jeps/277
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145471
>>>> Webrev: http://cr.openjdk.java.net/~jjg/8145471/webrev.01/
>>>
>


From jonathan.gibbons at oracle.com  Wed Oct 19 23:17:41 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 19 Oct 2016 16:17:41 -0700
Subject: RFR: 8168343: 3 javac tests fail when run on an exploded image
Message-ID: <5807FF15.8040407@oracle.com>

Please review some small changes to 3 javac tests, to allow them to run 
on an exploded image.

The "official" way to run tests is using a full image (as resulting from 
"make images").
But it is also highly desirable for developers to be able to skip the 
final stage of building
images, and to be able to run tests on an "exploded image" (as resulting 
from "make"
or "make default").

3 langtools tests fail in this case. Two of the failures are because of 
assumptions about
the presence of an image file, and can easily be fixed to accommodate an 
exploded image.
The other test fails because of an issue in the security manager's 
policy files. JDK-8155858.
This test is "fixed" for now by allowing it to be skipped when run on an 
exploded image.

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

-- Jon



From joe.darcy at oracle.com  Wed Oct 19 23:27:35 2016
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 19 Oct 2016 16:27:35 -0700
Subject: RFR: 8168343: 3 javac tests fail when run on an exploded image
In-Reply-To: <5807FF15.8040407@oracle.com>
References: <5807FF15.8040407@oracle.com>
Message-ID: <58080167.3010608@oracle.com>

Looks fine Jon; cheers,

-Joe

On 10/19/2016 4:17 PM, Jonathan Gibbons wrote:
> Please review some small changes to 3 javac tests, to allow them to 
> run on an exploded image.
>
> The "official" way to run tests is using a full image (as resulting 
> from "make images").
> But it is also highly desirable for developers to be able to skip the 
> final stage of building
> images, and to be able to run tests on an "exploded image" (as 
> resulting from "make"
> or "make default").
>
> 3 langtools tests fail in this case. Two of the failures are because 
> of assumptions about
> the presence of an image file, and can easily be fixed to accommodate 
> an exploded image.
> The other test fails because of an issue in the security manager's 
> policy files. JDK-8155858.
> This test is "fixed" for now by allowing it to be skipped when run on 
> an exploded image.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8168343
> Webrev: http://cr.openjdk.java.net/~jjg/8168343/webrev.00/
>
> -- Jon
>
>


From jonathan.gibbons at oracle.com  Fri Oct 21 01:31:53 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 20 Oct 2016 18:31:53 -0700
Subject: RFR: 8145471: javac changes for enhanced deprecation
In-Reply-To: <5806B782.9070704@oracle.com>
References: <58054A9C.7070003@oracle.com>
	<58054C72.3040907@oracle.com>	<58062A70.3040208@oracle.com>
	<5806B782.9070704@oracle.com>
Message-ID: <58097009.2090503@oracle.com>



On 10/18/2016 05:00 PM, Jonathan Gibbons wrote:
> Jan,
>
> You're correct, the change in make/CompileJavaModules.gmk is not 
> necessary. Well spotted.
> The changes to the other make/ file are still necessary for the time 
> being, to suppress warnings until the sources can be updated with 
> appropriate use of @SuppressWarnings.
>
> The use of the literal "true" in TypeEnter is definitely undesirable, 
> and I think you are correct in that there does not seem to be an easy 
> fix without changing how javac handles deprecation. Generally, I think 
> that this would mean that we would mean we would have to defer all 
> deprecation reporting until after annotation processing, when we can 
> reliably determine the evaluation of the @Deprecated annotation, and 
> therefore which sort of warning to generate. This is complicated by 
> the fact that the conditions for deprecated warnings and removal 
> warnings are slightly different. I will file a JBS entry.

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

>
> -- Jon
>
> On 10/18/2016 06:58 AM, Jan Lahoda wrote:
>> Overall, seem OK to me. Two comments:
>> -is the change in make/CompileJavaModules.gmk really needed given the 
>> adjusted JAVAC_WARNINGS in make/common/SetupJavaCompilers.gmk?
>>
>> -the reliance on literal "true" in TypeEnter seems suspicious to me. 
>> What if the value of the attribute is a compile-time constant? I 
>> suspect this may be non-trivial to fix, so no strict need to fix that 
>> under this patch, but I think we should have a good idea how we want 
>> this fixed, and there should be a JBS entry filled for that.
>>
>> Jan
>>
>> On 18.10.2016 00:10, Jonathan Gibbons wrote:
>>> Repeat, with subject line.
>>>
>>> -- Jon
>>>
>>> On 10/17/2016 03:03 PM, Jonathan Gibbons wrote:
>>>> Compiler folk, build folk,
>>>>
>>>> Please review this update for javac and some build files, for JEP 277.
>>>>
>>>> The work supports the enhanced Deprecation attribute, and generates a
>>>> new warning when items are referenced that are declared with
>>>> @Deprecated(forRemoval=true), in line with the proposals in JEP 277.
>>>>
>>>> The warnings are on by default, and can be suppressed with
>>>> -Xlint:-removal or @SuppressWarnings("removal").  Because the warnings
>>>> are on by default, and because the warnings currently show up when
>>>> building JDK, some minor build changes are temporarily required to
>>>> suppress the warnings that get generated during the build.
>>>>
>>>> -- Jon
>>>>
>>>> JEP: http://openjdk.java.net/jeps/277
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145471
>>>> Webrev: http://cr.openjdk.java.net/~jjg/8145471/webrev.01/
>>>
>


From cushon at google.com  Fri Oct 21 02:57:27 2016
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 20 Oct 2016 19:57:27 -0700
Subject: crash in flow analysis
Message-ID: <CAL4Qsgu1hC2VEWAFgZoQMEuyBp65TSz+ri8j3A21kBsonMPaBQ@mail.gmail.com>

The following snippet crashes javac 9ea+140. Is this a known issue?

The tree is copied a couple of times during speculative attribution, and
the break target isn't getting set for one of the copies.

abstract class Test {
  abstract void f(Runnable r);

  private void g() {
    f(
        () ->
            new Runnable() {
              public void run() {
                switch (42) {
                  default:
                    break;
                }
              }
            }.run());
  }
}
...
java.lang.AssertionError
        at com.sun.tools.javac.util.Assert.error(jdk.compiler at 9-ea
/Assert.java:155)
        at com.sun.tools.javac.util.Assert.check(jdk.compiler at 9-ea
/Assert.java:46)
        at
com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitMethodDef(jdk.compiler at 9-ea
/Flow.java:524)
        at
com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(jdk.compiler at 9-ea
/JCTree.java:852)
        at com.sun.tools.javac.tree.TreeScanner.scan(jdk.compiler at 9-ea
/TreeScanner.java:49)
        at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(jdk.compiler at 9-ea
/Flow.java:404)
        at
com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitClassDef(jdk.compiler at 9-ea
/Flow.java:494)
        at
com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(jdk.compiler at 9-ea
/JCTree.java:760)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161020/3e0d7e5b/attachment.html>

From maurizio.cimadamore at oracle.com  Fri Oct 21 13:02:01 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 21 Oct 2016 14:02:01 +0100
Subject: crash in flow analysis
In-Reply-To: <CAL4Qsgu1hC2VEWAFgZoQMEuyBp65TSz+ri8j3A21kBsonMPaBQ@mail.gmail.com>
References: <CAL4Qsgu1hC2VEWAFgZoQMEuyBp65TSz+ri8j3A21kBsonMPaBQ@mail.gmail.com>
Message-ID: <bbd7f258-6b9c-d30a-84a1-cfce3c85276b@oracle.com>

Thanks for the pointer. I've created this:

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

Maurizio


On 21/10/16 03:57, Liam Miller-Cushon wrote:
> The following snippet crashes javac 9ea+140. Is this a known issue?
>
> The tree is copied a couple of times during speculative attribution, 
> and the break target isn't getting set for one of the copies.
>
> abstract class Test {
>   abstract void f(Runnable r);
>
>   private void g() {
>     f(
>         () ->
>             new Runnable() {
>               public void run() {
>                 switch (42) {
>                   default:
>                     break;
>                 }
>               }
>             }.run());
>   }
> }
> ...
> java.lang.AssertionError
>         at 
> com.sun.tools.javac.util.Assert.error(jdk.compiler at 9-ea/Assert.java:155)
>         at 
> com.sun.tools.javac.util.Assert.check(jdk.compiler at 9-ea/Assert.java:46)
>         at 
> com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitMethodDef(jdk.compiler at 9-ea/Flow.java:524)
>         at 
> com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(jdk.compiler at 9-ea/JCTree.java:852)
>         at 
> com.sun.tools.javac.tree.TreeScanner.scan(jdk.compiler at 9-ea/TreeScanner.java:49)
>         at 
> com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(jdk.compiler at 9-ea/Flow.java:404)
>         at 
> com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitClassDef(jdk.compiler at 9-ea/Flow.java:494)
>         at 
> com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(jdk.compiler at 9-ea/JCTree.java:760)


From joe.darcy at oracle.com  Fri Oct 21 23:45:18 2016
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 21 Oct 2016 16:45:18 -0700
Subject: JDK 9 RFR of JDK-8168499: Workaround intermittent failures of
	IntersectionTargetTypeTest.java
Message-ID: <42849577-2471-bb98-f940-1952a3f7e760@oracle.com>

Hello,

The test

tools/javac/lambda/intersection/IntersectionTargetTypeTest.java

is seen to fail intermittently on win32. The suspected cause is the same 
as in other intermittent langtools failures on that platform (JDK-8163999).

Please review the patch below to address this.

Thanks,

-Joe


--- 
a/test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java 
Thu Oct 20 16:31:42 2016 -0700
+++ 
b/test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java 
Fri Oct 21 15:32:50 2016 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2012, 2015, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2012, 2016, 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
@@ -26,6 +26,7 @@
   * @bug 8002099 8010822
   * @summary Add support for intersection types in cast expression
   * @modules jdk.compiler/com.sun.tools.javac.util
+ * @run main/othervm IntersectionTargetTypeTest
   */

  import com.sun.source.util.JavacTask;



From amy.lu at oracle.com  Sat Oct 22 04:02:51 2016
From: amy.lu at oracle.com (Amy Lu)
Date: Sat, 22 Oct 2016 12:02:51 +0800
Subject: JDK 9 RFR of JDK-8168499: Workaround intermittent failures of
	IntersectionTargetTypeTest.java
In-Reply-To: <42849577-2471-bb98-f940-1952a3f7e760@oracle.com>
References: <42849577-2471-bb98-f940-1952a3f7e760@oracle.com>
Message-ID: <83bb4b9f-24e0-231a-3074-f534bc503ec6@oracle.com>

Looks fine.

(But I'm not an official reviewer.)

Thanks,
Amy

On 10/22/16 7:45 AM, joe darcy wrote:
> Hello,
>
> The test
>
> tools/javac/lambda/intersection/IntersectionTargetTypeTest.java
>
> is seen to fail intermittently on win32. The suspected cause is the 
> same as in other intermittent langtools failures on that platform 
> (JDK-8163999).
>
> Please review the patch below to address this.
>
> Thanks,
>
> -Joe
>
>
> --- 
> a/test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java 
> Thu Oct 20 16:31:42 2016 -0700
> +++ 
> b/test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java 
> Fri Oct 21 15:32:50 2016 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2012, 2015, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2012, 2016, 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
> @@ -26,6 +26,7 @@
>   * @bug 8002099 8010822
>   * @summary Add support for intersection types in cast expression
>   * @modules jdk.compiler/com.sun.tools.javac.util
> + * @run main/othervm IntersectionTargetTypeTest
>   */
>
>  import com.sun.source.util.JavacTask;
>
>


From robert.field at oracle.com  Sat Oct 22 05:06:32 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 21 Oct 2016 22:06:32 -0700
Subject: JDK 9 RFR of JDK-8168499: Workaround intermittent failures of
	IntersectionTargetTypeTest.java
In-Reply-To: <42849577-2471-bb98-f940-1952a3f7e760@oracle.com>
References: <42849577-2471-bb98-f940-1952a3f7e760@oracle.com>
Message-ID: <4E3DB8B2-074D-4F0B-9F25-866846105E0C@oracle.com>

Thumbs up

-Robert

> On Oct 21, 2016, at 4:45 PM, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> The test
> 
> tools/javac/lambda/intersection/IntersectionTargetTypeTest.java
> 
> is seen to fail intermittently on win32. The suspected cause is the same as in other intermittent langtools failures on that platform (JDK-8163999).
> 
> Please review the patch below to address this.
> 
> Thanks,
> 
> -Joe
> 
> 
> --- a/test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java Thu Oct 20 16:31:42 2016 -0700
> +++ b/test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java Fri Oct 21 15:32:50 2016 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2012, 2015, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2012, 2016, 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
> @@ -26,6 +26,7 @@
>  * @bug 8002099 8010822
>  * @summary Add support for intersection types in cast expression
>  * @modules jdk.compiler/com.sun.tools.javac.util
> + * @run main/othervm IntersectionTargetTypeTest
>  */
> 
> import com.sun.source.util.JavacTask;
> 
> 


From bsrbnd at gmail.com  Sat Oct 22 16:05:01 2016
From: bsrbnd at gmail.com (bsrbnd)
Date: Sat, 22 Oct 2016 18:05:01 +0200
Subject: [PATCH] 8147527: Non-optimal code generated for postfix unary
	operators
In-Reply-To: <CAEgw74A6RLjAH0knfYwmqWx_CrLpR8xQBuy+c4ucC6SaAPXqog@mail.gmail.com>
References: <CAEgw74A6RLjAH0knfYwmqWx_CrLpR8xQBuy+c4ucC6SaAPXqog@mail.gmail.com>
Message-ID: <CAEgw74AokHc6yyQjFqTi4wW2-4rTBUcjeH2n6cerO74hv4n_4Q@mail.gmail.com>

Hi,

Next is a probably better patch (derived from issue 8143388 changeset)
that handles also "this, this$0, ..." in addition to the existing
"super" handling. It optimizes the both cases ("this" and "super")
described in issue 8147527.
Notice that "thisDollar" could be part of the "Names" class if necessary.

Bernard

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
@@ -2218,8 +2218,10 @@
                 return builder.build(rval);
         }
         Name name = TreeInfo.name(rval);
-        if (name == names._super)
+        Name thisDollar = names.fromString(names._this + "$");
+        if (name != null && (name == names._super || name ==
names._this || name.startsWith(thisDollar))) {
             return builder.build(rval);
+        }
         VarSymbol var =
             new VarSymbol(FINAL|SYNTHETIC,
                           names.fromString(


2016-10-10 13:45 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
> Hi,
>
> Consider the following example slightly modified from issue 8147527
> description to incorporate an assignment operator and an inner class
> which are both of them involved in the optimization process:
>
> class Issue8147527 {
>     Integer i=0;
>     private Integer test() {
>         this.i += 3;
>         for (; i<5; this.i++);
>         return this.i++;
>     }
>
>     Integer j=10;
>     class Inner {
>         private Integer test() {
>             return Issue8147527.this.j++;
>         }
>     }
>
>     public static void main(String[] args) {
>         Issue8147527 self = new Issue8147527();
>         System.out.println(self.test());
>         System.out.println(self.i);
>
>         Inner in = self.new Inner();
>         System.out.println(in.test());
>         System.out.println(self.j);
>     }
> }
>
> The following patch omits "this" for the special case of a
> select-expression used as an lvalue.
> Thus we had before optimization:
>
>   private java.lang.Integer test();
>     Code:
>        0: aload_0
>        1: astore_1
>        2: aload_1
>        3: aload_1
>        4: getfield      #3                  // Field i:Ljava/lang/Integer;
>        7: invokevirtual #5                  // Method
> java/lang/Integer.intValue:()I
>       10: iconst_3
>       11: iadd
>       12: invokestatic  #2                  // Method
> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>       15: dup_x1
>       16: putfield      #3                  // Field i:Ljava/lang/Integer;
>
> And after optimization, we have:
>
>   private java.lang.Integer test();
>     Code:
>        0: aload_0
>        1: aload_0
>        2: getfield      #3                  // Field i:Ljava/lang/Integer;
>        5: invokevirtual #5                  // Method
> java/lang/Integer.intValue:()I
>        8: iconst_3
>        9: iadd
>       10: invokestatic  #2                  // Method
> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>       13: putfield      #3                  // Field i:Ljava/lang/Integer;
>
> I've run all javac tests and it seems quite good.
> Notice that I haven't checked the "super" case yet, waiting for any
> feedback about the first optimization.
>
> Regards,
> Bernard
>
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> @@ -2253,6 +2253,7 @@
>          case SELECT: {
>              final JCFieldAccess s = (JCFieldAccess)lval;
>              Symbol lid = TreeInfo.symbol(s.selected);
> +            if (lid != null && lid.name.equals(names._this)) return
> builder.build(make.Ident(s.sym));
>              if (lid != null && lid.kind == TYP) return builder.build(lval);
>              return abstractRval(s.selected, new TreeBuilder() {
>                      public JCExpression build(final JCExpression selected) {

From maurizio.cimadamore at oracle.com  Sat Oct 22 17:57:59 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Sat, 22 Oct 2016 18:57:59 +0100
Subject: JDK 9 RFR of JDK-8168499: Workaround intermittent failures of
	IntersectionTargetTypeTest.java
In-Reply-To: <42849577-2471-bb98-f940-1952a3f7e760@oracle.com>
References: <42849577-2471-bb98-f940-1952a3f7e760@oracle.com>
Message-ID: <cdcd4192-9a77-2917-57d1-382752295741@oracle.com>

Hi,
the fix should address the immediate problem, but I'm not sure that 
memory is the culprit here. I've been able to run all tests in 
test/tools/javac/lambda (512 tests including several combo ones) using a 
shared VM and only 64M of heap, which is way less than the default used 
in a typical test run. To profile the test run I passed the -verbose:gc 
option to the vm used by jtreg using the -vmoption and noted no 
significant leak during the execution of tests in this folder. So, while 
I believe that this tests ends up often with an intermittent failure, I 
haven't been able to find evidence of a leak.

Maurizio


On 22/10/16 00:45, joe darcy wrote:
> Hello,
>
> The test
>
> tools/javac/lambda/intersection/IntersectionTargetTypeTest.java
>
> is seen to fail intermittently on win32. The suspected cause is the 
> same as in other intermittent langtools failures on that platform 
> (JDK-8163999).
>
> Please review the patch below to address this.
>
> Thanks,
>
> -Joe
>
>
> --- 
> a/test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java 
> Thu Oct 20 16:31:42 2016 -0700
> +++ 
> b/test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java 
> Fri Oct 21 15:32:50 2016 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2012, 2015, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2012, 2016, 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
> @@ -26,6 +26,7 @@
>   * @bug 8002099 8010822
>   * @summary Add support for intersection types in cast expression
>   * @modules jdk.compiler/com.sun.tools.javac.util
> + * @run main/othervm IntersectionTargetTypeTest
>   */
>
>  import com.sun.source.util.JavacTask;
>
>


From cushon at google.com  Sun Oct 23 03:15:10 2016
From: cushon at google.com (Liam Miller-Cushon)
Date: Sat, 22 Oct 2016 20:15:10 -0700
Subject: spec clarification: wildcard array element signature
Message-ID: <CAL4QsgsBXbM=+XkSnvWxFgsYssPtk9m=p=hKnTG1MccAZDeK+A@mail.gmail.com>

When javac compiles the following program, it writes field i's signature as
"LA<[*>.I;".

I don't think the grammar in JVMS 4.7.9.1 allows for the element type of an
array to be a wildcard. Is that a spec bug?

class A<X> { class I {} }
class Test {
  class B<Y> extends A<Y[]> {}
  B<?>.I i;
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161022/e2102d25/attachment.html>

From erik.joelsson at oracle.com  Mon Oct 24 09:58:11 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 24 Oct 2016 11:58:11 +0200
Subject: RFR: 8167600 jib make run-test for langtools and intermittent
	failures on windows-x86
In-Reply-To: <e3e10252-4d80-e91b-98d9-c7f544668e4f@oracle.com>
References: <3eff9f30-7c35-4213-cfde-9c86a7f4633c@oracle.com>
	<8e98febd-958d-2145-9d82-baa69393881f@oracle.com>
	<b091ea51-ce71-5516-5efa-aaeda84462e3@oracle.com>
	<e3e10252-4d80-e91b-98d9-c7f544668e4f@oracle.com>
Message-ID: <4103fd2b-97d5-d606-e269-039c429d62b6@oracle.com>

Hello,

Isn't it the sun.arch.data.model of TESTJAVA that we are actually 
interested in?

/Erik

On 2016-10-19 15:00, Magnus Ihse Bursie wrote:
> On 2016-10-18 06:44, Tim Bell wrote:
>> Magnus:
>>
>> Thank you for the feedback.  See below:
>>
>>
>>> On 2016-10-15 03:23, Tim Bell wrote:
>>>> Please review this rework of the langtools/test/Makefile fix done in
>>>> 8166648. [1]  ARCH_DATA_MODEL is not set in all test scenarios, so a
>>>> better approach is to check the VM about to be tested.
>>>>
>>>> Bug report:
>>>> https://bugs.openjdk.java.net/browse/JDK-8167600
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~tbell/8167600/webrev.00/
>>>>
>>>> Testing:
>>>>    Successful JPRT runs on all platforms.  Inspected the
>>>> <platform>_<arch>.product-c2-langtools_jtreg.log files to verify the
>>>> expected flag was used only on 32-bit VMs.
>>>
>>> Hi Tim,
>>>
>>> Seems a bit complicated to create a temporary javascript and execute 
>>> it.
>>> Why not try something like:
>>> DATA_MODEL=`${JT_JAVA}/bin/java -XshowSettings:properties -version 2>&1
>>> | grep sun.arch.data.model | awk '{print $3}'`
>>> ?
>>
>> Excellent idea.  This is much simpler.
>>
>> Here is an updated webrev.  Tested as before, by submitting a JPRT 
>> job and inspecting the .log files.
>>
>> http://cr.openjdk.java.net/~tbell/8167600/webrev.01/
> Looks good to me.
>
> /Magnus
>
>>
>>
>> Tim
>>
>>
>>>> Thanks in advance-
>>>>
>>>> Tim
>>>>
>>>> [1] JDK-8166648 https://bugs.openjdk.java.net/browse/JDK-8166648
>>>
>>
>


From bsrbnd at gmail.com  Mon Oct 24 11:34:27 2016
From: bsrbnd at gmail.com (bsrbnd)
Date: Mon, 24 Oct 2016 13:34:27 +0200
Subject: [PATCH] 8147527: Non-optimal code generated for postfix unary
	operators
In-Reply-To: <CAEgw74AokHc6yyQjFqTi4wW2-4rTBUcjeH2n6cerO74hv4n_4Q@mail.gmail.com>
References: <CAEgw74A6RLjAH0knfYwmqWx_CrLpR8xQBuy+c4ucC6SaAPXqog@mail.gmail.com>
	<CAEgw74AokHc6yyQjFqTi4wW2-4rTBUcjeH2n6cerO74hv4n_4Q@mail.gmail.com>
Message-ID: <CAEgw74Ay_78UxGG8uLz6vBCZ4QALB=hP26PtqRDRpo_a-y4Y5A@mail.gmail.com>

Hi,

This issue is definitly very strange...
Examining deeply (with javap) my last patch, I came to the conclusion
that the changeset for issue 8143388 is perhaps wrong.
Consider the following example:

class Issue8147527 extends Parent {
    public static void main(String[] args) {
        Issue8147527 self = new Issue8147527();
        self.testAll();
    }

    private void testAll() {
        System.out.println(test());
        System.out.println(i);

        Inner in = new Inner();
        System.out.println(in.test());
        System.out.println(i);

        System.out.println(testParent());
        System.out.println(super.i);

        System.out.println(in.testParent());
        System.out.println(super.i);
    }

    Integer i=0;
    private Integer test() {
        return this.i++;
    }

    class Inner {
        private Integer test() {
            return Issue8147527.this.i++;
        }
        private Integer testParent() {
            return Issue8147527.super.i++;
        }
    }

    private Integer testParent() {
        return super.i++;
    }
}

class Parent {
    protected Integer i=10;
}

Running it gives the following output:
0
1
1
2
10
11
11
11

If I rollback issue 8143388 changeset, I get the following output;
last line looks better (I think):
0
1
1
2
10
11
11
12

Examining the generated code of "Inner" (I added a comment surrounded
with !!!), we had:

  private java.lang.Integer testParent();
    Code:
       0: aload_0
       1: getfield      #3                  // Field this$0:LIssue8147527;
       4: invokestatic  #8                  // Method
Issue8147527.access$201:(LIssue8147527;)Ljava/lang/Integer;
       7: astore_1                          // !!! REFERENCE TO VALUE
OF Field Parent.i:Ljava/lang/Integer; !!!
       8: aload_0
       9: getfield      #3                  // Field this$0:LIssue8147527;
      12: astore_3
      13: aload_3
      14: aload_3
      15: getfield      #5                  // Field
Issue8147527.i:Ljava/lang/Integer;
      18: invokevirtual #6                  // Method
java/lang/Integer.intValue:()I
      21: iconst_1
      22: iadd
      23: invokestatic  #7                  // Method
java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
      26: dup_x1
      27: putfield      #5                  // Field
Issue8147527.i:Ljava/lang/Integer;
      30: astore_2
      31: aload_1                           // !!! REFERENCE TO VALUE
OF Field Parent.i:Ljava/lang/Integer; !!!
      32: areturn

And rollbacking issue 8143388 changeset, we have (which looks better, I think):

  private java.lang.Integer testParent();
    Code:
       0: aload_0
       1: getfield      #3                  // Field this$0:LIssue8147527;
       4: astore_1
       5: aload_1
       6: getfield      #8                  // Field
Parent.i:Ljava/lang/Integer;
       9: astore_2
      10: aload_1
      11: aload_1
      12: getfield      #8                  // Field
Parent.i:Ljava/lang/Integer;
      15: invokevirtual #6                  // Method
java/lang/Integer.intValue:()I
      18: iconst_1
      19: iadd
      20: invokestatic  #7                  // Method
java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
      23: dup_x1
      24: putfield      #8                  // Field
Parent.i:Ljava/lang/Integer;
      27: astore_3
      28: aload_2
      29: areturn

Is issue 8143388 changeset really correct and harmless?

Thanks,
Bernard


2016-10-22 18:05 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
> Hi,
>
> Next is a probably better patch (derived from issue 8143388 changeset)
> that handles also "this, this$0, ..." in addition to the existing
> "super" handling. It optimizes the both cases ("this" and "super")
> described in issue 8147527.
> Notice that "thisDollar" could be part of the "Names" class if necessary.
>
> Bernard
>
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> @@ -2218,8 +2218,10 @@
>                  return builder.build(rval);
>          }
>          Name name = TreeInfo.name(rval);
> -        if (name == names._super)
> +        Name thisDollar = names.fromString(names._this + "$");
> +        if (name != null && (name == names._super || name ==
> names._this || name.startsWith(thisDollar))) {
>              return builder.build(rval);
> +        }
>          VarSymbol var =
>              new VarSymbol(FINAL|SYNTHETIC,
>                            names.fromString(
>
>
> 2016-10-10 13:45 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>> Hi,
>>
>> Consider the following example slightly modified from issue 8147527
>> description to incorporate an assignment operator and an inner class
>> which are both of them involved in the optimization process:
>>
>> class Issue8147527 {
>>     Integer i=0;
>>     private Integer test() {
>>         this.i += 3;
>>         for (; i<5; this.i++);
>>         return this.i++;
>>     }
>>
>>     Integer j=10;
>>     class Inner {
>>         private Integer test() {
>>             return Issue8147527.this.j++;
>>         }
>>     }
>>
>>     public static void main(String[] args) {
>>         Issue8147527 self = new Issue8147527();
>>         System.out.println(self.test());
>>         System.out.println(self.i);
>>
>>         Inner in = self.new Inner();
>>         System.out.println(in.test());
>>         System.out.println(self.j);
>>     }
>> }
>>
>> The following patch omits "this" for the special case of a
>> select-expression used as an lvalue.
>> Thus we had before optimization:
>>
>>   private java.lang.Integer test();
>>     Code:
>>        0: aload_0
>>        1: astore_1
>>        2: aload_1
>>        3: aload_1
>>        4: getfield      #3                  // Field i:Ljava/lang/Integer;
>>        7: invokevirtual #5                  // Method
>> java/lang/Integer.intValue:()I
>>       10: iconst_3
>>       11: iadd
>>       12: invokestatic  #2                  // Method
>> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>>       15: dup_x1
>>       16: putfield      #3                  // Field i:Ljava/lang/Integer;
>>
>> And after optimization, we have:
>>
>>   private java.lang.Integer test();
>>     Code:
>>        0: aload_0
>>        1: aload_0
>>        2: getfield      #3                  // Field i:Ljava/lang/Integer;
>>        5: invokevirtual #5                  // Method
>> java/lang/Integer.intValue:()I
>>        8: iconst_3
>>        9: iadd
>>       10: invokestatic  #2                  // Method
>> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>>       13: putfield      #3                  // Field i:Ljava/lang/Integer;
>>
>> I've run all javac tests and it seems quite good.
>> Notice that I haven't checked the "super" case yet, waiting for any
>> feedback about the first optimization.
>>
>> Regards,
>> Bernard
>>
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>> @@ -2253,6 +2253,7 @@
>>          case SELECT: {
>>              final JCFieldAccess s = (JCFieldAccess)lval;
>>              Symbol lid = TreeInfo.symbol(s.selected);
>> +            if (lid != null && lid.name.equals(names._this)) return
>> builder.build(make.Ident(s.sym));
>>              if (lid != null && lid.kind == TYP) return builder.build(lval);
>>              return abstractRval(s.selected, new TreeBuilder() {
>>                      public JCExpression build(final JCExpression selected) {

From maurizio.cimadamore at oracle.com  Mon Oct 24 13:50:59 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 24 Oct 2016 14:50:59 +0100
Subject: [PATCH] 8147527: Non-optimal code generated for postfix unary
	operators
In-Reply-To: <CAEgw74Ay_78UxGG8uLz6vBCZ4QALB=hP26PtqRDRpo_a-y4Y5A@mail.gmail.com>
References: <CAEgw74A6RLjAH0knfYwmqWx_CrLpR8xQBuy+c4ucC6SaAPXqog@mail.gmail.com>
	<CAEgw74AokHc6yyQjFqTi4wW2-4rTBUcjeH2n6cerO74hv4n_4Q@mail.gmail.com>
	<CAEgw74Ay_78UxGG8uLz6vBCZ4QALB=hP26PtqRDRpo_a-y4Y5A@mail.gmail.com>
Message-ID: <a4ee7750-6544-09ad-5629-3bf245fedf40@oracle.com>

I agree that something is up here - I think the patch in 8143388 
affected the way in which the synthetic tree was typed and this results 
in javac picking up the from member.

Maurizio


On 24/10/16 12:34, bsrbnd wrote:
> Hi,
>
> This issue is definitly very strange...
> Examining deeply (with javap) my last patch, I came to the conclusion
> that the changeset for issue 8143388 is perhaps wrong.
> Consider the following example:
>
> class Issue8147527 extends Parent {
>      public static void main(String[] args) {
>          Issue8147527 self = new Issue8147527();
>          self.testAll();
>      }
>
>      private void testAll() {
>          System.out.println(test());
>          System.out.println(i);
>
>          Inner in = new Inner();
>          System.out.println(in.test());
>          System.out.println(i);
>
>          System.out.println(testParent());
>          System.out.println(super.i);
>
>          System.out.println(in.testParent());
>          System.out.println(super.i);
>      }
>
>      Integer i=0;
>      private Integer test() {
>          return this.i++;
>      }
>
>      class Inner {
>          private Integer test() {
>              return Issue8147527.this.i++;
>          }
>          private Integer testParent() {
>              return Issue8147527.super.i++;
>          }
>      }
>
>      private Integer testParent() {
>          return super.i++;
>      }
> }
>
> class Parent {
>      protected Integer i=10;
> }
>
> Running it gives the following output:
> 0
> 1
> 1
> 2
> 10
> 11
> 11
> 11
>
> If I rollback issue 8143388 changeset, I get the following output;
> last line looks better (I think):
> 0
> 1
> 1
> 2
> 10
> 11
> 11
> 12
>
> Examining the generated code of "Inner" (I added a comment surrounded
> with !!!), we had:
>
>    private java.lang.Integer testParent();
>      Code:
>         0: aload_0
>         1: getfield      #3                  // Field this$0:LIssue8147527;
>         4: invokestatic  #8                  // Method
> Issue8147527.access$201:(LIssue8147527;)Ljava/lang/Integer;
>         7: astore_1                          // !!! REFERENCE TO VALUE
> OF Field Parent.i:Ljava/lang/Integer; !!!
>         8: aload_0
>         9: getfield      #3                  // Field this$0:LIssue8147527;
>        12: astore_3
>        13: aload_3
>        14: aload_3
>        15: getfield      #5                  // Field
> Issue8147527.i:Ljava/lang/Integer;
>        18: invokevirtual #6                  // Method
> java/lang/Integer.intValue:()I
>        21: iconst_1
>        22: iadd
>        23: invokestatic  #7                  // Method
> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>        26: dup_x1
>        27: putfield      #5                  // Field
> Issue8147527.i:Ljava/lang/Integer;
>        30: astore_2
>        31: aload_1                           // !!! REFERENCE TO VALUE
> OF Field Parent.i:Ljava/lang/Integer; !!!
>        32: areturn
>
> And rollbacking issue 8143388 changeset, we have (which looks better, I think):
>
>    private java.lang.Integer testParent();
>      Code:
>         0: aload_0
>         1: getfield      #3                  // Field this$0:LIssue8147527;
>         4: astore_1
>         5: aload_1
>         6: getfield      #8                  // Field
> Parent.i:Ljava/lang/Integer;
>         9: astore_2
>        10: aload_1
>        11: aload_1
>        12: getfield      #8                  // Field
> Parent.i:Ljava/lang/Integer;
>        15: invokevirtual #6                  // Method
> java/lang/Integer.intValue:()I
>        18: iconst_1
>        19: iadd
>        20: invokestatic  #7                  // Method
> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>        23: dup_x1
>        24: putfield      #8                  // Field
> Parent.i:Ljava/lang/Integer;
>        27: astore_3
>        28: aload_2
>        29: areturn
>
> Is issue 8143388 changeset really correct and harmless?
>
> Thanks,
> Bernard
>
>
> 2016-10-22 18:05 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>> Hi,
>>
>> Next is a probably better patch (derived from issue 8143388 changeset)
>> that handles also "this, this$0, ..." in addition to the existing
>> "super" handling. It optimizes the both cases ("this" and "super")
>> described in issue 8147527.
>> Notice that "thisDollar" could be part of the "Names" class if necessary.
>>
>> Bernard
>>
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>> @@ -2218,8 +2218,10 @@
>>                   return builder.build(rval);
>>           }
>>           Name name = TreeInfo.name(rval);
>> -        if (name == names._super)
>> +        Name thisDollar = names.fromString(names._this + "$");
>> +        if (name != null && (name == names._super || name ==
>> names._this || name.startsWith(thisDollar))) {
>>               return builder.build(rval);
>> +        }
>>           VarSymbol var =
>>               new VarSymbol(FINAL|SYNTHETIC,
>>                             names.fromString(
>>
>>
>> 2016-10-10 13:45 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>>> Hi,
>>>
>>> Consider the following example slightly modified from issue 8147527
>>> description to incorporate an assignment operator and an inner class
>>> which are both of them involved in the optimization process:
>>>
>>> class Issue8147527 {
>>>      Integer i=0;
>>>      private Integer test() {
>>>          this.i += 3;
>>>          for (; i<5; this.i++);
>>>          return this.i++;
>>>      }
>>>
>>>      Integer j=10;
>>>      class Inner {
>>>          private Integer test() {
>>>              return Issue8147527.this.j++;
>>>          }
>>>      }
>>>
>>>      public static void main(String[] args) {
>>>          Issue8147527 self = new Issue8147527();
>>>          System.out.println(self.test());
>>>          System.out.println(self.i);
>>>
>>>          Inner in = self.new Inner();
>>>          System.out.println(in.test());
>>>          System.out.println(self.j);
>>>      }
>>> }
>>>
>>> The following patch omits "this" for the special case of a
>>> select-expression used as an lvalue.
>>> Thus we had before optimization:
>>>
>>>    private java.lang.Integer test();
>>>      Code:
>>>         0: aload_0
>>>         1: astore_1
>>>         2: aload_1
>>>         3: aload_1
>>>         4: getfield      #3                  // Field i:Ljava/lang/Integer;
>>>         7: invokevirtual #5                  // Method
>>> java/lang/Integer.intValue:()I
>>>        10: iconst_3
>>>        11: iadd
>>>        12: invokestatic  #2                  // Method
>>> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>>>        15: dup_x1
>>>        16: putfield      #3                  // Field i:Ljava/lang/Integer;
>>>
>>> And after optimization, we have:
>>>
>>>    private java.lang.Integer test();
>>>      Code:
>>>         0: aload_0
>>>         1: aload_0
>>>         2: getfield      #3                  // Field i:Ljava/lang/Integer;
>>>         5: invokevirtual #5                  // Method
>>> java/lang/Integer.intValue:()I
>>>         8: iconst_3
>>>         9: iadd
>>>        10: invokestatic  #2                  // Method
>>> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>>>        13: putfield      #3                  // Field i:Ljava/lang/Integer;
>>>
>>> I've run all javac tests and it seems quite good.
>>> Notice that I haven't checked the "super" case yet, waiting for any
>>> feedback about the first optimization.
>>>
>>> Regards,
>>> Bernard
>>>
>>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>> @@ -2253,6 +2253,7 @@
>>>           case SELECT: {
>>>               final JCFieldAccess s = (JCFieldAccess)lval;
>>>               Symbol lid = TreeInfo.symbol(s.selected);
>>> +            if (lid != null && lid.name.equals(names._this)) return
>>> builder.build(make.Ident(s.sym));
>>>               if (lid != null && lid.kind == TYP) return builder.build(lval);
>>>               return abstractRval(s.selected, new TreeBuilder() {
>>>                       public JCExpression build(final JCExpression selected) {


From tim.bell at oracle.com  Mon Oct 24 14:18:55 2016
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 24 Oct 2016 07:18:55 -0700
Subject: RFR: 8167600 jib make run-test for langtools and intermittent
	failures on windows-x86
In-Reply-To: <4103fd2b-97d5-d606-e269-039c429d62b6@oracle.com>
References: <3eff9f30-7c35-4213-cfde-9c86a7f4633c@oracle.com>
	<8e98febd-958d-2145-9d82-baa69393881f@oracle.com>
	<b091ea51-ce71-5516-5efa-aaeda84462e3@oracle.com>
	<e3e10252-4d80-e91b-98d9-c7f544668e4f@oracle.com>
	<4103fd2b-97d5-d606-e269-039c429d62b6@oracle.com>
Message-ID: <b3c4166f-f5e1-57b9-cf4a-2aac6e8f0b53@oracle.com>

Erik:

> Hello,
>
> Isn't it the sun.arch.data.model of TESTJAVA that we are actually
> interested in?

You are correct.  JDK-8168369 is the follow-up bug report.

Tim


From cushon at google.com  Mon Oct 24 16:12:04 2016
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 24 Oct 2016 09:12:04 -0700
Subject: filemanager option handling and -Xlint:path
Message-ID: <CAL4QsgtKuiHbDCF395u4eHNkSuV1-aHB=Ta5Q+vhC7RADyG41Q@mail.gmail.com>

-Xlint:path doesn't work when javac is invoked using JSR 199.

The CLI breaks a circular dependency between option handling and
filemanager initialization, but JSR 199 eagerly initializes the filemanager
before xlint options have been processed.

Do you consider this to be a bug? I'm not sure what should happen for
user-supplied filemanagers, but the example below seems fixable:

=== JavacToolDemo.java ===
import javax.tools.JavaCompiler;
import javax.tools.StandardJavaFileManager;
import javax.tools.ToolProvider;
import java.util.Arrays;

public class JavacToolDemo {
  public static void main(String[] args) {
    JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
    StandardJavaFileManager fileManager =
compiler.getStandardFileManager(null, null, null);
    JavaCompiler.CompilationTask task =
      compiler.getTask(
          null,
          null,
          null,
          Arrays.asList("-verbose", "-Xlint:path,unchecked", "-cp",
"lib.jar"),
          null,
          fileManager.getJavaFileObjects("Hello.java"));
    System.exit(task.call() ? 0 : 1);
  }
}
===

The javac CLI handles -Xlint correctly:

$ echo "class Hello { java.util.List xs; }" > Hello.java
$ echo "Class-Path: NoSuch.jar" > Manifest.txt
$ jar cfm lib.jar Manifest.txt
$ javac -verbose -Xlint:all -cp lib.jar Hello.java
...
[search path for class files: ... NoSuch.jar]
...
warning: [path] bad path element "NoSuch.jar": no such file or directory
Hello.java:1: warning: [rawtypes] found raw type: List

The API does not:

$ javac JavacToolDemo.java
$ java JavacToolDemo
...
[search path for class files: ... NoSuch.jar]
...
Hello.java:1: warning: [rawtypes] found raw type: List
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161024/43653830/attachment.html>

From jonathan.gibbons at oracle.com  Mon Oct 24 17:15:24 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 24 Oct 2016 10:15:24 -0700
Subject: filemanager option handling and -Xlint:path
In-Reply-To: <CAL4QsgtKuiHbDCF395u4eHNkSuV1-aHB=Ta5Q+vhC7RADyG41Q@mail.gmail.com>
References: <CAL4QsgtKuiHbDCF395u4eHNkSuV1-aHB=Ta5Q+vhC7RADyG41Q@mail.gmail.com>
Message-ID: <6b1272d3-9dc2-6f47-7ce4-e79368a66f65@oracle.com>

I consider this a minor P4-level bug.  We're (still) teasing apart the 
use of the JavacFileManager as a standalone file manager from the 
mainline javac option decoding.   I'm (slightly) surprised at your 
example: I was expecting an example in which -Xlint:path comes *after* 
the -classpath option, for which there is definitely no attempt to 
handle it.

In general, I think API clients should be using API methods in 
preference to handleOption, and I think API clients have greater 
opportunity to check paths for validity before using setLocation. If 
anything, I'd prefer to either add API to enable warnings, or at least 
ensure that fm.handleOption("-Xlint:path") works on paths set via 
setLocation.

As for user file managers, it is currently up to them what options they 
support.  We have work in progress to at least define what options the 
file manager are provided by the default JDK ToolProvider's 
getSystemJavaCompiler.getStandardFileManager.  The main problem is what 
package/class to define this on. One likely possibility coming up is the 
javadoc on the jdk.compiler module itself.

-- Jon


On 10/24/16 9:12 AM, Liam Miller-Cushon wrote:
> -Xlint:path doesn't work when javac is invoked using JSR 199.
>
> The CLI breaks a circular dependency between option handling and 
> filemanager initialization, but JSR 199 eagerly initializes the 
> filemanager before xlint options have been processed.
>
> Do you consider this to be a bug? I'm not sure what should happen for 
> user-supplied filemanagers, but the example below seems fixable:
>
> === JavacToolDemo.java ===
> import javax.tools.JavaCompiler;
> import javax.tools.StandardJavaFileManager;
> import javax.tools.ToolProvider;
> import java.util.Arrays;
>
> public class JavacToolDemo {
>   public static void main(String[] args) {
>     JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
>     StandardJavaFileManager fileManager = 
> compiler.getStandardFileManager(null, null, null);
>     JavaCompiler.CompilationTask task =
>       compiler.getTask(
>           null,
>           null,
>           null,
>           Arrays.asList("-verbose", "-Xlint:path,unchecked", "-cp", 
> "lib.jar"),
>           null,
>           fileManager.getJavaFileObjects("Hello.java"));
>     System.exit(task.call() ? 0 : 1);
>   }
> }
> ===
>
> The javac CLI handles -Xlint correctly:
>
> $ echo "class Hello { java.util.List xs; }" > Hello.java
> $ echo "Class-Path: NoSuch.jar" > Manifest.txt
> $ jar cfm lib.jar Manifest.txt
> $ javac -verbose -Xlint:all -cp lib.jar Hello.java
> ...
> [search path for class files: ... NoSuch.jar]
> ...
> warning: [path] bad path element "NoSuch.jar": no such file or directory
> Hello.java:1: warning: [rawtypes] found raw type: List
>
> The API does not:
>
> $ javac JavacToolDemo.java
> $ java JavacToolDemo
> ...
> [search path for class files: ... NoSuch.jar]
> ...
> Hello.java:1: warning: [rawtypes] found raw type: List


From cushon at google.com  Mon Oct 24 18:00:46 2016
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 24 Oct 2016 11:00:46 -0700
Subject: filemanager option handling and -Xlint:path
In-Reply-To: <6b1272d3-9dc2-6f47-7ce4-e79368a66f65@oracle.com>
References: <CAL4QsgtKuiHbDCF395u4eHNkSuV1-aHB=Ta5Q+vhC7RADyG41Q@mail.gmail.com>
	<6b1272d3-9dc2-6f47-7ce4-e79368a66f65@oracle.com>
Message-ID: <CAL4Qsgst6YxxV272KtTCP2J1zRm5LcJ7+uCJSxDT0JUGmwmiPw@mail.gmail.com>

Thanks for confirming. P4 sounds about right to me, and we're generally
using the API methods over handleOption.

The only reason I asked is that the difference in behaviour between build
systems depending on whether they use the CLI or JSR 199 was surprising:
https://github.com/google/error-prone/issues/466#issuecomment-255791591

On Mon, Oct 24, 2016 at 10:15 AM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> I consider this a minor P4-level bug.  We're (still) teasing apart the use
> of the JavacFileManager as a standalone file manager from the mainline
> javac option decoding.   I'm (slightly) surprised at your example: I was
> expecting an example in which -Xlint:path comes *after* the -classpath
> option, for which there is definitely no attempt to handle it.
>
> In general, I think API clients should be using API methods in preference
> to handleOption, and I think API clients have greater opportunity to check
> paths for validity before using setLocation. If anything, I'd prefer to
> either add API to enable warnings, or at least ensure that
> fm.handleOption("-Xlint:path") works on paths set via setLocation.
>
> As for user file managers, it is currently up to them what options they
> support.  We have work in progress to at least define what options the file
> manager are provided by the default JDK ToolProvider's
> getSystemJavaCompiler.getStandardFileManager.  The main problem is what
> package/class to define this on. One likely possibility coming up is the
> javadoc on the jdk.compiler module itself.
>
> -- Jon
>
>
>
> On 10/24/16 9:12 AM, Liam Miller-Cushon wrote:
>
>> -Xlint:path doesn't work when javac is invoked using JSR 199.
>>
>> The CLI breaks a circular dependency between option handling and
>> filemanager initialization, but JSR 199 eagerly initializes the filemanager
>> before xlint options have been processed.
>>
>> Do you consider this to be a bug? I'm not sure what should happen for
>> user-supplied filemanagers, but the example below seems fixable:
>>
>> === JavacToolDemo.java ===
>> import javax.tools.JavaCompiler;
>> import javax.tools.StandardJavaFileManager;
>> import javax.tools.ToolProvider;
>> import java.util.Arrays;
>>
>> public class JavacToolDemo {
>>   public static void main(String[] args) {
>>     JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
>>     StandardJavaFileManager fileManager = compiler.getStandardFileManager(null,
>> null, null);
>>     JavaCompiler.CompilationTask task =
>>       compiler.getTask(
>>           null,
>>           null,
>>           null,
>>           Arrays.asList("-verbose", "-Xlint:path,unchecked", "-cp",
>> "lib.jar"),
>>           null,
>>           fileManager.getJavaFileObjects("Hello.java"));
>>     System.exit(task.call() ? 0 : 1);
>>   }
>> }
>> ===
>>
>> The javac CLI handles -Xlint correctly:
>>
>> $ echo "class Hello { java.util.List xs; }" > Hello.java
>> $ echo "Class-Path: NoSuch.jar" > Manifest.txt
>> $ jar cfm lib.jar Manifest.txt
>> $ javac -verbose -Xlint:all -cp lib.jar Hello.java
>> ...
>> [search path for class files: ... NoSuch.jar]
>> ...
>> warning: [path] bad path element "NoSuch.jar": no such file or directory
>> Hello.java:1: warning: [rawtypes] found raw type: List
>>
>> The API does not:
>>
>> $ javac JavacToolDemo.java
>> $ java JavacToolDemo
>> ...
>> [search path for class files: ... NoSuch.jar]
>> ...
>> Hello.java:1: warning: [rawtypes] found raw type: List
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161024/971c76be/attachment-0001.html>

From jonathan.gibbons at oracle.com  Mon Oct 24 18:17:50 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 24 Oct 2016 11:17:50 -0700
Subject: filemanager option handling and -Xlint:path
In-Reply-To: <CAL4Qsgst6YxxV272KtTCP2J1zRm5LcJ7+uCJSxDT0JUGmwmiPw@mail.gmail.com>
References: <CAL4QsgtKuiHbDCF395u4eHNkSuV1-aHB=Ta5Q+vhC7RADyG41Q@mail.gmail.com>
	<6b1272d3-9dc2-6f47-7ce4-e79368a66f65@oracle.com>
	<CAL4Qsgst6YxxV272KtTCP2J1zRm5LcJ7+uCJSxDT0JUGmwmiPw@mail.gmail.com>
Message-ID: <8d86f340-860e-a33f-8e6e-25a679c7ea67@oracle.com>

Yes, the disparity is annoying when the API is used to just build a 
different front end to javac, as compared to a deeply embedded component.

There are two (general) problems here.

1. Options that are (or may be) accepted by both javac and a file 
manager, which may or may not be JavacFileManager, or a wrapper around 
it. Having an API method on StandardJavaFileManager to enable warnings 
would be a good way to fix this. (And yes, that comes with some amount 
of compatibility design issues.)  One aspect of this problem is the 
backdoor path into the file manager via Context and Options. Generally, 
I've been trying to reduce the amount of info past this way. 
-Xlint:paths is the remaining most annoying use, but there are some 
hidden backdoor options which are also passed in this way.  Ideally, 
JavacFileManager should be a standalone component, and not use 
Context/Options at all.

2. Order of options.  Historically, command line javac lazily evaluated 
search paths (even before OpenJDK, file managers, JSR 199, etc), which 
meant that -Xlint:path could appear after a search path on the command 
line and still have an effect. You can see (or have seen) the code in 
command-line javac to retain that behavior. That is harder to do in the 
context of the (Standard)JavaFileManager API, where you want to throw 
IllegalArgumentException for really bad arguments, but maybe lazily give 
warnings for missing paths in the cases where -Xlint:path might 
eventually be specified.  Here, the complication is that the file 
manager might not be JavacFileManager, and we mustn't presume too much 
behavior there.  There are already too many "instanceof 
JavacFilemanager" in the code ;-)

-- Jon


On 10/24/16 11:00 AM, Liam Miller-Cushon wrote:
> Thanks for confirming. P4 sounds about right to me, and we're 
> generally using the API methods over handleOption.
>
> The only reason I asked is that the difference in behaviour between 
> build systems depending on whether they use the CLI or JSR 199 was 
> surprising: 
> https://github.com/google/error-prone/issues/466#issuecomment-255791591
>
> On Mon, Oct 24, 2016 at 10:15 AM, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     I consider this a minor P4-level bug.  We're (still) teasing apart
>     the use of the JavacFileManager as a standalone file manager from
>     the mainline javac option decoding.   I'm (slightly) surprised at
>     your example: I was expecting an example in which -Xlint:path
>     comes *after* the -classpath option, for which there is definitely
>     no attempt to handle it.
>
>     In general, I think API clients should be using API methods in
>     preference to handleOption, and I think API clients have greater
>     opportunity to check paths for validity before using setLocation.
>     If anything, I'd prefer to either add API to enable warnings, or
>     at least ensure that fm.handleOption("-Xlint:path") works on paths
>     set via setLocation.
>
>     As for user file managers, it is currently up to them what options
>     they support.  We have work in progress to at least define what
>     options the file manager are provided by the default JDK
>     ToolProvider's getSystemJavaCompiler.getStandardFileManager. The
>     main problem is what package/class to define this on. One likely
>     possibility coming up is the javadoc on the jdk.compiler module
>     itself.
>
>     -- Jon
>
>
>
>     On 10/24/16 9:12 AM, Liam Miller-Cushon wrote:
>
>         -Xlint:path doesn't work when javac is invoked using JSR 199.
>
>         The CLI breaks a circular dependency between option handling
>         and filemanager initialization, but JSR 199 eagerly
>         initializes the filemanager before xlint options have been
>         processed.
>
>         Do you consider this to be a bug? I'm not sure what should
>         happen for user-supplied filemanagers, but the example below
>         seems fixable:
>
>         === JavacToolDemo.java ===
>         import javax.tools.JavaCompiler;
>         import javax.tools.StandardJavaFileManager;
>         import javax.tools.ToolProvider;
>         import java.util.Arrays;
>
>         public class JavacToolDemo {
>           public static void main(String[] args) {
>             JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
>             StandardJavaFileManager fileManager =
>         compiler.getStandardFileManager(null, null, null);
>             JavaCompiler.CompilationTask task =
>               compiler.getTask(
>                   null,
>                   null,
>                   null,
>                   Arrays.asList("-verbose", "-Xlint:path,unchecked",
>         "-cp", "lib.jar"),
>                   null,
>                   fileManager.getJavaFileObjects("Hello.java"));
>             System.exit(task.call() ? 0 : 1);
>           }
>         }
>         ===
>
>         The javac CLI handles -Xlint correctly:
>
>         $ echo "class Hello { java.util.List xs; }" > Hello.java
>         $ echo "Class-Path: NoSuch.jar" > Manifest.txt
>         $ jar cfm lib.jar Manifest.txt
>         $ javac -verbose -Xlint:all -cp lib.jar Hello.java
>         ...
>         [search path for class files: ... NoSuch.jar]
>         ...
>         warning: [path] bad path element "NoSuch.jar": no such file or
>         directory
>         Hello.java:1: warning: [rawtypes] found raw type: List
>
>         The API does not:
>
>         $ javac JavacToolDemo.java
>         $ java JavacToolDemo
>         ...
>         [search path for class files: ... NoSuch.jar]
>         ...
>         Hello.java:1: warning: [rawtypes] found raw type: List
>
>
>

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

From alex.buckley at oracle.com  Mon Oct 24 18:28:28 2016
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 24 Oct 2016 11:28:28 -0700
Subject: spec clarification: wildcard array element signature
In-Reply-To: <CAL4QsgsBXbM=+XkSnvWxFgsYssPtk9m=p=hKnTG1MccAZDeK+A@mail.gmail.com>
References: <CAL4QsgsBXbM=+XkSnvWxFgsYssPtk9m=p=hKnTG1MccAZDeK+A@mail.gmail.com>
Message-ID: <580E52CC.4030408@oracle.com>

First, I don't know why javac is denoting the type of i using A rather 
than B, both in the field descriptor and in the Signature attribute. The 
field descriptor is specified in JLS8 13.1 as containing "a symbolic 
reference to the erasure of the type of the field". Plainly this is 
LB$I, and Signature would follow suit.

Second, there is nothing in JLS8 8.1.2 to deny B<?>'s supertype being 
A<?[]>, so to speak. But it was never envisaged in JVMS8 4.7.9.1 that 
there would be a type parameterized by "array of wildcards". This may be 
due to the trickiness of Signature having multiple roles: it reifies 
generic type information like B<Y> (where array types are not permitted 
as type parameters) in addition to parameterized type information like 
A<Y[]> (where array types are permitted as type arguments).

Third, on JDK 9b140, javac crashes if the declaration of i uses a 
bounded wildcard for B's type argument -- say B<? extends Number>.I

java.lang.ClassCastException:
com.sun.tools.javac.code.Type$TypeMapping$3 (in module: jdk.compiler)
cannot be cast to
com.sun.tools.javac.code.Type$WildcardType (in module: jdk.compiler)
at 
com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.validateAnnotatedType(jdk.compiler at 9-ea/Attr.java:4804)

Looking for others to comment.

Alex

On 10/22/2016 8:15 PM, Liam Miller-Cushon wrote:
> When javac compiles the following program, it writes field i's signature
> as "LA<[*>.I;".
>
> I don't think the grammar in JVMS 4.7.9.1 allows for the element type of
> an array to be a wildcard. Is that a spec bug?
>
> class A<X> { class I {} }
> class Test {
>    class B<Y> extends A<Y[]> {}
>    B<?>.I i;
> }

From jan.lahoda at oracle.com  Mon Oct 24 20:11:50 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 24 Oct 2016 22:11:50 +0200
Subject: [PATCH] 8147527: Non-optimal code generated for postfix unary
	operators
In-Reply-To: <a4ee7750-6544-09ad-5629-3bf245fedf40@oracle.com>
References: <CAEgw74A6RLjAH0knfYwmqWx_CrLpR8xQBuy+c4ucC6SaAPXqog@mail.gmail.com>
	<CAEgw74AokHc6yyQjFqTi4wW2-4rTBUcjeH2n6cerO74hv4n_4Q@mail.gmail.com>
	<CAEgw74Ay_78UxGG8uLz6vBCZ4QALB=hP26PtqRDRpo_a-y4Y5A@mail.gmail.com>
	<a4ee7750-6544-09ad-5629-3bf245fedf40@oracle.com>
Message-ID: <580E6B06.5000800@oracle.com>

Hi,

Yes, the current behavior indeed appears to be wrong.

This is what I think happens:
Consider the "Issue8147527.super.i++;" statement from the example.

In Lower.visitUnary, in the switch statement, in POSTINC/POSTDEC section 
(this is the code that translates the ++/-- operators for Integers to 
simplified AST that can be then written as bytecode):
http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/88cc9b782624/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l3324

the result of "lowerBoxedPostop(tree)" is along these lines:

(let /*synthetic*/ final Integer $997055773 = 
(Integer)Issue8147527.super.i in (let /*synthetic*/ final Integer 
$1063980005 = Issue8147527.super.i += 1 in $997055773))

That seems OK. The problem is that after the invocation of translate, 
the code looks like this:

(let /*synthetic*/ final Integer $997055773 = 
(Integer)Issue8147527.access$101(this$0) in (let /*synthetic*/ final 
Integer $1063980005 = (let /*synthetic*/ final Issue8147527 $173214986 = 
this$0 in $173214986.i = Integer.valueOf((int)($173214986.i.intValue() + 
1))) in $997055773))

This code is inside the Issue8147527.Inner class, and "this$0" is the 
outer this, i.e. the enclosing instance Issue8147527. So the code is 
actually manipulating the "i" variable from Issue8147527 not from the 
Parent, which is apparently wrong. (In JDK-8143388 the situation was 
different, as the Parent was in a different package, and so the variable 
was not accessible and so the correct accessors were generated after the 
fix.)

I believe the main issue here is that in the first desugared code:

(let /*synthetic*/ final Integer $997055773 = 
(Integer)Issue8147527.super.i in (let /*synthetic*/ final Integer 
$1063980005 = Issue8147527.super.i += 1 in $997055773))

there is only a single tree node for "Issue8147527.super.i", reused on 
two places. Further desugaring then replaces the "Issue8147527.super" 
with "this$0" (see "tree.selected = translate(tree.selected);" in 
Lower.visitSelect). This transiently leads to this code:

(let /*synthetic*/ final Integer $997055773 = (Integer)this$0.i in (let 
/*synthetic*/ final Integer $1063980005 = this$0.i += 1 in $997055773))

The first occurrence of "this$0.i" will get fixed by Lower.visitSelect 
(see the call to the access method) to 
"Issue8147527.access$101(this$0)", but the other one will not, causing 
the problem.

So far, it seems to me there are two possible fixes:
1) stop reusing the same tree on two places (each of them will get 
translated independently, avoiding the problem).
2) avoid the modification of tree.selected in Lower.visitSelect

Jan

On 24.10.2016 15:50, Maurizio Cimadamore wrote:
> I agree that something is up here - I think the patch in 8143388
> affected the way in which the synthetic tree was typed and this results
> in javac picking up the from member.
>
> Maurizio
>
>
> On 24/10/16 12:34, bsrbnd wrote:
>> Hi,
>>
>> This issue is definitly very strange...
>> Examining deeply (with javap) my last patch, I came to the conclusion
>> that the changeset for issue 8143388 is perhaps wrong.
>> Consider the following example:
>>
>> class Issue8147527 extends Parent {
>>      public static void main(String[] args) {
>>          Issue8147527 self = new Issue8147527();
>>          self.testAll();
>>      }
>>
>>      private void testAll() {
>>          System.out.println(test());
>>          System.out.println(i);
>>
>>          Inner in = new Inner();
>>          System.out.println(in.test());
>>          System.out.println(i);
>>
>>          System.out.println(testParent());
>>          System.out.println(super.i);
>>
>>          System.out.println(in.testParent());
>>          System.out.println(super.i);
>>      }
>>
>>      Integer i=0;
>>      private Integer test() {
>>          return this.i++;
>>      }
>>
>>      class Inner {
>>          private Integer test() {
>>              return Issue8147527.this.i++;
>>          }
>>          private Integer testParent() {
>>              return Issue8147527.super.i++;
>>          }
>>      }
>>
>>      private Integer testParent() {
>>          return super.i++;
>>      }
>> }
>>
>> class Parent {
>>      protected Integer i=10;
>> }
>>
>> Running it gives the following output:
>> 0
>> 1
>> 1
>> 2
>> 10
>> 11
>> 11
>> 11
>>
>> If I rollback issue 8143388 changeset, I get the following output;
>> last line looks better (I think):
>> 0
>> 1
>> 1
>> 2
>> 10
>> 11
>> 11
>> 12
>>
>> Examining the generated code of "Inner" (I added a comment surrounded
>> with !!!), we had:
>>
>>    private java.lang.Integer testParent();
>>      Code:
>>         0: aload_0
>>         1: getfield      #3                  // Field
>> this$0:LIssue8147527;
>>         4: invokestatic  #8                  // Method
>> Issue8147527.access$201:(LIssue8147527;)Ljava/lang/Integer;
>>         7: astore_1                          // !!! REFERENCE TO VALUE
>> OF Field Parent.i:Ljava/lang/Integer; !!!
>>         8: aload_0
>>         9: getfield      #3                  // Field
>> this$0:LIssue8147527;
>>        12: astore_3
>>        13: aload_3
>>        14: aload_3
>>        15: getfield      #5                  // Field
>> Issue8147527.i:Ljava/lang/Integer;
>>        18: invokevirtual #6                  // Method
>> java/lang/Integer.intValue:()I
>>        21: iconst_1
>>        22: iadd
>>        23: invokestatic  #7                  // Method
>> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>>        26: dup_x1
>>        27: putfield      #5                  // Field
>> Issue8147527.i:Ljava/lang/Integer;
>>        30: astore_2
>>        31: aload_1                           // !!! REFERENCE TO VALUE
>> OF Field Parent.i:Ljava/lang/Integer; !!!
>>        32: areturn
>>
>> And rollbacking issue 8143388 changeset, we have (which looks better,
>> I think):
>>
>>    private java.lang.Integer testParent();
>>      Code:
>>         0: aload_0
>>         1: getfield      #3                  // Field
>> this$0:LIssue8147527;
>>         4: astore_1
>>         5: aload_1
>>         6: getfield      #8                  // Field
>> Parent.i:Ljava/lang/Integer;
>>         9: astore_2
>>        10: aload_1
>>        11: aload_1
>>        12: getfield      #8                  // Field
>> Parent.i:Ljava/lang/Integer;
>>        15: invokevirtual #6                  // Method
>> java/lang/Integer.intValue:()I
>>        18: iconst_1
>>        19: iadd
>>        20: invokestatic  #7                  // Method
>> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>>        23: dup_x1
>>        24: putfield      #8                  // Field
>> Parent.i:Ljava/lang/Integer;
>>        27: astore_3
>>        28: aload_2
>>        29: areturn
>>
>> Is issue 8143388 changeset really correct and harmless?
>>
>> Thanks,
>> Bernard
>>
>>
>> 2016-10-22 18:05 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>>> Hi,
>>>
>>> Next is a probably better patch (derived from issue 8143388 changeset)
>>> that handles also "this, this$0, ..." in addition to the existing
>>> "super" handling. It optimizes the both cases ("this" and "super")
>>> described in issue 8147527.
>>> Notice that "thisDollar" could be part of the "Names" class if
>>> necessary.
>>>
>>> Bernard
>>>
>>> diff --git
>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>> @@ -2218,8 +2218,10 @@
>>>                   return builder.build(rval);
>>>           }
>>>           Name name = TreeInfo.name(rval);
>>> -        if (name == names._super)
>>> +        Name thisDollar = names.fromString(names._this + "$");
>>> +        if (name != null && (name == names._super || name ==
>>> names._this || name.startsWith(thisDollar))) {
>>>               return builder.build(rval);
>>> +        }
>>>           VarSymbol var =
>>>               new VarSymbol(FINAL|SYNTHETIC,
>>>                             names.fromString(
>>>
>>>
>>> 2016-10-10 13:45 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>>>> Hi,
>>>>
>>>> Consider the following example slightly modified from issue 8147527
>>>> description to incorporate an assignment operator and an inner class
>>>> which are both of them involved in the optimization process:
>>>>
>>>> class Issue8147527 {
>>>>      Integer i=0;
>>>>      private Integer test() {
>>>>          this.i += 3;
>>>>          for (; i<5; this.i++);
>>>>          return this.i++;
>>>>      }
>>>>
>>>>      Integer j=10;
>>>>      class Inner {
>>>>          private Integer test() {
>>>>              return Issue8147527.this.j++;
>>>>          }
>>>>      }
>>>>
>>>>      public static void main(String[] args) {
>>>>          Issue8147527 self = new Issue8147527();
>>>>          System.out.println(self.test());
>>>>          System.out.println(self.i);
>>>>
>>>>          Inner in = self.new Inner();
>>>>          System.out.println(in.test());
>>>>          System.out.println(self.j);
>>>>      }
>>>> }
>>>>
>>>> The following patch omits "this" for the special case of a
>>>> select-expression used as an lvalue.
>>>> Thus we had before optimization:
>>>>
>>>>    private java.lang.Integer test();
>>>>      Code:
>>>>         0: aload_0
>>>>         1: astore_1
>>>>         2: aload_1
>>>>         3: aload_1
>>>>         4: getfield      #3                  // Field
>>>> i:Ljava/lang/Integer;
>>>>         7: invokevirtual #5                  // Method
>>>> java/lang/Integer.intValue:()I
>>>>        10: iconst_3
>>>>        11: iadd
>>>>        12: invokestatic  #2                  // Method
>>>> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>>>>        15: dup_x1
>>>>        16: putfield      #3                  // Field
>>>> i:Ljava/lang/Integer;
>>>>
>>>> And after optimization, we have:
>>>>
>>>>    private java.lang.Integer test();
>>>>      Code:
>>>>         0: aload_0
>>>>         1: aload_0
>>>>         2: getfield      #3                  // Field
>>>> i:Ljava/lang/Integer;
>>>>         5: invokevirtual #5                  // Method
>>>> java/lang/Integer.intValue:()I
>>>>         8: iconst_3
>>>>         9: iadd
>>>>        10: invokestatic  #2                  // Method
>>>> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>>>>        13: putfield      #3                  // Field
>>>> i:Ljava/lang/Integer;
>>>>
>>>> I've run all javac tests and it seems quite good.
>>>> Notice that I haven't checked the "super" case yet, waiting for any
>>>> feedback about the first optimization.
>>>>
>>>> Regards,
>>>> Bernard
>>>>
>>>> diff --git
>>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>> ---
>>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>> +++
>>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>> @@ -2253,6 +2253,7 @@
>>>>           case SELECT: {
>>>>               final JCFieldAccess s = (JCFieldAccess)lval;
>>>>               Symbol lid = TreeInfo.symbol(s.selected);
>>>> +            if (lid != null && lid.name.equals(names._this)) return
>>>> builder.build(make.Ident(s.sym));
>>>>               if (lid != null && lid.kind == TYP) return
>>>> builder.build(lval);
>>>>               return abstractRval(s.selected, new TreeBuilder() {
>>>>                       public JCExpression build(final JCExpression
>>>> selected) {
>

From maurizio.cimadamore at oracle.com  Mon Oct 24 21:35:37 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 24 Oct 2016 22:35:37 +0100
Subject: spec clarification: wildcard array element signature
In-Reply-To: <580E52CC.4030408@oracle.com>
References: <CAL4QsgsBXbM=+XkSnvWxFgsYssPtk9m=p=hKnTG1MccAZDeK+A@mail.gmail.com>
	<580E52CC.4030408@oracle.com>
Message-ID: <5474bf92-130f-36aa-8435-03e392be4f0c@oracle.com>



On 24/10/16 19:28, Alex Buckley wrote:
> First, I don't know why javac is denoting the type of i using A rather 
> than B, both in the field descriptor and in the Signature attribute. 
> The field descriptor is specified in JLS8 13.1 as containing "a 
> symbolic reference to the erasure of the type of the field". Plainly 
> this is LB$I, and Signature would follow suit.
I think this is coming from this rule (13.1):

"The binary name of a member type (?8.5, ?9.5) consists of the binary 
name of its immediately enclosing type, followed by $, followed by the 
simple name of the member."

The rule speaks about 'enclosing type' hence A being used instead of B I 
believe. But that counts for the descriptor.

As for the contents of the signature attributes, my feeling is that the 
signature attribute attempts to 'augment' the information that's 
available in the descriptor, not completely replace it. I think having, 
say, Field.getType return A, but Field.getGenericType return 
B<something> would be a little weird, I believe. Other compilers such as 
ecj seem to be doing the exact same thing in this respect.

>
> Second, there is nothing in JLS8 8.1.2 to deny B<?>'s supertype being 
> A<?[]>, so to speak. But it was never envisaged in JVMS8 4.7.9.1 that 
> there would be a type parameterized by "array of wildcards". This may 
> be due to the trickiness of Signature having multiple roles: it 
> reifies generic type information like B<Y> (where array types are not 
> permitted as type parameters) in addition to parameterized type 
> information like A<Y[]> (where array types are permitted as type 
> arguments).
Right - this is not explicitly disallowed - but it seems in contrast to 
the rules for computing the supertype of a generic class: the supertype 
of B<?> is not A<?[]> but A<#CAP[]>, where #CAP <: Object. I believe 
keeping wildcards open in the bytecode (which is something ecj does too) 
might result in unsoundness? Presence of arrays here is largely 
irrelevant - if the supertype was just A<Y> wouldn't still be 
problematic to use A<?> as the field type?

At the same time, there's no representation at the bytecode level for 
captured variables, so there's not much that can be done in that space.
>
> Third, on JDK 9b140, javac crashes if the declaration of i uses a 
> bounded wildcard for B's type argument -- say B<? extends Number>.I
>
> java.lang.ClassCastException:
> com.sun.tools.javac.code.Type$TypeMapping$3 (in module: jdk.compiler)
> cannot be cast to
> com.sun.tools.javac.code.Type$WildcardType (in module: jdk.compiler)
> at 
> com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.validateAnnotatedType(jdk.compiler at 9-ea/Attr.java:4804)
This is a bug - I've also been able to reproduce on JDK 8.

Regarding the other issue about wildcards being replaced in supertypes, 
I think there are two options - none of which is particularly appealing:

* fix javac (and other compilers) so that the signature attribute only 
speaks about types in the source code, w/o attempting to do any 
membership computation - this should ensure that non-denotable types 
should not crop up in the process - unfortunately, doing so will change 
the signature attribute of real code out there - and the compatibility 
impact potentially large (the difference will be visible in core 
reflection).

* keep javac as is - live with 'weird' signatures and plug resulting 
soundness issues (esp. around separate compilation) ?

Maurizio
>
> Looking for others to comment.
>
> Alex
>
> On 10/22/2016 8:15 PM, Liam Miller-Cushon wrote:
>> When javac compiles the following program, it writes field i's signature
>> as "LA<[*>.I;".
>>
>> I don't think the grammar in JVMS 4.7.9.1 allows for the element type of
>> an array to be a wildcard. Is that a spec bug?
>>
>> class A<X> { class I {} }
>> class Test {
>>    class B<Y> extends A<Y[]> {}
>>    B<?>.I i;
>> }


From bangert at google.com  Tue Oct 25 01:30:39 2016
From: bangert at google.com (Julian Bangert)
Date: Tue, 25 Oct 2016 01:30:39 +0000
Subject: Question about type annotations
In-Reply-To: <CAOn4P0MxvwDUNvcEOsOxTj=17wixyfCHkLKGtwxVnt-Bcfz4fg@mail.gmail.com>
References: <CAOn4P0MW2M3b0iTnL-OeDQunT65biLTdiM6dhkS6_XSs27R21g@mail.gmail.com>
	<CAOn4P0M82v2CoLxZeDUR9a7h6REMJHh0prPo2UTws7i8H_wK-A@mail.gmail.com>
	<58056F20.6050201@oracle.com>
	<CAOn4P0MOBPDkTFc=O_0x3vsT_q2RB+u8=zh8JQj2R5DyadLWBA@mail.gmail.com>
	<58057443.5080609@oracle.com>
	<CAOn4P0MxvwDUNvcEOsOxTj=17wixyfCHkLKGtwxVnt-Bcfz4fg@mail.gmail.com>
Message-ID: <CAOn4P0On2J0XQxT43f25pDPZPWnG36J14j6sL0Ce1Gtch_rXwA@mail.gmail.com>

I investigated  a bit further. The issue stems from the two-phase design
currently used in javac to add type annotations (type annotations are
processed completely separately from types, which seems bad).

The  type parameters type objects are created in Attr.java,  specifically
in Attr.visitApply, which creates a list  of type attributes (with
attribAnyTypes) which is then passed to Type.ForAll and used to create the
specialized generic type.

TypeAnnotations.java then performs another pass, but crucially makes copies
of every task. It does not update the ForAll types. Is there a particular
reason for this?

Regards,
Julian

On Tue, Oct 18, 2016 at 2:34 PM Julian Bangert <bangert at google.com> wrote:

> Ok I hacked up something quick (see attachments). When running the tool, I
> get
> /usr/local/google/home/bangert/16/jdk-type-test/Annotation.java
> /usr/local/google/home/bangert/16/jdk-type-test/Testcase.java
> /usr/local/google/home/bangert/16/jdk-type-test/Generic.java
> CompilationUnit:
> /usr/local/google/home/bangert/16/jdk-type-test/Annotation.java
> CompilationUnit:
> /usr/local/google/home/bangert/16/jdk-type-test/Testcase.java
>
>
>  MethodInvocation: super()
> MethodSelect: JCTree.type: ()void
> MethodSelect: Trees.type: ()void
>
>
>  MethodInvocation: list.add(foo)
> MethodSelect: JCTree.type: (@test.Annotation java.lang.String)boolean
> MethodSelect: Trees.type: (java.lang.String)boolean
>
>
>  MethodInvocation: Generic.<@Annotation() String>Method(foo)
> MethodSelect: JCTree.type: (java.lang.String)void
> MethodSelect: Trees.type: (java.lang.String)void
> CompilationUnit:
> /usr/local/google/home/bangert/16/jdk-type-test/Generic.java
>
>
>  MethodInvocation: super()
> MethodSelect: JCTree.type: ()void
> MethodSelect: Trees.type: ()void
>
>
> The trees API always strips metadata (which is unfortunate, but other
> parts of error-prone already depend on JCType), so the annotations are
> always gone. However, when looking at the JCTree.type field, the class
> method on a generic has annotations on the substituted type parameter,
> whereas it doesn't for the generic method call. The same applies to
> constructors.
>
> Thanks again,
> Julian
> On Mon, Oct 17, 2016 at 6:00 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
> A small program that parses the test case you already provided, to get an
> AST, then walks the AST, looking for selected nodes, printing out any
> relevant info.   Essentially, encapsulate this part of your message in
> demonstrable code:
>
>
> > Now call node.getMethodSelect() on the MethodInvocation AST nodes
> > generated by this snippet. For the first call site (list.add(foo)),
> > node.getMethodSelect() returns a JCFieldAccess with type
> >
> > "(@test.Annotation java.lang.String)boolean"
> <(@test.Annotationjava.lang.String)boolean> (note the annotation).
> >
> > When I do the same for Generic.<@Annotation String>Method, I merely get
> > "(java.lang.String)void".
>
>
> If (but only if) you're familiar with the javac code base, and more
> importantly, the test base, if you know of DPrinter, you might be able to
> use that to dump the AST.  In fact, something like
>     java -classpath ...  DPrinter.Main -after PARSE -showTreeTypes
> source-files...
>
> might get you pretty much all the way to a script you could post.
>
> -- Jon
>
>
>
> On 10/17/2016 05:46 PM, Julian Bangert wrote:
>
> Thanks for the quick response -- how would you prefer the stripped down
> example? Should I send an error-prone testcase?
>
> On Mon, Oct 17, 2016 at 5:38 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
> As is typically the case in requests like this, it would help if you
> could post a working, stripped down example.
>
> You're also working with javac internal objects. It would help if you
> could post an example in terms of the public API, such as is available
> using
>      com.sun.source.*
>      javax.lang.model.*
>
> For example, if you have identified a node in an AST by a TreePath, use
>      com.sun.source.util.Trees.getTypeMirror(TreePath)
> and then, since TypeMirror extends AnnotatedConstruct, you can get the
> annotation mirrors.
>
> See:
>
> http://download.java.net/java/jdk9/docs/jdk/api/javac/tree/com/sun/source/util/Trees.html
>
> http://download.java.net/java/jdk9/docs/api/javax/lang/model/type/TypeMirror.html
>
> http://download.java.net/java/jdk9/docs/api/javax/lang/model/AnnotatedConstruct.html
>
> -- Jon
>
> On 10/17/2016 05:18 PM, Julian Bangert wrote:
> > Hello (re-sending due to moderation),
> >
> > I am working on a checker based on the error-prone framework that
> > works with (Java 8) type annotations. The javac AST seems to be
> > missing annotation types for generic methods (and constructors on
> > generic types):
> >
> > // Annotation .java
> > package test;
> > import java.lang.annotation.ElementType;
> > import java.lang.annotation.Target;
> >
> >  @Target({
> >     ElementType.TYPE_USE,
> >     ElementType.FIELD,
> >     ElementType.LOCAL_VARIABLE,
> >     ElementType.PARAMETER,
> >     ElementType.METHOD
> >   })
> > public interface @Annotation {}
> >
> >
> > // Generic.java
> >  package test;
> >   public class Generic {
> >       public static <V> void Method(V value) {
> >       }
> >   }
> >
> > // Testcase.java
> >
> > package test;
> > import java.util.List;
> > public class Testcase {
> >     void test(List<@Annotation String> list, String foo) {
> >         list.add(foo);
> >         Generic.<@Annotation String>Method(foo);
> >     }
> > }
> >
> > Now call node.getMethodSelect() on the MethodInvocation AST nodes
> > generated by this snippet. For the first call site (list.add(foo)),
> > node.getMethodSelect() returns a JCFieldAccess with type
> >
> > "(@test.Annotation java.lang.String)boolean"
> <(@test.Annotationjava.lang.String)boolean> (note the annotation).
> >
> > When I do the same for Generic.<@Annotation String>Method, I merely get
> > "(java.lang.String)void".
> >
> > Is this a bug or intended behaviour? Is there a way to get annotation
> > on the types (besides implementing my own lookup, which might be
> > buggy/unelegant).
> >
> > Regards,
> > Julian
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161025/095a2baf/attachment-0001.html>

From maurizio.cimadamore at oracle.com  Tue Oct 25 08:41:45 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 25 Oct 2016 09:41:45 +0100
Subject: [PATCH] 8147527: Non-optimal code generated for postfix unary
	operators
In-Reply-To: <580E6B06.5000800@oracle.com>
References: <CAEgw74A6RLjAH0knfYwmqWx_CrLpR8xQBuy+c4ucC6SaAPXqog@mail.gmail.com>
	<CAEgw74AokHc6yyQjFqTi4wW2-4rTBUcjeH2n6cerO74hv4n_4Q@mail.gmail.com>
	<CAEgw74Ay_78UxGG8uLz6vBCZ4QALB=hP26PtqRDRpo_a-y4Y5A@mail.gmail.com>
	<a4ee7750-6544-09ad-5629-3bf245fedf40@oracle.com>
	<580E6B06.5000800@oracle.com>
Message-ID: <c929b65f-24ee-d061-d77a-3af17052337d@oracle.com>

Hi Jan,
great analysis. I think (1) could be a safer path - but I admit I'm not 
entirely sold on another point; you say:

"Further desugaring then replaces the "Issue8147527.super" with "this$0" 
(see "tree.selected = translate(tree.selected);" in Lower.visitSelect)"

Isn't this already wrong? The static type of this$0 is Issue8147527, 
which is different from the static type of this.super (Parent). 
Shouldn't javac at least emit a cast there to preserve typing? While I 
don't dispute the other problems you discovered, which are real, I think 
the above desugaring doesn't make a lot of sense, and probably only 
succeeds because the visitor later fixes up the problem (probably by 
realizing that the owner of the symbol 'i' and the symbol of this$0 
disagree, therefore adding a cast?)

Maurizio



On 24/10/16 21:11, Jan Lahoda wrote:
> Hi,
>
> Yes, the current behavior indeed appears to be wrong.
>
> This is what I think happens:
> Consider the "Issue8147527.super.i++;" statement from the example.
>
> In Lower.visitUnary, in the switch statement, in POSTINC/POSTDEC 
> section (this is the code that translates the ++/-- operators for 
> Integers to simplified AST that can be then written as bytecode):
> http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/88cc9b782624/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l3324 
>
>
> the result of "lowerBoxedPostop(tree)" is along these lines:
>
> (let /*synthetic*/ final Integer $997055773 = 
> (Integer)Issue8147527.super.i in (let /*synthetic*/ final Integer 
> $1063980005 = Issue8147527.super.i += 1 in $997055773))
>
> That seems OK. The problem is that after the invocation of translate, 
> the code looks like this:
>
> (let /*synthetic*/ final Integer $997055773 = 
> (Integer)Issue8147527.access$101(this$0) in (let /*synthetic*/ final 
> Integer $1063980005 = (let /*synthetic*/ final Issue8147527 $173214986 
> = this$0 in $173214986.i = 
> Integer.valueOf((int)($173214986.i.intValue() + 1))) in $997055773))
>
> This code is inside the Issue8147527.Inner class, and "this$0" is the 
> outer this, i.e. the enclosing instance Issue8147527. So the code is 
> actually manipulating the "i" variable from Issue8147527 not from the 
> Parent, which is apparently wrong. (In JDK-8143388 the situation was 
> different, as the Parent was in a different package, and so the 
> variable was not accessible and so the correct accessors were 
> generated after the fix.)
>
> I believe the main issue here is that in the first desugared code:
>
> (let /*synthetic*/ final Integer $997055773 = 
> (Integer)Issue8147527.super.i in (let /*synthetic*/ final Integer 
> $1063980005 = Issue8147527.super.i += 1 in $997055773))
>
> there is only a single tree node for "Issue8147527.super.i", reused on 
> two places. Further desugaring then replaces the "Issue8147527.super" 
> with "this$0" (see "tree.selected = translate(tree.selected);" in 
> Lower.visitSelect). This transiently leads to this code:
>
> (let /*synthetic*/ final Integer $997055773 = (Integer)this$0.i in 
> (let /*synthetic*/ final Integer $1063980005 = this$0.i += 1 in 
> $997055773))
>
> The first occurrence of "this$0.i" will get fixed by Lower.visitSelect 
> (see the call to the access method) to 
> "Issue8147527.access$101(this$0)", but the other one will not, causing 
> the problem.
>
> So far, it seems to me there are two possible fixes:
> 1) stop reusing the same tree on two places (each of them will get 
> translated independently, avoiding the problem).
> 2) avoid the modification of tree.selected in Lower.visitSelect
>
> Jan
>
> On 24.10.2016 15:50, Maurizio Cimadamore wrote:
>> I agree that something is up here - I think the patch in 8143388
>> affected the way in which the synthetic tree was typed and this results
>> in javac picking up the from member.
>>
>> Maurizio
>>
>>
>> On 24/10/16 12:34, bsrbnd wrote:
>>> Hi,
>>>
>>> This issue is definitly very strange...
>>> Examining deeply (with javap) my last patch, I came to the conclusion
>>> that the changeset for issue 8143388 is perhaps wrong.
>>> Consider the following example:
>>>
>>> class Issue8147527 extends Parent {
>>>      public static void main(String[] args) {
>>>          Issue8147527 self = new Issue8147527();
>>>          self.testAll();
>>>      }
>>>
>>>      private void testAll() {
>>>          System.out.println(test());
>>>          System.out.println(i);
>>>
>>>          Inner in = new Inner();
>>>          System.out.println(in.test());
>>>          System.out.println(i);
>>>
>>>          System.out.println(testParent());
>>>          System.out.println(super.i);
>>>
>>>          System.out.println(in.testParent());
>>>          System.out.println(super.i);
>>>      }
>>>
>>>      Integer i=0;
>>>      private Integer test() {
>>>          return this.i++;
>>>      }
>>>
>>>      class Inner {
>>>          private Integer test() {
>>>              return Issue8147527.this.i++;
>>>          }
>>>          private Integer testParent() {
>>>              return Issue8147527.super.i++;
>>>          }
>>>      }
>>>
>>>      private Integer testParent() {
>>>          return super.i++;
>>>      }
>>> }
>>>
>>> class Parent {
>>>      protected Integer i=10;
>>> }
>>>
>>> Running it gives the following output:
>>> 0
>>> 1
>>> 1
>>> 2
>>> 10
>>> 11
>>> 11
>>> 11
>>>
>>> If I rollback issue 8143388 changeset, I get the following output;
>>> last line looks better (I think):
>>> 0
>>> 1
>>> 1
>>> 2
>>> 10
>>> 11
>>> 11
>>> 12
>>>
>>> Examining the generated code of "Inner" (I added a comment surrounded
>>> with !!!), we had:
>>>
>>>    private java.lang.Integer testParent();
>>>      Code:
>>>         0: aload_0
>>>         1: getfield      #3                  // Field
>>> this$0:LIssue8147527;
>>>         4: invokestatic  #8                  // Method
>>> Issue8147527.access$201:(LIssue8147527;)Ljava/lang/Integer;
>>>         7: astore_1                          // !!! REFERENCE TO VALUE
>>> OF Field Parent.i:Ljava/lang/Integer; !!!
>>>         8: aload_0
>>>         9: getfield      #3                  // Field
>>> this$0:LIssue8147527;
>>>        12: astore_3
>>>        13: aload_3
>>>        14: aload_3
>>>        15: getfield      #5                  // Field
>>> Issue8147527.i:Ljava/lang/Integer;
>>>        18: invokevirtual #6                  // Method
>>> java/lang/Integer.intValue:()I
>>>        21: iconst_1
>>>        22: iadd
>>>        23: invokestatic  #7                  // Method
>>> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>>>        26: dup_x1
>>>        27: putfield      #5                  // Field
>>> Issue8147527.i:Ljava/lang/Integer;
>>>        30: astore_2
>>>        31: aload_1                           // !!! REFERENCE TO VALUE
>>> OF Field Parent.i:Ljava/lang/Integer; !!!
>>>        32: areturn
>>>
>>> And rollbacking issue 8143388 changeset, we have (which looks better,
>>> I think):
>>>
>>>    private java.lang.Integer testParent();
>>>      Code:
>>>         0: aload_0
>>>         1: getfield      #3                  // Field
>>> this$0:LIssue8147527;
>>>         4: astore_1
>>>         5: aload_1
>>>         6: getfield      #8                  // Field
>>> Parent.i:Ljava/lang/Integer;
>>>         9: astore_2
>>>        10: aload_1
>>>        11: aload_1
>>>        12: getfield      #8                  // Field
>>> Parent.i:Ljava/lang/Integer;
>>>        15: invokevirtual #6                  // Method
>>> java/lang/Integer.intValue:()I
>>>        18: iconst_1
>>>        19: iadd
>>>        20: invokestatic  #7                  // Method
>>> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>>>        23: dup_x1
>>>        24: putfield      #8                  // Field
>>> Parent.i:Ljava/lang/Integer;
>>>        27: astore_3
>>>        28: aload_2
>>>        29: areturn
>>>
>>> Is issue 8143388 changeset really correct and harmless?
>>>
>>> Thanks,
>>> Bernard
>>>
>>>
>>> 2016-10-22 18:05 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>>>> Hi,
>>>>
>>>> Next is a probably better patch (derived from issue 8143388 changeset)
>>>> that handles also "this, this$0, ..." in addition to the existing
>>>> "super" handling. It optimizes the both cases ("this" and "super")
>>>> described in issue 8147527.
>>>> Notice that "thisDollar" could be part of the "Names" class if
>>>> necessary.
>>>>
>>>> Bernard
>>>>
>>>> diff --git
>>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>> --- 
>>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>> +++ 
>>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>> @@ -2218,8 +2218,10 @@
>>>>                   return builder.build(rval);
>>>>           }
>>>>           Name name = TreeInfo.name(rval);
>>>> -        if (name == names._super)
>>>> +        Name thisDollar = names.fromString(names._this + "$");
>>>> +        if (name != null && (name == names._super || name ==
>>>> names._this || name.startsWith(thisDollar))) {
>>>>               return builder.build(rval);
>>>> +        }
>>>>           VarSymbol var =
>>>>               new VarSymbol(FINAL|SYNTHETIC,
>>>>                             names.fromString(
>>>>
>>>>
>>>> 2016-10-10 13:45 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>>>>> Hi,
>>>>>
>>>>> Consider the following example slightly modified from issue 8147527
>>>>> description to incorporate an assignment operator and an inner class
>>>>> which are both of them involved in the optimization process:
>>>>>
>>>>> class Issue8147527 {
>>>>>      Integer i=0;
>>>>>      private Integer test() {
>>>>>          this.i += 3;
>>>>>          for (; i<5; this.i++);
>>>>>          return this.i++;
>>>>>      }
>>>>>
>>>>>      Integer j=10;
>>>>>      class Inner {
>>>>>          private Integer test() {
>>>>>              return Issue8147527.this.j++;
>>>>>          }
>>>>>      }
>>>>>
>>>>>      public static void main(String[] args) {
>>>>>          Issue8147527 self = new Issue8147527();
>>>>>          System.out.println(self.test());
>>>>>          System.out.println(self.i);
>>>>>
>>>>>          Inner in = self.new Inner();
>>>>>          System.out.println(in.test());
>>>>>          System.out.println(self.j);
>>>>>      }
>>>>> }
>>>>>
>>>>> The following patch omits "this" for the special case of a
>>>>> select-expression used as an lvalue.
>>>>> Thus we had before optimization:
>>>>>
>>>>>    private java.lang.Integer test();
>>>>>      Code:
>>>>>         0: aload_0
>>>>>         1: astore_1
>>>>>         2: aload_1
>>>>>         3: aload_1
>>>>>         4: getfield      #3                  // Field
>>>>> i:Ljava/lang/Integer;
>>>>>         7: invokevirtual #5                  // Method
>>>>> java/lang/Integer.intValue:()I
>>>>>        10: iconst_3
>>>>>        11: iadd
>>>>>        12: invokestatic  #2                  // Method
>>>>> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>>>>>        15: dup_x1
>>>>>        16: putfield      #3                  // Field
>>>>> i:Ljava/lang/Integer;
>>>>>
>>>>> And after optimization, we have:
>>>>>
>>>>>    private java.lang.Integer test();
>>>>>      Code:
>>>>>         0: aload_0
>>>>>         1: aload_0
>>>>>         2: getfield      #3                  // Field
>>>>> i:Ljava/lang/Integer;
>>>>>         5: invokevirtual #5                  // Method
>>>>> java/lang/Integer.intValue:()I
>>>>>         8: iconst_3
>>>>>         9: iadd
>>>>>        10: invokestatic  #2                  // Method
>>>>> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>>>>>        13: putfield      #3                  // Field
>>>>> i:Ljava/lang/Integer;
>>>>>
>>>>> I've run all javac tests and it seems quite good.
>>>>> Notice that I haven't checked the "super" case yet, waiting for any
>>>>> feedback about the first optimization.
>>>>>
>>>>> Regards,
>>>>> Bernard
>>>>>
>>>>> diff --git
>>>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>>> ---
>>>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>>> +++
>>>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>>> @@ -2253,6 +2253,7 @@
>>>>>           case SELECT: {
>>>>>               final JCFieldAccess s = (JCFieldAccess)lval;
>>>>>               Symbol lid = TreeInfo.symbol(s.selected);
>>>>> +            if (lid != null && lid.name.equals(names._this)) return
>>>>> builder.build(make.Ident(s.sym));
>>>>>               if (lid != null && lid.kind == TYP) return
>>>>> builder.build(lval);
>>>>>               return abstractRval(s.selected, new TreeBuilder() {
>>>>>                       public JCExpression build(final JCExpression
>>>>> selected) {
>>


From jan.lahoda at oracle.com  Tue Oct 25 12:15:24 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 25 Oct 2016 14:15:24 +0200
Subject: [PATCH] 8147527: Non-optimal code generated for postfix unary
	operators
In-Reply-To: <c929b65f-24ee-d061-d77a-3af17052337d@oracle.com>
References: <CAEgw74A6RLjAH0knfYwmqWx_CrLpR8xQBuy+c4ucC6SaAPXqog@mail.gmail.com>
	<CAEgw74AokHc6yyQjFqTi4wW2-4rTBUcjeH2n6cerO74hv4n_4Q@mail.gmail.com>
	<CAEgw74Ay_78UxGG8uLz6vBCZ4QALB=hP26PtqRDRpo_a-y4Y5A@mail.gmail.com>
	<a4ee7750-6544-09ad-5629-3bf245fedf40@oracle.com>
	<580E6B06.5000800@oracle.com>
	<c929b65f-24ee-d061-d77a-3af17052337d@oracle.com>
Message-ID: <580F4CDC.3020408@oracle.com>

On 25.10.2016 10:41, Maurizio Cimadamore wrote:
> Hi Jan,
> great analysis. I think (1) could be a safer path - but I admit I'm not
> entirely sold on another point; you say:
>
> "Further desugaring then replaces the "Issue8147527.super" with "this$0"
> (see "tree.selected = translate(tree.selected);" in Lower.visitSelect)"
>
> Isn't this already wrong? The static type of this$0 is Issue8147527,
> which is different from the static type of this.super (Parent).
> Shouldn't javac at least emit a cast there to preserve typing? While I
> don't dispute the other problems you discovered, which are real, I think
> the above desugaring doesn't make a lot of sense, and probably only
> succeeds because the visitor later fixes up the problem (probably by
> realizing that the owner of the symbol 'i' and the symbol of this$0
> disagree, therefore adding a cast?)

Normally (when the same tree is not reused), this is only a transient 
state inside the visitSelect method - the method keeps a flag 
(qualifiedSuperAccess) that the select expression is a the form 
"X.super", and this will then force generation of an accessor 
invocation, replacing the whole JCFieldAccess with something like 
"Issue8147527.access$101(this$0)". But in case of reused trees, this 
will only correct/replace the first use of the tree, and the subsequent 
one will remain broken.

Jan

>
> Maurizio
>
>
>
> On 24/10/16 21:11, Jan Lahoda wrote:
>> Hi,
>>
>> Yes, the current behavior indeed appears to be wrong.
>>
>> This is what I think happens:
>> Consider the "Issue8147527.super.i++;" statement from the example.
>>
>> In Lower.visitUnary, in the switch statement, in POSTINC/POSTDEC
>> section (this is the code that translates the ++/-- operators for
>> Integers to simplified AST that can be then written as bytecode):
>> http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/88cc9b782624/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l3324
>>
>>
>> the result of "lowerBoxedPostop(tree)" is along these lines:
>>
>> (let /*synthetic*/ final Integer $997055773 =
>> (Integer)Issue8147527.super.i in (let /*synthetic*/ final Integer
>> $1063980005 = Issue8147527.super.i += 1 in $997055773))
>>
>> That seems OK. The problem is that after the invocation of translate,
>> the code looks like this:
>>
>> (let /*synthetic*/ final Integer $997055773 =
>> (Integer)Issue8147527.access$101(this$0) in (let /*synthetic*/ final
>> Integer $1063980005 = (let /*synthetic*/ final Issue8147527 $173214986
>> = this$0 in $173214986.i =
>> Integer.valueOf((int)($173214986.i.intValue() + 1))) in $997055773))
>>
>> This code is inside the Issue8147527.Inner class, and "this$0" is the
>> outer this, i.e. the enclosing instance Issue8147527. So the code is
>> actually manipulating the "i" variable from Issue8147527 not from the
>> Parent, which is apparently wrong. (In JDK-8143388 the situation was
>> different, as the Parent was in a different package, and so the
>> variable was not accessible and so the correct accessors were
>> generated after the fix.)
>>
>> I believe the main issue here is that in the first desugared code:
>>
>> (let /*synthetic*/ final Integer $997055773 =
>> (Integer)Issue8147527.super.i in (let /*synthetic*/ final Integer
>> $1063980005 = Issue8147527.super.i += 1 in $997055773))
>>
>> there is only a single tree node for "Issue8147527.super.i", reused on
>> two places. Further desugaring then replaces the "Issue8147527.super"
>> with "this$0" (see "tree.selected = translate(tree.selected);" in
>> Lower.visitSelect). This transiently leads to this code:
>>
>> (let /*synthetic*/ final Integer $997055773 = (Integer)this$0.i in
>> (let /*synthetic*/ final Integer $1063980005 = this$0.i += 1 in
>> $997055773))
>>
>> The first occurrence of "this$0.i" will get fixed by Lower.visitSelect
>> (see the call to the access method) to
>> "Issue8147527.access$101(this$0)", but the other one will not, causing
>> the problem.
>>
>> So far, it seems to me there are two possible fixes:
>> 1) stop reusing the same tree on two places (each of them will get
>> translated independently, avoiding the problem).
>> 2) avoid the modification of tree.selected in Lower.visitSelect
>>
>> Jan
>>
>> On 24.10.2016 15:50, Maurizio Cimadamore wrote:
>>> I agree that something is up here - I think the patch in 8143388
>>> affected the way in which the synthetic tree was typed and this results
>>> in javac picking up the from member.
>>>
>>> Maurizio
>>>
>>>
>>> On 24/10/16 12:34, bsrbnd wrote:
>>>> Hi,
>>>>
>>>> This issue is definitly very strange...
>>>> Examining deeply (with javap) my last patch, I came to the conclusion
>>>> that the changeset for issue 8143388 is perhaps wrong.
>>>> Consider the following example:
>>>>
>>>> class Issue8147527 extends Parent {
>>>>      public static void main(String[] args) {
>>>>          Issue8147527 self = new Issue8147527();
>>>>          self.testAll();
>>>>      }
>>>>
>>>>      private void testAll() {
>>>>          System.out.println(test());
>>>>          System.out.println(i);
>>>>
>>>>          Inner in = new Inner();
>>>>          System.out.println(in.test());
>>>>          System.out.println(i);
>>>>
>>>>          System.out.println(testParent());
>>>>          System.out.println(super.i);
>>>>
>>>>          System.out.println(in.testParent());
>>>>          System.out.println(super.i);
>>>>      }
>>>>
>>>>      Integer i=0;
>>>>      private Integer test() {
>>>>          return this.i++;
>>>>      }
>>>>
>>>>      class Inner {
>>>>          private Integer test() {
>>>>              return Issue8147527.this.i++;
>>>>          }
>>>>          private Integer testParent() {
>>>>              return Issue8147527.super.i++;
>>>>          }
>>>>      }
>>>>
>>>>      private Integer testParent() {
>>>>          return super.i++;
>>>>      }
>>>> }
>>>>
>>>> class Parent {
>>>>      protected Integer i=10;
>>>> }
>>>>
>>>> Running it gives the following output:
>>>> 0
>>>> 1
>>>> 1
>>>> 2
>>>> 10
>>>> 11
>>>> 11
>>>> 11
>>>>
>>>> If I rollback issue 8143388 changeset, I get the following output;
>>>> last line looks better (I think):
>>>> 0
>>>> 1
>>>> 1
>>>> 2
>>>> 10
>>>> 11
>>>> 11
>>>> 12
>>>>
>>>> Examining the generated code of "Inner" (I added a comment surrounded
>>>> with !!!), we had:
>>>>
>>>>    private java.lang.Integer testParent();
>>>>      Code:
>>>>         0: aload_0
>>>>         1: getfield      #3                  // Field
>>>> this$0:LIssue8147527;
>>>>         4: invokestatic  #8                  // Method
>>>> Issue8147527.access$201:(LIssue8147527;)Ljava/lang/Integer;
>>>>         7: astore_1                          // !!! REFERENCE TO VALUE
>>>> OF Field Parent.i:Ljava/lang/Integer; !!!
>>>>         8: aload_0
>>>>         9: getfield      #3                  // Field
>>>> this$0:LIssue8147527;
>>>>        12: astore_3
>>>>        13: aload_3
>>>>        14: aload_3
>>>>        15: getfield      #5                  // Field
>>>> Issue8147527.i:Ljava/lang/Integer;
>>>>        18: invokevirtual #6                  // Method
>>>> java/lang/Integer.intValue:()I
>>>>        21: iconst_1
>>>>        22: iadd
>>>>        23: invokestatic  #7                  // Method
>>>> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>>>>        26: dup_x1
>>>>        27: putfield      #5                  // Field
>>>> Issue8147527.i:Ljava/lang/Integer;
>>>>        30: astore_2
>>>>        31: aload_1                           // !!! REFERENCE TO VALUE
>>>> OF Field Parent.i:Ljava/lang/Integer; !!!
>>>>        32: areturn
>>>>
>>>> And rollbacking issue 8143388 changeset, we have (which looks better,
>>>> I think):
>>>>
>>>>    private java.lang.Integer testParent();
>>>>      Code:
>>>>         0: aload_0
>>>>         1: getfield      #3                  // Field
>>>> this$0:LIssue8147527;
>>>>         4: astore_1
>>>>         5: aload_1
>>>>         6: getfield      #8                  // Field
>>>> Parent.i:Ljava/lang/Integer;
>>>>         9: astore_2
>>>>        10: aload_1
>>>>        11: aload_1
>>>>        12: getfield      #8                  // Field
>>>> Parent.i:Ljava/lang/Integer;
>>>>        15: invokevirtual #6                  // Method
>>>> java/lang/Integer.intValue:()I
>>>>        18: iconst_1
>>>>        19: iadd
>>>>        20: invokestatic  #7                  // Method
>>>> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>>>>        23: dup_x1
>>>>        24: putfield      #8                  // Field
>>>> Parent.i:Ljava/lang/Integer;
>>>>        27: astore_3
>>>>        28: aload_2
>>>>        29: areturn
>>>>
>>>> Is issue 8143388 changeset really correct and harmless?
>>>>
>>>> Thanks,
>>>> Bernard
>>>>
>>>>
>>>> 2016-10-22 18:05 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>>>>> Hi,
>>>>>
>>>>> Next is a probably better patch (derived from issue 8143388 changeset)
>>>>> that handles also "this, this$0, ..." in addition to the existing
>>>>> "super" handling. It optimizes the both cases ("this" and "super")
>>>>> described in issue 8147527.
>>>>> Notice that "thisDollar" could be part of the "Names" class if
>>>>> necessary.
>>>>>
>>>>> Bernard
>>>>>
>>>>> diff --git
>>>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>>> ---
>>>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>>> +++
>>>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>>> @@ -2218,8 +2218,10 @@
>>>>>                   return builder.build(rval);
>>>>>           }
>>>>>           Name name = TreeInfo.name(rval);
>>>>> -        if (name == names._super)
>>>>> +        Name thisDollar = names.fromString(names._this + "$");
>>>>> +        if (name != null && (name == names._super || name ==
>>>>> names._this || name.startsWith(thisDollar))) {
>>>>>               return builder.build(rval);
>>>>> +        }
>>>>>           VarSymbol var =
>>>>>               new VarSymbol(FINAL|SYNTHETIC,
>>>>>                             names.fromString(
>>>>>
>>>>>
>>>>> 2016-10-10 13:45 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>>>>>> Hi,
>>>>>>
>>>>>> Consider the following example slightly modified from issue 8147527
>>>>>> description to incorporate an assignment operator and an inner class
>>>>>> which are both of them involved in the optimization process:
>>>>>>
>>>>>> class Issue8147527 {
>>>>>>      Integer i=0;
>>>>>>      private Integer test() {
>>>>>>          this.i += 3;
>>>>>>          for (; i<5; this.i++);
>>>>>>          return this.i++;
>>>>>>      }
>>>>>>
>>>>>>      Integer j=10;
>>>>>>      class Inner {
>>>>>>          private Integer test() {
>>>>>>              return Issue8147527.this.j++;
>>>>>>          }
>>>>>>      }
>>>>>>
>>>>>>      public static void main(String[] args) {
>>>>>>          Issue8147527 self = new Issue8147527();
>>>>>>          System.out.println(self.test());
>>>>>>          System.out.println(self.i);
>>>>>>
>>>>>>          Inner in = self.new Inner();
>>>>>>          System.out.println(in.test());
>>>>>>          System.out.println(self.j);
>>>>>>      }
>>>>>> }
>>>>>>
>>>>>> The following patch omits "this" for the special case of a
>>>>>> select-expression used as an lvalue.
>>>>>> Thus we had before optimization:
>>>>>>
>>>>>>    private java.lang.Integer test();
>>>>>>      Code:
>>>>>>         0: aload_0
>>>>>>         1: astore_1
>>>>>>         2: aload_1
>>>>>>         3: aload_1
>>>>>>         4: getfield      #3                  // Field
>>>>>> i:Ljava/lang/Integer;
>>>>>>         7: invokevirtual #5                  // Method
>>>>>> java/lang/Integer.intValue:()I
>>>>>>        10: iconst_3
>>>>>>        11: iadd
>>>>>>        12: invokestatic  #2                  // Method
>>>>>> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>>>>>>        15: dup_x1
>>>>>>        16: putfield      #3                  // Field
>>>>>> i:Ljava/lang/Integer;
>>>>>>
>>>>>> And after optimization, we have:
>>>>>>
>>>>>>    private java.lang.Integer test();
>>>>>>      Code:
>>>>>>         0: aload_0
>>>>>>         1: aload_0
>>>>>>         2: getfield      #3                  // Field
>>>>>> i:Ljava/lang/Integer;
>>>>>>         5: invokevirtual #5                  // Method
>>>>>> java/lang/Integer.intValue:()I
>>>>>>         8: iconst_3
>>>>>>         9: iadd
>>>>>>        10: invokestatic  #2                  // Method
>>>>>> java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
>>>>>>        13: putfield      #3                  // Field
>>>>>> i:Ljava/lang/Integer;
>>>>>>
>>>>>> I've run all javac tests and it seems quite good.
>>>>>> Notice that I haven't checked the "super" case yet, waiting for any
>>>>>> feedback about the first optimization.
>>>>>>
>>>>>> Regards,
>>>>>> Bernard
>>>>>>
>>>>>> diff --git
>>>>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>>>> ---
>>>>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>>>> +++
>>>>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>>>>>> @@ -2253,6 +2253,7 @@
>>>>>>           case SELECT: {
>>>>>>               final JCFieldAccess s = (JCFieldAccess)lval;
>>>>>>               Symbol lid = TreeInfo.symbol(s.selected);
>>>>>> +            if (lid != null && lid.name.equals(names._this)) return
>>>>>> builder.build(make.Ident(s.sym));
>>>>>>               if (lid != null && lid.kind == TYP) return
>>>>>> builder.build(lval);
>>>>>>               return abstractRval(s.selected, new TreeBuilder() {
>>>>>>                       public JCExpression build(final JCExpression
>>>>>> selected) {
>>>
>

From tim.bell at oracle.com  Tue Oct 25 14:37:20 2016
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 25 Oct 2016 07:37:20 -0700
Subject: RFR: 8168369, , fix for langtools intermittent failures needs to check
	PRODUCT_HOME
Message-ID: <230f1499-23b9-1fe5-04fe-0358417476b4@oracle.com>

Hello

In the matter of intermittent test failures when run on 32-bit JVM 
installs.  My previous makefile fix [1] needs to check TESTJAVA instead 
of JT_JAVA.  Note: PRODUCT_HOME becomes TESTJAVA inside 
langtools/test/Makefile.

The bug report:
https://bugs.openjdk.java.net/browse/JDK-8168369

The webrev:
http://cr.openjdk.java.net/~tbell/8168369/

Thanks in advance-

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

From erik.joelsson at oracle.com  Tue Oct 25 15:04:00 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 25 Oct 2016 17:04:00 +0200
Subject: RFR: 8168369, , fix for langtools intermittent failures needs to
	check PRODUCT_HOME
In-Reply-To: <230f1499-23b9-1fe5-04fe-0358417476b4@oracle.com>
References: <230f1499-23b9-1fe5-04fe-0358417476b4@oracle.com>
Message-ID: <37c47462-03c5-31bf-50e9-948e0cd19694@oracle.com>

Looks good to me.

/Erik


On 2016-10-25 16:37, Tim Bell wrote:
> Hello
>
> In the matter of intermittent test failures when run on 32-bit JVM 
> installs.  My previous makefile fix [1] needs to check TESTJAVA 
> instead of JT_JAVA.  Note: PRODUCT_HOME becomes TESTJAVA inside 
> langtools/test/Makefile.
>
> The bug report:
> https://bugs.openjdk.java.net/browse/JDK-8168369
>
> The webrev:
> http://cr.openjdk.java.net/~tbell/8168369/
>
> Thanks in advance-
>
> Tim
> [1] https://bugs.openjdk.java.net/browse/JDK-8167600


From joe.darcy at oracle.com  Tue Oct 25 15:36:56 2016
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 25 Oct 2016 08:36:56 -0700
Subject: RFR: 8168369, , fix for langtools intermittent failures needs to
	check PRODUCT_HOME
In-Reply-To: <230f1499-23b9-1fe5-04fe-0358417476b4@oracle.com>
References: <230f1499-23b9-1fe5-04fe-0358417476b4@oracle.com>
Message-ID: <0166c29a-c75d-a7c6-971f-351c7afe51a4@oracle.com>

Look fine Tim; thanks,

-Joe


On 10/25/2016 7:37 AM, Tim Bell wrote:
> Hello
>
> In the matter of intermittent test failures when run on 32-bit JVM 
> installs.  My previous makefile fix [1] needs to check TESTJAVA 
> instead of JT_JAVA.  Note: PRODUCT_HOME becomes TESTJAVA inside 
> langtools/test/Makefile.
>
> The bug report:
> https://bugs.openjdk.java.net/browse/JDK-8168369
>
> The webrev:
> http://cr.openjdk.java.net/~tbell/8168369/
>
> Thanks in advance-
>
> Tim
> [1] https://bugs.openjdk.java.net/browse/JDK-8167600


From Ronald_Servant at ca.ibm.com  Tue Oct 25 20:02:02 2016
From: Ronald_Servant at ca.ibm.com (Ronald Servant)
Date: Tue, 25 Oct 2016 20:02:02 +0000
Subject: NPE in isSignaturePolymorphic(jdk.compiler@9-internal/Types.java:1079)
Message-ID: <OF07A665B5.057EE83D-ON00258057.00515B84-00258057.006E0CB3@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161025/60133e28/attachment-0001.html>

From maurizio.cimadamore at oracle.com  Tue Oct 25 20:29:16 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 25 Oct 2016 21:29:16 +0100
Subject: NPE in
	isSignaturePolymorphic(jdk.compiler@9-internal/Types.java:1079)
In-Reply-To: <OF07A665B5.057EE83D-ON00258057.00515B84-00258057.006E0CB3@notes.na.collabserv.com>
References: <OF07A665B5.057EE83D-ON00258057.00515B84-00258057.006E0CB3@notes.na.collabserv.com>
Message-ID: <edd551f9-99f8-56ef-a6d5-516177ff295f@oracle.com>

Thanks for the headsup (and the patch). This is an oversight in our 
implementation.

Maurizio


On 25/10/16 21:02, Ronald Servant wrote:
>
> Hi,
>
> When compiling the IBM J9 JVM classes for method handles, we hit an 
> internal compiler bug.
>
> java.lang.NullPointerException
>
>  at com.sun.tools.javac.code.Types.isSignaturePolymorphic(Types.java:1005)
>
>  at 
> com.sun.tools.javac.comp.MemberEnter.visitMethodDef(MemberEnter.java:199)
>
>  at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:852)
>
>  at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:161)
>
>  at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:173)
>
>  at 
> com.sun.tools.javac.comp.TypeEnter$MembersPhase.finishClass(TypeEnter.java:968)
>
>  at 
> com.sun.tools.javac.comp.TypeEnter$MembersPhase.runPhase(TypeEnter.java:953)
>
>  at 
> com.sun.tools.javac.comp.TypeEnter$Phase.doCompleteEnvs(TypeEnter.java:272)
>
>  at 
> com.sun.tools.javac.comp.TypeEnter$MembersPhase.doCompleteEnvs(TypeEnter.java:888)
>
>  at 
> com.sun.tools.javac.comp.TypeEnter$Phase.completeEnvs(TypeEnter.java:247)
>
> The check performed in isSignaturePolymorphic() assumes that all 
> native methods in MethodHandle or VarHandle will have at least 1 
> parameter.  That true for OpenJDK, but in the J9 implementation, we 
> have native methods without parameters.  This issue can be reproduced 
> by applying patch[1] below.
>
> Patch[2], below, adds a null check before 'argtypes.tail.tail == 
> null', as the NPE occurs when the second tail variable is dereferenced.
>
> When a native method with no parameters is added to MethodHandle or 
> VarHandle, 'argtypes.tail' is null.   It might also be prudent to add 
> a null check to argtypesbefore dereferencing argtypes.tail.
>
> Patch[1]:
>
> To reproduce apply this patch to the jdk repository, and run make all 
> (or make java.base):
>
> diff -r 11e15af1947f 
> src/java.base/share/classes/java/lang/invoke/MethodHandle.java
>
> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandle.java   
>  Tue Oct 25 07:38:50 2016 -0700
>
> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandle.java   
>  Tue Oct 25 15:54:56 2016 -0400
>
> @@ -483,6 +483,12 @@
>
>     */
>
>    @HotSpotIntrinsicCandidate
>
>    public final native @PolymorphicSignature Object 
> invokeExact(Object... args) throws Throwable;
>
> +
>
> +    /**
>
> +     * this is a test method to reproduce a bug in javac
>
> +     * @return nothing of interest
>
> +     */
>
> +    public static native Object test();
>
>    /**
>
>     * Invokes the method handle, allowing any caller type descriptor,
>
> @@ -1594,4 +1600,5 @@
>
>            throw newInternalError(ex);
>
>        }
>
>    }
>
> +
>
>  }
>
> Patch[2]:
>
> To fix, apply this patch:
>
> diff -r 32444e1ad88a 
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
>
> --- 
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java 
>  Tue Oct 25 08:39:12 2016 -0700
>
> +++ 
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java 
>  Tue Oct 25 15:57:05 2016 -0400
>
> @@ -1004,6 +1004,7 @@
>
>       List<Type> argtypes = msym.type.getParameterTypes();
>
>       return (msym.flags_field & NATIVE) != 0 &&
>
>             (msym.owner == syms.methodHandleType.tsym || msym.owner == 
> syms.varHandleType.tsym) &&
>
> +               argtypes.tail != null &&
>
>               argtypes.tail.tail == null &&
>
>               argtypes.head.hasTag(TypeTag.ARRAY) &&
>
>               ((ArrayType)argtypes.head).elemtype.tsym == 
> syms.objectType.tsym;
>
> Thank you,
> Ronald Servant
>

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

From alex.buckley at oracle.com  Tue Oct 25 20:47:49 2016
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 25 Oct 2016 13:47:49 -0700
Subject: NPE in
	isSignaturePolymorphic(jdk.compiler@9-internal/Types.java:1079)
In-Reply-To: <OF07A665B5.057EE83D-ON00258057.00515B84-00258057.006E0CB3@notes.na.collabserv.com>
References: <OF07A665B5.057EE83D-ON00258057.00515B84-00258057.006E0CB3@notes.na.collabserv.com>
Message-ID: <580FC4F5.1050300@oracle.com>

Hi Ronald,

On 10/25/2016 1:02 PM, Ronald Servant wrote:
> The check performed in isSignaturePolymorphic() assumes that all native
> methods in MethodHandle or VarHandle will have at least 1 parameter.
>   That true for OpenJDK, but in the J9 implementation, we have native
> methods without parameters.  This issue can be reproduced by applying
> patch[1] below.

Just to clarify: you are NOT suggesting that javac should treat 
zero-arity native methods in MethodHandle as signature polymorphic, right?

Alex

From forax at univ-mlv.fr  Tue Oct 25 22:01:54 2016
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 25 Oct 2016 22:01:54 +0000
Subject: NPE
	in	isSignaturePolymorphic(jdk.compiler@9-internal/Types.java:1079)
In-Reply-To: <580FC4F5.1050300@oracle.com>
References: <OF07A665B5.057EE83D-ON00258057.00515B84-00258057.006E0CB3@notes.na.collabserv.com>
	<580FC4F5.1050300@oracle.com>
Message-ID: <53FF2862-CB39-4082-87FD-0CE3BD9D889F@univ-mlv.fr>

Hi Alex,
a method with no parameter type still have a return type that can be back propagated if it's a polymorphic signature.

Anyway, Ronald just found a bug in the implementation of javac in the code that try to detect is a method has a polymorphic signature.
It should be fixed.

R?mi 


On October 25, 2016 10:47:49 PM GMT+02:00, Alex Buckley <alex.buckley at oracle.com> wrote:
>Hi Ronald,
>
>On 10/25/2016 1:02 PM, Ronald Servant wrote:
>> The check performed in isSignaturePolymorphic() assumes that all
>native
>> methods in MethodHandle or VarHandle will have at least 1 parameter.
>>   That true for OpenJDK, but in the J9 implementation, we have native
>> methods without parameters.  This issue can be reproduced by applying
>> patch[1] below.
>
>Just to clarify: you are NOT suggesting that javac should treat 
>zero-arity native methods in MethodHandle as signature polymorphic,
>right?
>
>Alex

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161025/9946d450/attachment.html>

From alex.buckley at oracle.com  Tue Oct 25 22:11:35 2016
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 25 Oct 2016 15:11:35 -0700
Subject: NPE in
	isSignaturePolymorphic(jdk.compiler@9-internal/Types.java:1079)
In-Reply-To: <53FF2862-CB39-4082-87FD-0CE3BD9D889F@univ-mlv.fr>
References: <OF07A665B5.057EE83D-ON00258057.00515B84-00258057.006E0CB3@notes.na.collabserv.com>
	<580FC4F5.1050300@oracle.com>
	<53FF2862-CB39-4082-87FD-0CE3BD9D889F@univ-mlv.fr>
Message-ID: <580FD897.40507@oracle.com>

On 10/25/2016 3:01 PM, Remi Forax wrote:
> a method with no parameter type still have a return type that can be
> back propagated if it's a polymorphic signature.

I don't know what you mean.

Alex

From stuart.marks at oracle.com  Tue Oct 25 22:19:05 2016
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 25 Oct 2016 15:19:05 -0700
Subject: RFR(s): 8165646 (jdeprscan) adjust tool output to improve clarity
Message-ID: <d6dcfc66-077e-477b-75db-257d1d8a550e@oracle.com>

Hi all,

Please review this change to jdeprscan.

I've rearranged and cleaned up the output of jdeprscan so that it's a bit more 
readable (though only a bit) and to remove some checks, eliminating redundant 
output. For example, one case in the regression test output used to be

class jdk/jdeprusage/UseClass$Construct uses type 
jdk/deprcases/types/DeprecatedClass deprecated
class jdk/jdeprusage/UseClass$Construct uses method in type 
jdk/deprcases/types/DeprecatedClass deprecated

and now it is

class jdk/jdeprusage/UseClass$Construct uses deprecated class 
jdk/deprcases/types/DeprecatedClass

I also changed things to continue processing arguments if an error has occurred, 
and to support direct reading of .class files as well as loading class names 
from the class path.

Webrev:

     http://cr.openjdk.java.net/~smarks/reviews/8165646/webrev.0/

Thanks,

s'marks

From forax at univ-mlv.fr  Tue Oct 25 22:28:09 2016
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 25 Oct 2016 22:28:09 +0000
Subject: NPE
	in	isSignaturePolymorphic(jdk.compiler@9-internal/Types.java:1079)
In-Reply-To: <580FD897.40507@oracle.com>
References: <OF07A665B5.057EE83D-ON00258057.00515B84-00258057.006E0CB3@notes.na.collabserv.com>
	<580FC4F5.1050300@oracle.com>
	<53FF2862-CB39-4082-87FD-0CE3BD9D889F@univ-mlv.fr>
	<580FD897.40507@oracle.com>
Message-ID: <247D3E27-A82E-4C15-95B9-2D2FB2436447@univ-mlv.fr>

You can imagine a polymorphic signature that returns the current time as an int or a long depending on the call site. 

R?mi 

On October 26, 2016 12:11:35 AM GMT+02:00, Alex Buckley <alex.buckley at oracle.com> wrote:
>On 10/25/2016 3:01 PM, Remi Forax wrote:
>> a method with no parameter type still have a return type that can be
>> back propagated if it's a polymorphic signature.
>
>I don't know what you mean.
>
>Alex

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161025/58c8fed4/attachment.html>

From alex.buckley at oracle.com  Tue Oct 25 22:31:01 2016
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 25 Oct 2016 15:31:01 -0700
Subject: NPE in
	isSignaturePolymorphic(jdk.compiler@9-internal/Types.java:1079)
In-Reply-To: <247D3E27-A82E-4C15-95B9-2D2FB2436447@univ-mlv.fr>
References: <OF07A665B5.057EE83D-ON00258057.00515B84-00258057.006E0CB3@notes.na.collabserv.com>
	<580FC4F5.1050300@oracle.com>
	<53FF2862-CB39-4082-87FD-0CE3BD9D889F@univ-mlv.fr>
	<580FD897.40507@oracle.com>
	<247D3E27-A82E-4C15-95B9-2D2FB2436447@univ-mlv.fr>
Message-ID: <580FDD25.6080905@oracle.com>

Sure, but the definition of a signature polymorphic method is that it 
has exactly one formal parameter. There seems to be an undercurrent that 
methods can have no formal parameters and still be signature 
polymorphic, which is wrong.

Alex

On 10/25/2016 3:28 PM, Remi Forax wrote:
> You can imagine a polymorphic signature that returns the current time as
> an int or a long depending on the call site.
>
> R?mi
>
> On October 26, 2016 12:11:35 AM GMT+02:00, Alex Buckley
> <alex.buckley at oracle.com> wrote:
>
>     On 10/25/2016 3:01 PM, Remi Forax wrote:
>
>         a method with no parameter type still have a return type that can be
>         back propagated if it's a polymorphic signature.
>
>
>     I don't know what you mean.
>
>     Alex
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

From jonathan.gibbons at oracle.com  Tue Oct 25 23:17:51 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 25 Oct 2016 16:17:51 -0700
Subject: RFR(s): 8165646 (jdeprscan) adjust tool output to improve clarity
In-Reply-To: <d6dcfc66-077e-477b-75db-257d1d8a550e@oracle.com>
References: <d6dcfc66-077e-477b-75db-257d1d8a550e@oracle.com>
Message-ID: <988aa807-42dd-5827-2e5c-2d3504dc59c3@oracle.com>

Not entirely (but somewhat) related to this review, the message 
reporting is suspect.  You use out.println, which will do the right 
thing with respect to line endings on Windows, but the strings you print 
have embedded \n characters, which will not be translated into the 
correct separator on Windows.

In javac, we use methods that break the string to be printed into lines, 
and then println each line separately.

-- Jon


On 10/25/16 3:19 PM, Stuart Marks wrote:
> Hi all,
>
> Please review this change to jdeprscan.
>
> I've rearranged and cleaned up the output of jdeprscan so that it's a 
> bit more readable (though only a bit) and to remove some checks, 
> eliminating redundant output. For example, one case in the regression 
> test output used to be
>
> class jdk/jdeprusage/UseClass$Construct uses type 
> jdk/deprcases/types/DeprecatedClass deprecated
> class jdk/jdeprusage/UseClass$Construct uses method in type 
> jdk/deprcases/types/DeprecatedClass deprecated
>
> and now it is
>
> class jdk/jdeprusage/UseClass$Construct uses deprecated class 
> jdk/deprcases/types/DeprecatedClass
>
> I also changed things to continue processing arguments if an error has 
> occurred, and to support direct reading of .class files as well as 
> loading class names from the class path.
>
> Webrev:
>
>     http://cr.openjdk.java.net/~smarks/reviews/8165646/webrev.0/
>
> Thanks,
>
> s'marks


From srikanth.adayapalam at oracle.com  Wed Oct 26 06:25:07 2016
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Wed, 26 Oct 2016 11:55:07 +0530
Subject: spec clarification: wildcard array element signature
Message-ID: <58104C43.9020205@oracle.com>

*> Alex Buckley*alex.buckley at 
oracle.com<mailto:compiler-dev%40openjdk.java.net?Subject=Re%3A%20spec%20clarification%3A%20wildcard%20array%20element%20signature&In-Reply-To=%3C580E52CC.4030408%40oracle.com%3E>
/> Mon Oct 24 18:28:28 UTC 2016

/

>Third, on JDK 9b140, javac crashes if the declaration of i uses a
>bounded wildcard for B's type argument -- say B<? extends Number>.I

>java.lang.ClassCastException:
>com.sun.tools.javac.code.Type$TypeMapping$3 (in module: jdk.compiler)
>cannot be cast to
>com.sun.tools.javac.code.Type$WildcardType (in module: jdk.compiler) at
>com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.validateAnnotatedType(jdk.compiler at 9-ea 
<http://mail.openjdk.java.net/mailman/listinfo/compiler-dev>/Attr.java:4804)

I have raised https://bugs.openjdk.java.net/browse/JDK-8168760

Thanks!
Srikanth


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

From bsrbnd at gmail.com  Wed Oct 26 10:22:07 2016
From: bsrbnd at gmail.com (bsrbnd)
Date: Wed, 26 Oct 2016 12:22:07 +0200
Subject: [PATCH] 8147527: Non-optimal code generated for postfix unary
	operators
In-Reply-To: <580F4CDC.3020408@oracle.com>
References: <CAEgw74A6RLjAH0knfYwmqWx_CrLpR8xQBuy+c4ucC6SaAPXqog@mail.gmail.com>
	<CAEgw74AokHc6yyQjFqTi4wW2-4rTBUcjeH2n6cerO74hv4n_4Q@mail.gmail.com>
	<CAEgw74Ay_78UxGG8uLz6vBCZ4QALB=hP26PtqRDRpo_a-y4Y5A@mail.gmail.com>
	<a4ee7750-6544-09ad-5629-3bf245fedf40@oracle.com>
	<580E6B06.5000800@oracle.com>
	<c929b65f-24ee-d061-d77a-3af17052337d@oracle.com>
	<580F4CDC.3020408@oracle.com>
Message-ID: <CAEgw74CBsskc+F0SEKgS+ueAcm9QSg3XTZpWOF2Yv_Zf5buwuA@mail.gmail.com>

Hi,

2016-10-25 14:15 GMT+02:00 Jan Lahoda <jan.lahoda at oracle.com>:
> On 25.10.2016 10:41, Maurizio Cimadamore wrote:
>>
>> Hi Jan,
>> great analysis. I think (1) could be a safer path - but I admit I'm not
>> entirely sold on another point; you say:
>>
>> "Further desugaring then replaces the "Issue8147527.super" with "this$0"
>> (see "tree.selected = translate(tree.selected);" in Lower.visitSelect)"
>>
>> Isn't this already wrong? The static type of this$0 is Issue8147527,
>> which is different from the static type of this.super (Parent).
>> Shouldn't javac at least emit a cast there to preserve typing? While I
>> don't dispute the other problems you discovered, which are real, I think
>> the above desugaring doesn't make a lot of sense, and probably only
>> succeeds because the visitor later fixes up the problem (probably by
>> realizing that the owner of the symbol 'i' and the symbol of this$0
>> disagree, therefore adding a cast?)
>
>
> Normally (when the same tree is not reused), this is only a transient state
> inside the visitSelect method - the method keeps a flag
> (qualifiedSuperAccess) that the select expression is a the form "X.super",
> and this will then force generation of an accessor invocation, replacing the
> whole JCFieldAccess with something like "Issue8147527.access$101(this$0)".
> But in case of reused trees, this will only correct/replace the first use of
> the tree, and the subsequent one will remain broken.
>
If "tree.selected=..." appears to be a wrong transient state, then
avoiding it (option 2 that Jan suggested) depending on the
"qualifiedSuperAccess" flag and forcing the accessor generation could
be the best approach.

The fix, here below, shows the idea...

I know it is not perfect, but as it corrects this specific case (and
all test/tools/javac/boxing passed), I would like to know your opinion
about it.
Is this a good direction to search?

Bernard

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
@@ -145,6 +145,7 @@
     /** A hash table mapping local classes to their definitions.
      */
     Map<ClassSymbol, JCClassDecl> classdefs;
+    Map<ClassSymbol, JCClassDecl> allclassdefs = new HashMap<>();

     /** A hash table mapping local classes to a list of pruned trees.
      */
@@ -210,6 +211,8 @@
             classMap.scan(outermostClassDef);
             def = classdefs.get(c);
         }
+        if (def == null)
+            def = allclassdefs.get(c);
         return def;
     }

@@ -1100,6 +1103,7 @@
             tree = make.at(tree.pos).Ident(sym);
         }
         JCExpression base = (tree.hasTag(SELECT)) ? ((JCFieldAccess)
tree).selected : null;
+        base = base != null ? translate(base) : null;
         switch (sym.kind) {
         case TYP:
             if (sym.owner.kind != PCK) {
@@ -1300,7 +1304,9 @@
                 //odd access codes represent qualified super accesses - need to
                 //emit reference to the direct superclass, even if the refered
                 //member is from an indirect superclass (JLS 13.1)
-
site.setType(types.erasure(types.supertype(vsym.owner.enclClass().type)));
+                Type supertype = types.supertype(vsym.owner.enclClass().type);
+                if (!supertype.equals(syms.objectType))
+                    site.setType(types.erasure(supertype));
             }
             ref = make.Select(site, sym);
             args = make.Idents(md.params.tail);
@@ -2413,6 +2419,7 @@
             attrEnv = prevEnv;

         classdefs.put(currentClass, tree);
+        allclassdefs.put(currentClass, tree);

         proxies = proxies.dup(currentClass);
         List<VarSymbol> prevOuterThisStack = outerThisStack;
@@ -3837,7 +3844,7 @@
             tree.selected.hasTag(SELECT) &&
             TreeInfo.name(tree.selected) == names._super &&
             !types.isDirectSuperInterface(((JCFieldAccess)tree.selected).selected.type.tsym,
currentClass);
-        tree.selected = translate(tree.selected);
+        if (!qualifiedSuperAccess) tree.selected = translate(tree.selected);
         if (tree.name == names._class) {
             result = classOf(tree.selected);
         }

From maurizio.cimadamore at oracle.com  Wed Oct 26 10:35:01 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 26 Oct 2016 11:35:01 +0100
Subject: NPE in
	isSignaturePolymorphic(jdk.compiler@9-internal/Types.java:1079)
In-Reply-To: <580FDD25.6080905@oracle.com>
References: <OF07A665B5.057EE83D-ON00258057.00515B84-00258057.006E0CB3@notes.na.collabserv.com>
	<580FC4F5.1050300@oracle.com>
	<53FF2862-CB39-4082-87FD-0CE3BD9D889F@univ-mlv.fr>
	<580FD897.40507@oracle.com>
	<247D3E27-A82E-4C15-95B9-2D2FB2436447@univ-mlv.fr>
	<580FDD25.6080905@oracle.com>
Message-ID: <2174e119-9790-32ae-4f41-3ca511ced249@oracle.com>



On 25/10/16 23:31, Alex Buckley wrote:
> Sure, but the definition of a signature polymorphic method is that it 
> has exactly one formal parameter. There seems to be an undercurrent 
> that methods can have no formal parameters and still be signature 
> polymorphic, which is wrong.
My reading of this situation: the spec mandates that a poly sig method 
must have a varargs argument Object... - that will stay the same.

On the other hand, javac will crash whenever it finds a native method in 
MethodHandle.java that has no arguments. That must be fixed. But, after 
the fix, the 0-ary method will NOT be considered as a poly signature 
method by javac.

Maurizio
>
> Alex
>
> On 10/25/2016 3:28 PM, Remi Forax wrote:
>> You can imagine a polymorphic signature that returns the current time as
>> an int or a long depending on the call site.
>>
>> R?mi
>>
>> On October 26, 2016 12:11:35 AM GMT+02:00, Alex Buckley
>> <alex.buckley at oracle.com> wrote:
>>
>>     On 10/25/2016 3:01 PM, Remi Forax wrote:
>>
>>         a method with no parameter type still have a return type that 
>> can be
>>         back propagated if it's a polymorphic signature.
>>
>>
>>     I don't know what you mean.
>>
>>     Alex
>>
>>
>> -- 
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.


From Ronald_Servant at ca.ibm.com  Wed Oct 26 14:28:44 2016
From: Ronald_Servant at ca.ibm.com (Ronald Servant)
Date: Wed, 26 Oct 2016 14:28:44 +0000
Subject: NPE inisSignaturePolymorphic(jdk.compiler at
	9-internal/Types.java:1079)
Message-ID: <OF31548A37.76C0D047-ON00258058.004F3EF6-00258058.004F8910@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161026/77756750/attachment.html>

From maurizio.cimadamore at oracle.com  Wed Oct 26 14:39:01 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 26 Oct 2016 15:39:01 +0100
Subject: NPE inisSignaturePolymorphic(jdk.compiler at
	9-internal/Types.java:1079)
In-Reply-To: <OF31548A37.76C0D047-ON00258058.004F3EF6-00258058.004F8910@notes.na.collabserv.com>
References: <OF31548A37.76C0D047-ON00258058.004F3EF6-00258058.004F8910@notes.na.collabserv.com>
Message-ID: <fe97c955-4514-6c51-b246-f1f7c7e84110@oracle.com>

Thanks for the confirmation. A fix is in the works.

Maurizio


On 26/10/16 15:28, Ronald Servant wrote:
> >My reading of this situation: the spec mandates that a poly sig method
> >must have a varargs argument Object... - that will stay the same.
> >
> >On the other hand, javac will crash whenever it finds a native method in
> >MethodHandle.java that has no arguments. That must be fixed. But, after
> >the fix, the 0-ary method will NOT be considered as a poly signature
> >method by javac.
>
> >Maurizio
> Agreed. There was a bug in javac when trying to decide if the method 
> had a polymorphic signature. I'm not asking that we change the spec. :)
> Ron
>

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

From alex.buckley at oracle.com  Wed Oct 26 18:12:03 2016
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 26 Oct 2016 11:12:03 -0700
Subject: NPE inisSignaturePolymorphic(jdk.compiler at
	9-internal/Types.java:1079)
In-Reply-To: <OF31548A37.76C0D047-ON00258058.004F3EF6-00258058.004F8910@notes.na.collabserv.com>
References: <OF31548A37.76C0D047-ON00258058.004F3EF6-00258058.004F8910@notes.na.collabserv.com>
Message-ID: <5810F1F3.1000402@oracle.com>

On 10/26/2016 7:28 AM, Ronald Servant wrote:
>>My reading of this situation: the spec mandates that a poly sig method
>>must have a varargs argument Object... - that will stay the same.
>>
>>On the other hand, javac will crash whenever it finds a native method in
>>MethodHandle.java that has no arguments. That must be fixed. But, after
>>the fix, the 0-ary method will NOT be considered as a poly signature
>>method by javac.
>
>>Maurizio
>
> Agreed. There was a bug in javac when trying to decide if the method had
> a polymorphic signature. I'm not asking that we change the spec. :)
> Ron

Thanks Ron, that's all the clarification I was looking for.

Alex

From weijun.wang at oracle.com  Thu Oct 27 08:59:48 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 27 Oct 2016 16:59:48 +0800
Subject: How to compile code calling unexpected classes to an older release?
Message-ID: <2367EFE4-9983-4A81-8EFE-E51B0873875E@oracle.com>

I have a program like this:

public class A1 {
   public static void main(String[] args) throws Exception {
       new sun.security.util.HexDumpEncoder()
               .encodeBuffer(new byte[16], System.out);
   }
}

and I want to compile it to jdk8 using javac in jdk9.

It fails with

$ javac --release 8 A1.java
A1.java:7: error: package sun.security.util does not exist
       new sun.security.util.HexDumpEncoder()
                            ^
1 error

Same error if I added "--add-exports java.base/sun.security.util=ALL-UNNAMED", although I think that should be useless in this case.

Is there a way to do it?

Thanks
Max

P.S. I cannot just use javac from jdk8 because this is meant to be a jtreg test and the test might launch an earlier version of VM to execute itself again, and specifying -compilejdk:$JDK8 shows other failures (--class-path not recognizable).



From claes.redestad at oracle.com  Thu Oct 27 09:14:36 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 27 Oct 2016 11:14:36 +0200
Subject: How to compile code calling unexpected classes to an older
	release?
In-Reply-To: <2367EFE4-9983-4A81-8EFE-E51B0873875E@oracle.com>
References: <2367EFE4-9983-4A81-8EFE-E51B0873875E@oracle.com>
Message-ID: <fbfa39db-a045-64de-83c7-458762570119@oracle.com>

Hi,

"-XDignore.symbol.file -source 8 -target 8" can get your code to compile 
(add -nowarn or set a valid bootclasspath to get rid of the warning).

So, it seems --release 8 has issues with internal classes not visible to 
javac in 9?

/Claes

On 2016-10-27 10:59, Wang Weijun wrote:
> I have a program like this:
>
> public class A1 {
>     public static void main(String[] args) throws Exception {
>         new sun.security.util.HexDumpEncoder()
>                 .encodeBuffer(new byte[16], System.out);
>     }
> }
>
> and I want to compile it to jdk8 using javac in jdk9.
>
> It fails with
>
> $ javac --release 8 A1.java
> A1.java:7: error: package sun.security.util does not exist
>         new sun.security.util.HexDumpEncoder()
>                              ^
> 1 error
>
> Same error if I added "--add-exports java.base/sun.security.util=ALL-UNNAMED", although I think that should be useless in this case.
>
> Is there a way to do it?
>
> Thanks
> Max
>
> P.S. I cannot just use javac from jdk8 because this is meant to be a jtreg test and the test might launch an earlier version of VM to execute itself again, and specifying -compilejdk:$JDK8 shows other failures (--class-path not recognizable).
>
>


From bsrbnd at gmail.com  Thu Oct 27 13:33:45 2016
From: bsrbnd at gmail.com (bsrbnd)
Date: Thu, 27 Oct 2016 15:33:45 +0200
Subject: [PATCH] 8147527: Non-optimal code generated for postfix unary
	operators
In-Reply-To: <CAEgw74CBsskc+F0SEKgS+ueAcm9QSg3XTZpWOF2Yv_Zf5buwuA@mail.gmail.com>
References: <CAEgw74A6RLjAH0knfYwmqWx_CrLpR8xQBuy+c4ucC6SaAPXqog@mail.gmail.com>
	<CAEgw74AokHc6yyQjFqTi4wW2-4rTBUcjeH2n6cerO74hv4n_4Q@mail.gmail.com>
	<CAEgw74Ay_78UxGG8uLz6vBCZ4QALB=hP26PtqRDRpo_a-y4Y5A@mail.gmail.com>
	<a4ee7750-6544-09ad-5629-3bf245fedf40@oracle.com>
	<580E6B06.5000800@oracle.com>
	<c929b65f-24ee-d061-d77a-3af17052337d@oracle.com>
	<580F4CDC.3020408@oracle.com>
	<CAEgw74CBsskc+F0SEKgS+ueAcm9QSg3XTZpWOF2Yv_Zf5buwuA@mail.gmail.com>
Message-ID: <CAEgw74AZaT0-SAQNPTYL+_i5orfa0Yw1v16X4ard=GXDXBCAYQ@mail.gmail.com>

I've noticed another esoterism in Inner.testParent().

The proposed fix places the accessor for field "i" in Parent:

  private java.lang.Integer testParent();
    Code:
       0: aload_0
       1: getfield      #3                  // Field this$0:LIssue8147527;
       4: invokestatic  #8                  // Method
Parent.access$201:(LParent;)Ljava/lang/Integer;
       7: astore_1

Prior to that, it was placed in Issue8147527:

  private java.lang.Integer testParent();
    Code:
       0: aload_0
       1: getfield      #3                  // Field this$0:LIssue8147527;
       4: invokestatic  #8                  // Method
Issue8147527.access$201:(LIssue8147527;)Ljava/lang/Integer;
       7: astore_1                          // !!! REFERENCE TO VALUE
OF Field Parent.i:Ljava/lang/Integer; !!!

And before issue 8143388 changeset, it was accessed directly:

  private java.lang.Integer testParent();
    Code:
       0: aload_0
       1: getfield      #3                  // Field this$0:LIssue8147527;
       4: astore_1
       5: aload_1
       6: getfield      #8                  // Field
Parent.i:Ljava/lang/Integer;
       9: astore_2

What's the expected accessing way?

Bernard


2016-10-26 12:22 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
> Hi,
>
> 2016-10-25 14:15 GMT+02:00 Jan Lahoda <jan.lahoda at oracle.com>:
>> On 25.10.2016 10:41, Maurizio Cimadamore wrote:
>>>
>>> Hi Jan,
>>> great analysis. I think (1) could be a safer path - but I admit I'm not
>>> entirely sold on another point; you say:
>>>
>>> "Further desugaring then replaces the "Issue8147527.super" with "this$0"
>>> (see "tree.selected = translate(tree.selected);" in Lower.visitSelect)"
>>>
>>> Isn't this already wrong? The static type of this$0 is Issue8147527,
>>> which is different from the static type of this.super (Parent).
>>> Shouldn't javac at least emit a cast there to preserve typing? While I
>>> don't dispute the other problems you discovered, which are real, I think
>>> the above desugaring doesn't make a lot of sense, and probably only
>>> succeeds because the visitor later fixes up the problem (probably by
>>> realizing that the owner of the symbol 'i' and the symbol of this$0
>>> disagree, therefore adding a cast?)
>>
>>
>> Normally (when the same tree is not reused), this is only a transient state
>> inside the visitSelect method - the method keeps a flag
>> (qualifiedSuperAccess) that the select expression is a the form "X.super",
>> and this will then force generation of an accessor invocation, replacing the
>> whole JCFieldAccess with something like "Issue8147527.access$101(this$0)".
>> But in case of reused trees, this will only correct/replace the first use of
>> the tree, and the subsequent one will remain broken.
>>
> If "tree.selected=..." appears to be a wrong transient state, then
> avoiding it (option 2 that Jan suggested) depending on the
> "qualifiedSuperAccess" flag and forcing the accessor generation could
> be the best approach.
>
> The fix, here below, shows the idea...
>
> I know it is not perfect, but as it corrects this specific case (and
> all test/tools/javac/boxing passed), I would like to know your opinion
> about it.
> Is this a good direction to search?
>
> Bernard
>
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> @@ -145,6 +145,7 @@
>      /** A hash table mapping local classes to their definitions.
>       */
>      Map<ClassSymbol, JCClassDecl> classdefs;
> +    Map<ClassSymbol, JCClassDecl> allclassdefs = new HashMap<>();
>
>      /** A hash table mapping local classes to a list of pruned trees.
>       */
> @@ -210,6 +211,8 @@
>              classMap.scan(outermostClassDef);
>              def = classdefs.get(c);
>          }
> +        if (def == null)
> +            def = allclassdefs.get(c);
>          return def;
>      }
>
> @@ -1100,6 +1103,7 @@
>              tree = make.at(tree.pos).Ident(sym);
>          }
>          JCExpression base = (tree.hasTag(SELECT)) ? ((JCFieldAccess)
> tree).selected : null;
> +        base = base != null ? translate(base) : null;
>          switch (sym.kind) {
>          case TYP:
>              if (sym.owner.kind != PCK) {
> @@ -1300,7 +1304,9 @@
>                  //odd access codes represent qualified super accesses - need to
>                  //emit reference to the direct superclass, even if the refered
>                  //member is from an indirect superclass (JLS 13.1)
> -
> site.setType(types.erasure(types.supertype(vsym.owner.enclClass().type)));
> +                Type supertype = types.supertype(vsym.owner.enclClass().type);
> +                if (!supertype.equals(syms.objectType))
> +                    site.setType(types.erasure(supertype));
>              }
>              ref = make.Select(site, sym);
>              args = make.Idents(md.params.tail);
> @@ -2413,6 +2419,7 @@
>              attrEnv = prevEnv;
>
>          classdefs.put(currentClass, tree);
> +        allclassdefs.put(currentClass, tree);
>
>          proxies = proxies.dup(currentClass);
>          List<VarSymbol> prevOuterThisStack = outerThisStack;
> @@ -3837,7 +3844,7 @@
>              tree.selected.hasTag(SELECT) &&
>              TreeInfo.name(tree.selected) == names._super &&
>              !types.isDirectSuperInterface(((JCFieldAccess)tree.selected).selected.type.tsym,
> currentClass);
> -        tree.selected = translate(tree.selected);
> +        if (!qualifiedSuperAccess) tree.selected = translate(tree.selected);
>          if (tree.name == names._class) {
>              result = classOf(tree.selected);
>          }

From joe.darcy at oracle.com  Thu Oct 27 15:59:30 2016
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 27 Oct 2016 08:59:30 -0700
Subject: How to compile code calling unexpected classes to an older
	release?
In-Reply-To: <fbfa39db-a045-64de-83c7-458762570119@oracle.com>
References: <2367EFE4-9983-4A81-8EFE-E51B0873875E@oracle.com>
	<fbfa39db-a045-64de-83c7-458762570119@oracle.com>
Message-ID: <ab2dcc37-9d49-b108-3c8b-26a862208749@oracle.com>

On 10/27/2016 2:14 AM, Claes Redestad wrote:
> Hi,
>
> "-XDignore.symbol.file -source 8 -target 8" can get your code to 
> compile (add -nowarn or set a valid bootclasspath to get rid of the 
> warning).
>
> So, it seems --release 8 has issues with internal classes not visible 
> to javac in 9?

By design, --release 8 does not expose internal classes :-)

-Joe


From bsrbnd at gmail.com  Thu Oct 27 17:33:21 2016
From: bsrbnd at gmail.com (bsrbnd)
Date: Thu, 27 Oct 2016 19:33:21 +0200
Subject: [PATCH] 8147527: Non-optimal code generated for postfix unary
	operators
In-Reply-To: <CAEgw74AZaT0-SAQNPTYL+_i5orfa0Yw1v16X4ard=GXDXBCAYQ@mail.gmail.com>
References: <CAEgw74A6RLjAH0knfYwmqWx_CrLpR8xQBuy+c4ucC6SaAPXqog@mail.gmail.com>
	<CAEgw74AokHc6yyQjFqTi4wW2-4rTBUcjeH2n6cerO74hv4n_4Q@mail.gmail.com>
	<CAEgw74Ay_78UxGG8uLz6vBCZ4QALB=hP26PtqRDRpo_a-y4Y5A@mail.gmail.com>
	<a4ee7750-6544-09ad-5629-3bf245fedf40@oracle.com>
	<580E6B06.5000800@oracle.com>
	<c929b65f-24ee-d061-d77a-3af17052337d@oracle.com>
	<580F4CDC.3020408@oracle.com>
	<CAEgw74CBsskc+F0SEKgS+ueAcm9QSg3XTZpWOF2Yv_Zf5buwuA@mail.gmail.com>
	<CAEgw74AZaT0-SAQNPTYL+_i5orfa0Yw1v16X4ard=GXDXBCAYQ@mail.gmail.com>
Message-ID: <CAEgw74BQO-3E-c792RKfLHfG6VtmKJoxT7DvS4BrE1pWVYL0DQ@mail.gmail.com>

I finally put the accessor in class "Issue8147527" as explained in
Lower.accessSymbol() first comment.
The fix looks quite good now (I hope)...

Bernard

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
@@ -926,7 +926,7 @@
         ClassSymbol accOwner = refSuper && protAccess
             // For access via qualified super (T.super.x), place the
             // access symbol on T.
-            ? (ClassSymbol)((JCFieldAccess) tree).selected.type.tsym
+            ? (ClassSymbol)((JCFieldAccess)((JCFieldAccess)
tree).selected).selected.type.tsym
             // Otherwise pretend that the owner of an accessed
             // protected symbol is the enclosing class of the current
             // class which is a subclass of the symbol's owner.
@@ -1100,6 +1100,7 @@
             tree = make.at(tree.pos).Ident(sym);
         }
         JCExpression base = (tree.hasTag(SELECT)) ? ((JCFieldAccess)
tree).selected : null;
+        base = refSuper ? translate(base) : base;
         switch (sym.kind) {
         case TYP:
             if (sym.owner.kind != PCK) {
@@ -3837,7 +3838,7 @@
             tree.selected.hasTag(SELECT) &&
             TreeInfo.name(tree.selected) == names._super &&
             !types.isDirectSuperInterface(((JCFieldAccess)tree.selected).selected.type.tsym,
currentClass);
-        tree.selected = translate(tree.selected);
+        if (!qualifiedSuperAccess) tree.selected = translate(tree.selected);
         if (tree.name == names._class) {
             result = classOf(tree.selected);
         }


2016-10-27 15:33 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
> I've noticed another esoterism in Inner.testParent().
>
> The proposed fix places the accessor for field "i" in Parent:
>
>   private java.lang.Integer testParent();
>     Code:
>        0: aload_0
>        1: getfield      #3                  // Field this$0:LIssue8147527;
>        4: invokestatic  #8                  // Method
> Parent.access$201:(LParent;)Ljava/lang/Integer;
>        7: astore_1
>
> Prior to that, it was placed in Issue8147527:
>
>   private java.lang.Integer testParent();
>     Code:
>        0: aload_0
>        1: getfield      #3                  // Field this$0:LIssue8147527;
>        4: invokestatic  #8                  // Method
> Issue8147527.access$201:(LIssue8147527;)Ljava/lang/Integer;
>        7: astore_1                          // !!! REFERENCE TO VALUE
> OF Field Parent.i:Ljava/lang/Integer; !!!
>
> And before issue 8143388 changeset, it was accessed directly:
>
>   private java.lang.Integer testParent();
>     Code:
>        0: aload_0
>        1: getfield      #3                  // Field this$0:LIssue8147527;
>        4: astore_1
>        5: aload_1
>        6: getfield      #8                  // Field
> Parent.i:Ljava/lang/Integer;
>        9: astore_2
>
> What's the expected accessing way?
>
> Bernard
>
>
> 2016-10-26 12:22 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>> Hi,
>>
>> 2016-10-25 14:15 GMT+02:00 Jan Lahoda <jan.lahoda at oracle.com>:
>>> On 25.10.2016 10:41, Maurizio Cimadamore wrote:
>>>>
>>>> Hi Jan,
>>>> great analysis. I think (1) could be a safer path - but I admit I'm not
>>>> entirely sold on another point; you say:
>>>>
>>>> "Further desugaring then replaces the "Issue8147527.super" with "this$0"
>>>> (see "tree.selected = translate(tree.selected);" in Lower.visitSelect)"
>>>>
>>>> Isn't this already wrong? The static type of this$0 is Issue8147527,
>>>> which is different from the static type of this.super (Parent).
>>>> Shouldn't javac at least emit a cast there to preserve typing? While I
>>>> don't dispute the other problems you discovered, which are real, I think
>>>> the above desugaring doesn't make a lot of sense, and probably only
>>>> succeeds because the visitor later fixes up the problem (probably by
>>>> realizing that the owner of the symbol 'i' and the symbol of this$0
>>>> disagree, therefore adding a cast?)
>>>
>>>
>>> Normally (when the same tree is not reused), this is only a transient state
>>> inside the visitSelect method - the method keeps a flag
>>> (qualifiedSuperAccess) that the select expression is a the form "X.super",
>>> and this will then force generation of an accessor invocation, replacing the
>>> whole JCFieldAccess with something like "Issue8147527.access$101(this$0)".
>>> But in case of reused trees, this will only correct/replace the first use of
>>> the tree, and the subsequent one will remain broken.
>>>
>> If "tree.selected=..." appears to be a wrong transient state, then
>> avoiding it (option 2 that Jan suggested) depending on the
>> "qualifiedSuperAccess" flag and forcing the accessor generation could
>> be the best approach.
>>
>> The fix, here below, shows the idea...
>>
>> I know it is not perfect, but as it corrects this specific case (and
>> all test/tools/javac/boxing passed), I would like to know your opinion
>> about it.
>> Is this a good direction to search?
>>
>> Bernard
>>
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
>> @@ -145,6 +145,7 @@
>>      /** A hash table mapping local classes to their definitions.
>>       */
>>      Map<ClassSymbol, JCClassDecl> classdefs;
>> +    Map<ClassSymbol, JCClassDecl> allclassdefs = new HashMap<>();
>>
>>      /** A hash table mapping local classes to a list of pruned trees.
>>       */
>> @@ -210,6 +211,8 @@
>>              classMap.scan(outermostClassDef);
>>              def = classdefs.get(c);
>>          }
>> +        if (def == null)
>> +            def = allclassdefs.get(c);
>>          return def;
>>      }
>>
>> @@ -1100,6 +1103,7 @@
>>              tree = make.at(tree.pos).Ident(sym);
>>          }
>>          JCExpression base = (tree.hasTag(SELECT)) ? ((JCFieldAccess)
>> tree).selected : null;
>> +        base = base != null ? translate(base) : null;
>>          switch (sym.kind) {
>>          case TYP:
>>              if (sym.owner.kind != PCK) {
>> @@ -1300,7 +1304,9 @@
>>                  //odd access codes represent qualified super accesses - need to
>>                  //emit reference to the direct superclass, even if the refered
>>                  //member is from an indirect superclass (JLS 13.1)
>> -
>> site.setType(types.erasure(types.supertype(vsym.owner.enclClass().type)));
>> +                Type supertype = types.supertype(vsym.owner.enclClass().type);
>> +                if (!supertype.equals(syms.objectType))
>> +                    site.setType(types.erasure(supertype));
>>              }
>>              ref = make.Select(site, sym);
>>              args = make.Idents(md.params.tail);
>> @@ -2413,6 +2419,7 @@
>>              attrEnv = prevEnv;
>>
>>          classdefs.put(currentClass, tree);
>> +        allclassdefs.put(currentClass, tree);
>>
>>          proxies = proxies.dup(currentClass);
>>          List<VarSymbol> prevOuterThisStack = outerThisStack;
>> @@ -3837,7 +3844,7 @@
>>              tree.selected.hasTag(SELECT) &&
>>              TreeInfo.name(tree.selected) == names._super &&
>>              !types.isDirectSuperInterface(((JCFieldAccess)tree.selected).selected.type.tsym,
>> currentClass);
>> -        tree.selected = translate(tree.selected);
>> +        if (!qualifiedSuperAccess) tree.selected = translate(tree.selected);
>>          if (tree.name == names._class) {
>>              result = classOf(tree.selected);
>>          }

From stuart.marks at oracle.com  Thu Oct 27 20:42:41 2016
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 27 Oct 2016 13:42:41 -0700
Subject: RFR(s): 8165646 (jdeprscan) adjust tool output to improve clarity
In-Reply-To: <988aa807-42dd-5827-2e5c-2d3504dc59c3@oracle.com>
References: <d6dcfc66-077e-477b-75db-257d1d8a550e@oracle.com>
	<988aa807-42dd-5827-2e5c-2d3504dc59c3@oracle.com>
Message-ID: <d3ca6d1d-ca4d-0868-b9bc-9939ced806b3@oracle.com>

Oh yes, good point about line breaks in multi-line messages. I looked around for 
techniques to deal with this, and I found that javap simply does a string 
replace() operation to change the line breaks prior to output. I've retrofitted 
a similar technique into jdeprscan's messages.

Revised webrev:

http://cr.openjdk.java.net/~smarks/reviews/8165646/webrev.1/

s'marks


On 10/25/16 4:17 PM, Jonathan Gibbons wrote:
> Not entirely (but somewhat) related to this review, the message reporting is
> suspect.  You use out.println, which will do the right thing with respect to
> line endings on Windows, but the strings you print have embedded \n characters,
> which will not be translated into the correct separator on Windows.
>
> In javac, we use methods that break the string to be printed into lines, and
> then println each line separately.
>
> -- Jon
>
>
> On 10/25/16 3:19 PM, Stuart Marks wrote:
>> Hi all,
>>
>> Please review this change to jdeprscan.
>>
>> I've rearranged and cleaned up the output of jdeprscan so that it's a bit more
>> readable (though only a bit) and to remove some checks, eliminating redundant
>> output. For example, one case in the regression test output used to be
>>
>> class jdk/jdeprusage/UseClass$Construct uses type
>> jdk/deprcases/types/DeprecatedClass deprecated
>> class jdk/jdeprusage/UseClass$Construct uses method in type
>> jdk/deprcases/types/DeprecatedClass deprecated
>>
>> and now it is
>>
>> class jdk/jdeprusage/UseClass$Construct uses deprecated class
>> jdk/deprcases/types/DeprecatedClass
>>
>> I also changed things to continue processing arguments if an error has
>> occurred, and to support direct reading of .class files as well as loading
>> class names from the class path.
>>
>> Webrev:
>>
>>     http://cr.openjdk.java.net/~smarks/reviews/8165646/webrev.0/
>>
>> Thanks,
>>
>> s'marks
>

From keimpe.bronkhorst at oracle.com  Fri Oct 28 17:29:10 2016
From: keimpe.bronkhorst at oracle.com (Keimpe Bronkhorst)
Date: Fri, 28 Oct 2016 11:29:10 -0600
Subject: How to compile code calling unexpected classes to an older
	release?
In-Reply-To: <mailman.39448.1477600968.23828.compiler-dev@openjdk.java.net>
References: <mailman.39448.1477600968.23828.compiler-dev@openjdk.java.net>
Message-ID: <34487297-10d9-f46e-fcde-16a13985ed9c@oracle.com>

Joe,

I don't understand this, doesn't this make "-release 8" useless for any 
code base that uses an internal JDK API, which is likely most production 
code bases. For instance, the Windows PLAF classes are often used:

import com.sun.java.swing.plaf.windows.WindowsComboBoxUI;
class t1 { public static void main(String[] args) {  } }

this will compile fine with either:
<jdk8_path>/javac t1.java
<jdk9_path>/javac --add-exports 
java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED t1.java

but not with either of:
<jdk9_path>/javac --release 8 t1.java
<jdk9_path>/javac --release 8 --add-exports 
java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED t1.java


Keimpe Bronkhorst
JDeveloper Team


On 10/27/2016 2:42 PM, compiler-dev-request at openjdk.java.net wrote:
> Message: 3
> Date: Thu, 27 Oct 2016 08:59:30 -0700
> From: joe darcy <joe.darcy at oracle.com>
> To: compiler-dev at openjdk.java.net
> Subject: Re: How to compile code calling unexpected classes to an
> 	older	release?
> Message-ID: <ab2dcc37-9d49-b108-3c8b-26a862208749 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 10/27/2016 2:14 AM, Claes Redestad wrote:
>> Hi,
>>
>> "-XDignore.symbol.file -source 8 -target 8" can get your code to
>> compile (add -nowarn or set a valid bootclasspath to get rid of the
>> warning).
>>
>> So, it seems --release 8 has issues with internal classes not visible
>> to javac in 9?
> By design, --release 8 does not expose internal classes :-)
>
> -Joe
>
>


From jonathan.gibbons at oracle.com  Fri Oct 28 18:26:42 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 28 Oct 2016 11:26:42 -0700
Subject: How to compile code calling unexpected classes to an older
	release?
In-Reply-To: <34487297-10d9-f46e-fcde-16a13985ed9c@oracle.com>
References: <mailman.39448.1477600968.23828.compiler-dev@openjdk.java.net>
	<34487297-10d9-f46e-fcde-16a13985ed9c@oracle.com>
Message-ID: <84da8811-5067-5457-4aba-b369cd364756@oracle.com>

Keimpe,

If you're compiling against internal JDK classes, you should be using 
the rt.jar from the appropriate release.

-- Jon


On 10/28/16 10:29 AM, Keimpe Bronkhorst wrote:
> Joe,
>
> I don't understand this, doesn't this make "-release 8" useless for 
> any code base that uses an internal JDK API, which is likely most 
> production code bases. For instance, the Windows PLAF classes are 
> often used:
>
> import com.sun.java.swing.plaf.windows.WindowsComboBoxUI;
> class t1 { public static void main(String[] args) {  } }
>
> this will compile fine with either:
> <jdk8_path>/javac t1.java
> <jdk9_path>/javac --add-exports 
> java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED t1.java
>
> but not with either of:
> <jdk9_path>/javac --release 8 t1.java
> <jdk9_path>/javac --release 8 --add-exports 
> java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED t1.java
>
>
> Keimpe Bronkhorst
> JDeveloper Team
>
>
> On 10/27/2016 2:42 PM, compiler-dev-request at openjdk.java.net wrote:
>> Message: 3
>> Date: Thu, 27 Oct 2016 08:59:30 -0700
>> From: joe darcy <joe.darcy at oracle.com>
>> To: compiler-dev at openjdk.java.net
>> Subject: Re: How to compile code calling unexpected classes to an
>>     older    release?
>> Message-ID: <ab2dcc37-9d49-b108-3c8b-26a862208749 at oracle.com>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> On 10/27/2016 2:14 AM, Claes Redestad wrote:
>>> Hi,
>>>
>>> "-XDignore.symbol.file -source 8 -target 8" can get your code to
>>> compile (add -nowarn or set a valid bootclasspath to get rid of the
>>> warning).
>>>
>>> So, it seems --release 8 has issues with internal classes not visible
>>> to javac in 9?
>> By design, --release 8 does not expose internal classes :-)
>>
>> -Joe
>>
>>
>


From joe.darcy at oracle.com  Fri Oct 28 22:13:13 2016
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 28 Oct 2016 15:13:13 -0700
Subject: How to compile code calling unexpected classes to an older
	release?
In-Reply-To: <84da8811-5067-5457-4aba-b369cd364756@oracle.com>
References: <mailman.39448.1477600968.23828.compiler-dev@openjdk.java.net>
	<34487297-10d9-f46e-fcde-16a13985ed9c@oracle.com>
	<84da8811-5067-5457-4aba-b369cd364756@oracle.com>
Message-ID: <fb2ec0a3-50ff-1684-e972-1db218c225ce@oracle.com>


On 10/28/2016 11:26 AM, Jonathan Gibbons wrote:
> Keimpe,
>
> If you're compiling against internal JDK classes, you should be using 
> the rt.jar from the appropriate release.
>
> -- Jon
>
>
> On 10/28/16 10:29 AM, Keimpe Bronkhorst wrote:
>> Joe,
>>
>> I don't understand this, doesn't this make "-release 8" useless for 
>> any code base that uses an internal JDK API, which is likely most 
>> production code bases. For instance, the Windows PLAF classes are 
>> often used:
>>
>> import com.sun.java.swing.plaf.windows.WindowsComboBoxUI;
>> class t1 { public static void main(String[] args) {  } }
>>
>> this will compile fine with either:
>> <jdk8_path>/javac t1.java
>> <jdk9_path>/javac --add-exports 
>> java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED t1.java
>>
>> but not with either of:
>> <jdk9_path>/javac --release 8 t1.java
>> <jdk9_path>/javac --release 8 --add-exports 
>> java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED t1.java


Some additional details on --release from Jan that I used in a JavaOne talk:

The APIs covered by --release are Java SE APIs along with 
@Exported(true) APIs, that is, the APIs in namespaces like jdk.* and 
com.sun.* that are not part of SE are are part of the exported API of 
the JDK. As of JDK 8, such API are marked with a @Exported(true) 
annotation. The compiler API in com.sun.soure.* is a notable example of 
an API in this category.

The types in java/awt/peer and java/awt/dnd/peer are included, but a few 
classes that are exported (or are in exported) packages are not part of 
the --release date as they are platform-specific. Some of these are 
package private (like java/io/UnixFileSystem), but there are a handful 
of classes that aren't part of the data and are @Exported(true), like 
com/sun/security/auth/module/UnixSystem.

HTH,

-Joe


From weijun.wang at oracle.com  Sat Oct 29 06:30:39 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Sat, 29 Oct 2016 14:30:39 +0800
Subject: How to compile code calling unexpected classes to an older
	release?
In-Reply-To: <fbfa39db-a045-64de-83c7-458762570119@oracle.com>
References: <2367EFE4-9983-4A81-8EFE-E51B0873875E@oracle.com>
	<fbfa39db-a045-64de-83c7-458762570119@oracle.com>
Message-ID: <D4F656B8-9CC6-4ED8-A3A0-D2E3822099B8@oracle.com>


> On Oct 27, 2016, at 5:14 PM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> "-XDignore.symbol.file -source 8 -target 8" can get your code to compile (add -nowarn or set a valid bootclasspath to get rid of the warning).

Great, this works.

Thanks
Max


From paul.sandoz at oracle.com  Mon Oct 31 22:20:11 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 31 Oct 2016 15:20:11 -0700
Subject: RFR(s): 8165646 (jdeprscan) adjust tool output to improve clarity
In-Reply-To: <d3ca6d1d-ca4d-0868-b9bc-9939ced806b3@oracle.com>
References: <d6dcfc66-077e-477b-75db-257d1d8a550e@oracle.com>
	<988aa807-42dd-5827-2e5c-2d3504dc59c3@oracle.com>
	<d3ca6d1d-ca4d-0868-b9bc-9939ced806b3@oracle.com>
Message-ID: <5FC01865-3BFA-4083-B5EA-13C4A5118971@oracle.com>


> On 27 Oct 2016, at 13:42, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> Oh yes, good point about line breaks in multi-line messages. I looked around for techniques to deal with this, and I found that javap simply does a string replace() operation to change the line breaks prior to output. I've retrofitted a similar technique into jdeprscan's messages.
> 
> Revised webrev:
> 
> http://cr.openjdk.java.net/~smarks/reviews/8165646/webrev.1/
> 

+1

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161031/8f98f60f/signature.asc>