From bitterfoxc at gmail.com  Mon Oct  5 00:42:21 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Mon, 5 Oct 2015 09:42:21 +0900
Subject: RFR 8138840: NPE when compiling bitwise operations with illegal
	operand types
Message-ID: <CAHjBcHMoVCZDPdqK-pCwrb=z5MU9oMiNx6gNkkYOMFjVSXDUig@mail.gmail.com>

Hi Jan, Maurizio and compiler group,
I found the NPE bug related to
http://hg.openjdk.java.net/jdk9/dev/langtools/rev/098657cc98c9
It's for bitwise operations with illegal operand types:

int n = 0;
double d = 0;
System.out.println(n & d);

I've just filed this issue:

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

And I already have the fix for this.
Could you review my patch?

http://cr.openjdk.java.net/~shinyafox/8138840/webrev.00/

Now, BinaryNumericOperator is used for bitwise operators in Operators.
BinaryNumericOperator accepts numeric operand types but bitwise operators
should be allowed for integral types(JLS 15.22.1).
So the accepted types are same as shift operators'(BinaryShiftOperator).

In my change, I create BinaryBitwiseOperator which allows only the integral
types such as BinaryShiftOperator I use it for bitwise operators instead of
BinaryNumericOperator.
(And I also change the comment for BinaryBooleanOperator, because it is not
"bitwise operator(JLS 15.22.1)" but "logical operator(15.22.2).")

Regards,
shinyafox
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20151005/07c18883/attachment.html>

From srikanth.adayapalam at oracle.com  Mon Oct  5 03:09:40 2015
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Mon, 05 Oct 2015 08:39:40 +0530
Subject: [PATCH] 8133135: NPE on anonymous class defined by qualified
	instance creation expression with diamond
In-Reply-To: <55ED6C80.8020202@oracle.com>
References: <CAEgw74Awhki0yoUx3PRJOpt9yD9UO8Q4SBHQE351HA4Pie3Gzg@mail.gmail.com>	<55E46580.8070705@oracle.com>	<CAEgw74AGHCCh=6mHBS4LbbGJpPD1vuGAuhhKnyprYWAwsJrGEw@mail.gmail.com>
	<55ED6C80.8020202@oracle.com>
Message-ID: <5611E9F4.8040408@oracle.com>



On Monday 07 September 2015 04:22 PM, Srikanth wrote:
> Hello !
>
> Thanks for the patch. I can help take it forward. (I implemented
> <> with anonymous classes - I have been away on leave for some
> time and expect to have some cycles beginning this week.)

Hello, sorry for the delay, I am finally back online full time to look into
this issue.

Unfortunately, the proposed patch fails some of the diamond tests so
cannot be accepted as is - I'll investigate a fix and take it forward.

Thanks!
Srikanth

>
> Thanks!
> Srikanth
>
> On Saturday 05 September 2015 08:49 PM, bsrbnd wrote:
>> Just a little precision;
>> clazz is reassigned with clazzid1 in method Attr.visitNewClass() (on
>> line 1973) which implies that it differs from tree.clazz:
>>
>>          if (tree.encl != null) {
>>              // We are seeing a qualified new, of the form
>>              //    <expr>.new C <...> (...) ...
>>
>>              [...]
>>
>>              clazz = clazzid1;
>>          }
>>
>>
>> It is then passed to Attr.visitAnonymousClassDefinition() and used to
>> perform type inference.
>> This is why recurcivity condition could be made on clazz.type instead
>> of tree.clazz.type as shown in the first patch.
>>
>> But, I was also wondering if tree.clazz should really differs from
>> clazz as we assign clazz.type to tree.clazz.type in
>> Attr.visitNewClass() on line 2088 before calling
>> Attr.visitAnonymousClassDefinition()?
>>
>>                  if (!constructorType.isErroneous()) {
>>                      tree.clazz.type = clazz.type =
>> constructorType.getReturnType();
>>                      tree.constructorType =
>> types.createMethodTypeWithReturn(constructorType, syms.voidType);
>>                  }
>>
>> If it shouldn't, tree.clazz have to match clazz and then recurcivity
>> condition on tree.clazz.type could be right...
>> This leads me to give next a second patch (only in
>> Attr.visitNewClass()) with a slightly different meaning as explained
>> above:
>>
>> 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
>> @@ -1970,7 +1970,7 @@
>>                                 ((JCTypeApply) clazz).arguments);
>>               }
>>
>> -            clazz = clazzid1;
>> +            tree.clazz = clazz = clazzid1;
>>           }
>>
>>           // Attribute clazz expression and store
>>
>> Regards,
>> bsrbnd
>>
>> 2015-08-31 16:32 GMT+02:00 Maurizio Cimadamore 
>> <maurizio.cimadamore at oracle.com>:
>>> Thanks, I'll take a look.
>>>
>>> Maurizio
>>>
>>>
>>> On 31/08/15 14:40, bsrbnd wrote:
>>>> Hi,
>>>>
>>>> As explained in issue 8133135, the following code produces a null
>>>> pointer exception because the symbol of the anonymous class is not set
>>>> during the attribute phase:
>>>>
>>>> class List<T> {}
>>>>
>>>> class ClassOut {
>>>>       class ClassIn<T> { public ClassIn() {}}
>>>> }
>>>>
>>>> public class TestBug {
>>>>       public static <T> List<T> m(List<T> list, T item) {return list;}
>>>>
>>>>
>>>>       public static void main(String[] args) {
>>>>           m(new List<ClassOut.ClassIn<String>>(), new ClassOut().new
>>>> ClassIn<>(){});
>>>>       }
>>>> }
>>>>
>>>> Method Attr.visitAnonymousClassDefinition() doesn't perform well type
>>>> inference with diamond. Recurcivity condition on tree.clazz.type seems
>>>> to be wrong because it never changes... instead, it should be made on
>>>> clazz.type (or clazztype) to go deeper on the type resolution.
>>>>
>>>> The following patch shows a possible solution, I think (to be checked
>>>> by someone who knows the code better than me...):
>>>>
>>>> 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
>>>> @@ -2173,7 +2173,7 @@
>>>>                final boolean isDiamond = TreeInfo.isDiamond(tree);
>>>>                if (isDiamond
>>>>                        && ((tree.constructorType != null &&
>>>> inferenceContext.free(tree.constructorType))
>>>> -                    || (tree.clazz.type != null &&
>>>> inferenceContext.free(tree.clazz.type)))) {
>>>> +                    || (clazz.type != null &&
>>>> inferenceContext.free(clazz.type)))) {
>>>>                    final ResultInfo resultInfoForClassDefinition =
>>>> this.resultInfo;
>>>>
>>>> inferenceContext.addFreeTypeListener(List.of(tree.constructorType,
>>>> tree.clazz.type),
>>>>                            instantiatedContext -> {
>>>>
>>>> Regards,
>>>>
>>>> bsrbnd
>>>
>


From daniel.smith at oracle.com  Tue Oct  6 19:28:50 2015
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 6 Oct 2015 13:28:50 -0600
Subject: Subtyping constraint and unchecked conversion
In-Reply-To: <55F31828.8040002@oracle.com>
References: <55F2ACAC.2060801@oracle.com> <55F30143.3050901@oracle.com>
	<55F30CF0.6060300@oracle.com> <55F31025.5010601@oracle.com>
	<55F31828.8040002@oracle.com>
Message-ID: <1A395AC1-3EAE-44C5-8C6D-7B72EE09CE6B@oracle.com>

> On Sep 11, 2015, at 12:06 PM, Georgiy Rakov <georgiy.rakov at oracle.com> wrote:
> 
> Foo <: Foo<Integer>
> 4. Since raw type is not a subtype of corresponding generic type parameterization, and unchecked conversion is not applied here too,     compile time error should occur, but it doesn't. If it were a type compatibility constraint then it will be reduced to true, but this is a subtyping constraint.

> In general this looks like a javac bug. Could you please tell if it really is.

Yep, known bug:
https://bugs.openjdk.java.net/browse/JDK-8026527

?Dan

From bsrbnd at gmail.com  Thu Oct  8 09:10:18 2015
From: bsrbnd at gmail.com (bsrbnd)
Date: Thu, 8 Oct 2015 11:10:18 +0200
Subject: [PATCH] 8133135: NPE on anonymous class defined by qualified
	instance creation expression with diamond
In-Reply-To: <5611E9F4.8040408@oracle.com>
References: <CAEgw74Awhki0yoUx3PRJOpt9yD9UO8Q4SBHQE351HA4Pie3Gzg@mail.gmail.com>
	<55E46580.8070705@oracle.com>
	<CAEgw74AGHCCh=6mHBS4LbbGJpPD1vuGAuhhKnyprYWAwsJrGEw@mail.gmail.com>
	<55ED6C80.8020202@oracle.com> <5611E9F4.8040408@oracle.com>
Message-ID: <CAEgw74BS-_LbhmqKR9q719=R7-G2GyxfEhb3JnnK_2ZeNg-Z_w@mail.gmail.com>

Thanks,
Your changeset (http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d034f4347b09)
looks fine:-)

bsrbnd

2015-10-05 5:09 GMT+02:00 Srikanth <srikanth.adayapalam at oracle.com>:
>
>
> On Monday 07 September 2015 04:22 PM, Srikanth wrote:
>>
>> Hello !
>>
>> Thanks for the patch. I can help take it forward. (I implemented
>> <> with anonymous classes - I have been away on leave for some
>> time and expect to have some cycles beginning this week.)
>
>
> Hello, sorry for the delay, I am finally back online full time to look into
> this issue.
>
> Unfortunately, the proposed patch fails some of the diamond tests so
> cannot be accepted as is - I'll investigate a fix and take it forward.
>
> Thanks!
> Srikanth
>
>
>>
>> Thanks!
>> Srikanth
>>
>> On Saturday 05 September 2015 08:49 PM, bsrbnd wrote:
>>>
>>> Just a little precision;
>>> clazz is reassigned with clazzid1 in method Attr.visitNewClass() (on
>>> line 1973) which implies that it differs from tree.clazz:
>>>
>>>          if (tree.encl != null) {
>>>              // We are seeing a qualified new, of the form
>>>              //    <expr>.new C <...> (...) ...
>>>
>>>              [...]
>>>
>>>              clazz = clazzid1;
>>>          }
>>>
>>>
>>> It is then passed to Attr.visitAnonymousClassDefinition() and used to
>>> perform type inference.
>>> This is why recurcivity condition could be made on clazz.type instead
>>> of tree.clazz.type as shown in the first patch.
>>>
>>> But, I was also wondering if tree.clazz should really differs from
>>> clazz as we assign clazz.type to tree.clazz.type in
>>> Attr.visitNewClass() on line 2088 before calling
>>> Attr.visitAnonymousClassDefinition()?
>>>
>>>                  if (!constructorType.isErroneous()) {
>>>                      tree.clazz.type = clazz.type =
>>> constructorType.getReturnType();
>>>                      tree.constructorType =
>>> types.createMethodTypeWithReturn(constructorType, syms.voidType);
>>>                  }
>>>
>>> If it shouldn't, tree.clazz have to match clazz and then recurcivity
>>> condition on tree.clazz.type could be right...
>>> This leads me to give next a second patch (only in
>>> Attr.visitNewClass()) with a slightly different meaning as explained
>>> above:
>>>
>>> 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
>>> @@ -1970,7 +1970,7 @@
>>>                                 ((JCTypeApply) clazz).arguments);
>>>               }
>>>
>>> -            clazz = clazzid1;
>>> +            tree.clazz = clazz = clazzid1;
>>>           }
>>>
>>>           // Attribute clazz expression and store
>>>
>>> Regards,
>>> bsrbnd
>>>
>>> 2015-08-31 16:32 GMT+02:00 Maurizio Cimadamore
>>> <maurizio.cimadamore at oracle.com>:
>>>>
>>>> Thanks, I'll take a look.
>>>>
>>>> Maurizio
>>>>
>>>>
>>>> On 31/08/15 14:40, bsrbnd wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> As explained in issue 8133135, the following code produces a null
>>>>> pointer exception because the symbol of the anonymous class is not set
>>>>> during the attribute phase:
>>>>>
>>>>> class List<T> {}
>>>>>
>>>>> class ClassOut {
>>>>>       class ClassIn<T> { public ClassIn() {}}
>>>>> }
>>>>>
>>>>> public class TestBug {
>>>>>       public static <T> List<T> m(List<T> list, T item) {return list;}
>>>>>
>>>>>
>>>>>       public static void main(String[] args) {
>>>>>           m(new List<ClassOut.ClassIn<String>>(), new ClassOut().new
>>>>> ClassIn<>(){});
>>>>>       }
>>>>> }
>>>>>
>>>>> Method Attr.visitAnonymousClassDefinition() doesn't perform well type
>>>>> inference with diamond. Recurcivity condition on tree.clazz.type seems
>>>>> to be wrong because it never changes... instead, it should be made on
>>>>> clazz.type (or clazztype) to go deeper on the type resolution.
>>>>>
>>>>> The following patch shows a possible solution, I think (to be checked
>>>>> by someone who knows the code better than me...):
>>>>>
>>>>> 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
>>>>> @@ -2173,7 +2173,7 @@
>>>>>                final boolean isDiamond = TreeInfo.isDiamond(tree);
>>>>>                if (isDiamond
>>>>>                        && ((tree.constructorType != null &&
>>>>> inferenceContext.free(tree.constructorType))
>>>>> -                    || (tree.clazz.type != null &&
>>>>> inferenceContext.free(tree.clazz.type)))) {
>>>>> +                    || (clazz.type != null &&
>>>>> inferenceContext.free(clazz.type)))) {
>>>>>                    final ResultInfo resultInfoForClassDefinition =
>>>>> this.resultInfo;
>>>>>
>>>>> inferenceContext.addFreeTypeListener(List.of(tree.constructorType,
>>>>> tree.clazz.type),
>>>>>                            instantiatedContext -> {
>>>>>
>>>>> Regards,
>>>>>
>>>>> bsrbnd
>>>>
>>>>
>>
>

From bsrbnd at gmail.com  Thu Oct  8 09:15:08 2015
From: bsrbnd at gmail.com (bsrbnd)
Date: Thu, 8 Oct 2015 11:15:08 +0200
Subject: [PATCH] 8129740: Runtime exception when passing lambda in inner
	class constructor
In-Reply-To: <CAEgw74AjX9gQAtDetsJPF66MXz19rp2J46X22vKFN0QHBvQftg@mail.gmail.com>
References: <CAEgw74D94dxY2a_uwn-8XDmk+A3dYO8eUCNAZNR5vqHGUQONPw@mail.gmail.com>
	<CAEgw74AjX9gQAtDetsJPF66MXz19rp2J46X22vKFN0QHBvQftg@mail.gmail.com>
Message-ID: <CAEgw74DsTBYEgYTDp=a2sKK+XNaXbjej6DdoCC-7RrgKZm=+AA@mail.gmail.com>

Any comment about this issue and the patch below?
Thanks,

bsrbnd

2015-09-17 13:46 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
> Hi,
>
> Just two precisions:
>
> 1) If you run the compiled example, a "java.lang.VerifyError
> (uninitializedThis)" is thrown, not a runtime exception (sorry for
> that mistake):
>
> Exception in thread "main" java.lang.VerifyError: Bad type on operand stack
> Exception Details:
>   Location:
>     Bug$Inner.<init>(LBug;)V @3: invokedynamic
>   Reason:
>     Type uninitializedThis (current frame, stack[2]) is not assignable
> to 'Bug$Inner'
>
>
> 2) The output of javap on "Inner" class gives us a good explaination.
> The lambda expression is translated into an instance method (to access
> instance members of the class and outer-class) and thus "this" is used
> by "invokedynamic" before calling the constructor which leads to the
> VerifiyError:
>
> public class Bug$Inner {
>   java.lang.Object vi;
>   final Bug this$0;
>   public Bug$Inner(Bug, java.lang.Runnable);
>   public Bug$Inner(Bug, java.lang.Object);
>   public Bug$Inner(Bug);
>   private void lambda$new$0();
> }
>
>   public Bug$Inner(Bug);
>     Code:
>        0: aload_0
>        1: aload_1
>        2: aload_0
>        3: invokedynamic #8,  0              // InvokeDynamic
> #0:run:(LBug$Inner;)Ljava/lang/Runnable;
>        8: invokespecial #9                  // Method
> "<init>":(LBug;Ljava/lang/Runnable;)V
>       11: return
>
> If the lambda expression doesn't access instance members of the class
> (but static members or instance members of other classes), the lamda
> expression is translated into a static method an the "invokedynamic"
> doesn't need "this". For example:
>  this(()->System.out.println(new Other().o));
>
> gives:
>
> public class Bug$Inner {
>   java.lang.Object vi;
>   final Bug this$0;
>   public Bug$Inner(Bug, java.lang.Runnable);
>   public Bug$Inner(Bug, java.lang.Object);
>   public Bug$Inner(Bug);
>   private static void lambda$new$0();
> }
>
>   public Bug$Inner(Bug);
>     Code:
>        0: aload_0
>        1: aload_1
>        2: invokedynamic #8,  0              // InvokeDynamic
> #0:run:()Ljava/lang/Runnable;
>        7: invokespecial #9                  // Method
> "<init>":(LBug;Ljava/lang/Runnable;)V
>       10: return
>
> Thus, jls 8.8.7.1 seems to be respected (the error appears to be
> "right" in issue 8129740) and then javac should (I think) give an
> error message as shown in the patch below.
>
> Regards,
> bsrbnd
>
> 2015-09-14 15:11 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>> Hi,
>>
>> As explained in issue 8129740, the following code produces a runtime
>> exception ("uninitialized this"):
>>
>> public class Bug {
>>     Object vb=new Object();
>>
>>     public class Inner {
>>         Object vi=new Object();
>>
>>         public Inner(Runnable r) {r.run();}
>>         public Inner(Object o) {System.out.println(o);}
>>         public Inner() {
>>             this(()->System.out.println(vb)); // KO (bug 8129740
>> runtime exception)
>>         }
>>     }
>>     public static void main(String[] args) {
>>         new Bug().new Inner();
>>     }
>> }
>>
>> class Other {
>>     public Object o=new Object();
>> }
>>
>> With respect to JLS 8.8.7.1 (p. 264, l. 1-4), I think (if I've not
>> missed anything) that this example should probably run without
>> exception because "vb" is not within "Inner" class but in the
>> outer-class.
>>
>> For example, all the following statements compile and run according to
>> jls 8.8.7.1:
>>  this(vb);
>>  this(()->System.out.println(new Other().o));
>>  this(new Runnable() {public void run() {System.out.println(vb);}});
>>
>> And the following ones doesn't compile, according to jls:
>>  this(vi);
>>  this(()->System.out.println(vi));
>>  this(new Runnable() {public void run() {System.out.println(vi);}});
>>
>> But, if the runtime exception is "right" (as said in issue 8129740),
>> we can detect in the attribute phase the special case of an outer
>> member access within a lambda expression in a this/super call as shown
>> in the following patch.
>> Method Attr.visitLambda() keeps a track in the AttrContext if we are
>> in a this/super call and method Attr.visitIdent() produces an error
>> message for that case (notice that "noOuterThisPath" on line 3209
>> never changes).
>>
>> Regards,
>> bsrbnd
>>
>> 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
>> @@ -2327,6 +2327,7 @@
>>          }
>>          //create an environment for attribution of the lambda expression
>>          final Env<AttrContext> localEnv = lambdaEnv(that, env);
>> +        localEnv.info.isLambdaInSelfCall = localEnv.info.isSelfCall;
>>          boolean needsRecovery =
>>                  resultInfo.checkContext.deferredAttrContext().mode ==
>> DeferredAttr.AttrMode.CHECK;
>>          try {
>> @@ -3207,6 +3208,7 @@
>>          //     (`noOuterThisPath').
>>          Env<AttrContext> symEnv = env;
>>          boolean noOuterThisPath = false;
>> +        boolean isLambdaInSelfCall = symEnv.info.isLambdaInSelfCall;
>>          if (env.enclClass.sym.owner.kind != PCK && // we are in an inner class
>>              sym.kind.matches(KindSelector.VAL_MTH) &&
>>              sym.owner.kind == TYP &&
>> @@ -3238,7 +3240,7 @@
>>          // In a constructor body,
>>          // if symbol is a field or instance method, check that it is
>>          // not accessed before the supertype constructor is called.
>> -        if ((symEnv.info.isSelfCall || noOuterThisPath) &&
>> +        if ((symEnv.info.isSelfCall || isLambdaInSelfCall ||
>> noOuterThisPath) &&
>>              sym.kind.matches(KindSelector.VAL_MTH) &&
>>              sym.owner.kind == TYP &&
>>              (sym.flags() & STATIC) == 0) {
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java
>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java
>> @@ -72,6 +72,8 @@
>>       *  Is this an attribution environment for an instance creation expression?
>>       */
>>      boolean isNewClass = false;
>> +
>> +    boolean isLambdaInSelfCall = false;
>>
>>      /** Are arguments to current function applications boxed into an
>> array for varargs?
>>       */
>> @@ -112,6 +114,7 @@
>>          info.isSpeculative = isSpeculative;
>>          info.isAnonymousDiamond = isAnonymousDiamond;
>>          info.isNewClass = isNewClass;
>> +        info.isLambdaInSelfCall = isLambdaInSelfCall;
>>          return info;
>>      }

From srikanth.adayapalam at oracle.com  Thu Oct  8 09:29:51 2015
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Thu, 08 Oct 2015 14:59:51 +0530
Subject: [PATCH] 8129740: Runtime exception when passing lambda in inner
	class constructor
In-Reply-To: <CAEgw74DsTBYEgYTDp=a2sKK+XNaXbjej6DdoCC-7RrgKZm=+AA@mail.gmail.com>
References: <CAEgw74D94dxY2a_uwn-8XDmk+A3dYO8eUCNAZNR5vqHGUQONPw@mail.gmail.com>	<CAEgw74AjX9gQAtDetsJPF66MXz19rp2J46X22vKFN0QHBvQftg@mail.gmail.com>
	<CAEgw74DsTBYEgYTDp=a2sKK+XNaXbjej6DdoCC-7RrgKZm=+AA@mail.gmail.com>
Message-ID: <5616378F.10400@oracle.com>

I seemed to have missed this thread as I was on vacation, but have been
working on https://bugs.openjdk.java.net/browse/JDK-8129740. ATM, my belief
is that this is valid code and should be accepted and run without any 
errors.

I have captured some notes in 
https://bugs.openjdk.java.net/browse/JDK-8129740
that show the reasoning.

Thanks!
Srikanth

On Thursday 08 October 2015 02:45 PM, bsrbnd wrote:
> Any comment about this issue and the patch below?
> Thanks,
>
> bsrbnd
>
> 2015-09-17 13:46 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>> Hi,
>>
>> Just two precisions:
>>
>> 1) If you run the compiled example, a "java.lang.VerifyError
>> (uninitializedThis)" is thrown, not a runtime exception (sorry for
>> that mistake):
>>
>> Exception in thread "main" java.lang.VerifyError: Bad type on operand stack
>> Exception Details:
>>    Location:
>>      Bug$Inner.<init>(LBug;)V @3: invokedynamic
>>    Reason:
>>      Type uninitializedThis (current frame, stack[2]) is not assignable
>> to 'Bug$Inner'
>>
>>
>> 2) The output of javap on "Inner" class gives us a good explaination.
>> The lambda expression is translated into an instance method (to access
>> instance members of the class and outer-class) and thus "this" is used
>> by "invokedynamic" before calling the constructor which leads to the
>> VerifiyError:
>>
>> public class Bug$Inner {
>>    java.lang.Object vi;
>>    final Bug this$0;
>>    public Bug$Inner(Bug, java.lang.Runnable);
>>    public Bug$Inner(Bug, java.lang.Object);
>>    public Bug$Inner(Bug);
>>    private void lambda$new$0();
>> }
>>
>>    public Bug$Inner(Bug);
>>      Code:
>>         0: aload_0
>>         1: aload_1
>>         2: aload_0
>>         3: invokedynamic #8,  0              // InvokeDynamic
>> #0:run:(LBug$Inner;)Ljava/lang/Runnable;
>>         8: invokespecial #9                  // Method
>> "<init>":(LBug;Ljava/lang/Runnable;)V
>>        11: return
>>
>> If the lambda expression doesn't access instance members of the class
>> (but static members or instance members of other classes), the lamda
>> expression is translated into a static method an the "invokedynamic"
>> doesn't need "this". For example:
>>   this(()->System.out.println(new Other().o));
>>
>> gives:
>>
>> public class Bug$Inner {
>>    java.lang.Object vi;
>>    final Bug this$0;
>>    public Bug$Inner(Bug, java.lang.Runnable);
>>    public Bug$Inner(Bug, java.lang.Object);
>>    public Bug$Inner(Bug);
>>    private static void lambda$new$0();
>> }
>>
>>    public Bug$Inner(Bug);
>>      Code:
>>         0: aload_0
>>         1: aload_1
>>         2: invokedynamic #8,  0              // InvokeDynamic
>> #0:run:()Ljava/lang/Runnable;
>>         7: invokespecial #9                  // Method
>> "<init>":(LBug;Ljava/lang/Runnable;)V
>>        10: return
>>
>> Thus, jls 8.8.7.1 seems to be respected (the error appears to be
>> "right" in issue 8129740) and then javac should (I think) give an
>> error message as shown in the patch below.
>>
>> Regards,
>> bsrbnd
>>
>> 2015-09-14 15:11 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>>> Hi,
>>>
>>> As explained in issue 8129740, the following code produces a runtime
>>> exception ("uninitialized this"):
>>>
>>> public class Bug {
>>>      Object vb=new Object();
>>>
>>>      public class Inner {
>>>          Object vi=new Object();
>>>
>>>          public Inner(Runnable r) {r.run();}
>>>          public Inner(Object o) {System.out.println(o);}
>>>          public Inner() {
>>>              this(()->System.out.println(vb)); // KO (bug 8129740
>>> runtime exception)
>>>          }
>>>      }
>>>      public static void main(String[] args) {
>>>          new Bug().new Inner();
>>>      }
>>> }
>>>
>>> class Other {
>>>      public Object o=new Object();
>>> }
>>>
>>> With respect to JLS 8.8.7.1 (p. 264, l. 1-4), I think (if I've not
>>> missed anything) that this example should probably run without
>>> exception because "vb" is not within "Inner" class but in the
>>> outer-class.
>>>
>>> For example, all the following statements compile and run according to
>>> jls 8.8.7.1:
>>>   this(vb);
>>>   this(()->System.out.println(new Other().o));
>>>   this(new Runnable() {public void run() {System.out.println(vb);}});
>>>
>>> And the following ones doesn't compile, according to jls:
>>>   this(vi);
>>>   this(()->System.out.println(vi));
>>>   this(new Runnable() {public void run() {System.out.println(vi);}});
>>>
>>> But, if the runtime exception is "right" (as said in issue 8129740),
>>> we can detect in the attribute phase the special case of an outer
>>> member access within a lambda expression in a this/super call as shown
>>> in the following patch.
>>> Method Attr.visitLambda() keeps a track in the AttrContext if we are
>>> in a this/super call and method Attr.visitIdent() produces an error
>>> message for that case (notice that "noOuterThisPath" on line 3209
>>> never changes).
>>>
>>> Regards,
>>> bsrbnd
>>>
>>> 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
>>> @@ -2327,6 +2327,7 @@
>>>           }
>>>           //create an environment for attribution of the lambda expression
>>>           final Env<AttrContext> localEnv = lambdaEnv(that, env);
>>> +        localEnv.info.isLambdaInSelfCall = localEnv.info.isSelfCall;
>>>           boolean needsRecovery =
>>>                   resultInfo.checkContext.deferredAttrContext().mode ==
>>> DeferredAttr.AttrMode.CHECK;
>>>           try {
>>> @@ -3207,6 +3208,7 @@
>>>           //     (`noOuterThisPath').
>>>           Env<AttrContext> symEnv = env;
>>>           boolean noOuterThisPath = false;
>>> +        boolean isLambdaInSelfCall = symEnv.info.isLambdaInSelfCall;
>>>           if (env.enclClass.sym.owner.kind != PCK && // we are in an inner class
>>>               sym.kind.matches(KindSelector.VAL_MTH) &&
>>>               sym.owner.kind == TYP &&
>>> @@ -3238,7 +3240,7 @@
>>>           // In a constructor body,
>>>           // if symbol is a field or instance method, check that it is
>>>           // not accessed before the supertype constructor is called.
>>> -        if ((symEnv.info.isSelfCall || noOuterThisPath) &&
>>> +        if ((symEnv.info.isSelfCall || isLambdaInSelfCall ||
>>> noOuterThisPath) &&
>>>               sym.kind.matches(KindSelector.VAL_MTH) &&
>>>               sym.owner.kind == TYP &&
>>>               (sym.flags() & STATIC) == 0) {
>>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java
>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java
>>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java
>>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java
>>> @@ -72,6 +72,8 @@
>>>        *  Is this an attribution environment for an instance creation expression?
>>>        */
>>>       boolean isNewClass = false;
>>> +
>>> +    boolean isLambdaInSelfCall = false;
>>>
>>>       /** Are arguments to current function applications boxed into an
>>> array for varargs?
>>>        */
>>> @@ -112,6 +114,7 @@
>>>           info.isSpeculative = isSpeculative;
>>>           info.isAnonymousDiamond = isAnonymousDiamond;
>>>           info.isNewClass = isNewClass;
>>> +        info.isLambdaInSelfCall = isLambdaInSelfCall;
>>>           return info;
>>>       }


From maurizio.cimadamore at oracle.com  Fri Oct  9 12:29:49 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 9 Oct 2015 13:29:49 +0100
Subject: RFR 8138840: NPE when compiling bitwise operations with illegal
	operand types
In-Reply-To: <CAHjBcHMoVCZDPdqK-pCwrb=z5MU9oMiNx6gNkkYOMFjVSXDUig@mail.gmail.com>
References: <CAHjBcHMoVCZDPdqK-pCwrb=z5MU9oMiNx6gNkkYOMFjVSXDUig@mail.gmail.com>
Message-ID: <5617B33D.6050900@oracle.com>

(dropping jdk9-dev)

Hi Shinya
we are working on this - thanks for the patch - we are investigating a 
very similar fix.

Maurizio

On 05/10/15 01:42, ShinyaYoshida wrote:
> Hi Jan, Maurizio and compiler group,
> I found the NPE bug related to
> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/098657cc98c9
> It's for bitwise operations with illegal operand types:
>
> int n = 0;
> double d = 0;
> System.out.println(n & d);
>
> I've just filed this issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8138840
>
> And I already have the fix for this.
> Could you review my patch?
>
> http://cr.openjdk.java.net/~shinyafox/8138840/webrev.00/
>
> Now, BinaryNumericOperator is used for bitwise operators in Operators.
> BinaryNumericOperator accepts numeric operand types but bitwise operators
> should be allowed for integral types(JLS 15.22.1).
> So the accepted types are same as shift operators'(BinaryShiftOperator).
>
> In my change, I create BinaryBitwiseOperator which allows only the integral
> types such as BinaryShiftOperator I use it for bitwise operators instead of
> BinaryNumericOperator.
> (And I also change the comment for BinaryBooleanOperator, because it is not
> "bitwise operator(JLS 15.22.1)" but "logical operator(15.22.2).")
>
> Regards,
> shinyafox


From bsrbnd at gmail.com  Mon Oct 12 10:58:09 2015
From: bsrbnd at gmail.com (bsrbnd)
Date: Mon, 12 Oct 2015 12:58:09 +0200
Subject: KSL: Reflection's orthogonality improvement
Message-ID: <CAEgw74CXMmSq9iFaoi1BNeXjH7iucjdXXhZrPQms3JXKs=u5aQ@mail.gmail.com>

Hi,

Just an idea for the "Kitchen Sink Language".
I hope this subject hasn't already been discussed and that I haven't missed
anything in the quite big and complex JLS.
It's said not to think too much if this is a good or bad idea before
submitting it for the KSL, but I hope I've thought enough...;-)
Any comments, ideas or suggestions are welcomed.
No implementation draft has been done until now, but it could be explored
if comments are encouraging...

Thanks in advance,
bsrbnd

Abstract
--------
Reflection is designed to access a class member given its name as a String.
For example:
MyClass.class.getDeclaredField("field") reflects MyClass.field or
MyClass.class.getDeclaredMethod("method") reflects MyClass.method()
But the reciprocal is false, we can't get the "String name" of a class member
given its identifier.
This implies a runtime check of the "String name" and an eventual exception
if the name doesn't match a declared member...
For this reason, we can say that reflection isn't totally orthogonal.

Reciprocity with qualified strings (to be added to JLS 6.5.6.2,15.8,..?)
------------------------------------------------------------------------
To avoid occasional exceptions (but not runtime checks) and improve reflection's
orthogonality, I suggest to add the concept of "qualified strings".
For example:
MyClass."field" checks at compile-time that "field" is declared on
MyClass and respects accessibility and visibility rules in a compatible way
defined by reflection's API. This means that all declared member's names
(private, protected, public, static or not) but neither inherited nor synthetic
should be accessible as they are accepted by getDeclaredField() or
getDeclaredMethod().
If all compile-checks pass, this expression gives back the name of the
member as a String.

Grammar update (JLS 15.8)
-------------------------
I suggest to add the following line in "PrimaryNoNewArray" rule of the grammar:

PrimaryNoNewArray:
 TypeName . " Identifier "

A simple databases example using "qualified strings"
----------------------------------------------------
In the following example, "qualified strings" ensure that valid member's names
are used in SQL requests to be correctly used by reflection to store back
the result of the request:

class MyTable {
 public static final String name=MyTable.class.getSimpleName().toLowerCase();
 public Integer id;
 public Integer value;
}
MyTable line = new MyTable();

String request =
"SELECT " + MyTable."value" + " FROM " + MyTable.name +
" WHERE " + MyTable."id" + "=" + line.id

String valueColumn = resultset.getMetaData().getColumnName(1);
Field f = MyTable.class.getDeclaredField(valueColumn.toLowerCase());
f.set(line, resultSet.getInt(valueColumn));

Conclusion
----------
The usefulness of "qualified strings" isn't limited to this simple
database example.
It extends to every context where it is necessary to get informations
from external parties and store back results dynamically in objects
through reflection.

From maurizio.cimadamore at oracle.com  Mon Oct 12 12:45:21 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 12 Oct 2015 13:45:21 +0100
Subject: KSL: Reflection's orthogonality improvement
In-Reply-To: <CAEgw74CXMmSq9iFaoi1BNeXjH7iucjdXXhZrPQms3JXKs=u5aQ@mail.gmail.com>
References: <CAEgw74CXMmSq9iFaoi1BNeXjH7iucjdXXhZrPQms3JXKs=u5aQ@mail.gmail.com>
Message-ID: <561BAB61.6050302@oracle.com>

Hi,
Note that in general it is not possible to implement reflection checks 
statically, simply because the compile time and the runtime views of the 
world might be different: so, if all access checking was done at 
compile-time, (and the code would be replaced with the member name), you 
could have cases where at runtime no access error occurs - in cases 
where the member is no longer accessible (i.e. because of separate 
compilation).

A different approach would be e.g. to say that we have some syntactic 
sugar to create reflective elements. In such a setting lookup, 
accessibility check would still occur dynamically - the compiler will 
only help you removing the boilerplate. But I'm not sure such a feature 
would help much in the BD-like example you posted.

Maurizio

On 12/10/15 11:58, bsrbnd wrote:
> Hi,
>
> Just an idea for the "Kitchen Sink Language".
> I hope this subject hasn't already been discussed and that I haven't missed
> anything in the quite big and complex JLS.
> It's said not to think too much if this is a good or bad idea before
> submitting it for the KSL, but I hope I've thought enough...;-)
> Any comments, ideas or suggestions are welcomed.
> No implementation draft has been done until now, but it could be explored
> if comments are encouraging...
>
> Thanks in advance,
> bsrbnd
>
> Abstract
> --------
> Reflection is designed to access a class member given its name as a String.
> For example:
> MyClass.class.getDeclaredField("field") reflects MyClass.field or
> MyClass.class.getDeclaredMethod("method") reflects MyClass.method()
> But the reciprocal is false, we can't get the "String name" of a class member
> given its identifier.
> This implies a runtime check of the "String name" and an eventual exception
> if the name doesn't match a declared member...
> For this reason, we can say that reflection isn't totally orthogonal.
>
> Reciprocity with qualified strings (to be added to JLS 6.5.6.2,15.8,..?)
> ------------------------------------------------------------------------
> To avoid occasional exceptions (but not runtime checks) and improve reflection's
> orthogonality, I suggest to add the concept of "qualified strings".
> For example:
> MyClass."field" checks at compile-time that "field" is declared on
> MyClass and respects accessibility and visibility rules in a compatible way
> defined by reflection's API. This means that all declared member's names
> (private, protected, public, static or not) but neither inherited nor synthetic
> should be accessible as they are accepted by getDeclaredField() or
> getDeclaredMethod().
> If all compile-checks pass, this expression gives back the name of the
> member as a String.
>
> Grammar update (JLS 15.8)
> -------------------------
> I suggest to add the following line in "PrimaryNoNewArray" rule of the grammar:
>
> PrimaryNoNewArray:
>   TypeName . " Identifier "
>
> A simple databases example using "qualified strings"
> ----------------------------------------------------
> In the following example, "qualified strings" ensure that valid member's names
> are used in SQL requests to be correctly used by reflection to store back
> the result of the request:
>
> class MyTable {
>   public static final String name=MyTable.class.getSimpleName().toLowerCase();
>   public Integer id;
>   public Integer value;
> }
> MyTable line = new MyTable();
>
> String request =
> "SELECT " + MyTable."value" + " FROM " + MyTable.name +
> " WHERE " + MyTable."id" + "=" + line.id
>
> String valueColumn = resultset.getMetaData().getColumnName(1);
> Field f = MyTable.class.getDeclaredField(valueColumn.toLowerCase());
> f.set(line, resultSet.getInt(valueColumn));
>
> Conclusion
> ----------
> The usefulness of "qualified strings" isn't limited to this simple
> database example.
> It extends to every context where it is necessary to get informations
> from external parties and store back results dynamically in objects
> through reflection.


From chris.hegarty at oracle.com  Mon Oct 12 13:53:51 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 12 Oct 2015 14:53:51 +0100
Subject: RFR [9]8139371: Three langtools test failures after the removal of
	sun.misc.Lock
Message-ID: <561BBB6F.6080803@oracle.com>

The removal of sun.misc.Lock and a related type (JDK-8139307 [1])
has triggered three langtools test to fail, as they refer to the
removed types:

  tools/javac/proprietary/WarnClass.java
  tools/javac/warnings/6594914/T6594914b.java
  tools/jdeps/APIDeps.java

Another internal type should be used instead. The sun.security.x509
package seems stable, and is being used in other areas, jigsaw/jake,
to test accessibility.

http://cr.openjdk.java.net/~chegar/8139371/webrev.00/

-Chris.

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

From mandy.chung at oracle.com  Mon Oct 12 16:29:05 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 12 Oct 2015 09:29:05 -0700
Subject: RFR [9]8139371: Three langtools test failures after the removal
	of sun.misc.Lock
In-Reply-To: <561BBB6F.6080803@oracle.com>
References: <561BBB6F.6080803@oracle.com>
Message-ID: <D3BDD0B6-D2E2-49E6-A62F-35BF3F02AD8A@oracle.com>


> On Oct 12, 2015, at 6:53 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> The removal of sun.misc.Lock and a related type (JDK-8139307 [1])
> has triggered three langtools test to fail, as they refer to the
> removed types:
> 
> tools/javac/proprietary/WarnClass.java
> tools/javac/warnings/6594914/T6594914b.java
> tools/jdeps/APIDeps.java
> 
> Another internal type should be used instead. The sun.security.x509
> package seems stable, and is being used in other areas, jigsaw/jake,
> to test accessibility.
> 
> http://cr.openjdk.java.net/~chegar/8139371/webrev.00/

jdeps test change looks fine to me.

Mandy

From alex.buckley at oracle.com  Mon Oct 12 19:00:21 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 12 Oct 2015 12:00:21 -0700
Subject: KSL: Reflection's orthogonality improvement
In-Reply-To: <CAEgw74CXMmSq9iFaoi1BNeXjH7iucjdXXhZrPQms3JXKs=u5aQ@mail.gmail.com>
References: <CAEgw74CXMmSq9iFaoi1BNeXjH7iucjdXXhZrPQms3JXKs=u5aQ@mail.gmail.com>
Message-ID: <561C0345.80204@oracle.com>

There have been many suggestions over the years for some symbology in
the Java language to denote reflective operations over classes and
members. The underlying desire (often unstated) is a metaprogramming
facility in the language that allows abstraction over classes and
members. However, Java decided long ago to solve this problem with
metaDATA in the language -- annotations -- and leave the metaPROGRAMMING
part to ordinary programs that use the reflection or language model APIs
to read annotations -- frameworks like JPA and Dagger.

It's easy to say that metaPROGRAMMING is "obviously" the right thing and
that metaDATA is a poor relation -- in which case I urge a viewing of
"Stewardship: The Sobering Parts", particularly "The
Obvious Way is Often Wrong" at https://youtu.be/2y5Pv4yN0b0?t=28m40s.

Of course this is not the list for protracted discussion of language 
design philosophy, and in any case the "Kitchen Sink Language" is a 
concept from another era, but I thought some wider context might be helpful.

Alex

On 10/12/2015 3:58 AM, bsrbnd wrote:
> Hi,
>
> Just an idea for the "Kitchen Sink Language".
> I hope this subject hasn't already been discussed and that I haven't missed
> anything in the quite big and complex JLS.
> It's said not to think too much if this is a good or bad idea before
> submitting it for the KSL, but I hope I've thought enough...;-)
> Any comments, ideas or suggestions are welcomed.
> No implementation draft has been done until now, but it could be explored
> if comments are encouraging...
>
> Thanks in advance,
> bsrbnd

From jonathan.gibbons at oracle.com  Tue Oct 13 01:09:41 2015
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 12 Oct 2015 18:09:41 -0700
Subject: RFR [9]8139371: Three langtools test failures after the removal
	of sun.misc.Lock
In-Reply-To: <561BBB6F.6080803@oracle.com>
References: <561BBB6F.6080803@oracle.com>
Message-ID: <561C59D5.7080506@oracle.com>

Looks good to me.

-- Jon

On 10/12/2015 06:53 AM, Chris Hegarty wrote:
> The removal of sun.misc.Lock and a related type (JDK-8139307 [1])
> has triggered three langtools test to fail, as they refer to the
> removed types:
>
>  tools/javac/proprietary/WarnClass.java
>  tools/javac/warnings/6594914/T6594914b.java
>  tools/jdeps/APIDeps.java
>
> Another internal type should be used instead. The sun.security.x509
> package seems stable, and is being used in other areas, jigsaw/jake,
> to test accessibility.
>
> http://cr.openjdk.java.net/~chegar/8139371/webrev.00/
>
> -Chris.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8139307


From sergei.pikalev at oracle.com  Wed Oct 14 07:12:53 2015
From: sergei.pikalev at oracle.com (Sergei Pikalev)
Date: Wed, 14 Oct 2015 10:12:53 +0300
Subject: RFR JDK-8080641: JEP-JDK-8042880 : Implement new tests on Project Coin
Message-ID: <561E0075.7030701@oracle.com>


Hello,

This is the code with new Project Coin tests from SQE.

A webrev with the tests is here:

http://cr.openjdk.java.net/~shurailine/webrev.8080641/

Please review.

Thanks,
     Sergei


From jonathan.gibbons at oracle.com  Wed Oct 14 15:55:28 2015
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 14 Oct 2015 08:55:28 -0700
Subject: The -release option is not compatible with JavaFileManagers
In-Reply-To: <561D8AB2.7050006@oracle.com>
References: <561D8AB2.7050006@oracle.com>
Message-ID: <561E7AF0.8090008@oracle.com>

On 10/13/2015 03:50 PM, Keimpe Bronkhorst wrote:
> I have a custom JavaFileManager used for JSR199 compilations, but when 
> I use the -release option I see:
>
> Error: -release option specified, but the provided JavaFileManager is 
> not a StandardJavaFileManager..
>
> This basically forces everybody to implement StandardJavaFileManagers, 
> even if they don't want that. Isn't there a way to make this work with 
> JavaFileManagers?
>
> Keimpe Bronkhorst
> JDeveloper
>

cc: compiler-dev at openjdk.java.net
bcc: jigsaw-dev at openjdk.java.net

Keimpe,

This is not a Jigsaw issue. This would be better addressed on 
compiler-dev at openjdk.java.net.

-release works in a fairly general way by checking that -source, 
-target, -bootclasspath+friends, are not set, and then providing values 
for them. This implies that -release will internally call 
fileManager.setLocationFromPaths(PLATFORM_CLASS_PATH, <<path>>) which 
requires that the file manager should be a StandardJavaFileManager.

We can investigate whether it might be possible to generalize this.

-- Jon

From alex.buckley at oracle.com  Thu Oct 15 23:20:15 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 15 Oct 2015 16:20:15 -0700
Subject: RFR JDK-8080641: JEP-JDK-8042880 : Implement new tests on Project
	Coin
In-Reply-To: <561E0075.7030701@oracle.com>
References: <561E0075.7030701@oracle.com>
Message-ID: <562034AF.3070403@oracle.com>

Hi Sergei,

Most of the new regression tests are about conformance to the spec, 
rather than probing some javac-internal treatment of the t-w-r 
statement. I hope someone from JCK-Compiler can comment on their suppor 
for the expanded t-w-r statement.

That said, here are some comments on the new tests:

- ResourceVariableOutsideTry - @summary should be "Resource variable 
should be in scope throughout try, catch, and finally blocks". 
Accessibility is not relevant to a local variable like c.

- TwrAndAnonymousClass - this is a positive test when an anonymous class 
implements AutoCloseable, but what about a negative test when an 
anonymous class doesn't implement AutoCloseable?

- TwrAndGenerics - should be called TwrAndTypeVariables - plus same 
comment as above (type variables S and T _not_ extending AutoCloseable).

- TwrAndLambda - same comment as above (lambda expressions and method 
references _not_ implementing AutoCloseable).

- TwrVarKinds - good test, but if you're doing to test four kinds of 
variables then you may as well test all seven (JLS 4.12.3). In 
particular, array components should be tested. You should test using 
components from an array of AutoCloseables, and components of components 
from an array of an array of AutoCloseables. (The second situation in 
particular will expose any mistreatment of array components by javac -- 
if javac accidentally erases the array-ness of a resource variable, then 
in the first situation it will end up with an AutoCloseable and that's 
ordinary enough that everything might still work, but in the second 
situation it ends up with an array of AutoCloseables and that might blow 
up some logic.)

- WeirdTwr_WithVar - there is nothing weird or strange here. It's just 
one resource variable aliasing another, which was possible already. 
You're right to extend it so that a resource variable declared by 'try' 
aliases a resource variable declared outside 'try' -- also do it the 
other way around. Also, need a test where the resource variable declared 
outside 'try' is null.

- What's truly new when a try (...) header uses a resource variable 
declared outside the 'try'? Answer: no exception can be thrown, whereas 
the declaration of a resource variable by 'try' includes an initializer 
expression that can throw an exception. There should be a test to 
"prove" that try (r1) {...} doesn't throw exceptions from resource 
initialization, and that try (r1; AutoCloseable r2 = ...) {...} only 
throws exceptions due to r2's initialization.

Alex

On 10/14/2015 12:12 AM, Sergei Pikalev wrote:
>
> Hello,
>
> This is the code with new Project Coin tests from SQE.
>
> A webrev with the tests is here:
>
> http://cr.openjdk.java.net/~shurailine/webrev.8080641/
>
> Please review.
>
> Thanks,
>      Sergei
>

From andreas.lundblad at oracle.com  Fri Oct 16 10:24:20 2015
From: andreas.lundblad at oracle.com (Andreas Lundblad)
Date: Fri, 16 Oct 2015 12:24:20 +0200
Subject: GraphDependencies and completion
In-Reply-To: <20151009144814.GD3695@e6430>
References: <20151009144814.GD3695@e6430>
Message-ID: <20151016102420.GA26912@e6430>

Widening the audience of this discussion. Jan and Maurizio, forgive the overlap with previous email.

I've looked into the Dependencies class and tried to figure out how it can be adjusted to cover the requirements of sjavac (with the help of Jan and Maurizio). A summary follows.

Currently the Dependencies mechanism works as follows: When a symbol is about to be completed, it's pushed onto a stack and when completion finishes the stack is popped. If a symbol A is pushed, and then symbol B is pushed on top of A, it means that the completion of A triggered completion of B and by that we conclude that A depends on B. To hook into the completion mechanism the Dependencies class replaces the null completer with itself.

There are currently two issues with this approach.

1) If symbol A triggers completion of symbol B, but B happens to already be completed the dependency from A to B may go unnoticed.

2) When the Dependencies installs itself as a completer for the symbol, it *might* overwrite an important completer. Right now it seems like this doesn't happen, but it's fragile.

Problem 1 can be solved by always calling complete, even for the null completer. (I will benchmark carefully to make sure it doesn't cause a performance regression.)

Problem 2 is trickier. The most robust alternative would be to move the Dependencies.push/pop logic into Symbol.complete. Symbol doesn't have a reference to the context however, so getting hold of Dependencies is problematic. Another alternative would be to move the functionality over to the completer. It can be done without spreading the logic across all completers by making Completer an abstract class that takes care of this. I've tried this and it is possible but it gets quite complicated since for instance even the null completer needs to reference the context, and Symbol.complete needs a reference to the null completer.

Another option that has struck me is to let Symbol keep track of the dependencies by having a 'private static Symbol currentlyCompleted'. The complete method would then look something like

    if (currentlyCompleted != null)
        currentlyCompleted.deps.add(this);
    Symbol prev = currentlyCompleted;
    currentlyCompleted = this;
    c.complete(this);
    currentlyCompleted = prev;

Unfortunately this solution would actually require currentlyCompleted to be something like a ThreadLocal, which is not the javac-idiomatic way of solving per javac instance data, so I assume this is a no-go?

So, since I've already spent a lot of time on this, I'm now thinking of ignoring issue 2 for the time being. If anyone sees a solution, please let me know. (Should the current solution fall apart, my plan B is to go back to analyzing the AST.)

-- Andreas

From vicente.romero at oracle.com  Fri Oct 16 16:55:54 2015
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Fri, 16 Oct 2015 09:55:54 -0700
Subject: GraphDependencies and completion
In-Reply-To: <20151016102420.GA26912@e6430>
References: <20151009144814.GD3695@e6430> <20151016102420.GA26912@e6430>
Message-ID: <56212C1A.2080305@oracle.com>

Hi,

On 10/16/2015 03:24 AM, Andreas Lundblad wrote:
> Widening the audience of this discussion. Jan and Maurizio, forgive the overlap with previous email.
>
> I've looked into the Dependencies class and tried to figure out how it can be adjusted to cover the requirements of sjavac (with the help of Jan and Maurizio). A summary follows.
>
> Currently the Dependencies mechanism works as follows: When a symbol is about to be completed, it's pushed onto a stack and when completion finishes the stack is popped.

Where is this stack living? According to this description this algorithm 
is trying to find a topological sort of the dependency graph but it 
seems like its logic is not explicit but interleaved with the completion 
process. Probably this is the only way to do it. Can you provide some 
links to the current code implementing this?

Thanks,
Vicente

>   If a symbol A is pushed, and then symbol B is pushed on top of A, it means that the completion of A triggered completion of B and by that we conclude that A depends on B. To hook into the completion mechanism the Dependencies class replaces the null completer with itself.
>
> There are currently two issues with this approach.
>
> 1) If symbol A triggers completion of symbol B, but B happens to already be completed the dependency from A to B may go unnoticed.
>
> 2) When the Dependencies installs itself as a completer for the symbol, it *might* overwrite an important completer. Right now it seems like this doesn't happen, but it's fragile.
>
> Problem 1 can be solved by always calling complete, even for the null completer. (I will benchmark carefully to make sure it doesn't cause a performance regression.)
>
> Problem 2 is trickier. The most robust alternative would be to move the Dependencies.push/pop logic into Symbol.complete. Symbol doesn't have a reference to the context however, so getting hold of Dependencies is problematic. Another alternative would be to move the functionality over to the completer. It can be done without spreading the logic across all completers by making Completer an abstract class that takes care of this. I've tried this and it is possible but it gets quite complicated since for instance even the null completer needs to reference the context, and Symbol.complete needs a reference to the null completer.
>
> Another option that has struck me is to let Symbol keep track of the dependencies by having a 'private static Symbol currentlyCompleted'. The complete method would then look something like
>
>      if (currentlyCompleted != null)
>          currentlyCompleted.deps.add(this);
>      Symbol prev = currentlyCompleted;
>      currentlyCompleted = this;
>      c.complete(this);
>      currentlyCompleted = prev;
>
> Unfortunately this solution would actually require currentlyCompleted to be something like a ThreadLocal, which is not the javac-idiomatic way of solving per javac instance data, so I assume this is a no-go?
>
> So, since I've already spent a lot of time on this, I'm now thinking of ignoring issue 2 for the time being. If anyone sees a solution, please let me know. (Should the current solution fall apart, my plan B is to go back to analyzing the AST.)
>
> -- Andreas


From andreas.lundblad at oracle.com  Fri Oct 16 19:03:28 2015
From: andreas.lundblad at oracle.com (Andreas Lundblad)
Date: Fri, 16 Oct 2015 21:03:28 +0200
Subject: GraphDependencies and completion
In-Reply-To: <56212C1A.2080305@oracle.com>
References: <20151009144814.GD3695@e6430> <20151016102420.GA26912@e6430>
	<56212C1A.2080305@oracle.com>
Message-ID: <20151016190327.GC26912@e6430>

On Fri, Oct 16, 2015 at 09:55:54AM -0700, Vicente-Arturo Romero-Zaldivar wrote:
> Hi,
> 
> On 10/16/2015 03:24 AM, Andreas Lundblad wrote:
> >Widening the audience of this discussion. Jan and Maurizio, forgive the overlap with previous email.
> >
> >I've looked into the Dependencies class and tried to figure out how it can be adjusted to cover the requirements of sjavac (with the help of Jan and Maurizio). A summary follows.
> >
> >Currently the Dependencies mechanism works as follows: When a symbol is about to be completed, it's pushed onto a stack and when completion finishes the stack is popped.
> 
> Where is this stack living? According to this description this
> algorithm is trying to find a topological sort of the dependency
> graph but it seems like its logic is not explicit but interleaved
> with the completion process. Probably this is the only way to do it.
> Can you provide some links to the current code implementing this?

The stack lives in Dependencies.java (in the GraphDependencies class to be specific).

In a sense symbols are completed in a topological sorted order I guess, but note that completion of A may trigger completion of B which in turn may trigger completion of A again. This would mean that A depends on B and B depends on A. That is, the resulting dependency relation is not a topological sorted sequence, but an arbitrary graph.

You are right that the algorithm is interleaved with the completion process. Previously I analyzed the trees explicitly after the compilation, but it was more code and more cases to cover. Dependencies.java was already there for another purpose, so I switched to that which simplified the code a lot. As discovered later it introduced this regression.

-- Andreas

From vicente.romero at oracle.com  Fri Oct 16 19:06:31 2015
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Fri, 16 Oct 2015 12:06:31 -0700
Subject: GraphDependencies and completion
In-Reply-To: <20151016190327.GC26912@e6430>
References: <20151009144814.GD3695@e6430> <20151016102420.GA26912@e6430>
	<56212C1A.2080305@oracle.com> <20151016190327.GC26912@e6430>
Message-ID: <56214AB7.4050308@oracle.com>

On 10/16/2015 12:03 PM, Andreas Lundblad wrote:
> On Fri, Oct 16, 2015 at 09:55:54AM -0700, Vicente-Arturo Romero-Zaldivar wrote:
>> Hi,
>>
>> On 10/16/2015 03:24 AM, Andreas Lundblad wrote:
>>> Widening the audience of this discussion. Jan and Maurizio, forgive the overlap with previous email.
>>>
>>> I've looked into the Dependencies class and tried to figure out how it can be adjusted to cover the requirements of sjavac (with the help of Jan and Maurizio). A summary follows.
>>>
>>> Currently the Dependencies mechanism works as follows: When a symbol is about to be completed, it's pushed onto a stack and when completion finishes the stack is popped.
>> Where is this stack living? According to this description this
>> algorithm is trying to find a topological sort of the dependency
>> graph but it seems like its logic is not explicit but interleaved
>> with the completion process. Probably this is the only way to do it.
>> Can you provide some links to the current code implementing this?
> The stack lives in Dependencies.java (in the GraphDependencies class to be specific).
>
> In a sense symbols are completed in a topological sorted order I guess, but note that completion of A may trigger completion of B which in turn may trigger completion of A again. This would mean that A depends on B and B depends on A. That is, the resulting dependency relation is not a topological sorted sequence, but an arbitrary graph.
>
> You are right that the algorithm is interleaved with the completion process. Previously I analyzed the trees explicitly after the compilation, but it was more code and more cases to cover. Dependencies.java was already there for another purpose, so I switched to that which simplified the code a lot. As discovered later it introduced this regression.

Is it possible to just "observe" the process, gathering the needed 
information and build the graph you need once the process finishes?

Vicente
>
> -- Andreas


From maurizio.cimadamore at oracle.com  Fri Oct 16 21:17:54 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 16 Oct 2015 23:17:54 +0200
Subject: GraphDependencies and completion
In-Reply-To: <20151016102420.GA26912@e6430>
References: <20151009144814.GD3695@e6430> <20151016102420.GA26912@e6430>
Message-ID: <56216982.1000608@oracle.com>

Would a delegation model work for problem 2? I.e. the dependencies 
completer could be a 'spy' completer that did its own bit of logic and 
then delegated to the completer originally installed (which could be a 
real completer or the null completer).

Maurizio

On 16/10/15 12:24, Andreas Lundblad wrote:
> Widening the audience of this discussion. Jan and Maurizio, forgive the overlap with previous email.
>
> I've looked into the Dependencies class and tried to figure out how it can be adjusted to cover the requirements of sjavac (with the help of Jan and Maurizio). A summary follows.
>
> Currently the Dependencies mechanism works as follows: When a symbol is about to be completed, it's pushed onto a stack and when completion finishes the stack is popped. If a symbol A is pushed, and then symbol B is pushed on top of A, it means that the completion of A triggered completion of B and by that we conclude that A depends on B. To hook into the completion mechanism the Dependencies class replaces the null completer with itself.
>
> There are currently two issues with this approach.
>
> 1) If symbol A triggers completion of symbol B, but B happens to already be completed the dependency from A to B may go unnoticed.
>
> 2) When the Dependencies installs itself as a completer for the symbol, it *might* overwrite an important completer. Right now it seems like this doesn't happen, but it's fragile.
>
> Problem 1 can be solved by always calling complete, even for the null completer. (I will benchmark carefully to make sure it doesn't cause a performance regression.)
>
> Problem 2 is trickier. The most robust alternative would be to move the Dependencies.push/pop logic into Symbol.complete. Symbol doesn't have a reference to the context however, so getting hold of Dependencies is problematic. Another alternative would be to move the functionality over to the completer. It can be done without spreading the logic across all completers by making Completer an abstract class that takes care of this. I've tried this and it is possible but it gets quite complicated since for instance even the null completer needs to reference the context, and Symbol.complete needs a reference to the null completer.
>
> Another option that has struck me is to let Symbol keep track of the dependencies by having a 'private static Symbol currentlyCompleted'. The complete method would then look something like
>
>      if (currentlyCompleted != null)
>          currentlyCompleted.deps.add(this);
>      Symbol prev = currentlyCompleted;
>      currentlyCompleted = this;
>      c.complete(this);
>      currentlyCompleted = prev;
>
> Unfortunately this solution would actually require currentlyCompleted to be something like a ThreadLocal, which is not the javac-idiomatic way of solving per javac instance data, so I assume this is a no-go?
>
> So, since I've already spent a lot of time on this, I'm now thinking of ignoring issue 2 for the time being. If anyone sees a solution, please let me know. (Should the current solution fall apart, my plan B is to go back to analyzing the AST.)
>
> -- Andreas


From alex.buckley at oracle.com  Fri Oct 16 21:41:13 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 16 Oct 2015 14:41:13 -0700
Subject: RFR JDK-8080641: JEP-JDK-8042880 : Implement new tests on Project
	Coin
In-Reply-To: <56215BF5.7050003@oracle.com>
References: <561E0075.7030701@oracle.com> <562034AF.3070403@oracle.com>
	<56215BF5.7050003@oracle.com>
Message-ID: <56216EF9.2040407@oracle.com>

On 10/16/2015 1:20 PM, Sergei Pikalev wrote:
> I've fixed all remarks you've send me except one. I'd like to ask you
> about it.
>
>> - What's truly new when a try (...) header uses a resource variable
>> declared outside the 'try'? Answer: no exception can be thrown,
>> whereas the declaration of a resource variable by 'try' includes an
>> initializer expression that can throw an exception. There should be a
>> test to "prove" that try (r1) {...} doesn't throw exceptions from
>> resource initialization, and that try (r1; AutoCloseable r2 = ...)
>> {...} only throws exceptions due to r2's initialization.
>
> I can imagine just one case of variables where r1 could throw something.
> It's r1 = null case.
> So try (r1) {...} throws NullPointerException and catch block catches
> it. Also the case
> try (r1; AutoCloseable r2 = ...) {...} catches NullPointerException
> because it is thrown first.
> In other cases we have either correctly initialized r1 in try(r1) block
> or stop execution on
> exceptions with initialization of r1 before try(r1) {...} block.
>
> What do you really meant here?

Remember that a resource variable can be initialized to null. There's 
nothing wrong with that. It simply means the resource won't be closed 
automatically. See JLS8 14.20.3. Nothing has changed in this regard for 
SE 9.

What you're trying to "prove" is that this code -- try (r1) {} -- never 
throws any exceptions at run time regardless of the value of r1. Not 
from resource initialization, not from the try block, not from resource 
closure. I'm assuming the close() method in question doesn't throw 
anything, like Scanner::close. The number of resources can be increased, 
in both the old and new styles -- try (r1; AutoCloseable r2 = r1; 
AutoCloseable r3 = r2; r4) {}.

For try (r1) {} -- the single resource is ALWAYS initialized, and the 
try block is ALWAYS reachable (look at the translation in 14.20.3.1), 
and the single resource is ALWAYS closed provided it's non-null. Before 
SE 9, it was NOT true that a resource is ALWAYS closed because of the 
possibility that the resource failed to initialize. (Yes, if it did 
initialize to a non-null value, then it would always be closed, but 
initialization could prevent r1.close() ever being run.) So, another 
test should prove that r1's close() method is always run.

Now consider this extension -- try (r1; AutoCloseable r2 = 
alwaysBlowUp()) {}. This t-w-r will always initialize the first resource 
and ALWAYS close the first resource (provided r1 is non-null) even if 
the second resource failed to initialize. So regardless of the 
exceptions from r2's initialization, r1.close() will always be run.

Regarding the kind of variable that r1 is -- we talked about it being an 
array component, and it should also be a local variable that's not 
definitely assigned and a blank final field that's not definitely assigned.

Alex

From vicente.romero at oracle.com  Fri Oct 16 22:33:58 2015
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Fri, 16 Oct 2015 15:33:58 -0700
Subject: GraphDependencies and completion
In-Reply-To: <56216982.1000608@oracle.com>
References: <20151009144814.GD3695@e6430> <20151016102420.GA26912@e6430>
	<56216982.1000608@oracle.com>
Message-ID: <56217B56.5010308@oracle.com>

On 10/16/2015 02:17 PM, Maurizio Cimadamore wrote:
> Would a delegation model work for problem 2? I.e. the dependencies 
> completer could be a 'spy' completer that did its own bit of logic and 
> then delegated to the completer originally installed (which could be a 
> real completer or the null completer).

I also thought about this, but IMO the model could be more general. I 
mean it doesn't seem to be necessary to stablish an order between the 
dependencies completer and the "original" completer. It seems to me like 
they can be executed in any order thus effectively working as "event 
listeners". This could imply having a list, or set if you want to 
enforce uniqueness, of completers instead of only one completer.

Vicente

>
> Maurizio
>
> On 16/10/15 12:24, Andreas Lundblad wrote:
>> Widening the audience of this discussion. Jan and Maurizio, forgive 
>> the overlap with previous email.
>>
>> I've looked into the Dependencies class and tried to figure out how 
>> it can be adjusted to cover the requirements of sjavac (with the help 
>> of Jan and Maurizio). A summary follows.
>>
>> Currently the Dependencies mechanism works as follows: When a symbol 
>> is about to be completed, it's pushed onto a stack and when 
>> completion finishes the stack is popped. If a symbol A is pushed, and 
>> then symbol B is pushed on top of A, it means that the completion of 
>> A triggered completion of B and by that we conclude that A depends on 
>> B. To hook into the completion mechanism the Dependencies class 
>> replaces the null completer with itself.
>>
>> There are currently two issues with this approach.
>>
>> 1) If symbol A triggers completion of symbol B, but B happens to 
>> already be completed the dependency from A to B may go unnoticed.
>>
>> 2) When the Dependencies installs itself as a completer for the 
>> symbol, it *might* overwrite an important completer. Right now it 
>> seems like this doesn't happen, but it's fragile.
>>
>> Problem 1 can be solved by always calling complete, even for the null 
>> completer. (I will benchmark carefully to make sure it doesn't cause 
>> a performance regression.)
>>
>> Problem 2 is trickier. The most robust alternative would be to move 
>> the Dependencies.push/pop logic into Symbol.complete. Symbol doesn't 
>> have a reference to the context however, so getting hold of 
>> Dependencies is problematic. Another alternative would be to move the 
>> functionality over to the completer. It can be done without spreading 
>> the logic across all completers by making Completer an abstract class 
>> that takes care of this. I've tried this and it is possible but it 
>> gets quite complicated since for instance even the null completer 
>> needs to reference the context, and Symbol.complete needs a reference 
>> to the null completer.
>>
>> Another option that has struck me is to let Symbol keep track of the 
>> dependencies by having a 'private static Symbol currentlyCompleted'. 
>> The complete method would then look something like
>>
>>      if (currentlyCompleted != null)
>>          currentlyCompleted.deps.add(this);
>>      Symbol prev = currentlyCompleted;
>>      currentlyCompleted = this;
>>      c.complete(this);
>>      currentlyCompleted = prev;
>>
>> Unfortunately this solution would actually require currentlyCompleted 
>> to be something like a ThreadLocal, which is not the javac-idiomatic 
>> way of solving per javac instance data, so I assume this is a no-go?
>>
>> So, since I've already spent a lot of time on this, I'm now thinking 
>> of ignoring issue 2 for the time being. If anyone sees a solution, 
>> please let me know. (Should the current solution fall apart, my plan 
>> B is to go back to analyzing the AST.)
>>
>> -- Andreas
>


From andreas.lundblad at oracle.com  Sat Oct 17 08:41:33 2015
From: andreas.lundblad at oracle.com (Andreas Lundblad)
Date: Sat, 17 Oct 2015 10:41:33 +0200
Subject: GraphDependencies and completion
In-Reply-To: <56217B56.5010308@oracle.com>
References: <20151009144814.GD3695@e6430> <20151016102420.GA26912@e6430>
	<56216982.1000608@oracle.com> <56217B56.5010308@oracle.com>
Message-ID: <20151017084133.GB29088@e6430>

On Fri, Oct 16, 2015 at 03:33:58PM -0700, Vicente-Arturo Romero-Zaldivar wrote:
> On 10/16/2015 02:17 PM, Maurizio Cimadamore wrote:
> >Would a delegation model work for problem 2? I.e. the dependencies
> >completer could be a 'spy' completer that did its own bit of logic
> >and then delegated to the completer originally installed (which
> >could be a real completer or the null completer).
> 
> I also thought about this, but IMO the model could be more general.
> I mean it doesn't seem to be necessary to stablish an order between
> the dependencies completer and the "original" completer. It seems to
> me like they can be executed in any order thus effectively working
> as "event listeners". This could imply having a list, or set if you
> want to enforce uniqueness, of completers instead of only one
> completer.

If I understand you correctly, you're suggesting something like

    symbol.completer = dependencies.wrapCompleter(someCompleter);

Jan suggested this as well. The drawback is that there are ~20 writes to the symbol.completer field, two of which are inside Symbol that doesn't have a reference to the context.

-- Andreas

From vicente.romero at oracle.com  Sun Oct 18 21:31:46 2015
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Sun, 18 Oct 2015 14:31:46 -0700
Subject: GraphDependencies and completion
In-Reply-To: <20151017084133.GB29088@e6430>
References: <20151009144814.GD3695@e6430> <20151016102420.GA26912@e6430>
	<56216982.1000608@oracle.com> <56217B56.5010308@oracle.com>
	<20151017084133.GB29088@e6430>
Message-ID: <56240FC2.4090002@oracle.com>

On 10/17/2015 01:41 AM, Andreas Lundblad wrote:
> On Fri, Oct 16, 2015 at 03:33:58PM -0700, Vicente-Arturo Romero-Zaldivar wrote:
>> On 10/16/2015 02:17 PM, Maurizio Cimadamore wrote:
>>> Would a delegation model work for problem 2? I.e. the dependencies
>>> completer could be a 'spy' completer that did its own bit of logic
>>> and then delegated to the completer originally installed (which
>>> could be a real completer or the null completer).
>> I also thought about this, but IMO the model could be more general.
>> I mean it doesn't seem to be necessary to stablish an order between
>> the dependencies completer and the "original" completer. It seems to
>> me like they can be executed in any order thus effectively working
>> as "event listeners". This could imply having a list, or set if you
>> want to enforce uniqueness, of completers instead of only one
>> completer.
> If I understand you correctly, you're suggesting something like
>
>      symbol.completer = dependencies.wrapCompleter(someCompleter);
>
> Jan suggested this as well. The drawback is that there are ~20 writes to the symbol.completer field, two of which are inside Symbol that doesn't have a reference to the context.

I guess that this is what Maurizio is also proposing. In theory this 
model can work but it imply an order: the dependencies completer will 
always be executed before the "original" completer. I believe that the 
order is not important here and that a symbol can in general contain a 
list of completers which can be notified of events. Different completers 
don't need to know about or affect other completers in the list.

Vicente

>
> -- Andreas


From bsrbnd at gmail.com  Mon Oct 19 08:30:52 2015
From: bsrbnd at gmail.com (bsrbnd)
Date: Mon, 19 Oct 2015 10:30:52 +0200
Subject: KSL: Reflection's orthogonality improvement
In-Reply-To: <CAEgw74CXMmSq9iFaoi1BNeXjH7iucjdXXhZrPQms3JXKs=u5aQ@mail.gmail.com>
References: <CAEgw74CXMmSq9iFaoi1BNeXjH7iucjdXXhZrPQms3JXKs=u5aQ@mail.gmail.com>
Message-ID: <CAEgw74AdOE+Hv4bDRAHjnbKVbFzqzuDCB=obyv9PC7uCd7H84g@mail.gmail.com>

Thanks for your both answers.

Referring to the first message, I agree that compile-time and runtime
are distinct worlds.
But, in our case, the link between them is the "String name" of members.
Therefore you can see qualified strings as a kind of compile-time
reflection (the reciprocal of runtime reflection).
In this context, the reflective object of an identifier is just a
"String" representing its name.
This is why it is different from a syntactic sugar or a specific
symbology to access reflective objects through class members.

But we could go further in this approch by getting a kind of "Symbol"
instead of a "String" to reflect the identifier.
For example:
 MyClass.#myMethod
would denote a "MethodSymbol" representing the compile-time view of myMethod().
If you define (in addition to its name), an apply(Object, Object...)
method on it; you would be able to call a precise method, without
dynamic binding.
This could let you access other methods than the specific one...
For example:
 Object.#toString.name
would be equivalent to Object."toString" (qualified string) and:
 Object.#toString.apply(new Integer(1))
would apply on "new Integer(1)" the method "toString()" defined on
"Object" instead of the one defined on "Integer".
This is, of course, only an example to demonstrate the concept behind
qualified strings, not to discuss about object-oriented principles...

Referring now to the second message, I agree that one of the reasons
behind this is to add some kind of meta-programming facility.
Nevertheless, I understand if it has already been discussed along the
years and therefore doesn't
meet the adopted design philosophy.
But, it was very tempting to suggest this concept regarding to its
quite straightforward implementation
and the added possibilities it brings...

bsrbnd

2015-10-12 12:58 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
> Hi,
>
> Just an idea for the "Kitchen Sink Language".
> I hope this subject hasn't already been discussed and that I haven't missed
> anything in the quite big and complex JLS.
> It's said not to think too much if this is a good or bad idea before
> submitting it for the KSL, but I hope I've thought enough...;-)
> Any comments, ideas or suggestions are welcomed.
> No implementation draft has been done until now, but it could be explored
> if comments are encouraging...
>
> Thanks in advance,
> bsrbnd
>
> Abstract
> --------
> Reflection is designed to access a class member given its name as a String.
> For example:
> MyClass.class.getDeclaredField("field") reflects MyClass.field or
> MyClass.class.getDeclaredMethod("method") reflects MyClass.method()
> But the reciprocal is false, we can't get the "String name" of a class member
> given its identifier.
> This implies a runtime check of the "String name" and an eventual exception
> if the name doesn't match a declared member...
> For this reason, we can say that reflection isn't totally orthogonal.
>
> Reciprocity with qualified strings (to be added to JLS 6.5.6.2,15.8,..?)
> ------------------------------------------------------------------------
> To avoid occasional exceptions (but not runtime checks) and improve reflection's
> orthogonality, I suggest to add the concept of "qualified strings".
> For example:
> MyClass."field" checks at compile-time that "field" is declared on
> MyClass and respects accessibility and visibility rules in a compatible way
> defined by reflection's API. This means that all declared member's names
> (private, protected, public, static or not) but neither inherited nor synthetic
> should be accessible as they are accepted by getDeclaredField() or
> getDeclaredMethod().
> If all compile-checks pass, this expression gives back the name of the
> member as a String.
>
> Grammar update (JLS 15.8)
> -------------------------
> I suggest to add the following line in "PrimaryNoNewArray" rule of the grammar:
>
> PrimaryNoNewArray:
>  TypeName . " Identifier "
>
> A simple databases example using "qualified strings"
> ----------------------------------------------------
> In the following example, "qualified strings" ensure that valid member's names
> are used in SQL requests to be correctly used by reflection to store back
> the result of the request:
>
> class MyTable {
>  public static final String name=MyTable.class.getSimpleName().toLowerCase();
>  public Integer id;
>  public Integer value;
> }
> MyTable line = new MyTable();
>
> String request =
> "SELECT " + MyTable."value" + " FROM " + MyTable.name +
> " WHERE " + MyTable."id" + "=" + line.id
>
> String valueColumn = resultset.getMetaData().getColumnName(1);
> Field f = MyTable.class.getDeclaredField(valueColumn.toLowerCase());
> f.set(line, resultSet.getInt(valueColumn));
>
> Conclusion
> ----------
> The usefulness of "qualified strings" isn't limited to this simple
> database example.
> It extends to every context where it is necessary to get informations
> from external parties and store back results dynamically in objects
> through reflection.

From sergei.pikalev at oracle.com  Mon Oct 19 15:05:43 2015
From: sergei.pikalev at oracle.com (Sergei Pikalev)
Date: Mon, 19 Oct 2015 18:05:43 +0300
Subject: RFR JDK-8080641: JEP-JDK-8042880 : Implement new tests on Project
	Coin
In-Reply-To: <562034AF.3070403@oracle.com>
References: <561E0075.7030701@oracle.com> <562034AF.3070403@oracle.com>
Message-ID: <562506C7.5040208@oracle.com>


Hi All,

http://cr.openjdk.java.net/~shurailine/8080641/webrev.01/

There are updated tests with respect to Alex's remarks.

Thanks,
     Sergi

On 16.10.2015 02:20, Alex Buckley wrote:
> Hi Sergei,
>
> Most of the new regression tests are about conformance to the spec, 
> rather than probing some javac-internal treatment of the t-w-r 
> statement. I hope someone from JCK-Compiler can comment on their 
> suppor for the expanded t-w-r statement.
>
> That said, here are some comments on the new tests:
>
> - ResourceVariableOutsideTry - @summary should be "Resource variable 
> should be in scope throughout try, catch, and finally blocks". 
> Accessibility is not relevant to a local variable like c.
>
> - TwrAndAnonymousClass - this is a positive test when an anonymous 
> class implements AutoCloseable, but what about a negative test when an 
> anonymous class doesn't implement AutoCloseable?
>
> - TwrAndGenerics - should be called TwrAndTypeVariables - plus same 
> comment as above (type variables S and T _not_ extending AutoCloseable).
>
> - TwrAndLambda - same comment as above (lambda expressions and method 
> references _not_ implementing AutoCloseable).
>
> - TwrVarKinds - good test, but if you're doing to test four kinds of 
> variables then you may as well test all seven (JLS 4.12.3). In 
> particular, array components should be tested. You should test using 
> components from an array of AutoCloseables, and components of 
> components from an array of an array of AutoCloseables. (The second 
> situation in particular will expose any mistreatment of array 
> components by javac -- if javac accidentally erases the array-ness of 
> a resource variable, then in the first situation it will end up with 
> an AutoCloseable and that's ordinary enough that everything might 
> still work, but in the second situation it ends up with an array of 
> AutoCloseables and that might blow up some logic.)
>
> - WeirdTwr_WithVar - there is nothing weird or strange here. It's just 
> one resource variable aliasing another, which was possible already. 
> You're right to extend it so that a resource variable declared by 
> 'try' aliases a resource variable declared outside 'try' -- also do it 
> the other way around. Also, need a test where the resource variable 
> declared outside 'try' is null.
>
> - What's truly new when a try (...) header uses a resource variable 
> declared outside the 'try'? Answer: no exception can be thrown, 
> whereas the declaration of a resource variable by 'try' includes an 
> initializer expression that can throw an exception. There should be a 
> test to "prove" that try (r1) {...} doesn't throw exceptions from 
> resource initialization, and that try (r1; AutoCloseable r2 = ...) 
> {...} only throws exceptions due to r2's initialization.
>
> Alex
>
> On 10/14/2015 12:12 AM, Sergei Pikalev wrote:
>>
>> Hello,
>>
>> This is the code with new Project Coin tests from SQE.
>>
>> A webrev with the tests is here:
>>
>> http://cr.openjdk.java.net/~shurailine/webrev.8080641/
>>
>> Please review.
>>
>> Thanks,
>>      Sergei
>>


From alex.buckley at oracle.com  Mon Oct 19 23:57:07 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 19 Oct 2015 16:57:07 -0700
Subject: RFR JDK-8080641: JEP-JDK-8042880 : Implement new tests on Project
	Coin
In-Reply-To: <562506C7.5040208@oracle.com>
References: <561E0075.7030701@oracle.com> <562034AF.3070403@oracle.com>
	<562506C7.5040208@oracle.com>
Message-ID: <56258353.2050608@oracle.com>

I don't see any testing of array components as resources, or testing 
that a resource declared outside the t-w-r statement can either be null 
or is guaranteed to initialize (as discussed in a separate mail).

Alex

On 10/19/2015 8:05 AM, Sergei Pikalev wrote:
>
> Hi All,
>
> http://cr.openjdk.java.net/~shurailine/8080641/webrev.01/
>
> There are updated tests with respect to Alex's remarks.
>
> Thanks,
>      Sergi
>
> On 16.10.2015 02:20, Alex Buckley wrote:
>> Hi Sergei,
>>
>> Most of the new regression tests are about conformance to the spec,
>> rather than probing some javac-internal treatment of the t-w-r
>> statement. I hope someone from JCK-Compiler can comment on their
>> suppor for the expanded t-w-r statement.
>>
>> That said, here are some comments on the new tests:
>>
>> - ResourceVariableOutsideTry - @summary should be "Resource variable
>> should be in scope throughout try, catch, and finally blocks".
>> Accessibility is not relevant to a local variable like c.
>>
>> - TwrAndAnonymousClass - this is a positive test when an anonymous
>> class implements AutoCloseable, but what about a negative test when an
>> anonymous class doesn't implement AutoCloseable?
>>
>> - TwrAndGenerics - should be called TwrAndTypeVariables - plus same
>> comment as above (type variables S and T _not_ extending AutoCloseable).
>>
>> - TwrAndLambda - same comment as above (lambda expressions and method
>> references _not_ implementing AutoCloseable).
>>
>> - TwrVarKinds - good test, but if you're doing to test four kinds of
>> variables then you may as well test all seven (JLS 4.12.3). In
>> particular, array components should be tested. You should test using
>> components from an array of AutoCloseables, and components of
>> components from an array of an array of AutoCloseables. (The second
>> situation in particular will expose any mistreatment of array
>> components by javac -- if javac accidentally erases the array-ness of
>> a resource variable, then in the first situation it will end up with
>> an AutoCloseable and that's ordinary enough that everything might
>> still work, but in the second situation it ends up with an array of
>> AutoCloseables and that might blow up some logic.)
>>
>> - WeirdTwr_WithVar - there is nothing weird or strange here. It's just
>> one resource variable aliasing another, which was possible already.
>> You're right to extend it so that a resource variable declared by
>> 'try' aliases a resource variable declared outside 'try' -- also do it
>> the other way around. Also, need a test where the resource variable
>> declared outside 'try' is null.
>>
>> - What's truly new when a try (...) header uses a resource variable
>> declared outside the 'try'? Answer: no exception can be thrown,
>> whereas the declaration of a resource variable by 'try' includes an
>> initializer expression that can throw an exception. There should be a
>> test to "prove" that try (r1) {...} doesn't throw exceptions from
>> resource initialization, and that try (r1; AutoCloseable r2 = ...)
>> {...} only throws exceptions due to r2's initialization.
>>
>> Alex
>>
>> On 10/14/2015 12:12 AM, Sergei Pikalev wrote:
>>>
>>> Hello,
>>>
>>> This is the code with new Project Coin tests from SQE.
>>>
>>> A webrev with the tests is here:
>>>
>>> http://cr.openjdk.java.net/~shurailine/webrev.8080641/
>>>
>>> Please review.
>>>
>>> Thanks,
>>>      Sergei
>>>
>

From sergei.pikalev at oracle.com  Tue Oct 20 00:35:51 2015
From: sergei.pikalev at oracle.com (Sergei Pikalev)
Date: Tue, 20 Oct 2015 03:35:51 +0300
Subject: RFR JDK-8080641: JEP-JDK-8042880 : Implement new tests on Project
	Coin
In-Reply-To: <56258353.2050608@oracle.com>
References: <561E0075.7030701@oracle.com>
	<562034AF.3070403@oracle.com>	<562506C7.5040208@oracle.com>
	<56258353.2050608@oracle.com>
Message-ID: <56258C67.3050700@oracle.com>


Hi Alex,

These test are additional to existing test, and developers recommended me
not to create new files but enrich existing as far as possible.

Array components assertions are located at TwrForVariable2.

Other discussed issues are in TwrForVariable1. Null cases 'prove' that 
null does
not generate exceptions beyond the t-w-r block. Positive part checks 
initialized
resources.

Some of this assertions came from developers' unit test. Some was added 
by me.

Sergi

On 20.10.2015 02:57, Alex Buckley wrote:
> I don't see any testing of array components as resources, or testing 
> that a resource declared outside the t-w-r statement can either be 
> null or is guaranteed to initialize (as discussed in a separate mail).
>
> Alex
>
> On 10/19/2015 8:05 AM, Sergei Pikalev wrote:
>>
>> Hi All,
>>
>> http://cr.openjdk.java.net/~shurailine/8080641/webrev.01/
>>
>> There are updated tests with respect to Alex's remarks.
>>
>> Thanks,
>>      Sergi
>>
>> On 16.10.2015 02:20, Alex Buckley wrote:
>>> Hi Sergei,
>>>
>>> Most of the new regression tests are about conformance to the spec,
>>> rather than probing some javac-internal treatment of the t-w-r
>>> statement. I hope someone from JCK-Compiler can comment on their
>>> suppor for the expanded t-w-r statement.
>>>
>>> That said, here are some comments on the new tests:
>>>
>>> - ResourceVariableOutsideTry - @summary should be "Resource variable
>>> should be in scope throughout try, catch, and finally blocks".
>>> Accessibility is not relevant to a local variable like c.
>>>
>>> - TwrAndAnonymousClass - this is a positive test when an anonymous
>>> class implements AutoCloseable, but what about a negative test when an
>>> anonymous class doesn't implement AutoCloseable?
>>>
>>> - TwrAndGenerics - should be called TwrAndTypeVariables - plus same
>>> comment as above (type variables S and T _not_ extending 
>>> AutoCloseable).
>>>
>>> - TwrAndLambda - same comment as above (lambda expressions and method
>>> references _not_ implementing AutoCloseable).
>>>
>>> - TwrVarKinds - good test, but if you're doing to test four kinds of
>>> variables then you may as well test all seven (JLS 4.12.3). In
>>> particular, array components should be tested. You should test using
>>> components from an array of AutoCloseables, and components of
>>> components from an array of an array of AutoCloseables. (The second
>>> situation in particular will expose any mistreatment of array
>>> components by javac -- if javac accidentally erases the array-ness of
>>> a resource variable, then in the first situation it will end up with
>>> an AutoCloseable and that's ordinary enough that everything might
>>> still work, but in the second situation it ends up with an array of
>>> AutoCloseables and that might blow up some logic.)
>>>
>>> - WeirdTwr_WithVar - there is nothing weird or strange here. It's just
>>> one resource variable aliasing another, which was possible already.
>>> You're right to extend it so that a resource variable declared by
>>> 'try' aliases a resource variable declared outside 'try' -- also do it
>>> the other way around. Also, need a test where the resource variable
>>> declared outside 'try' is null.
>>>
>>> - What's truly new when a try (...) header uses a resource variable
>>> declared outside the 'try'? Answer: no exception can be thrown,
>>> whereas the declaration of a resource variable by 'try' includes an
>>> initializer expression that can throw an exception. There should be a
>>> test to "prove" that try (r1) {...} doesn't throw exceptions from
>>> resource initialization, and that try (r1; AutoCloseable r2 = ...)
>>> {...} only throws exceptions due to r2's initialization.
>>>
>>> Alex
>>>
>>> On 10/14/2015 12:12 AM, Sergei Pikalev wrote:
>>>>
>>>> Hello,
>>>>
>>>> This is the code with new Project Coin tests from SQE.
>>>>
>>>> A webrev with the tests is here:
>>>>
>>>> http://cr.openjdk.java.net/~shurailine/webrev.8080641/
>>>>
>>>> Please review.
>>>>
>>>> Thanks,
>>>>      Sergei
>>>>
>>


From alex.buckley at oracle.com  Tue Oct 20 01:08:26 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 19 Oct 2015 18:08:26 -0700
Subject: RFR JDK-8080641: JEP-JDK-8042880 : Implement new tests on Project
	Coin
In-Reply-To: <56258C67.3050700@oracle.com>
References: <561E0075.7030701@oracle.com>	<562034AF.3070403@oracle.com>	<562506C7.5040208@oracle.com>	<56258353.2050608@oracle.com>
	<56258C67.3050700@oracle.com>
Message-ID: <5625940A.1060503@oracle.com>

Thanks for the pointers.

I remember now: array components can't be used as resources because, as 
variables, they are never final or effectively final. (Only an array 
variable itself may be final or effectively final, not its components.) 
That's why the grammar only allows ExpressionName and FieldAccess, not 
ArrayAccess.

But, since array components are variables, I would have expected them to 
be tested in TwrVarKinds rather than TwrForVariable2. And, I would have 
expected the negative tests in TwrForVariable2 for a conditional 
expression and a null-with-cast to be located in TwrForVariable3 where 
other (illegal) expressions are tried. Tests should be written in the 
right place if we want people to read them.

WeirdTwr_WithVar is misnamed and unnecessary. The single t-w-r statement 
that it contains could live perfectly well in TwrForVariable1, near the 
nice new cases for assertCloseCount(7) and  assertCloseCount(10).

Alex

On 10/19/2015 5:35 PM, Sergei Pikalev wrote:
>
> Hi Alex,
>
> These test are additional to existing test, and developers recommended me
> not to create new files but enrich existing as far as possible.
>
> Array components assertions are located at TwrForVariable2.
>
> Other discussed issues are in TwrForVariable1. Null cases 'prove' that
> null does
> not generate exceptions beyond the t-w-r block. Positive part checks
> initialized
> resources.
>
> Some of this assertions came from developers' unit test. Some was added
> by me.
>
> Sergi
>
> On 20.10.2015 02:57, Alex Buckley wrote:
>> I don't see any testing of array components as resources, or testing
>> that a resource declared outside the t-w-r statement can either be
>> null or is guaranteed to initialize (as discussed in a separate mail).
>>
>> Alex
>>
>> On 10/19/2015 8:05 AM, Sergei Pikalev wrote:
>>>
>>> Hi All,
>>>
>>> http://cr.openjdk.java.net/~shurailine/8080641/webrev.01/
>>>
>>> There are updated tests with respect to Alex's remarks.
>>>
>>> Thanks,
>>>      Sergi
>>>
>>> On 16.10.2015 02:20, Alex Buckley wrote:
>>>> Hi Sergei,
>>>>
>>>> Most of the new regression tests are about conformance to the spec,
>>>> rather than probing some javac-internal treatment of the t-w-r
>>>> statement. I hope someone from JCK-Compiler can comment on their
>>>> suppor for the expanded t-w-r statement.
>>>>
>>>> That said, here are some comments on the new tests:
>>>>
>>>> - ResourceVariableOutsideTry - @summary should be "Resource variable
>>>> should be in scope throughout try, catch, and finally blocks".
>>>> Accessibility is not relevant to a local variable like c.
>>>>
>>>> - TwrAndAnonymousClass - this is a positive test when an anonymous
>>>> class implements AutoCloseable, but what about a negative test when an
>>>> anonymous class doesn't implement AutoCloseable?
>>>>
>>>> - TwrAndGenerics - should be called TwrAndTypeVariables - plus same
>>>> comment as above (type variables S and T _not_ extending
>>>> AutoCloseable).
>>>>
>>>> - TwrAndLambda - same comment as above (lambda expressions and method
>>>> references _not_ implementing AutoCloseable).
>>>>
>>>> - TwrVarKinds - good test, but if you're doing to test four kinds of
>>>> variables then you may as well test all seven (JLS 4.12.3). In
>>>> particular, array components should be tested. You should test using
>>>> components from an array of AutoCloseables, and components of
>>>> components from an array of an array of AutoCloseables. (The second
>>>> situation in particular will expose any mistreatment of array
>>>> components by javac -- if javac accidentally erases the array-ness of
>>>> a resource variable, then in the first situation it will end up with
>>>> an AutoCloseable and that's ordinary enough that everything might
>>>> still work, but in the second situation it ends up with an array of
>>>> AutoCloseables and that might blow up some logic.)
>>>>
>>>> - WeirdTwr_WithVar - there is nothing weird or strange here. It's just
>>>> one resource variable aliasing another, which was possible already.
>>>> You're right to extend it so that a resource variable declared by
>>>> 'try' aliases a resource variable declared outside 'try' -- also do it
>>>> the other way around. Also, need a test where the resource variable
>>>> declared outside 'try' is null.
>>>>
>>>> - What's truly new when a try (...) header uses a resource variable
>>>> declared outside the 'try'? Answer: no exception can be thrown,
>>>> whereas the declaration of a resource variable by 'try' includes an
>>>> initializer expression that can throw an exception. There should be a
>>>> test to "prove" that try (r1) {...} doesn't throw exceptions from
>>>> resource initialization, and that try (r1; AutoCloseable r2 = ...)
>>>> {...} only throws exceptions due to r2's initialization.
>>>>
>>>> Alex
>>>>
>>>> On 10/14/2015 12:12 AM, Sergei Pikalev wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> This is the code with new Project Coin tests from SQE.
>>>>>
>>>>> A webrev with the tests is here:
>>>>>
>>>>> http://cr.openjdk.java.net/~shurailine/webrev.8080641/
>>>>>
>>>>> Please review.
>>>>>
>>>>> Thanks,
>>>>>      Sergei
>>>>>
>>>
>

From sergei.pikalev at oracle.com  Tue Oct 20 04:52:14 2015
From: sergei.pikalev at oracle.com (Sergei Pikalev)
Date: Tue, 20 Oct 2015 07:52:14 +0300
Subject: RFR JDK-8080641: JEP-JDK-8042880 : Implement new tests on Project
	Coin
In-Reply-To: <5625940A.1060503@oracle.com>
References: <561E0075.7030701@oracle.com>	<562034AF.3070403@oracle.com>	<562506C7.5040208@oracle.com>	<56258353.2050608@oracle.com>	<56258C67.3050700@oracle.com>
	<5625940A.1060503@oracle.com>
Message-ID: <5625C87E.3080702@oracle.com>


Hi Alex and compiler team,

New webrev is here: 
http://cr.openjdk.java.net/~shurailine/8080641/webrev.02/

Illegal expressions moved to TwrForVariable3.
Array components as variables moved to TwrVarKinds.
WeirdTwr_WithVar case moved to TwrForVariable1.

Sergi

On 20.10.2015 04:08, Alex Buckley wrote:
> Thanks for the pointers.
>
> I remember now: array components can't be used as resources because, 
> as variables, they are never final or effectively final. (Only an 
> array variable itself may be final or effectively final, not its 
> components.) That's why the grammar only allows ExpressionName and 
> FieldAccess, not ArrayAccess.
>
> But, since array components are variables, I would have expected them 
> to be tested in TwrVarKinds rather than TwrForVariable2. And, I would 
> have expected the negative tests in TwrForVariable2 for a conditional 
> expression and a null-with-cast to be located in TwrForVariable3 where 
> other (illegal) expressions are tried. Tests should be written in the 
> right place if we want people to read them.
>
> WeirdTwr_WithVar is misnamed and unnecessary. The single t-w-r 
> statement that it contains could live perfectly well in 
> TwrForVariable1, near the nice new cases for assertCloseCount(7) and  
> assertCloseCount(10).
>
> Alex
>
> On 10/19/2015 5:35 PM, Sergei Pikalev wrote:
>>
>> Hi Alex,
>>
>> These test are additional to existing test, and developers 
>> recommended me
>> not to create new files but enrich existing as far as possible.
>>
>> Array components assertions are located at TwrForVariable2.
>>
>> Other discussed issues are in TwrForVariable1. Null cases 'prove' that
>> null does
>> not generate exceptions beyond the t-w-r block. Positive part checks
>> initialized
>> resources.
>>
>> Some of this assertions came from developers' unit test. Some was added
>> by me.
>>
>> Sergi
>>
>> On 20.10.2015 02:57, Alex Buckley wrote:
>>> I don't see any testing of array components as resources, or testing
>>> that a resource declared outside the t-w-r statement can either be
>>> null or is guaranteed to initialize (as discussed in a separate mail).
>>>
>>> Alex
>>>
>>> On 10/19/2015 8:05 AM, Sergei Pikalev wrote:
>>>>
>>>> Hi All,
>>>>
>>>> http://cr.openjdk.java.net/~shurailine/8080641/webrev.01/
>>>>
>>>> There are updated tests with respect to Alex's remarks.
>>>>
>>>> Thanks,
>>>>      Sergi
>>>>
>>>> On 16.10.2015 02:20, Alex Buckley wrote:
>>>>> Hi Sergei,
>>>>>
>>>>> Most of the new regression tests are about conformance to the spec,
>>>>> rather than probing some javac-internal treatment of the t-w-r
>>>>> statement. I hope someone from JCK-Compiler can comment on their
>>>>> suppor for the expanded t-w-r statement.
>>>>>
>>>>> That said, here are some comments on the new tests:
>>>>>
>>>>> - ResourceVariableOutsideTry - @summary should be "Resource variable
>>>>> should be in scope throughout try, catch, and finally blocks".
>>>>> Accessibility is not relevant to a local variable like c.
>>>>>
>>>>> - TwrAndAnonymousClass - this is a positive test when an anonymous
>>>>> class implements AutoCloseable, but what about a negative test 
>>>>> when an
>>>>> anonymous class doesn't implement AutoCloseable?
>>>>>
>>>>> - TwrAndGenerics - should be called TwrAndTypeVariables - plus same
>>>>> comment as above (type variables S and T _not_ extending
>>>>> AutoCloseable).
>>>>>
>>>>> - TwrAndLambda - same comment as above (lambda expressions and method
>>>>> references _not_ implementing AutoCloseable).
>>>>>
>>>>> - TwrVarKinds - good test, but if you're doing to test four kinds of
>>>>> variables then you may as well test all seven (JLS 4.12.3). In
>>>>> particular, array components should be tested. You should test using
>>>>> components from an array of AutoCloseables, and components of
>>>>> components from an array of an array of AutoCloseables. (The second
>>>>> situation in particular will expose any mistreatment of array
>>>>> components by javac -- if javac accidentally erases the array-ness of
>>>>> a resource variable, then in the first situation it will end up with
>>>>> an AutoCloseable and that's ordinary enough that everything might
>>>>> still work, but in the second situation it ends up with an array of
>>>>> AutoCloseables and that might blow up some logic.)
>>>>>
>>>>> - WeirdTwr_WithVar - there is nothing weird or strange here. It's 
>>>>> just
>>>>> one resource variable aliasing another, which was possible already.
>>>>> You're right to extend it so that a resource variable declared by
>>>>> 'try' aliases a resource variable declared outside 'try' -- also 
>>>>> do it
>>>>> the other way around. Also, need a test where the resource variable
>>>>> declared outside 'try' is null.
>>>>>
>>>>> - What's truly new when a try (...) header uses a resource variable
>>>>> declared outside the 'try'? Answer: no exception can be thrown,
>>>>> whereas the declaration of a resource variable by 'try' includes an
>>>>> initializer expression that can throw an exception. There should be a
>>>>> test to "prove" that try (r1) {...} doesn't throw exceptions from
>>>>> resource initialization, and that try (r1; AutoCloseable r2 = ...)
>>>>> {...} only throws exceptions due to r2's initialization.
>>>>>
>>>>> Alex
>>>>>
>>>>> On 10/14/2015 12:12 AM, Sergei Pikalev wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> This is the code with new Project Coin tests from SQE.
>>>>>>
>>>>>> A webrev with the tests is here:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~shurailine/webrev.8080641/
>>>>>>
>>>>>> Please review.
>>>>>>
>>>>>> Thanks,
>>>>>>      Sergei
>>>>>>
>>>>
>>


From alex.buckley at oracle.com  Tue Oct 20 17:08:31 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 20 Oct 2015 10:08:31 -0700
Subject: RFR JDK-8080641: JEP-JDK-8042880 : Implement new tests on Project
	Coin
In-Reply-To: <5625C87E.3080702@oracle.com>
References: <561E0075.7030701@oracle.com>	<562034AF.3070403@oracle.com>	<562506C7.5040208@oracle.com>	<56258353.2050608@oracle.com>	<56258C67.3050700@oracle.com>	<5625940A.1060503@oracle.com>
	<5625C87E.3080702@oracle.com>
Message-ID: <5626750F.2050502@oracle.com>

Good improvements. Many thanks Sergei.

Alex

On 10/19/2015 9:52 PM, Sergei Pikalev wrote:
>
> Hi Alex and compiler team,
>
> New webrev is here:
> http://cr.openjdk.java.net/~shurailine/8080641/webrev.02/
>
> Illegal expressions moved to TwrForVariable3.
> Array components as variables moved to TwrVarKinds.
> WeirdTwr_WithVar case moved to TwrForVariable1.
>
> Sergi
>
> On 20.10.2015 04:08, Alex Buckley wrote:
>> Thanks for the pointers.
>>
>> I remember now: array components can't be used as resources because,
>> as variables, they are never final or effectively final. (Only an
>> array variable itself may be final or effectively final, not its
>> components.) That's why the grammar only allows ExpressionName and
>> FieldAccess, not ArrayAccess.
>>
>> But, since array components are variables, I would have expected them
>> to be tested in TwrVarKinds rather than TwrForVariable2. And, I would
>> have expected the negative tests in TwrForVariable2 for a conditional
>> expression and a null-with-cast to be located in TwrForVariable3 where
>> other (illegal) expressions are tried. Tests should be written in the
>> right place if we want people to read them.
>>
>> WeirdTwr_WithVar is misnamed and unnecessary. The single t-w-r
>> statement that it contains could live perfectly well in
>> TwrForVariable1, near the nice new cases for assertCloseCount(7) and
>> assertCloseCount(10).
>>
>> Alex

From andreas.eriksson at oracle.com  Thu Oct 22 09:41:10 2015
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Thu, 22 Oct 2015 11:41:10 +0200
Subject: RFR: 8134759: jdb: Incorrect stepping inside finally block
In-Reply-To: <56264170.60201@oracle.com>
References: <56264170.60201@oracle.com>
Message-ID: <5628AF36.30100@oracle.com>

Hi,

Please review this change to javac, which fixes line number mappings for 
non-void returns inside a try-finally.
The pending line number was already saved and restored for void returns, 
but not for methods where the return had a value.
This change adds the save and restore of the line number for non-void 
returns as well.

Bug: 8134759 <https://bugs.openjdk.java.net/browse/JDK-8134759>: jdb: 
Incorrect stepping inside finally block
Webrev: http://cr.openjdk.java.net/~aeriksso/8134759/webrev.00/

Regards,
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20151022/25f85d67/attachment.html>

From maurizio.cimadamore at oracle.com  Thu Oct 22 13:34:56 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 22 Oct 2015 14:34:56 +0100
Subject: RFR: 8134759: jdb: Incorrect stepping inside finally block
In-Reply-To: <5628AF36.30100@oracle.com>
References: <56264170.60201@oracle.com> <5628AF36.30100@oracle.com>
Message-ID: <5628E600.9050608@oracle.com>

Looks good - thanks!

Maurizio

On 22/10/15 10:41, Andreas Eriksson wrote:
> Hi,
>
> Please review this change to javac, which fixes line number mappings 
> for non-void returns inside a try-finally.
> The pending line number was already saved and restored for void 
> returns, but not for methods where the return had a value.
> This change adds the save and restore of the line number for non-void 
> returns as well.
>
> Bug: 8134759 <https://bugs.openjdk.java.net/browse/JDK-8134759>: jdb: 
> Incorrect stepping inside finally block
> Webrev: http://cr.openjdk.java.net/~aeriksso/8134759/webrev.00/
>
> Regards,
> Andreas

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

From Victor.Rudometov at oracle.com  Thu Oct 22 13:50:56 2015
From: Victor.Rudometov at oracle.com (Victor Rudometov)
Date: Thu, 22 Oct 2015 16:50:56 +0300
Subject: RFR JDK-8080641: JEP-JDK-8042880 : Implement new tests on Project
	Coin
In-Reply-To: <562034AF.3070403@oracle.com>
References: <561E0075.7030701@oracle.com> <562034AF.3070403@oracle.com>
Message-ID: <5628E9C0.7050009@oracle.com>

On 16-Oct-15 02:20, Alex Buckley wrote:
> Hi Sergei,
>
> Most of the new regression tests are about conformance to the spec, 
> rather than probing some javac-internal treatment of the t-w-r 
> statement. I hope someone from JCK-Compiler can comment on their 
> suppor for the expanded t-w-r statement.

Hi Alex, Sergei,

The JCK test dev for JDK9 t-w-r statement was completed this April with 
665 testcases developed.
I will double check that we've covered cases from Sergei's webrev. F.e. 
I don't recall "array components as variables", we'll have to add such 
tests.

Thanks.
Victor.


>
> That said, here are some comments on the new tests:
>
> - ResourceVariableOutsideTry - @summary should be "Resource variable 
> should be in scope throughout try, catch, and finally blocks". 
> Accessibility is not relevant to a local variable like c.
>
> - TwrAndAnonymousClass - this is a positive test when an anonymous 
> class implements AutoCloseable, but what about a negative test when an 
> anonymous class doesn't implement AutoCloseable?
>
> - TwrAndGenerics - should be called TwrAndTypeVariables - plus same 
> comment as above (type variables S and T _not_ extending AutoCloseable).
>
> - TwrAndLambda - same comment as above (lambda expressions and method 
> references _not_ implementing AutoCloseable).
>
> - TwrVarKinds - good test, but if you're doing to test four kinds of 
> variables then you may as well test all seven (JLS 4.12.3). In 
> particular, array components should be tested. You should test using 
> components from an array of AutoCloseables, and components of 
> components from an array of an array of AutoCloseables. (The second 
> situation in particular will expose any mistreatment of array 
> components by javac -- if javac accidentally erases the array-ness of 
> a resource variable, then in the first situation it will end up with 
> an AutoCloseable and that's ordinary enough that everything might 
> still work, but in the second situation it ends up with an array of 
> AutoCloseables and that might blow up some logic.)
>
> - WeirdTwr_WithVar - there is nothing weird or strange here. It's just 
> one resource variable aliasing another, which was possible already. 
> You're right to extend it so that a resource variable declared by 
> 'try' aliases a resource variable declared outside 'try' -- also do it 
> the other way around. Also, need a test where the resource variable 
> declared outside 'try' is null.
>
> - What's truly new when a try (...) header uses a resource variable 
> declared outside the 'try'? Answer: no exception can be thrown, 
> whereas the declaration of a resource variable by 'try' includes an 
> initializer expression that can throw an exception. There should be a 
> test to "prove" that try (r1) {...} doesn't throw exceptions from 
> resource initialization, and that try (r1; AutoCloseable r2 = ...) 
> {...} only throws exceptions due to r2's initialization.
>
> Alex
>
> On 10/14/2015 12:12 AM, Sergei Pikalev wrote:
>>
>> Hello,
>>
>> This is the code with new Project Coin tests from SQE.
>>
>> A webrev with the tests is here:
>>
>> http://cr.openjdk.java.net/~shurailine/webrev.8080641/
>>
>> Please review.
>>
>> Thanks,
>>      Sergei
>>


From andreas.eriksson at oracle.com  Thu Oct 22 14:48:25 2015
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Thu, 22 Oct 2015 16:48:25 +0200
Subject: RFR: 8134759: jdb: Incorrect stepping inside finally block
In-Reply-To: <5628E600.9050608@oracle.com>
References: <56264170.60201@oracle.com> <5628AF36.30100@oracle.com>
	<5628E600.9050608@oracle.com>
Message-ID: <5628F739.8030405@oracle.com>

Thanks for looking at this.
Andrey Nazarov asked that I change the standalone test to be a part of 
test/tools/javac/classfiles/attributes/LineNumberTable/LineNumberTestBase.java 
instead.
I'll send out a new review once that's done.

- Andreas

On 2015-10-22 15:34, Maurizio Cimadamore wrote:
> Looks good - thanks!
>
> Maurizio
>
> On 22/10/15 10:41, Andreas Eriksson wrote:
>> Hi,
>>
>> Please review this change to javac, which fixes line number mappings 
>> for non-void returns inside a try-finally.
>> The pending line number was already saved and restored for void 
>> returns, but not for methods where the return had a value.
>> This change adds the save and restore of the line number for non-void 
>> returns as well.
>>
>> Bug: 8134759 <https://bugs.openjdk.java.net/browse/JDK-8134759>: jdb: 
>> Incorrect stepping inside finally block
>> Webrev: http://cr.openjdk.java.net/~aeriksso/8134759/webrev.00/
>>
>> Regards,
>> Andreas
>

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

From andreas.eriksson at oracle.com  Fri Oct 23 09:25:06 2015
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Fri, 23 Oct 2015 11:25:06 +0200
Subject: RFR: 8134759: jdb: Incorrect stepping inside finally block
In-Reply-To: <5628F739.8030405@oracle.com>
References: <56264170.60201@oracle.com> <5628AF36.30100@oracle.com>
	<5628E600.9050608@oracle.com> <5628F739.8030405@oracle.com>
Message-ID: <5629FCF2.7030705@oracle.com>

LineNumberTestBase.java couldn't handle this particular test case, so 
I'll go ahead and push change with the original test.

Thanks,
Andreas

On 2015-10-22 16:48, Andreas Eriksson wrote:
> Thanks for looking at this.
> Andrey Nazarov asked that I change the standalone test to be a part of 
> test/tools/javac/classfiles/attributes/LineNumberTable/LineNumberTestBase.java 
> instead.
> I'll send out a new review once that's done.
>
> - Andreas
>
> On 2015-10-22 15:34, Maurizio Cimadamore wrote:
>> Looks good - thanks!
>>
>> Maurizio
>>
>> On 22/10/15 10:41, Andreas Eriksson wrote:
>>> Hi,
>>>
>>> Please review this change to javac, which fixes line number mappings 
>>> for non-void returns inside a try-finally.
>>> The pending line number was already saved and restored for void 
>>> returns, but not for methods where the return had a value.
>>> This change adds the save and restore of the line number for 
>>> non-void returns as well.
>>>
>>> Bug: 8134759 <https://bugs.openjdk.java.net/browse/JDK-8134759>: 
>>> jdb: Incorrect stepping inside finally block
>>> Webrev: http://cr.openjdk.java.net/~aeriksso/8134759/webrev.00/
>>>
>>> Regards,
>>> Andreas
>>
>

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