From vicente.romero at oracle.com  Wed Nov  1 13:57:52 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 1 Nov 2017 09:57:52 -0400
Subject: RFR JDK-8190315: Test
 tools/javac/tree/NoPrivateTypesExported.java failing
In-Reply-To: <59F78D07.8050508@oracle.com>
References: <59F78D07.8050508@oracle.com>
Message-ID: <e0426ef7-4237-bf89-1781-6e9e3477a734@oracle.com>

looks good,

Vicente

On 10/30/2017 04:35 PM, Jan Lahoda wrote:
> Hi,
>
> test/langtools/tools/javac/tree/NoPrivateTypesExported.java is 
> failing. The intent of the test is to verify the API elements don't 
> refer to non-public types. This is similar to Xlint:exports, but 
> older. Seems reasonable to keep the test for now, despite it might be 
> superseded by -Xlint:exports. The issue why the test is failing is 
> that it does not ignore constant annotation values, which the proposed 
> fix is doing:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8190315
> Webrev: http://cr.openjdk.java.net/~jlahoda/8190315/webrev.00/
>
> Thanks,
> ??? Jan


From kumar.x.srinivasan at oracle.com  Thu Nov  2 12:35:01 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 02 Nov 2017 05:35:01 -0700
Subject: RFR: JDK-8189778: Jshell crash on tab for StringBuilder.append(
In-Reply-To: <59F8A8E6.6030609@oracle.com>
References: <59F1AC72.4020202@oracle.com> <59F8A8E6.6030609@oracle.com>
Message-ID: <59FB10F5.4000407@oracle.com>


Hi Jan,

Generally it looks fine to me, a few nits...

JavadocHelper.java

1.

-                        //which will be resolve in visitInheritDoc:
suggest....
+                        //which will be resolved in visitInheritDoc:
   

2. Suggest adding a space after /** or /* makes it a little easier
to read the comments.

3.

- //insertPos (as future missing elements should be inserted behind
+ //insertPos (as future missing elements should be inserted before

4.
-  //if there is a newline immediatelly after this tree, insert after
+   //if there is a newline immediately after this tree, insert after

5. Several private methods have have javadoc comments /**, do you
run javadoc -private on jshell sources ?

You may want to get Jon's review on this, he is much more familiar
with these things, than I.

Thanks
Kumar

> I've updated to patch to have some comments at places that seemed 
> important:
> http://cr.openjdk.java.net/~jlahoda/8189778/webrev.01/
>
> Jan
>
> On 26.10.2017 11:35, Jan Lahoda wrote:
>> Hi,
>>
>> Typing:
>> jshell> StringBuilder sb = new StringBuilder();
>> jshell> sb.append(<tab><tab>
>>
>> Will lead to an exception:
>> jshell> sb.append(Exception in thread "main"
>> java.lang.StringIndexOutOfBoundsException: start -59, end -59, length 
>> 238
>> [snip]
>> jdk.compiler/jdk.internal.shellsupport.doc.JavadocHelper$OnDemandJavadocHelper.getResolvedDocComment(JavadocHelper.java:481) 
>>
>>
>>
>> The reason is that the javadoc for StringBuilder.append(CharSequence,
>> int, int) is:
>>      /**
>>       * @throws     IndexOutOfBoundsException {@inheritDoc}
>>       */
>>
>> The JavadocHelper tries to fill in the missing javadoc entries, but that
>> fails because it tries to insert the preceding entries at an
>> uninitialized place.
>>
>> The proposed patch:
>> -fixes the above
>> -adds a test that runs the JavadocHelper on all
>> methods/fields/constructors of top-level types in all exported packages
>> (this runs for a considerable time, and we may need to disable this test
>> if it proves to be too heavyweight)
>> -adds a few more test cases for problems found by the above test
>> -fixes the javadoc resolution to treat missing javadoc body as
>> {@inheritDoc} (so that the overridden method's javadoc text is used if
>> missing in this method)
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189778
>> Webrev: http://cr.openjdk.java.net/~jlahoda/8189778/webrev.00/
>>
>> Feedback is welcome.
>>
>> Thanks,
>>      Jan


From jan.lahoda at oracle.com  Thu Nov  2 16:21:53 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 2 Nov 2017 17:21:53 +0100
Subject: RFR: JDK-8189778: Jshell crash on tab for StringBuilder.append(
In-Reply-To: <59FB10F5.4000407@oracle.com>
References: <59F1AC72.4020202@oracle.com> <59F8A8E6.6030609@oracle.com>
 <59FB10F5.4000407@oracle.com>
Message-ID: <59FB4621.6010704@oracle.com>

Hi Kumar,

Thanks for the comments.

On 2.11.2017 13:35, Kumar Srinivasan wrote:
>
> Hi Jan,
>
> Generally it looks fine to me, a few nits...
>
> JavadocHelper.java
>
> 1.
>
> -                        //which will be resolve in visitInheritDoc:
> suggest....
> +                        //which will be resolved in visitInheritDoc:
>
> 2. Suggest adding a space after /** or /* makes it a little easier
> to read the comments.
>
> 3.
>
> - //insertPos (as future missing elements should be inserted behind
> + //insertPos (as future missing elements should be inserted before
>
> 4.
> -  //if there is a newline immediatelly after this tree, insert after
> +   //if there is a newline immediately after this tree, insert after

Will do the above.

>
> 5. Several private methods have have javadoc comments /**, do you
> run javadoc -private on jshell sources ?

No, but a lot javac code uses /** comments to comment methods (even if 
they are not a full javadoc comment, like Attr.isType), so I simply kept 
using the same strategy. (IDEs may also be able to show the javadoc 
comments in code completion.)

Thanks,
     Jan

>
> You may want to get Jon's review on this, he is much more familiar
> with these things, than I.
>
> Thanks
> Kumar
>
>> I've updated to patch to have some comments at places that seemed
>> important:
>> http://cr.openjdk.java.net/~jlahoda/8189778/webrev.01/
>>
>> Jan
>>
>> On 26.10.2017 11:35, Jan Lahoda wrote:
>>> Hi,
>>>
>>> Typing:
>>> jshell> StringBuilder sb = new StringBuilder();
>>> jshell> sb.append(<tab><tab>
>>>
>>> Will lead to an exception:
>>> jshell> sb.append(Exception in thread "main"
>>> java.lang.StringIndexOutOfBoundsException: start -59, end -59, length
>>> 238
>>> [snip]
>>> jdk.compiler/jdk.internal.shellsupport.doc.JavadocHelper$OnDemandJavadocHelper.getResolvedDocComment(JavadocHelper.java:481)
>>>
>>>
>>>
>>> The reason is that the javadoc for StringBuilder.append(CharSequence,
>>> int, int) is:
>>>      /**
>>>       * @throws     IndexOutOfBoundsException {@inheritDoc}
>>>       */
>>>
>>> The JavadocHelper tries to fill in the missing javadoc entries, but that
>>> fails because it tries to insert the preceding entries at an
>>> uninitialized place.
>>>
>>> The proposed patch:
>>> -fixes the above
>>> -adds a test that runs the JavadocHelper on all
>>> methods/fields/constructors of top-level types in all exported packages
>>> (this runs for a considerable time, and we may need to disable this test
>>> if it proves to be too heavyweight)
>>> -adds a few more test cases for problems found by the above test
>>> -fixes the javadoc resolution to treat missing javadoc body as
>>> {@inheritDoc} (so that the overridden method's javadoc text is used if
>>> missing in this method)
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189778
>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8189778/webrev.00/
>>>
>>> Feedback is welcome.
>>>
>>> Thanks,
>>>      Jan
>

From bsrbnd at gmail.com  Thu Nov  2 23:26:20 2017
From: bsrbnd at gmail.com (B. Blaser)
Date: Fri, 3 Nov 2017 00:26:20 +0100
Subject: Linear implementation of Tarjan's algorithm
In-Reply-To: <7ba40e17-cb0b-1641-9e49-5391f55bae1c@oracle.com>
References: <CAEgw74DvX6zNhGP1OGVqgSifjmyGRWZQsKFYdUG-bChU2tuekw@mail.gmail.com>
 <451662128.2472977.1508695563065.JavaMail.zimbra@u-pem.fr>
 <8b879ed0-1c88-1e6d-a477-88797190f202@oracle.com>
 <CAEgw74AgkLzB98HCaKU8zW0-RJ-HEsS055GCwwN1O6wEA17r2Q@mail.gmail.com>
 <a16ecbb2-b6fe-704e-4f57-48782c84f311@oracle.com>
 <CAEgw74Cu4CY+JXfHY+6wS7DnhQMDeVYkjGPs=sOuODOMzEoosA@mail.gmail.com>
 <6bb6b44c-c842-7c41-0d4b-3877cf5d0bad@oracle.com>
 <CAEgw74D3aFFVbRkyV6oLrj+t0makU8JKxSmT1e0idgh2tFFXpg@mail.gmail.com>
 <ff0bf044-1f55-4624-ad1a-0e5c88442fcd@oracle.com>
 <CAEgw74ABH0+R6KeNbaPPBaeHC=wD7VUanjXqa-VxOgFLnMPvFA@mail.gmail.com>
 <7ba40e17-cb0b-1641-9e49-5391f55bae1c@oracle.com>
Message-ID: <CAEgw74BHfaeHUu1Usv3z385Gbxju_qpqz-Z69ZHr23VoWqc2JA@mail.gmail.com>

Hi Maurizio,

On 25 October 2017 at 22:16, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> Thanks for testing - I imagined something similar - our target here is what
> is said in the bug report:
>
> "In JDK 7, compilation takes less than a second." (this is with 100 points).
>
> Your tests show that the smaller the inference graph, the smaller the gain
> (you start from 2x, and you end with 5x). But for bigger graphs, these kind
> of improvements are not going to cut it (still 2mins against <1s in JDK 7).
>
> And, if you fix this at a deeper level, so that the incorporation has to do
> less work, then you go back to subsecond compilation, in which case the
> contribution of your optimization is likely to be negligible.
>
> So, I don't want to sound overly critical (I realize I can sound that way
> sometimes) - you did a great experiment, and it's showing some good numbers
> - but the real problem here is that in JDK 7, _no matter how many nodes you
> had_ compilation always stayed subsecond. So, when I see a compilation time
> that increase depending on how many nested call you add, I worry - because,
> no matter how you optimize, you can always add few extra nodes and go back
> being as slow as you were (or more!) before the optimization.
>
> During JDK 9 we did a great job at optimizing this pattern:
>
> m1(m2(m3 .... mN() ) ) ) )
>
> I think it's time we do something similar for
>
> m(g1(), g2(), ... gN())
>
> Note that when we made incorporation smart enough to detect the first case,
> all other performance related concerns became negligible - I'm hoping we can
> pull a similar trick here (and we have few ideas on how to do that).

I perhaps found why a large number of same upper bounds are checked
multiple times, which seems to be one of the bottlenecks in
JDK-8152289. This is probably because 'Types.isSameType()' doesn't
work properly with recursive types.

Consider two clones of the same type variable 'P extends
Comparable<P>'. 'LooseSameTypeVisitor.checkSameBounds()' will
currently return 'false' when the upper bound of 'P' is recursively
checked (see [1]) which will then make
'LooseSameTypeVisitor.sameTypeVars()' return 'false' (see [2]).

I think 'LooseSameTypeVisitor.checkSameBounds()' should return 'true'
within recursive calls because only the root of recursion is able to
effectively check the bounds.

Fixing this little bug, as below, gives roughly the same results as
previously when using a cache (from 2x to 5x faster than initially).

Of course, it will still require some optimization to be sub-second
(as you said), but this simple correction could do half of the job.

What do you think?

Thanks,
Bernard


[1] http://hg.openjdk.java.net/jdk10/master/file/6d0e943bcd24/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#l1452

[2] http://hg.openjdk.java.net/jdk10/master/file/6d0e943bcd24/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#l1432

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
@@ -1449,7 +1449,7 @@
                         cache.remove(p);
                     }
                 } else {
-                    return false;
+                    return true;
                 }
             }
         };

> Cheers
> Maurizio

From maurizio.cimadamore at oracle.com  Fri Nov  3 01:58:37 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 3 Nov 2017 01:58:37 +0000
Subject: Linear implementation of Tarjan's algorithm
In-Reply-To: <CAEgw74BHfaeHUu1Usv3z385Gbxju_qpqz-Z69ZHr23VoWqc2JA@mail.gmail.com>
References: <CAEgw74DvX6zNhGP1OGVqgSifjmyGRWZQsKFYdUG-bChU2tuekw@mail.gmail.com>
 <451662128.2472977.1508695563065.JavaMail.zimbra@u-pem.fr>
 <8b879ed0-1c88-1e6d-a477-88797190f202@oracle.com>
 <CAEgw74AgkLzB98HCaKU8zW0-RJ-HEsS055GCwwN1O6wEA17r2Q@mail.gmail.com>
 <a16ecbb2-b6fe-704e-4f57-48782c84f311@oracle.com>
 <CAEgw74Cu4CY+JXfHY+6wS7DnhQMDeVYkjGPs=sOuODOMzEoosA@mail.gmail.com>
 <6bb6b44c-c842-7c41-0d4b-3877cf5d0bad@oracle.com>
 <CAEgw74D3aFFVbRkyV6oLrj+t0makU8JKxSmT1e0idgh2tFFXpg@mail.gmail.com>
 <ff0bf044-1f55-4624-ad1a-0e5c88442fcd@oracle.com>
 <CAEgw74ABH0+R6KeNbaPPBaeHC=wD7VUanjXqa-VxOgFLnMPvFA@mail.gmail.com>
 <7ba40e17-cb0b-1641-9e49-5391f55bae1c@oracle.com>
 <CAEgw74BHfaeHUu1Usv3z385Gbxju_qpqz-Z69ZHr23VoWqc2JA@mail.gmail.com>
Message-ID: <da76d50b-6304-7544-e810-98f60050012f@oracle.com>



On 02/11/17 23:26, B. Blaser wrote:
> Of course, it will still require some optimization to be sub-second
> (as you said), but this simple correction could do half of the job.
Hi Bernard,
unfortunately this optimization is unsound - there's no way to prove 
that P <: Comparable<P> is the same as P' <: Comparable<P'>, because of 
the f-bound. That's why the cache is there - it's not an optimization, 
is something that prevents javac from doing the same check over and over 
again.

When such a loop occurs, the right thing to do is to say 'false', as it 
is not possible to prove that the bounds are indeed the same. Note that 
the fact that the two variables are clones is largely irrelevant here - 
we clone new tvars every time we check a new instance of the same 
generic method call/diamond constructor - so in a way these are all 
different variables which just happen to have the same name/same set of 
initial (declared) bounds.

Moreover, the 'loose' type equality test is an artifact of the past - it 
was introduced because the strict behavior (which was the default in 6) 
was, well, sometimes too strict - essentially, if bounds of a type 
variable are replaced for other type variables (e.g. replace U in the 
bound of 'Z extends List<U>'), javac creates a different type-variable 
with the replaced bound. If you performed the same replacement twice on 
the original variable, the resulting replaced vars would not be deemed 
'equals' by javac, which is why this looser behavior was added. Some 
more comments are added here:

http://hg.openjdk.java.net/jdk7/jdk7/langtools/file/tip/src/share/classes/com/sun/tools/javac/code/Types.java#l632

These changes have been added as a consequence of the fixes for:

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

Now, all this is relatively ancient history, which predates the Java 8 
changes - in fact, this 'legacy' loose behavior, is very problematic - 
it's completely outside the spec, and, in the general case with fbounds, 
it cannot even be proven to always complete (which is why the cache is 
there). During 8, I sidestepped this issue by adding the 'strict' type 
equality check, which should become the 'standard' - but, as I there was 
only so much code I could rewrite in one shot (:-)), I added the new 
routine beside the old one, instead of having the new routine completely 
replacing the old one (and deal with the compatibility fallout).

I think the time is come that we do a bit of spring cleaning in the 
area, and get rid of the legacy (and unsound) loose check, and see where 
we're at.

That said, speaking of inference performances, if we ever move the 
entire code base to use the strict equality check, your proposed 
optimization would not even apply - in a way your optimization is 
exploiting the fact that that particular check is using the loose check 
instead of the strict one - with the strict one, two different type var 
instances (no matter if they are clones, and even have same bounds) will 
still be deemed different.

I still stand by my earlier analysis that the particular issue 
highlighted in 8152289 is not something that needs to be addressed by 
looking at the profiler. While you can make the bottleneck smaller and 
smaller, you still have an underlying behavior that doesn't scale with 
the number of nested calls - with increasing values of N, you do 10, 
100, 1000, 10000, 1000 ....00000 checks - so no matter how fast the 
rewritten logic is, you can always add a bunch new nested call to bring 
the compilation time more or less in time to what it was before the fix.

The real fix is to find a way so that the incorporation machinery 
doesn't have to actually perform a number of steps that is exponential 
in the number of the type variables involved, and to detect patterns 
that can be exploited in order to reduce the complexity of the 
incorporation step.

Thanks
Maurizio





From bsrbnd at gmail.com  Fri Nov  3 13:17:37 2017
From: bsrbnd at gmail.com (B. Blaser)
Date: Fri, 3 Nov 2017 14:17:37 +0100
Subject: Linear implementation of Tarjan's algorithm
In-Reply-To: <da76d50b-6304-7544-e810-98f60050012f@oracle.com>
References: <CAEgw74DvX6zNhGP1OGVqgSifjmyGRWZQsKFYdUG-bChU2tuekw@mail.gmail.com>
 <451662128.2472977.1508695563065.JavaMail.zimbra@u-pem.fr>
 <8b879ed0-1c88-1e6d-a477-88797190f202@oracle.com>
 <CAEgw74AgkLzB98HCaKU8zW0-RJ-HEsS055GCwwN1O6wEA17r2Q@mail.gmail.com>
 <a16ecbb2-b6fe-704e-4f57-48782c84f311@oracle.com>
 <CAEgw74Cu4CY+JXfHY+6wS7DnhQMDeVYkjGPs=sOuODOMzEoosA@mail.gmail.com>
 <6bb6b44c-c842-7c41-0d4b-3877cf5d0bad@oracle.com>
 <CAEgw74D3aFFVbRkyV6oLrj+t0makU8JKxSmT1e0idgh2tFFXpg@mail.gmail.com>
 <ff0bf044-1f55-4624-ad1a-0e5c88442fcd@oracle.com>
 <CAEgw74ABH0+R6KeNbaPPBaeHC=wD7VUanjXqa-VxOgFLnMPvFA@mail.gmail.com>
 <7ba40e17-cb0b-1641-9e49-5391f55bae1c@oracle.com>
 <CAEgw74BHfaeHUu1Usv3z385Gbxju_qpqz-Z69ZHr23VoWqc2JA@mail.gmail.com>
 <da76d50b-6304-7544-e810-98f60050012f@oracle.com>
Message-ID: <CAEgw74DObnCge4-w0y3Psk_bMNS8=81JOToGR-Lmj7OkJFYXVg@mail.gmail.com>

On 3 November 2017 at 02:58, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
>
> On 02/11/17 23:26, B. Blaser wrote:
>>
>> Of course, it will still require some optimization to be sub-second
>> (as you said), but this simple correction could do half of the job.
>
> Hi Bernard,
> unfortunately this optimization is unsound - there's no way to prove that P
> <: Comparable<P> is the same as P' <: Comparable<P'>, because of the
> f-bound. That's why the cache is there - it's not an optimization, is
> something that prevents javac from doing the same check over and over again.
>
> When such a loop occurs, the right thing to do is to say 'false', as it is
> not possible to prove that the bounds are indeed the same.

If we want to prove that "P <: Comparable<P>" is the same type as "P'
<: Comparable<P'>", we have to do something like the following lines
of Prolog:

% same(P1, P2) :- samesym(P1, P2), samebounds(comparable(P1), comparable(P2)).
% samebounds(comparable(P1), comparable(P2)) :- samesym(P1, P2),
cache(comparable(P1), comparable(P2)).

To prove 'same(P1, P2)', we have to know about 'samesym(P1, P2)' and
'cache(comparable(P1), comparable(P2))'.
Looking at the implementation, we find that 'samesym(P1, P2)' is given
by 'P1.tsym == P2.tsym' and 'cache(comparable(P1), comparable(P2))'
currently returns 'false'.

Now, we can look at the truth table for 'samesym()' and 'cache()':

% samesym(P1, P2) :- true.
% cache(comparable(P1), comparable(P2)) :- true.
%
% ?- same(P1, P2).
% true.

% samesym(P1, P2) :- true.
% cache(comparable(P1), comparable(P2)) :- false.
%
% ?- same(P1, P2).
% false.

% samesym(P1, P2) :- false.
% cache(comparable(P1), comparable(P2)) :- true.
%
% ?- same(P1, P2).
% false.

% samesym(P1, P2) :- false.
% cache(comparable(P1), comparable(P2)) :- false.
%
% ?- same(P1, P2).
% false.

We see that the only way to prove that 'same(P1, P2) = true' is to
postulate that 'cache(...) = true' which is what I suggested.

If we make the opposite hypothesis that 'cache(...) = false', which is
currently done, we will never be able to prove that 'same(P, P) =
true'... but the strict comparison would do that successfully!

What do you think (for the rest, I agree with you)?

Bernard


> Note that the
> fact that the two variables are clones is largely irrelevant here - we clone
> new tvars every time we check a new instance of the same generic method
> call/diamond constructor - so in a way these are all different variables
> which just happen to have the same name/same set of initial (declared)
> bounds.
>
> Moreover, the 'loose' type equality test is an artifact of the past - it was
> introduced because the strict behavior (which was the default in 6) was,
> well, sometimes too strict - essentially, if bounds of a type variable are
> replaced for other type variables (e.g. replace U in the bound of 'Z extends
> List<U>'), javac creates a different type-variable with the replaced bound.
> If you performed the same replacement twice on the original variable, the
> resulting replaced vars would not be deemed 'equals' by javac, which is why
> this looser behavior was added. Some more comments are added here:
>
> http://hg.openjdk.java.net/jdk7/jdk7/langtools/file/tip/src/share/classes/com/sun/tools/javac/code/Types.java#l632
>
> These changes have been added as a consequence of the fixes for:
>
> https://bugs.openjdk.java.net/browse/JDK-6729401
>
> Now, all this is relatively ancient history, which predates the Java 8
> changes - in fact, this 'legacy' loose behavior, is very problematic - it's
> completely outside the spec, and, in the general case with fbounds, it
> cannot even be proven to always complete (which is why the cache is there).
> During 8, I sidestepped this issue by adding the 'strict' type equality
> check, which should become the 'standard' - but, as I there was only so much
> code I could rewrite in one shot (:-)), I added the new routine beside the
> old one, instead of having the new routine completely replacing the old one
> (and deal with the compatibility fallout).
>
> I think the time is come that we do a bit of spring cleaning in the area,
> and get rid of the legacy (and unsound) loose check, and see where we're at.
>
> That said, speaking of inference performances, if we ever move the entire
> code base to use the strict equality check, your proposed optimization would
> not even apply - in a way your optimization is exploiting the fact that that
> particular check is using the loose check instead of the strict one - with
> the strict one, two different type var instances (no matter if they are
> clones, and even have same bounds) will still be deemed different.
>
> I still stand by my earlier analysis that the particular issue highlighted
> in 8152289 is not something that needs to be addressed by looking at the
> profiler. While you can make the bottleneck smaller and smaller, you still
> have an underlying behavior that doesn't scale with the number of nested
> calls - with increasing values of N, you do 10, 100, 1000, 10000, 1000
> ....00000 checks - so no matter how fast the rewritten logic is, you can
> always add a bunch new nested call to bring the compilation time more or
> less in time to what it was before the fix.
>
> The real fix is to find a way so that the incorporation machinery doesn't
> have to actually perform a number of steps that is exponential in the number
> of the type variables involved, and to detect patterns that can be exploited
> in order to reduce the complexity of the incorporation step.
>
> Thanks
> Maurizio

From maurizio.cimadamore at oracle.com  Fri Nov  3 13:57:40 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 3 Nov 2017 13:57:40 +0000
Subject: Linear implementation of Tarjan's algorithm
In-Reply-To: <CAEgw74DObnCge4-w0y3Psk_bMNS8=81JOToGR-Lmj7OkJFYXVg@mail.gmail.com>
References: <CAEgw74DvX6zNhGP1OGVqgSifjmyGRWZQsKFYdUG-bChU2tuekw@mail.gmail.com>
 <451662128.2472977.1508695563065.JavaMail.zimbra@u-pem.fr>
 <8b879ed0-1c88-1e6d-a477-88797190f202@oracle.com>
 <CAEgw74AgkLzB98HCaKU8zW0-RJ-HEsS055GCwwN1O6wEA17r2Q@mail.gmail.com>
 <a16ecbb2-b6fe-704e-4f57-48782c84f311@oracle.com>
 <CAEgw74Cu4CY+JXfHY+6wS7DnhQMDeVYkjGPs=sOuODOMzEoosA@mail.gmail.com>
 <6bb6b44c-c842-7c41-0d4b-3877cf5d0bad@oracle.com>
 <CAEgw74D3aFFVbRkyV6oLrj+t0makU8JKxSmT1e0idgh2tFFXpg@mail.gmail.com>
 <ff0bf044-1f55-4624-ad1a-0e5c88442fcd@oracle.com>
 <CAEgw74ABH0+R6KeNbaPPBaeHC=wD7VUanjXqa-VxOgFLnMPvFA@mail.gmail.com>
 <7ba40e17-cb0b-1641-9e49-5391f55bae1c@oracle.com>
 <CAEgw74BHfaeHUu1Usv3z385Gbxju_qpqz-Z69ZHr23VoWqc2JA@mail.gmail.com>
 <da76d50b-6304-7544-e810-98f60050012f@oracle.com>
 <CAEgw74DObnCge4-w0y3Psk_bMNS8=81JOToGR-Lmj7OkJFYXVg@mail.gmail.com>
Message-ID: <878a12b6-2f93-f10c-2fba-f7894aee9e14@oracle.com>

I agree that it's a bug in the loose check not to consider if tv1 == 
tv2. But that should be added to the sameTypeVars() predicate, not done 
by tweaking the behavior in the cache. In other words:

class LooseSameTypeVisitor extends SameTypeVisitor {

 ??????????? @Override
 ??????????? boolean sameTypeVars(TypeVar tv1, TypeVar tv2) {
 ??????????????? return tv1 == tv2 ||
 ??? ??? ??? ??? ??? (tv1.tsym == tv2.tsym && checkSameBounds(tv1, tv2));
 ??????????? }

}


This should make the loose check a proper superset of the strict check.

But I bet that this doesn't help the performance problem, which is 
probably triggered by clones of the same var, not just by == instances. 
Am I right?

Maurizio


On 03/11/17 13:17, B. Blaser wrote:
> On 3 November 2017 at 02:58, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>>
>> On 02/11/17 23:26, B. Blaser wrote:
>>> Of course, it will still require some optimization to be sub-second
>>> (as you said), but this simple correction could do half of the job.
>> Hi Bernard,
>> unfortunately this optimization is unsound - there's no way to prove that P
>> <: Comparable<P> is the same as P' <: Comparable<P'>, because of the
>> f-bound. That's why the cache is there - it's not an optimization, is
>> something that prevents javac from doing the same check over and over again.
>>
>> When such a loop occurs, the right thing to do is to say 'false', as it is
>> not possible to prove that the bounds are indeed the same.
> If we want to prove that "P <: Comparable<P>" is the same type as "P'
> <: Comparable<P'>", we have to do something like the following lines
> of Prolog:
>
> % same(P1, P2) :- samesym(P1, P2), samebounds(comparable(P1), comparable(P2)).
> % samebounds(comparable(P1), comparable(P2)) :- samesym(P1, P2),
> cache(comparable(P1), comparable(P2)).
>
> To prove 'same(P1, P2)', we have to know about 'samesym(P1, P2)' and
> 'cache(comparable(P1), comparable(P2))'.
> Looking at the implementation, we find that 'samesym(P1, P2)' is given
> by 'P1.tsym == P2.tsym' and 'cache(comparable(P1), comparable(P2))'
> currently returns 'false'.
>
> Now, we can look at the truth table for 'samesym()' and 'cache()':
>
> % samesym(P1, P2) :- true.
> % cache(comparable(P1), comparable(P2)) :- true.
> %
> % ?- same(P1, P2).
> % true.
>
> % samesym(P1, P2) :- true.
> % cache(comparable(P1), comparable(P2)) :- false.
> %
> % ?- same(P1, P2).
> % false.
>
> % samesym(P1, P2) :- false.
> % cache(comparable(P1), comparable(P2)) :- true.
> %
> % ?- same(P1, P2).
> % false.
>
> % samesym(P1, P2) :- false.
> % cache(comparable(P1), comparable(P2)) :- false.
> %
> % ?- same(P1, P2).
> % false.
>
> We see that the only way to prove that 'same(P1, P2) = true' is to
> postulate that 'cache(...) = true' which is what I suggested.
>
> If we make the opposite hypothesis that 'cache(...) = false', which is
> currently done, we will never be able to prove that 'same(P, P) =
> true'... but the strict comparison would do that successfully!
>
> What do you think (for the rest, I agree with you)?
>
> Bernard
>
>
>> Note that the
>> fact that the two variables are clones is largely irrelevant here - we clone
>> new tvars every time we check a new instance of the same generic method
>> call/diamond constructor - so in a way these are all different variables
>> which just happen to have the same name/same set of initial (declared)
>> bounds.
>>
>> Moreover, the 'loose' type equality test is an artifact of the past - it was
>> introduced because the strict behavior (which was the default in 6) was,
>> well, sometimes too strict - essentially, if bounds of a type variable are
>> replaced for other type variables (e.g. replace U in the bound of 'Z extends
>> List<U>'), javac creates a different type-variable with the replaced bound.
>> If you performed the same replacement twice on the original variable, the
>> resulting replaced vars would not be deemed 'equals' by javac, which is why
>> this looser behavior was added. Some more comments are added here:
>>
>> http://hg.openjdk.java.net/jdk7/jdk7/langtools/file/tip/src/share/classes/com/sun/tools/javac/code/Types.java#l632
>>
>> These changes have been added as a consequence of the fixes for:
>>
>> https://bugs.openjdk.java.net/browse/JDK-6729401
>>
>> Now, all this is relatively ancient history, which predates the Java 8
>> changes - in fact, this 'legacy' loose behavior, is very problematic - it's
>> completely outside the spec, and, in the general case with fbounds, it
>> cannot even be proven to always complete (which is why the cache is there).
>> During 8, I sidestepped this issue by adding the 'strict' type equality
>> check, which should become the 'standard' - but, as I there was only so much
>> code I could rewrite in one shot (:-)), I added the new routine beside the
>> old one, instead of having the new routine completely replacing the old one
>> (and deal with the compatibility fallout).
>>
>> I think the time is come that we do a bit of spring cleaning in the area,
>> and get rid of the legacy (and unsound) loose check, and see where we're at.
>>
>> That said, speaking of inference performances, if we ever move the entire
>> code base to use the strict equality check, your proposed optimization would
>> not even apply - in a way your optimization is exploiting the fact that that
>> particular check is using the loose check instead of the strict one - with
>> the strict one, two different type var instances (no matter if they are
>> clones, and even have same bounds) will still be deemed different.
>>
>> I still stand by my earlier analysis that the particular issue highlighted
>> in 8152289 is not something that needs to be addressed by looking at the
>> profiler. While you can make the bottleneck smaller and smaller, you still
>> have an underlying behavior that doesn't scale with the number of nested
>> calls - with increasing values of N, you do 10, 100, 1000, 10000, 1000
>> ....00000 checks - so no matter how fast the rewritten logic is, you can
>> always add a bunch new nested call to bring the compilation time more or
>> less in time to what it was before the fix.
>>
>> The real fix is to find a way so that the incorporation machinery doesn't
>> have to actually perform a number of steps that is exponential in the number
>> of the type variables involved, and to detect patterns that can be exploited
>> in order to reduce the complexity of the incorporation step.
>>
>> Thanks
>> Maurizio


From maurizio.cimadamore at oracle.com  Fri Nov  3 14:00:35 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 3 Nov 2017 14:00:35 +0000
Subject: Linear implementation of Tarjan's algorithm
In-Reply-To: <878a12b6-2f93-f10c-2fba-f7894aee9e14@oracle.com>
References: <CAEgw74DvX6zNhGP1OGVqgSifjmyGRWZQsKFYdUG-bChU2tuekw@mail.gmail.com>
 <451662128.2472977.1508695563065.JavaMail.zimbra@u-pem.fr>
 <8b879ed0-1c88-1e6d-a477-88797190f202@oracle.com>
 <CAEgw74AgkLzB98HCaKU8zW0-RJ-HEsS055GCwwN1O6wEA17r2Q@mail.gmail.com>
 <a16ecbb2-b6fe-704e-4f57-48782c84f311@oracle.com>
 <CAEgw74Cu4CY+JXfHY+6wS7DnhQMDeVYkjGPs=sOuODOMzEoosA@mail.gmail.com>
 <6bb6b44c-c842-7c41-0d4b-3877cf5d0bad@oracle.com>
 <CAEgw74D3aFFVbRkyV6oLrj+t0makU8JKxSmT1e0idgh2tFFXpg@mail.gmail.com>
 <ff0bf044-1f55-4624-ad1a-0e5c88442fcd@oracle.com>
 <CAEgw74ABH0+R6KeNbaPPBaeHC=wD7VUanjXqa-VxOgFLnMPvFA@mail.gmail.com>
 <7ba40e17-cb0b-1641-9e49-5391f55bae1c@oracle.com>
 <CAEgw74BHfaeHUu1Usv3z385Gbxju_qpqz-Z69ZHr23VoWqc2JA@mail.gmail.com>
 <da76d50b-6304-7544-e810-98f60050012f@oracle.com>
 <CAEgw74DObnCge4-w0y3Psk_bMNS8=81JOToGR-Lmj7OkJFYXVg@mail.gmail.com>
 <878a12b6-2f93-f10c-2fba-f7894aee9e14@oracle.com>
Message-ID: <6ce30be1-ca4d-ad6d-4218-198e68e5112d@oracle.com>

Or, in terms of Prolog, add a clause to your definitions (and probably 
some 'cuts' ;-)):

same(P, P).


Maurizio

On 03/11/17 13:57, Maurizio Cimadamore wrote:
> I agree that it's a bug in the loose check not to consider if tv1 == 
> tv2. But that should be added to the sameTypeVars() predicate, not 
> done by tweaking the behavior in the cache. In other words:
>
> class LooseSameTypeVisitor extends SameTypeVisitor {
>
> ??????????? @Override
> ??????????? boolean sameTypeVars(TypeVar tv1, TypeVar tv2) {
> ??????????????? return tv1 == tv2 ||
> ??? ??? ??? ??? ??? (tv1.tsym == tv2.tsym && checkSameBounds(tv1, tv2));
> ??????????? }
>
> }
>
>
> This should make the loose check a proper superset of the strict check.
>
> But I bet that this doesn't help the performance problem, which is 
> probably triggered by clones of the same var, not just by == 
> instances. Am I right?
>
> Maurizio
>
>
> On 03/11/17 13:17, B. Blaser wrote:
>> On 3 November 2017 at 02:58, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>>>
>>> On 02/11/17 23:26, B. Blaser wrote:
>>>> Of course, it will still require some optimization to be sub-second
>>>> (as you said), but this simple correction could do half of the job.
>>> Hi Bernard,
>>> unfortunately this optimization is unsound - there's no way to prove 
>>> that P
>>> <: Comparable<P> is the same as P' <: Comparable<P'>, because of the
>>> f-bound. That's why the cache is there - it's not an optimization, is
>>> something that prevents javac from doing the same check over and 
>>> over again.
>>>
>>> When such a loop occurs, the right thing to do is to say 'false', as 
>>> it is
>>> not possible to prove that the bounds are indeed the same.
>> If we want to prove that "P <: Comparable<P>" is the same type as "P'
>> <: Comparable<P'>", we have to do something like the following lines
>> of Prolog:
>>
>> % same(P1, P2) :- samesym(P1, P2), samebounds(comparable(P1), 
>> comparable(P2)).
>> % samebounds(comparable(P1), comparable(P2)) :- samesym(P1, P2),
>> cache(comparable(P1), comparable(P2)).
>>
>> To prove 'same(P1, P2)', we have to know about 'samesym(P1, P2)' and
>> 'cache(comparable(P1), comparable(P2))'.
>> Looking at the implementation, we find that 'samesym(P1, P2)' is given
>> by 'P1.tsym == P2.tsym' and 'cache(comparable(P1), comparable(P2))'
>> currently returns 'false'.
>>
>> Now, we can look at the truth table for 'samesym()' and 'cache()':
>>
>> % samesym(P1, P2) :- true.
>> % cache(comparable(P1), comparable(P2)) :- true.
>> %
>> % ?- same(P1, P2).
>> % true.
>>
>> % samesym(P1, P2) :- true.
>> % cache(comparable(P1), comparable(P2)) :- false.
>> %
>> % ?- same(P1, P2).
>> % false.
>>
>> % samesym(P1, P2) :- false.
>> % cache(comparable(P1), comparable(P2)) :- true.
>> %
>> % ?- same(P1, P2).
>> % false.
>>
>> % samesym(P1, P2) :- false.
>> % cache(comparable(P1), comparable(P2)) :- false.
>> %
>> % ?- same(P1, P2).
>> % false.
>>
>> We see that the only way to prove that 'same(P1, P2) = true' is to
>> postulate that 'cache(...) = true' which is what I suggested.
>>
>> If we make the opposite hypothesis that 'cache(...) = false', which is
>> currently done, we will never be able to prove that 'same(P, P) =
>> true'... but the strict comparison would do that successfully!
>>
>> What do you think (for the rest, I agree with you)?
>>
>> Bernard
>>
>>
>>> Note that the
>>> fact that the two variables are clones is largely irrelevant here - 
>>> we clone
>>> new tvars every time we check a new instance of the same generic method
>>> call/diamond constructor - so in a way these are all different 
>>> variables
>>> which just happen to have the same name/same set of initial (declared)
>>> bounds.
>>>
>>> Moreover, the 'loose' type equality test is an artifact of the past 
>>> - it was
>>> introduced because the strict behavior (which was the default in 6) 
>>> was,
>>> well, sometimes too strict - essentially, if bounds of a type 
>>> variable are
>>> replaced for other type variables (e.g. replace U in the bound of 'Z 
>>> extends
>>> List<U>'), javac creates a different type-variable with the replaced 
>>> bound.
>>> If you performed the same replacement twice on the original 
>>> variable, the
>>> resulting replaced vars would not be deemed 'equals' by javac, which 
>>> is why
>>> this looser behavior was added. Some more comments are added here:
>>>
>>> http://hg.openjdk.java.net/jdk7/jdk7/langtools/file/tip/src/share/classes/com/sun/tools/javac/code/Types.java#l632 
>>>
>>>
>>> These changes have been added as a consequence of the fixes for:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-6729401
>>>
>>> Now, all this is relatively ancient history, which predates the Java 8
>>> changes - in fact, this 'legacy' loose behavior, is very problematic 
>>> - it's
>>> completely outside the spec, and, in the general case with fbounds, it
>>> cannot even be proven to always complete (which is why the cache is 
>>> there).
>>> During 8, I sidestepped this issue by adding the 'strict' type equality
>>> check, which should become the 'standard' - but, as I there was only 
>>> so much
>>> code I could rewrite in one shot (:-)), I added the new routine 
>>> beside the
>>> old one, instead of having the new routine completely replacing the 
>>> old one
>>> (and deal with the compatibility fallout).
>>>
>>> I think the time is come that we do a bit of spring cleaning in the 
>>> area,
>>> and get rid of the legacy (and unsound) loose check, and see where 
>>> we're at.
>>>
>>> That said, speaking of inference performances, if we ever move the 
>>> entire
>>> code base to use the strict equality check, your proposed 
>>> optimization would
>>> not even apply - in a way your optimization is exploiting the fact 
>>> that that
>>> particular check is using the loose check instead of the strict one 
>>> - with
>>> the strict one, two different type var instances (no matter if they are
>>> clones, and even have same bounds) will still be deemed different.
>>>
>>> I still stand by my earlier analysis that the particular issue 
>>> highlighted
>>> in 8152289 is not something that needs to be addressed by looking at 
>>> the
>>> profiler. While you can make the bottleneck smaller and smaller, you 
>>> still
>>> have an underlying behavior that doesn't scale with the number of 
>>> nested
>>> calls - with increasing values of N, you do 10, 100, 1000, 10000, 1000
>>> ....00000 checks - so no matter how fast the rewritten logic is, you 
>>> can
>>> always add a bunch new nested call to bring the compilation time 
>>> more or
>>> less in time to what it was before the fix.
>>>
>>> The real fix is to find a way so that the incorporation machinery 
>>> doesn't
>>> have to actually perform a number of steps that is exponential in 
>>> the number
>>> of the type variables involved, and to detect patterns that can be 
>>> exploited
>>> in order to reduce the complexity of the incorporation step.
>>>
>>> Thanks
>>> Maurizio
>


From karen.kinnear at oracle.com  Fri Nov  3 18:14:53 2017
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Fri, 3 Nov 2017 14:14:53 -0400
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
Message-ID: <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com>

Thank you so much for doing this jointly.

Couple of questions/comments:
1. thank you for making UseBootstrapCallInfo diagnostic

2. org/objectweb/asmClassReader.java
why hardcoded 17 instead of ClassWriter.CONDY?

3. java/lang/invoke/package-info.java 128-134
Error handling could be clearer.
My understanding is that if a LinkageError or subclass is thrown, this will be rethrown
for all subsequent attempts. Other errors, e.g. VMError may retry resolution

Also: after line 165: rules do not enable the JVM to share call sites.
Is it worth noting anywhere that the Constant_Dynamic resolution is shared?

4. SD::find_java_mirror_for_type
lines 2679+
  ConDy should not be supporting CONSTANT_Class(?;? + FD)
  IIRC that is temporary for MVT but not part of ConDy?s spec, nor part of what
  should be checked in for 18.3
also line 2731 - remove comment about ?Foo;?

5. constantTag.hpp
ofBasicType: case T_OBJECT return constantTag(JVM_CONSTANT_String) ?
why not JVM_CONSTANT_CLASS?

6. SD::find_java_mirror_for_type
You have resolve_or_null/fail doing CHECK_(empty) which should
check for a NULL constant_type_klass. This is followed by an explicit if
(constant_type_klass == NULL) ? is that needed?

7. reflection.cpp
get_mirror_from_signature
Looks like potential for side effects. Odd to set mirror_oop inside if (log_is_enabled)
Is the intent to assert that k->java_mirror() == mirror_oop?
Or is the issue that we have a make drop here and the potential for a safe point?
If so, make a handle and extract it on return?

? Or better yet - don?t make any changes to reflection.cpp - not necessary

8. BootstrapMethodInvoker
Could you possibly add a comment that the default today is vmIsPushing and IsPullModeBSM is false?
Or find a slightly different naming to make that clearer?

9. test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java
How would I write an ldc CONSTANT_Dynamic which referred to a bootstrap method that
was not ACC_STATIC?
Or was not ACC_PUBLIC?
Or was 
Or did I read the invoke dynamic method incorrectly?

thanks,
Karen

> On Oct 26, 2017, at 1:03 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi,
> 
> Please review the following patch for minimal dynamic constant support:
> 
>  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/>
> 
>  https://bugs.openjdk.java.net/browse/JDK-8186046 <https://bugs.openjdk.java.net/browse/JDK-8186046>
>  https://bugs.openjdk.java.net/browse/JDK-8186209 <https://bugs.openjdk.java.net/browse/JDK-8186209>
> 
> This patch is based on the JDK 10 unified HotSpot repository. Testing so far looks good.
> 
> By minimal i mean just the support in the runtime for a dynamic constant pool entry to be referenced by a LDC instruction or a bootstrap method argument. Much of the work leverages the foundations built by invoke dynamic but is arguably simpler since resolution is less complex.
> 
> A small set of bootstrap methods will be proposed as a follow on issue for 10 (these are currently being refined in the amber repository).
> 
> Bootstrap method invocation has not changed (and the rules are the same for dynamic constants and indy). It is planned to enhance this in a further major release to support lazy resolution of bootstrap method arguments.
> 
> The CSR for the VM specification is here:
> 
>  https://bugs.openjdk.java.net/browse/JDK-8189199 <https://bugs.openjdk.java.net/browse/JDK-8189199>
> 
> the j.l.invoke package documentation was also updated but please consider the VM specification as the definitive "source of truth" (we may clean up this area further later on so it becomes more informative, and that may also apply to duplicative text on MethodHandles/VarHandles).
> 
> Any AoT-related work will be deferred to a future release.
> 
> ?
> 
> This patch only supports x64 platforms. There is a small set of changes specific to x64 (specifically to support null and primitives constants, as prior to this patch null was used as a sentinel for resolution and certain primitives types would never have been encountered, such as say byte).
> 
> We will need to follow up with the SPARC platform and it is hoped/anticipated that OpenJDK members responsible for other platforms (namely ARM and PPC) will separately provide patches.
> 
> ?
> 
> Many of tests rely on an experimental byte code API that supports the generation of byte code with dynamic constants.
> 
> One test uses class file bytes produced from a modified version of asmtools.  The modifications have now been pushed but a new version of asmtools need to be rolled into jtreg before the test can operate directly on asmtools information rather than embedding class file bytes directly in the test.
> 
> ?
> 
> Paul.

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

From bsrbnd at gmail.com  Fri Nov  3 19:59:26 2017
From: bsrbnd at gmail.com (B. Blaser)
Date: Fri, 3 Nov 2017 20:59:26 +0100
Subject: Linear implementation of Tarjan's algorithm
In-Reply-To: <6ce30be1-ca4d-ad6d-4218-198e68e5112d@oracle.com>
References: <CAEgw74DvX6zNhGP1OGVqgSifjmyGRWZQsKFYdUG-bChU2tuekw@mail.gmail.com>
 <451662128.2472977.1508695563065.JavaMail.zimbra@u-pem.fr>
 <8b879ed0-1c88-1e6d-a477-88797190f202@oracle.com>
 <CAEgw74AgkLzB98HCaKU8zW0-RJ-HEsS055GCwwN1O6wEA17r2Q@mail.gmail.com>
 <a16ecbb2-b6fe-704e-4f57-48782c84f311@oracle.com>
 <CAEgw74Cu4CY+JXfHY+6wS7DnhQMDeVYkjGPs=sOuODOMzEoosA@mail.gmail.com>
 <6bb6b44c-c842-7c41-0d4b-3877cf5d0bad@oracle.com>
 <CAEgw74D3aFFVbRkyV6oLrj+t0makU8JKxSmT1e0idgh2tFFXpg@mail.gmail.com>
 <ff0bf044-1f55-4624-ad1a-0e5c88442fcd@oracle.com>
 <CAEgw74ABH0+R6KeNbaPPBaeHC=wD7VUanjXqa-VxOgFLnMPvFA@mail.gmail.com>
 <7ba40e17-cb0b-1641-9e49-5391f55bae1c@oracle.com>
 <CAEgw74BHfaeHUu1Usv3z385Gbxju_qpqz-Z69ZHr23VoWqc2JA@mail.gmail.com>
 <da76d50b-6304-7544-e810-98f60050012f@oracle.com>
 <CAEgw74DObnCge4-w0y3Psk_bMNS8=81JOToGR-Lmj7OkJFYXVg@mail.gmail.com>
 <878a12b6-2f93-f10c-2fba-f7894aee9e14@oracle.com>
 <6ce30be1-ca4d-ad6d-4218-198e68e5112d@oracle.com>
Message-ID: <CAEgw74DQjVgpHUQ=Ya57i0QOFmQshp3-fcFOZzcN-0KJg1=N8g@mail.gmail.com>

I think both solutions are slightly different.

Given 'P1 <: Comparable<P1>', 'P2 <: Comparable<P2>' and 'P1.tsym == P2.tsym':

* with your suggestion 'same(P1, P2) = false'
* with my suggestion 'same(P1, P2) = true'

So, it depends what we are expecting loose-same-type to do. But, as it
seems that loose-same-type should use the type symbol not to distinct
clones, I think the second suggestion would make more sense.

That said, the performance problem starts in 'Types.lub()' which uses
loose-same-type. Fortunately, with the current impl or with your
suggestion 'same(P1, P2) = false' which is what we are expecting in
'lub()' (I think) even if causing a performance problem. But 'same(P1,
P2)' currently doesn't return 'false' for the good reason (because of
the bug in loose-same-type instead of checking if 'P1 == P2').

So, we have to decide what 'loose-same-type' should really do to
choose between the two suggestions and eventually fix 'Types.lub()'
(and other places) to use strict-same-type instead, if necessary.

What do you think?

Bernard


On 3 November 2017 at 15:00, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> Or, in terms of Prolog, add a clause to your definitions (and probably some
> 'cuts' ;-)):
>
> same(P, P).
>
>
> Maurizio
>
>
> On 03/11/17 13:57, Maurizio Cimadamore wrote:
>>
>> I agree that it's a bug in the loose check not to consider if tv1 == tv2.
>> But that should be added to the sameTypeVars() predicate, not done by
>> tweaking the behavior in the cache. In other words:
>>
>> class LooseSameTypeVisitor extends SameTypeVisitor {
>>
>>             @Override
>>             boolean sameTypeVars(TypeVar tv1, TypeVar tv2) {
>>                 return tv1 == tv2 ||
>>                     (tv1.tsym == tv2.tsym && checkSameBounds(tv1, tv2));
>>             }
>>
>> }
>>
>>
>> This should make the loose check a proper superset of the strict check.
>>
>> But I bet that this doesn't help the performance problem, which is
>> probably triggered by clones of the same var, not just by == instances. Am I
>> right?
>>
>> Maurizio
>>
>>
>> On 03/11/17 13:17, B. Blaser wrote:
>>>
>>> On 3 November 2017 at 02:58, Maurizio Cimadamore
>>> <maurizio.cimadamore at oracle.com> wrote:
>>>>
>>>>
>>>> On 02/11/17 23:26, B. Blaser wrote:
>>>>>
>>>>> Of course, it will still require some optimization to be sub-second
>>>>> (as you said), but this simple correction could do half of the job.
>>>>
>>>> Hi Bernard,
>>>> unfortunately this optimization is unsound - there's no way to prove
>>>> that P
>>>> <: Comparable<P> is the same as P' <: Comparable<P'>, because of the
>>>> f-bound. That's why the cache is there - it's not an optimization, is
>>>> something that prevents javac from doing the same check over and over
>>>> again.
>>>>
>>>> When such a loop occurs, the right thing to do is to say 'false', as it
>>>> is
>>>> not possible to prove that the bounds are indeed the same.
>>>
>>> If we want to prove that "P <: Comparable<P>" is the same type as "P'
>>> <: Comparable<P'>", we have to do something like the following lines
>>> of Prolog:
>>>
>>> % same(P1, P2) :- samesym(P1, P2), samebounds(comparable(P1),
>>> comparable(P2)).
>>> % samebounds(comparable(P1), comparable(P2)) :- samesym(P1, P2),
>>> cache(comparable(P1), comparable(P2)).
>>>
>>> To prove 'same(P1, P2)', we have to know about 'samesym(P1, P2)' and
>>> 'cache(comparable(P1), comparable(P2))'.
>>> Looking at the implementation, we find that 'samesym(P1, P2)' is given
>>> by 'P1.tsym == P2.tsym' and 'cache(comparable(P1), comparable(P2))'
>>> currently returns 'false'.
>>>
>>> Now, we can look at the truth table for 'samesym()' and 'cache()':
>>>
>>> % samesym(P1, P2) :- true.
>>> % cache(comparable(P1), comparable(P2)) :- true.
>>> %
>>> % ?- same(P1, P2).
>>> % true.
>>>
>>> % samesym(P1, P2) :- true.
>>> % cache(comparable(P1), comparable(P2)) :- false.
>>> %
>>> % ?- same(P1, P2).
>>> % false.
>>>
>>> % samesym(P1, P2) :- false.
>>> % cache(comparable(P1), comparable(P2)) :- true.
>>> %
>>> % ?- same(P1, P2).
>>> % false.
>>>
>>> % samesym(P1, P2) :- false.
>>> % cache(comparable(P1), comparable(P2)) :- false.
>>> %
>>> % ?- same(P1, P2).
>>> % false.
>>>
>>> We see that the only way to prove that 'same(P1, P2) = true' is to
>>> postulate that 'cache(...) = true' which is what I suggested.
>>>
>>> If we make the opposite hypothesis that 'cache(...) = false', which is
>>> currently done, we will never be able to prove that 'same(P, P) =
>>> true'... but the strict comparison would do that successfully!
>>>
>>> What do you think (for the rest, I agree with you)?
>>>
>>> Bernard
>>>
>>>
>>>> Note that the
>>>> fact that the two variables are clones is largely irrelevant here - we
>>>> clone
>>>> new tvars every time we check a new instance of the same generic method
>>>> call/diamond constructor - so in a way these are all different variables
>>>> which just happen to have the same name/same set of initial (declared)
>>>> bounds.
>>>>
>>>> Moreover, the 'loose' type equality test is an artifact of the past - it
>>>> was
>>>> introduced because the strict behavior (which was the default in 6) was,
>>>> well, sometimes too strict - essentially, if bounds of a type variable
>>>> are
>>>> replaced for other type variables (e.g. replace U in the bound of 'Z
>>>> extends
>>>> List<U>'), javac creates a different type-variable with the replaced
>>>> bound.
>>>> If you performed the same replacement twice on the original variable,
>>>> the
>>>> resulting replaced vars would not be deemed 'equals' by javac, which is
>>>> why
>>>> this looser behavior was added. Some more comments are added here:
>>>>
>>>>
>>>> http://hg.openjdk.java.net/jdk7/jdk7/langtools/file/tip/src/share/classes/com/sun/tools/javac/code/Types.java#l632
>>>>
>>>> These changes have been added as a consequence of the fixes for:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-6729401
>>>>
>>>> Now, all this is relatively ancient history, which predates the Java 8
>>>> changes - in fact, this 'legacy' loose behavior, is very problematic -
>>>> it's
>>>> completely outside the spec, and, in the general case with fbounds, it
>>>> cannot even be proven to always complete (which is why the cache is
>>>> there).
>>>> During 8, I sidestepped this issue by adding the 'strict' type equality
>>>> check, which should become the 'standard' - but, as I there was only so
>>>> much
>>>> code I could rewrite in one shot (:-)), I added the new routine beside
>>>> the
>>>> old one, instead of having the new routine completely replacing the old
>>>> one
>>>> (and deal with the compatibility fallout).
>>>>
>>>> I think the time is come that we do a bit of spring cleaning in the
>>>> area,
>>>> and get rid of the legacy (and unsound) loose check, and see where we're
>>>> at.
>>>>
>>>> That said, speaking of inference performances, if we ever move the
>>>> entire
>>>> code base to use the strict equality check, your proposed optimization
>>>> would
>>>> not even apply - in a way your optimization is exploiting the fact that
>>>> that
>>>> particular check is using the loose check instead of the strict one -
>>>> with
>>>> the strict one, two different type var instances (no matter if they are
>>>> clones, and even have same bounds) will still be deemed different.
>>>>
>>>> I still stand by my earlier analysis that the particular issue
>>>> highlighted
>>>> in 8152289 is not something that needs to be addressed by looking at the
>>>> profiler. While you can make the bottleneck smaller and smaller, you
>>>> still
>>>> have an underlying behavior that doesn't scale with the number of nested
>>>> calls - with increasing values of N, you do 10, 100, 1000, 10000, 1000
>>>> ....00000 checks - so no matter how fast the rewritten logic is, you can
>>>> always add a bunch new nested call to bring the compilation time more or
>>>> less in time to what it was before the fix.
>>>>
>>>> The real fix is to find a way so that the incorporation machinery
>>>> doesn't
>>>> have to actually perform a number of steps that is exponential in the
>>>> number
>>>> of the type variables involved, and to detect patterns that can be
>>>> exploited
>>>> in order to reduce the complexity of the incorporation step.
>>>>
>>>> Thanks
>>>> Maurizio
>>
>>
>

From paul.sandoz at oracle.com  Fri Nov  3 21:28:54 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 3 Nov 2017 14:28:54 -0700
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com>
Message-ID: <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com>


> On 3 Nov 2017, at 11:14, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
> Thank you so much for doing this jointly.
> 
> Couple of questions/comments:
> 1. thank you for making UseBootstrapCallInfo diagnostic
> 
> 2. org/objectweb/asmClassReader.java
> why hardcoded 17 instead of ClassWriter.CONDY?
> 

I chose to make the absolute minimal amount of changes to our internal ASM to reduce possible conflicts as i anticipate that a new version of ASM with condy support will eventually be rolled in.


> 3. java/lang/invoke/package-info.java 128-134
> Error handling could be clearer.
> My understanding is that if a LinkageError or subclass is thrown, this will be rethrown
> for all subsequent attempts. Other errors, e.g. VMError may retry resolution
> 
> Also: after line 165: rules do not enable the JVM to share call sites.
> Is it worth noting anywhere that the Constant_Dynamic resolution is shared?
> 
> 4. SD::find_java_mirror_for_type
> lines 2679+
>   ConDy should not be supporting CONSTANT_Class(?;? + FD)
>   IIRC that is temporary for MVT but not part of ConDy?s spec, nor part of what
>   should be checked in for 18.3


Yes, i deleted lines 2678 to 2687

TempNewSymbol type_buf;
if (type->utf8_length() > 1 && type->byte_at(0) == ';') {
  // Strip the quote, which may have come from CONSTANT_Class[";"+FD].
  // (This logic corresponds to the use of "FieldType::is_obj"
  // in resolve_or_null.  A field type can be unwrapped to a class
  // type and vice versa.)
  type = SymbolTable::new_symbol(type->as_C_string() + 1,
                                 type->utf8_length() - 1, CHECK_(empty));
  type_buf = type;  // will free later
}


> also line 2731 - remove comment about ?Foo;?
> 

Removed.


> 5. constantTag.hpp
> ofBasicType: case T_OBJECT return constantTag(JVM_CONSTANT_String) ?
> why not JVM_CONSTANT_CLASS?
> 

We would have to ask John on that, i am guessing it does not matter much since round tripping is ok and it is the more benign of the mapping. I do find this sits awkwardly though, perhaps there is a more general cleanup that can follow in this regard?


> 6. SD::find_java_mirror_for_type
> You have resolve_or_null/fail doing CHECK_(empty) which should
> check for a NULL constant_type_klass. This is followed by an explicit if
> (constant_type_klass == NULL) ? is that needed?
> 

Can SD:resolve_or_null return a null value when HAS_PENDING_EXCEPTION=false?

I see other usages that suggest this to be the case. Where as for resolve_or_fail:

Klass* SystemDictionary::resolve_or_fail(Symbol* class_name, Handle class_loader, Handle protection_domain, bool throw_error, TRAPS) {
  Klass* klass = resolve_or_null(class_name, class_loader, protection_domain, THREAD);
  if (HAS_PENDING_EXCEPTION || klass == NULL) {
    // can return a null klass
    klass = handle_resolution_exception(class_name, throw_error, klass, THREAD);
  }
  return klass;
}


It suggests we can change the code from:

if (failure_mode == SignatureStream::ReturnNull) {
  constant_type_klass = resolve_or_null(type, class_loader, protection_domain,
                                        CHECK_(empty));
} else {
  bool throw_error = (failure_mode == SignatureStream::NCDFError);
  constant_type_klass = resolve_or_fail(type, class_loader, protection_domain,
                                        throw_error, CHECK_(empty));
}
if (constant_type_klass == NULL) {
  return Handle();  // report failure this way
}

to

if (failure_mode == SignatureStream::ReturnNull) {
  constant_type_klass = resolve_or_null(type, class_loader, protection_domain,
                                        CHECK_(empty));
  if (constant_type_klass == NULL) {
    return Handle();  // report failure this way
  }
} else {
  bool throw_error = (failure_mode == SignatureStream::NCDFError);
  constant_type_klass = resolve_or_fail(type, class_loader, protection_domain,
                                        throw_error, CHECK_(empty));
}

?


> 7. reflection.cpp
> get_mirror_from_signature
> Looks like potential for side effects. Odd to set mirror_oop inside if (log_is_enabled)
> Is the intent to assert that k->java_mirror() == mirror_oop?
> Or is the issue that we have a make drop here and the potential for a safe point?
> If so, make a handle and extract it on return?
> 
> ? Or better yet - don?t make any changes to reflection.cpp - not necessary
> 

Lois, John?

My recollection was John was attempting to tunnel things through a single method find_java_mirror_for_type, but i agree the setting of mirror_oop is odd.



> 8. BootstrapMethodInvoker
> Could you possibly add a comment that the default today is vmIsPushing and IsPullModeBSM is false?
> Or find a slightly different naming to make that clearer?

boolean pullMode = isPullModeBSM(bootstrapMethod);  // default value is false
boolean vmIsPushing = !staticArgumentsPulled(info); // default value is true

?


> 
> 9. test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java
> How would I write an ldc CONSTANT_Dynamic which referred to a bootstrap method that
> was not ACC_STATIC?

https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html#jvms-4.7.23

See the note under bootstrap_method_ref. The kind of method handle is constrained because of the arguments that are pushed on the stack before invocation. I believe it?s possible to have a constructor, but the declaring class would need to be a subtype of CallSite in the case of indy, and a subtype of the constant value type in the case of condy.


> Or was not ACC_PUBLIC?

That?s dependent on the accessibility between the lookup class the the BSM declaring class.


> Or was 
> Or did I read the invoke dynamic method incorrectly?
> 

By default, and for convenience, the InstructionHelper assumes the BSM is declared by the lookup class. I recently modified that to support the BSM being declared on another class, to test the minimal set of BSMs for condy (separate issue [1]). Note it?s always possible to use the bytecode API more directly.

So we can easily add more -ve tests for non-accessible or non-static BSMs.

Paul.

[1] http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/


From maurizio.cimadamore at oracle.com  Fri Nov  3 21:44:27 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 3 Nov 2017 21:44:27 +0000
Subject: Linear implementation of Tarjan's algorithm
In-Reply-To: <CAEgw74DQjVgpHUQ=Ya57i0QOFmQshp3-fcFOZzcN-0KJg1=N8g@mail.gmail.com>
References: <CAEgw74DvX6zNhGP1OGVqgSifjmyGRWZQsKFYdUG-bChU2tuekw@mail.gmail.com>
 <8b879ed0-1c88-1e6d-a477-88797190f202@oracle.com>
 <CAEgw74AgkLzB98HCaKU8zW0-RJ-HEsS055GCwwN1O6wEA17r2Q@mail.gmail.com>
 <a16ecbb2-b6fe-704e-4f57-48782c84f311@oracle.com>
 <CAEgw74Cu4CY+JXfHY+6wS7DnhQMDeVYkjGPs=sOuODOMzEoosA@mail.gmail.com>
 <6bb6b44c-c842-7c41-0d4b-3877cf5d0bad@oracle.com>
 <CAEgw74D3aFFVbRkyV6oLrj+t0makU8JKxSmT1e0idgh2tFFXpg@mail.gmail.com>
 <ff0bf044-1f55-4624-ad1a-0e5c88442fcd@oracle.com>
 <CAEgw74ABH0+R6KeNbaPPBaeHC=wD7VUanjXqa-VxOgFLnMPvFA@mail.gmail.com>
 <7ba40e17-cb0b-1641-9e49-5391f55bae1c@oracle.com>
 <CAEgw74BHfaeHUu1Usv3z385Gbxju_qpqz-Z69ZHr23VoWqc2JA@mail.gmail.com>
 <da76d50b-6304-7544-e810-98f60050012f@oracle.com>
 <CAEgw74DObnCge4-w0y3Psk_bMNS8=81JOToGR-Lmj7OkJFYXVg@mail.gmail.com>
 <878a12b6-2f93-f10c-2fba-f7894aee9e14@oracle.com>
 <6ce30be1-ca4d-ad6d-4218-198e68e5112d@oracle.com>
 <CAEgw74DQjVgpHUQ=Ya57i0QOFmQshp3-fcFOZzcN-0KJg1=N8g@mail.gmail.com>
Message-ID: <098480ed-8eaa-5f87-264d-d812e1317b26@oracle.com>



On 03/11/17 19:59, B. Blaser wrote:
> So, we have to decide what 'loose-same-type' should really do to
> choose between the two suggestions and eventually fix 'Types.lub()'
> (and other places) to use strict-same-type instead, if necessary.
>
> What do you think?
Sure that's what I was getting at yesterday - there ought to be only one 
relationship for type equivalence, not two. I suspect getting there is 
gonna be painful, because of the compatibility concerns (this area is a 
mine field), but we should nevertheless strive to get there - both from 
an implementation sanity perspective and from a conformance perspective.

But this is orthogonal to performance, and more related to the general 
effort of bringing javac and JLS closer together - you might be aware 
that Dan has been filing quite a number of spec/javac issues on this 
topic - the full list can be viewed here:

https://bugs.openjdk.java.net/browse/JDK-8078095?jql=project%20%3D%20JDK%20AND%20labels%20%3D%20jls-types

Of these, I can see several entries that are at least partially related 
to the topic we've been discussing - example:

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

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

So, again, this is something that will require more of an holistic 
effort - doing a point-fix here has an high potential of increasing the 
level of entropy of the implementation in a very delicate area, so it's 
better to come up with a concrete and comprehensive plan before touching 
anything (otherwise the risk is keep chasing long bug tails).

Cheers
Maurizio

From david.holmes at oracle.com  Mon Nov  6 00:55:04 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 6 Nov 2017 10:55:04 +1000
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com>
 <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com>
Message-ID: <8cbd0397-a840-0c84-9a17-3dbe2a6bed1b@oracle.com>

On 4/11/2017 7:28 AM, Paul Sandoz wrote:
>> On 3 Nov 2017, at 11:14, Karen Kinnear <karen.kinnear at oracle.com> wrote:
>> 6. SD::find_java_mirror_for_type
>> You have resolve_or_null/fail doing CHECK_(empty) which should
>> check for a NULL constant_type_klass. This is followed by an explicit if
>> (constant_type_klass == NULL) ? is that needed?
>>
> 
> Can SD:resolve_or_null return a null value when HAS_PENDING_EXCEPTION=false?

I don't believe it actually can - the only reason you would get NULL is 
if something went wrong, for which an exception must be pending. 
However, even the internal implementation underlying this seems unclear 
on that point e.g in SystemDictionary::resolve_instance_class_or_null we 
have:

   if (HAS_PENDING_EXCEPTION || k == NULL) {
     return NULL;
   }

David
-----

> I see other usages that suggest this to be the case. Where as for resolve_or_fail:
> 
> Klass* SystemDictionary::resolve_or_fail(Symbol* class_name, Handle class_loader, Handle protection_domain, bool throw_error, TRAPS) {
>    Klass* klass = resolve_or_null(class_name, class_loader, protection_domain, THREAD);
>    if (HAS_PENDING_EXCEPTION || klass == NULL) {
>      // can return a null klass
>      klass = handle_resolution_exception(class_name, throw_error, klass, THREAD);
>    }
>    return klass;
> }
> 
> 
> It suggests we can change the code from:
> 
> if (failure_mode == SignatureStream::ReturnNull) {
>    constant_type_klass = resolve_or_null(type, class_loader, protection_domain,
>                                          CHECK_(empty));
> } else {
>    bool throw_error = (failure_mode == SignatureStream::NCDFError);
>    constant_type_klass = resolve_or_fail(type, class_loader, protection_domain,
>                                          throw_error, CHECK_(empty));
> }
> if (constant_type_klass == NULL) {
>    return Handle();  // report failure this way
> }
> 
> to
> 
> if (failure_mode == SignatureStream::ReturnNull) {
>    constant_type_klass = resolve_or_null(type, class_loader, protection_domain,
>                                          CHECK_(empty));
>    if (constant_type_klass == NULL) {
>      return Handle();  // report failure this way
>    }
> } else {
>    bool throw_error = (failure_mode == SignatureStream::NCDFError);
>    constant_type_klass = resolve_or_fail(type, class_loader, protection_domain,
>                                          throw_error, CHECK_(empty));
> }
> 
> ?
> 
> 
>> 7. reflection.cpp
>> get_mirror_from_signature
>> Looks like potential for side effects. Odd to set mirror_oop inside if (log_is_enabled)
>> Is the intent to assert that k->java_mirror() == mirror_oop?
>> Or is the issue that we have a make drop here and the potential for a safe point?
>> If so, make a handle and extract it on return?
>>
>> ? Or better yet - don?t make any changes to reflection.cpp - not necessary
>>
> 
> Lois, John?
> 
> My recollection was John was attempting to tunnel things through a single method find_java_mirror_for_type, but i agree the setting of mirror_oop is odd.
> 
> 
> 
>> 8. BootstrapMethodInvoker
>> Could you possibly add a comment that the default today is vmIsPushing and IsPullModeBSM is false?
>> Or find a slightly different naming to make that clearer?
> 
> boolean pullMode = isPullModeBSM(bootstrapMethod);  // default value is false
> boolean vmIsPushing = !staticArgumentsPulled(info); // default value is true
> 
> ?
> 
> 
>>
>> 9. test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java
>> How would I write an ldc CONSTANT_Dynamic which referred to a bootstrap method that
>> was not ACC_STATIC?
> 
> https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html#jvms-4.7.23
> 
> See the note under bootstrap_method_ref. The kind of method handle is constrained because of the arguments that are pushed on the stack before invocation. I believe it?s possible to have a constructor, but the declaring class would need to be a subtype of CallSite in the case of indy, and a subtype of the constant value type in the case of condy.
> 
> 
>> Or was not ACC_PUBLIC?
> 
> That?s dependent on the accessibility between the lookup class the the BSM declaring class.
> 
> 
>> Or was
>> Or did I read the invoke dynamic method incorrectly?
>>
> 
> By default, and for convenience, the InstructionHelper assumes the BSM is declared by the lookup class. I recently modified that to support the BSM being declared on another class, to test the minimal set of BSMs for condy (separate issue [1]). Note it?s always possible to use the bytecode API more directly.
> 
> So we can easily add more -ve tests for non-accessible or non-static BSMs.
> 
> Paul.
> 
> [1] http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/
> 

From paul.sandoz at oracle.com  Tue Nov  7 16:31:02 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 7 Nov 2017 08:31:02 -0800
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <8cbd0397-a840-0c84-9a17-3dbe2a6bed1b@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com>
 <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com>
 <8cbd0397-a840-0c84-9a17-3dbe2a6bed1b@oracle.com>
Message-ID: <B7028E51-6948-499E-B5AD-389354B5EBAC@oracle.com>


> On 5 Nov 2017, at 16:55, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 4/11/2017 7:28 AM, Paul Sandoz wrote:
>>> On 3 Nov 2017, at 11:14, Karen Kinnear <karen.kinnear at oracle.com> wrote:
>>> 6. SD::find_java_mirror_for_type
>>> You have resolve_or_null/fail doing CHECK_(empty) which should
>>> check for a NULL constant_type_klass. This is followed by an explicit if
>>> (constant_type_klass == NULL) ? is that needed?
>>> 
>> Can SD:resolve_or_null return a null value when HAS_PENDING_EXCEPTION=false?
> 
> I don't believe it actually can - the only reason you would get NULL is if something went wrong, for which an exception must be pending. However, even the internal implementation underlying this seems unclear on that point

Right, i am gonna leave things as they are for now unless we come up with a more definitive answer.

Paul.

> e.g in SystemDictionary::resolve_instance_class_or_null we have:
> 
>  if (HAS_PENDING_EXCEPTION || k == NULL) {
>    return NULL;
>  }
> 
> David
> ??

From bsrbnd at gmail.com  Tue Nov  7 18:31:40 2017
From: bsrbnd at gmail.com (B. Blaser)
Date: Tue, 7 Nov 2017 19:31:40 +0100
Subject: Spec clarification about intersection types
Message-ID: <CAEgw74C5OyCyxvAbcQSJML+6ZTPrKo_tGsLWk+9+Y78AVw3HEQ@mail.gmail.com>

Hi,

I would like to request a clarification about intersection types. This
subject was briefly discussed on compiler-dev but it didn't appear
clearly if there was a specification or conformance issue (or
nothing?).

Consider the following example:

class A {
    interface I {}

    I nil1() { return null; }

    <T extends I> T nil2() { return null; }

    static final class Final {}

    void a() {
        // Fails per JLS9 ?5.1.6.1 pt (5) + (12)
        Final f1 = (Final & I) nil1();

        // Succeeds as A isn't final
        A a = (A & I) nil1();

        // Should fail per JLS9 ?18.4 ?
        Final f2 = nil2();
    }

    // Should fail per JLS9 ?4.9 ?
    <U extends Final & I> U nil3() { return null; }
}

Javac currently behaves as follows:

(1) 'Final f1 = (Final & I) nil1()' fails to compile per JLS9 ?5.1.6.1
points 5 and 12 which seems to be right:

"A narrowing reference conversion exists from reference type S to
reference type T if all of the following are true:
 ...
? One of the following cases applies:
 ...
5. S is an interface type, T is a class type, and T does not name a final class.
 ...
12. T is an intersection type T1 & ... & Tn, and for all i (1 ? i ?
n), either a widening reference conversion or a narrowing reference
conversion exists from S to Ti."


(2) 'Final f2 = nil2()' succeeds but should probably fail per JLS9 ?18.4:

"If the bound set produced in the step above contains the bound false;

then let Y1, ..., Yn be fresh type variables whose bounds are as follows:
 ...
? For all i (1 ? i ? n), where ?i has upper bounds U1, ..., Uk, let
the upper bound of Yi be glb(U1 ?, ..., Uk ?), where ? is the
substitution [?1:=Y1, ..., ?n:=Yn].

If the type variables Y1, ..., Yn do not have well-formed bounds (that
is, a lower bound is not a subtype of an upper bound, or an
intersection type is inconsistent), then resolution fails."

In our example, 'T' has the two upper bounds 'T <: I' (from definition
of 'T') and 'T <: Final' (from return type constraint). From ?18.4,
the upper bound of 'Y' is 'Final & I' which is an inconsistent
intersection type (but ?4.9 isn't absolutely clear about that, see
next) then resolution should fail.


(3) '<U extends Final & I>' succeeds but should probably fail per JLS9 ?4.9:

"otherwise, a notional class is induced with direct superclass Ck.
This class or interface has direct superinterfaces T1', ..., Tn' and
is declared in the package in which the intersection type appears."

In our case, it seems to be impossible to have a "notional class
induced with direct superclass" 'Final'.


In conclusion, JLS9 ?5.1.6.1 clearly expresses that (1) should fail
but ?18.4 and ?4.9 are probably not clear enough to establish if (2)
and (3) should really succeed or fail.

I hope I didn't miss anything.

Thanks in advance for any clarification,

Bernard


P.S.

Note for the case 'A a = nil2()' where 'A' isn't 'final', it was
suggested to emit a lint warning because 'nil2()' has no way to know
the expected return type, see:

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

From karen.kinnear at oracle.com  Tue Nov  7 20:04:57 2017
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Tue, 7 Nov 2017 15:04:57 -0500
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com>
 <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com>
Message-ID: <22E25545-9DEA-4B3F-9735-8B34D9E69B2E@oracle.com>

Paul,

Thank you for the explanations. Asking for your help in some test case construction at the end here:

>> 3. java/lang/invoke/package-info.java 128-134
>> Error handling could be clearer.
>> My understanding is that if a LinkageError or subclass is thrown, this will be rethrown
>> for all subsequent attempts. Other errors, e.g. VMError may retry resolution
I was WRONG here - this does match the JVMS. Apologies for the confusion.
>> 
>> 9. test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java
>> How would I write an ldc CONSTANT_Dynamic which referred to a bootstrap method that
>> was not ACC_STATIC?
> 
> https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html#jvms-4.7.23 <https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html#jvms-4.7.23>
> 
> See the note under bootstrap_method_ref. The kind of method handle is constrained because of the arguments that are pushed on the stack before invocation. I believe it?s possible to have a constructor, but the declaring class would need to be a subtype of CallSite in the case of indy, and a subtype of the constant value type in the case of condy.
> 
> 
>> Or was not ACC_PUBLIC?
> 
> That?s dependent on the accessibility between the lookup class the the BSM declaring class.
> 
> 
>> Or was 
>> Or did I read the invoke dynamic method incorrectly?
>> 
> 
> By default, and for convenience, the InstructionHelper assumes the BSM is declared by the lookup class. I recently modified that to support the BSM being declared on another class, to test the minimal set of BSMs for condy (separate issue [1]). Note it?s always possible to use the bytecode API more directly.
> 
> So we can easily add more -ve tests for non-accessible or non-static BSMs.
Thank you - that is what we were trying to do - test BSM declared in another class, test in-accessible
BSM and test non static method.

Could you help us figure out how to
1) invoke a constructor? 
2) invoke a virtual method? How do you pass the receiver? 

thanks,
Karen

> 
> Paul.
> 
> [1] http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171107/2252405e/attachment.html>

From paul.sandoz at oracle.com  Tue Nov  7 22:47:16 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 7 Nov 2017 14:47:16 -0800
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <22E25545-9DEA-4B3F-9735-8B34D9E69B2E@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com>
 <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com>
 <22E25545-9DEA-4B3F-9735-8B34D9E69B2E@oracle.com>
Message-ID: <8F7AE06B-34A0-43A7-8861-24BE952A5532@oracle.com>


> On 7 Nov 2017, at 12:04, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
> Paul,
> 
> Thank you for the explanations. Asking for your help in some test case construction at the end here:
> 
>>> 3. java/lang/invoke/package-info.java 128-134
>>> Error handling could be clearer.
>>> My understanding is that if a LinkageError or subclass is thrown, this will be rethrown
>>> for all subsequent attempts. Other errors, e.g. VMError may retry resolution
> I was WRONG here - this does match the JVMS. Apologies for the confusion.
>>> 
>>> 9. test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java
>>> How would I write an ldc CONSTANT_Dynamic which referred to a bootstrap method that
>>> was not ACC_STATIC?
>> 
>> https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html#jvms-4.7.23
>> 
>> See the note under bootstrap_method_ref. The kind of method handle is constrained because of the arguments that are pushed on the stack before invocation. I believe it?s possible to have a constructor, but the declaring class would need to be a subtype of CallSite in the case of indy, and a subtype of the constant value type in the case of condy.
>> 
>> 
>>> Or was not ACC_PUBLIC?
>> 
>> That?s dependent on the accessibility between the lookup class the the BSM declaring class.
>> 
>> 
>>> Or was 
>>> Or did I read the invoke dynamic method incorrectly?
>>> 
>> 
>> By default, and for convenience, the InstructionHelper assumes the BSM is declared by the lookup class. I recently modified that to support the BSM being declared on another class, to test the minimal set of BSMs for condy (separate issue [1]). Note it?s always possible to use the bytecode API more directly.
>> 
>> So we can easily add more -ve tests for non-accessible or non-static BSMs.

I am wrong, i forgot i updated the API to remove the declaration of the BSM kind, and it only supports static BSMs.


> Thank you - that is what we were trying to do - test BSM declared in another class, test in-accessible
> BSM and test non static method.
> 

The latter (access to a BSM in another class) is easy now using the high-level construct of InstructionHelper.ldcDynamicConstant (see patch for the condy BSMs, which is also in the amber repo in the condy branch).


> Could you help us figure out how to
> 1) invoke a constructor? 
> 2) invoke a virtual method? How do you pass the receiver? 
> 

I think for these you will need to use ASM tools to massage the MH for the BSM e.g. develop for a class with a static BSM then adjust the constant pool entry for the associated MH.

Paul.

From jonathan.gibbons at oracle.com  Thu Nov  9 23:42:43 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 09 Nov 2017 15:42:43 -0800
Subject: RFR: 8182758: Remove the Native-Header Generation Tool (javah)
Message-ID: <5A04E7F3.5000700@oracle.com>

Please review a fix to remove the javah tool, as previously advertised
in JDK-8152360. (The replacement is to use the javac -h option.)

Not surprisingly, most of this is removing code, with just a couple of src/
files being modified, as well as some tests.

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

-- Jon

From jan.lahoda at oracle.com  Tue Nov 14 13:17:44 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 14 Nov 2017 14:17:44 +0100
Subject: JDK-8191112: javac OutOfMemoryError caused by "-Xlint:exports" option
Message-ID: <5A0AECF8.2010603@oracle.com>

Hi,

Consider an automatic module "dep" with class "dep.Dep", and additional 
automatic modules ext1 and ext2.

When javac has these on the modulepath, and compiles a module like this:
---
module mod {
     requires dep;
     exports api;
}

package api;

public class Api extends dep.Dep {}
---

-Xlint:exports can be used to report exported APIs that refer to types 
potentially inaccessible to the clients. In this case, the supertype of 
api.Api may be inaccessible unless the client has a dependency on "dep", 
so the lint will warn about that. But since the dep, ext1 and ext2 are 
automatic modules, each of the modules "requires transitive" the other 
automatic modules, and the check may go into an infinite loop.

Moreover, for code like this:
---
module mod {
requires transitive ext1;
exports api;
}
---

"dep.Dep" is accessible using requires transitive edges of the automatic 
modules, hence the warning/lint is not printed.

That does not seem quite right, an explicit "requires transitive dep" 
dependency would be better, otherwise the changes in the module path can 
lead to surprising behavior.

The suggested patch is to simply ignore the dependencies of automatic 
modules in the check - that should avoid the infinite loop and print the 
warning in the "requires transitive ext1" case.

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

What do you think?

Thanks,
     Jan


From alex.buckley at oracle.com  Tue Nov 14 19:03:31 2017
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 14 Nov 2017 11:03:31 -0800
Subject: JDK-8191112: javac OutOfMemoryError caused by "-Xlint:exports"
 option
In-Reply-To: <5A0AECF8.2010603@oracle.com>
References: <5A0AECF8.2010603@oracle.com>
Message-ID: <5A0B3E03.1020006@oracle.com>

On 11/14/2017 5:17 AM, Jan Lahoda wrote:
> ---
> module mod {
> requires transitive ext1;
> exports api;
> }
> ---
>
> "dep.Dep" is accessible using requires transitive edges of the automatic
> modules, hence the warning/lint is not printed.
>
> That does not seem quite right, an explicit "requires transitive dep"
> dependency would be better, otherwise the changes in the module path can
> lead to surprising behavior.
>
> The suggested patch is to simply ignore the dependencies of automatic
> modules in the check - that should avoid the infinite loop and print the
> warning in the "requires transitive ext1" case.

Good idea to make -Xlint:exports be more sophisticated w.r.t. automatic 
modules ... but for the very last point, are you saying that a warning 
is given for "requires transitive ext1" because of "transitive" or 
because of "ext1"? That is, would a warning be printed for just 
"requires ext1" ? I think it should be; the "transitive" in "requires 
transitive ext1" is for the benefit of consumers of mod, which is not 
germane to mod's barely-visible consumption of dep via ext1's implicit 
"requires transitive dep1".

Alex

From jan.lahoda at oracle.com  Tue Nov 14 19:16:04 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 14 Nov 2017 20:16:04 +0100
Subject: JDK-8191112: javac OutOfMemoryError caused by "-Xlint:exports"
 option
In-Reply-To: <5A0B3E03.1020006@oracle.com>
References: <5A0AECF8.2010603@oracle.com> <5A0B3E03.1020006@oracle.com>
Message-ID: <5A0B40F4.9020602@oracle.com>

Hi Alex,

On 14.11.2017 20:03, Alex Buckley wrote:
> On 11/14/2017 5:17 AM, Jan Lahoda wrote:
>> ---
>> module mod {
>> requires transitive ext1;
>> exports api;
>> }
>> ---
>>
>> "dep.Dep" is accessible using requires transitive edges of the automatic
>> modules, hence the warning/lint is not printed.
>>
>> That does not seem quite right, an explicit "requires transitive dep"
>> dependency would be better, otherwise the changes in the module path can
>> lead to surprising behavior.
>>
>> The suggested patch is to simply ignore the dependencies of automatic
>> modules in the check - that should avoid the infinite loop and print the
>> warning in the "requires transitive ext1" case.
>
> Good idea to make -Xlint:exports be more sophisticated w.r.t. automatic
> modules ... but for the very last point, are you saying that a warning
> is given for "requires transitive ext1" because of "transitive" or
> because of "ext1"? That is, would a warning be printed for just
> "requires ext1" ? I think it should be; the "transitive" in "requires
> transitive ext1" is for the benefit of consumers of mod, which is not
> germane to mod's barely-visible consumption of dep via ext1's implicit
> "requires transitive dep1".

(For completeness, there are other checks that inspect dependencies on 
automatic modules, but this one is not specific to automatic modules, it 
warns about using possibly inaccessible types in exported API.)

With the proposed patch, the warning would be printed for all "requires 
transitive ext1", "requires ext1" and "requires dep", but not for 
"requires transitive dep", as in the last case depending on "mod" will 
make exported types from dep available to the client (which may be also 
true for "requires transitive ext1", but that depends on how the module 
path is constructed). If "ext1" would be an explicit module, which would 
have "requires transitive dep", then the warning would not be printed 
for "requires transitive ext1". If ext1 would contain only "requires 
dep", then the warning would be printed.

Jan

>
> Alex

From alex.buckley at oracle.com  Tue Nov 14 19:36:52 2017
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 14 Nov 2017 11:36:52 -0800
Subject: JDK-8191112: javac OutOfMemoryError caused by "-Xlint:exports"
 option
In-Reply-To: <5A0B40F4.9020602@oracle.com>
References: <5A0AECF8.2010603@oracle.com> <5A0B3E03.1020006@oracle.com>
 <5A0B40F4.9020602@oracle.com>
Message-ID: <5A0B45D4.5060602@oracle.com>

On 11/14/2017 11:16 AM, Jan Lahoda wrote:
> With the proposed patch, the warning would be printed for all "requires
> transitive ext1", "requires ext1" and "requires dep", but not for
> "requires transitive dep", as in the last case depending on "mod" will
> make exported types from dep available to the client ...

 > If "ext1" would be an explicit module, which would
> have "requires transitive dep", then the warning would not be printed
> for "requires transitive ext1".

 > If ext1 would contain only "requires
> dep", then the warning would be printed.

All sounds good!

Alex

From jonathan.gibbons at oracle.com  Wed Nov 15 22:50:55 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 15 Nov 2017 14:50:55 -0800
Subject: JDK-8191112: javac OutOfMemoryError caused by "-Xlint:exports"
 option
In-Reply-To: <5A0AECF8.2010603@oracle.com>
References: <5A0AECF8.2010603@oracle.com>
Message-ID: <5A0CC4CF.7000109@oracle.com>

+1

-- Jon

On 11/14/2017 05:17 AM, Jan Lahoda wrote:
> Hi,
>
> Consider an automatic module "dep" with class "dep.Dep", and 
> additional automatic modules ext1 and ext2.
>
> When javac has these on the modulepath, and compiles a module like this:
> ---
> module mod {
>     requires dep;
>     exports api;
> }
>
> package api;
>
> public class Api extends dep.Dep {}
> ---
>
> -Xlint:exports can be used to report exported APIs that refer to types 
> potentially inaccessible to the clients. In this case, the supertype 
> of api.Api may be inaccessible unless the client has a dependency on 
> "dep", so the lint will warn about that. But since the dep, ext1 and 
> ext2 are automatic modules, each of the modules "requires transitive" 
> the other automatic modules, and the check may go into an infinite loop.
>
> Moreover, for code like this:
> ---
> module mod {
> requires transitive ext1;
> exports api;
> }
> ---
>
> "dep.Dep" is accessible using requires transitive edges of the 
> automatic modules, hence the warning/lint is not printed.
>
> That does not seem quite right, an explicit "requires transitive dep" 
> dependency would be better, otherwise the changes in the module path 
> can lead to surprising behavior.
>
> The suggested patch is to simply ignore the dependencies of automatic 
> modules in the check - that should avoid the infinite loop and print 
> the warning in the "requires transitive ext1" case.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191112
> Webrev: http://cr.openjdk.java.net/~jlahoda/8191112/webrev.00/
>
> What do you think?
>
> Thanks,
>     Jan
>


From jonathan.gibbons at oracle.com  Fri Nov 17 18:29:52 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 17 Nov 2017 10:29:52 -0800
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
Message-ID: <5A0F2AA0.8020906@oracle.com>

Goetz,

I understand why you might want to ensure that a basic set of help 
options is supported,
but I don't understand why that justifies removing older options, like 
"-help" for many tools.

In addition, I notice the CSR says:

> *Compatibility Risk Description:* 
> <https://bugs.openjdk.java.net/browse/JDK-8191477#> Only new flags are 
> added, none removed.

But that is not true, since your edits for javac and javadoc remove the 
option completely.

Also, in the CSR, look for these typos:
     serveral
     deperecation
     OpenJdk (should be OpenJDK)


Also, I note that you've changed localized resource files. The usual 
procedure is to never
touch those files, since they get updated later by Oracle's localization 
team.

-- Jon

On 11/17/2017 03:23 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> please review this change. I also filed a CSR for this:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
>
> See the webrev for a detailed description of the changes.
>
> If required, I'll make break-out changes to be reviewed separately.
>
> I had posted a RFR before, but improved the change to
> give a more complete overview of currently supported flags
> for the CSR:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html
>
> Best regards,
>    Goetz.
>

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

From dmitry.samersoff at bell-sw.com  Wed Nov  1 07:47:57 2017
From: dmitry.samersoff at bell-sw.com (Dmitry Samersoff)
Date: Wed, 01 Nov 2017 07:47:57 -0000
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <58726425-BA16-482B-A02E-3B0613CD5010@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <b8c8d33a-2782-cfba-64df-fc32151ac117@bell-sw.com>
 <93431280-9CBF-4722-961D-F2D2D0F83B4E@oracle.com>
 <EBC28788-F65A-42F8-A6AD-7B670FDB74C5@oracle.com>
 <d3d6c258-4a26-331b-a85c-9e7f23fa8229@bell-sw.com>
 <58726425-BA16-482B-A02E-3B0613CD5010@oracle.com>
Message-ID: <ff937e56-43ba-1f44-7f37-96d715661082@bell-sw.com>

Paul,

Thank you!

-Dmitry


On 31.10.2017 20:32, Paul Sandoz wrote:
> 
>> On 31 Oct 2017, at 05:58, Dmitry Samersoff <dmitry.samersoff at bell-sw.com> wrote:
>>
>> Paul and Frederic,
>>
>> Thank you.
>>
>> One more question. Do we need to call verify_oop below?
>>
>> 509   { // Check for the null sentinel.
>> ...
>> 517      xorptr(result, result);  // NULL object reference
>> ...
>>
>> 521   if (VerifyOops) {
>> 522      verify_oop(result);
>> 523   }
>>
> 
> I believe it?s harmless.
> 
> When the flag is on it eventually results in a call to the stub generated by generate_verify_oop:
> 
> http://hg.openjdk.java.net/jdk10/hs/file/tip/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#l1023
> 
>     // make sure object is 'reasonable'
>     __ testptr(rax, rax);
>     __ jcc(Assembler::zero, exit); // if obj is NULL it is OK
> 
> If the oop is null the verification will exit safely.
> 
> Paul.
> 
>> -Dmitry
>>
>>
>> On 31.10.2017 00:56, Frederic Parain wrote:
>>> I?m seeing no issue with rcx being aliased in this code.
>>>
>>> Fred
>>>
>>>> On Oct 30, 2017, at 15:44, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Thanks for reviewing.
>>>>
>>>>> On 30 Oct 2017, at 11:05, Dmitry Samersoff <dmitry.samersoff at bell-sw.com> wrote:
>>>>>
>>>>> Paul,
>>>>>
>>>>> templateTable_x86.cpp:
>>>>>
>>>>> 564   const Register flags = rcx;
>>>>> 565   const Register rarg = NOT_LP64(rcx) LP64_ONLY(c_rarg1);
>>>>>
>>>>> Should we use another register for rarg under NOT_LP64 ?
>>>>>
>>>>
>>>> I think it should be ok, it i ain?t an expert here on the interpreter and the calling conventions, so please correct me.
>>>>
>>>> Some more context:
>>>>
>>>> +  const Register flags = rcx;
>>>> +  const Register rarg = NOT_LP64(rcx) LP64_ONLY(c_rarg1);
>>>> +  __ movl(rarg, (int)bytecode());
>>>>
>>>> The current bytecode code is loaded into ?rarg?
>>>>
>>>> +  call_VM(obj, CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_ldc), rarg);
>>>>
>>>> Then ?rarg" is the argument to the call to InterpreterRuntime::resolve_ldc, after which it is no longer referred to.
>>>>
>>>> +#ifndef _LP64
>>>> +  // borrow rdi from locals
>>>> +  __ get_thread(rdi);
>>>> +  __ get_vm_result_2(flags, rdi);
>>>> +  __ restore_locals();
>>>> +#else
>>>> +  __ get_vm_result_2(flags, r15_thread);
>>>> +#endif
>>>>
>>>> The result from the call is then loaded into flags.
>>>>
>>>> So i don?t think it matters in this case if rcx is aliased.
>>>>
>>>> Paul.
>>>>
>>>>> -Dmitry
>>>>>
>>>>>
>>>>> On 10/26/2017 08:03 PM, Paul Sandoz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the following patch for minimal dynamic constant support:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/>
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8186046 <https://bugs.openjdk.java.net/browse/JDK-8186046>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8186209 <https://bugs.openjdk.java.net/browse/JDK-8186209>
>>>>>>
>>>>>> This patch is based on the JDK 10 unified HotSpot repository. Testing so far looks good.
>>>>>>
>>>>>> By minimal i mean just the support in the runtime for a dynamic constant pool entry to be referenced by a LDC instruction or a bootstrap method argument. Much of the work leverages the foundations built by invoke dynamic but is arguably simpler since resolution is less complex.
>>>>>>
>>>>>> A small set of bootstrap methods will be proposed as a follow on issue for 10 (these are currently being refined in the amber repository).
>>>>>>
>>>>>> Bootstrap method invocation has not changed (and the rules are the same for dynamic constants and indy). It is planned to enhance this in a further major release to support lazy resolution of bootstrap method arguments.
>>>>>>
>>>>>> The CSR for the VM specification is here:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8189199 <https://bugs.openjdk.java.net/browse/JDK-8189199>
>>>>>>
>>>>>> the j.l.invoke package documentation was also updated but please consider the VM specification as the definitive "source of truth" (we may clean up this area further later on so it becomes more informative, and that may also apply to duplicative text on MethodHandles/VarHandles).
>>>>>>
>>>>>> Any AoT-related work will be deferred to a future release.
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> This patch only supports x64 platforms. There is a small set of changes specific to x64 (specifically to support null and primitives constants, as prior to this patch null was used as a sentinel for resolution and certain primitives types would never have been encountered, such as say byte).
>>>>>>
>>>>>> We will need to follow up with the SPARC platform and it is hoped/anticipated that OpenJDK members responsible for other platforms (namely ARM and PPC) will separately provide patches.
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> Many of tests rely on an experimental byte code API that supports the generation of byte code with dynamic constants.
>>>>>>
>>>>>> One test uses class file bytes produced from a modified version of asmtools.  The modifications have now been pushed but a new version of asmtools need to be rolled into jtreg before the test can operate directly on asmtools information rather than embedding class file bytes directly in the test.
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> Paul.
>>>>>>
>>>>>
>>>>
>>>
>>
>>
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171101/cd1316d8/signature-0001.asc>

From goetz.lindenmaier at sap.com  Fri Nov 17 11:23:04 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 17 Nov 2017 11:23:04 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
Message-ID: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>

Hi,

please review this change. I also filed a CSR for this:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
CSR: https://bugs.openjdk.java.net/browse/JDK-8191477

See the webrev for a detailed description of the changes.

If required, I'll make break-out changes to be reviewed separately.

I had posted a RFR before, but improved the change to 
give a more complete overview of currently supported flags
for the CSR:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html

Best regards,
  Goetz.


From robert.field at oracle.com  Fri Nov 17 19:06:57 2017
From: robert.field at oracle.com (Robert Field)
Date: Fri, 17 Nov 2017 11:06:57 -0800
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
Message-ID: <6C0CD3C8-D6DD-4A37-97DE-F4EF2E1A2D7A@oracle.com>

JShell changes ?

The code change is fine.

The help change in the properties file is not consistent with the other items, note:        --help-extra, -X      Print help on?
      so this should be:      ?help, -h, -?
Or, if there is a tool-wide standard, then the ?help-extra entry should be changed.

The tests of ??help? should be updated to include the now documented ?-h? and ?-??

As Jon noted, the _ja and _zh_CN properties should not be touched.

-Robert

> On Nov 17, 2017, at 3:23 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi,
> 
> please review this change. I also filed a CSR for this:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> 
> See the webrev for a detailed description of the changes.
> 
> If required, I'll make break-out changes to be reviewed separately.
> 
> I had posted a RFR before, but improved the change to 
> give a more complete overview of currently supported flags
> for the CSR:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html
> 
> Best regards,
>  Goetz.
> 


From tomasz.kowalczewski at gmail.com  Fri Nov 17 20:47:43 2017
From: tomasz.kowalczewski at gmail.com (Tomasz Kowalczewski)
Date: Fri, 17 Nov 2017 21:47:43 +0100
Subject: AssertionError in c.s.t.jc.comp.Modules.enter(..)
In-Reply-To: <CA+pBWhsgjcqTJO5hyDWtwoCTP2Y8deYYnsM1_xiiYw=nqU4xYQ@mail.gmail.com>
References: <CA+pBWhsG0xyhVaDHY3DE-80Ft-pKZjooKhTb+62FW-8UWj7zfQ@mail.gmail.com>
 <584EA78E.3030207@oracle.com>
 <CA+pBWhsgjcqTJO5hyDWtwoCTP2Y8deYYnsM1_xiiYw=nqU4xYQ@mail.gmail.com>
Message-ID: <CANTKXY=_hend2yci-6_X-z3-9pz0YkjDJaddu3Zaf_62Tf_q6Q@mail.gmail.com>

Hi,

was this issue investigated or resolved? I am trying to upgrade our
application to Java 9 and encountered similar error why trying to compile
using Apache Maven 3.5.2, Java version: 9.0.1, maven-compiler-plugin
version 3.7.0.

xception in thread "main" java.lang.AssertionError
at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
at jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:250)
at
jdk.compiler/com.sun.tools.javac.main.JavaCompiler.readSourceFile(JavaCompiler.java:821)
at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$ImplicitCompleter.complete(JavacProcessingEnvironment.java:1510)
at jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:633)
at
jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1314)
at
jdk.compiler/com.sun.tools.javac.code.Type$ClassType.complete(Type.java:1139)
at
jdk.compiler/com.sun.tools.javac.code.Type$ClassType.getTypeArguments(Type.java:1065)
at
jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType(Printer.java:237)
at
jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType(Printer.java:52)
at
jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:992)
at jdk.compiler/com.sun.tools.javac.code.Printer.visit(Printer.java:136)
at
jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:197)
at
jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:165)
at
jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111)
at
jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67)
at
jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:183)
at
jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:165)
at
jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111)
at
jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67)
at
jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.getMessage(JCDiagnostic.java:771)
at
jdk.compiler/com.sun.tools.javac.api.ClientCodeWrapper$DiagnosticSourceUnwrapper.getMessage(ClientCodeWrapper.java:799)
at
org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:131)
at
org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:174)
at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1075)
at
org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:168)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

Regards,
Tomasz Kowalczewski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171117/b7a2152f/attachment.html>

From Alan.Bateman at oracle.com  Sat Nov 18 08:41:47 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 18 Nov 2017 08:41:47 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
Message-ID: <71c9130c-a8b6-c811-b14f-564b6f38574e@oracle.com>

On 17/11/2017 11:23, Lindenmaier, Goetz wrote:
> Hi,
>
> please review this change. I also filed a CSR for this:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
>
> See the webrev for a detailed description of the changes.
>
A question for Jon Gibbons: In JEP 293 the guideline is that tools 
should support `--help`. Do you think this should be expanded to include 
`-help`, and `-?` (and maybe `-h` where it make sense)?

As regards the webrev then the changes to the localized resources can be 
dropped. As Jon noted, we don't usually edit these directly as they are 
bulk updated/replaced by translation drops that usually happen late in 
each release.

It's not clear to me that it's wroth trying to update the JAXB, JAX-WS, 
and CORBA tools. One reason the corresponding tool modules are 
deprecated-for-removal and there is a draft JEP to remove them 
completely [1]. In addition, the JAXB ad JAX-WS tools are problematic to 
change as they are owned by upstream projects on the Java EE github - 
any changes to the code in these modules needs to coordinated to avoid 
having a fork here.

-Alan

[1] http://openjdk.java.net/jeps/8189188

From weijun.wang at oracle.com  Sun Nov 19 00:28:01 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sun, 19 Nov 2017 08:28:01 +0800
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
Message-ID: <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com>

I am OK with all commands supporting --help, but I am not sure if every tool should show it on the help screen if the tools's other options are still using the old single-"-" style. It looks like the tools are half-converted.

Is there a timetable to add "--" support to all tools?

Thanks
Max

> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi,
> 
> please review this change. I also filed a CSR for this:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> 
> See the webrev for a detailed description of the changes.
> 
> If required, I'll make break-out changes to be reviewed separately.
> 
> I had posted a RFR before, but improved the change to 
> give a more complete overview of currently supported flags
> for the CSR:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html
> 
> Best regards,
>  Goetz.
> 


From joe.darcy at oracle.com  Sun Nov 19 14:49:59 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Sun, 19 Nov 2017 06:49:59 -0800
Subject: JDK 10 RFR of JDK-8191162: Use @implSpec tag for
 javax.lang.model.util visitor methods
Message-ID: <899be237-80c3-aeab-9d4f-45c66a9b02d6@oracle.com>

Hello,

Please review the changes to address

     JDK-8191162: Use @implSpec tag for javax.lang.model.util visitor 
methods

     http://cr.openjdk.java.net/~darcy/8191162.1/
     http://cr.openjdk.java.net/~darcy/8191162.1-specdiff/

As the title of the bug implies, the change attempts to more 
systematically use @implSpec tags in the various concrete visitor 
methods to separate out required behavior for the method and its 
overrides vs the specified behavior for a particular method in a class.

Thanks,

-Joe


From joe.darcy at oracle.com  Sun Nov 19 15:50:18 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Sun, 19 Nov 2017 07:50:18 -0800
Subject: JDK 10 RFR of JDK-8191162: Use @implSpec tag for
 javax.lang.model.util visitor methods
In-Reply-To: <899be237-80c3-aeab-9d4f-45c66a9b02d6@oracle.com>
References: <899be237-80c3-aeab-9d4f-45c66a9b02d6@oracle.com>
Message-ID: <dc8b701b-fa9c-de13-7c74-bf666ac3165e@oracle.com>

PS And corresponding CSR for review as well:

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

Thanks,

-Joe


On 11/19/2017 6:49 AM, joe darcy wrote:
> Hello,
>
> Please review the changes to address
>
>     JDK-8191162: Use @implSpec tag for javax.lang.model.util visitor 
> methods
>
>     http://cr.openjdk.java.net/~darcy/8191162.1/
>     http://cr.openjdk.java.net/~darcy/8191162.1-specdiff/
>
> As the title of the bug implies, the change attempts to more 
> systematically use @implSpec tags in the various concrete visitor 
> methods to separate out required behavior for the method and its 
> overrides vs the specified behavior for a particular method in a class.
>
> Thanks,
>
> -Joe
>


From jonathan.gibbons at oracle.com  Sun Nov 19 18:12:17 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sun, 19 Nov 2017 10:12:17 -0800
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com>
Message-ID: <00717f78-f393-b406-da71-423c17acaf21@oracle.com>

We are already in a hybrid world of old-style and new-style options :-(

All the new module-related options added in JDK 9 are "new style", 
following the guidelines of JEP 293.

It does not make sense to add "--" to some of the older tools, that may 
be going away at some point, and while we may be able to add the ability 
for other tools to accept "--" options, we have to be careful about 
removing support for existing options.

-- Jon


On 11/18/17 4:28 PM, Weijun Wang wrote:
> I am OK with all commands supporting --help, but I am not sure if every tool should show it on the help screen if the tools's other options are still using the old single-"-" style. It looks like the tools are half-converted.
>
> Is there a timetable to add "--" support to all tools?
>
> Thanks
> Max
>
>> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
>>
>> Hi,
>>
>> please review this change. I also filed a CSR for this:
>> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
>>
>> See the webrev for a detailed description of the changes.
>>
>> If required, I'll make break-out changes to be reviewed separately.
>>
>> I had posted a RFR before, but improved the change to
>> give a more complete overview of currently supported flags
>> for the CSR:
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html
>>
>> Best regards,
>>   Goetz.
>>


From goetz.lindenmaier at sap.com  Mon Nov 20 11:21:57 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 20 Nov 2017 11:21:57 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <5A0F2AA0.8020906@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <5A0F2AA0.8020906@oracle.com>
Message-ID: <367811cf4e0248298c9125f5bdece730@sap.com>

Hi Jon, 

thanks for your feedback.

Sorry for getting the javac/Javadoc wrong, I missed that. 
The point is that the option implementation there does not have
the possibility to accept an option but not document it.

javac:
I'd like to propose to add -help again.  javac else prints:
  javac: invalid flag: -help
  Usage: javac <options> <source files>
  use --help for a list of possible options
Which isn't that nice.

Javadoc:
I'd prefer to remove -help because then it's not documented
which is more streamlined with the overall idea of this change. And Javadoc
behaves "friendly": Javadoc -help prints the usage but exits with 
return code '1'.  I don't think that's a major problem.

I'll update the CSR accordingly once we decide on this.

I'm happy not to edit the properties files :) I'll revert that.
(Although I would have liked to edit some of the German translations.)

I fixed the typos in the CSR.

Best regards,
  Goetz

Change to javac:

--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java	Tue Oct 10 14:39:45 2017 +0200
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java	Mon Nov 20 12:19:49 2017 +0100
@@ -360,7 +360,7 @@
     },
 
     // Note: -h is already taken for "native header output directory".
-    HELP("-? --help", "opt.help", STANDARD, INFO) {
+    HELP("-? --help -help", "opt.help", STANDARD, INFO) {
         @Override
         public void process(OptionHelper helper, String option) throws InvalidValueException {
             Log log = helper.getLog();






> -----Original Message-----
> From: Jonathan Gibbons [mailto:jonathan.gibbons at oracle.com]
> Sent: Freitag, 17. November 2017 19:30
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; core-libs-
> dev at openjdk.java.net; 'compiler-dev at openjdk.java.net' <compiler-
> dev at openjdk.java.net>; serviceability-dev (serviceability-
> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> Goetz,
> 
> I understand why you might want to ensure that a basic set of help options is
> supported,
> but I don't understand why that justifies removing older options, like "-help"
> for many tools.
> 
> In addition, I notice the CSR says:
> 
> 
> 
> 	Compatibility Risk Description:
> <https://bugs.openjdk.java.net/browse/JDK-8191477#> Only new flags are
> added, none removed.
> 
> 
> 
> But that is not true, since your edits for javac and javadoc remove the option
> completely.
> 
> Also, in the CSR, look for these typos:
>     serveral
>     deperecation
>     OpenJdk (should be OpenJDK)
> 
> 
> Also, I note that you've changed localized resource files. The usual procedure
> is to never
> touch those files, since they get updated later by Oracle's localization team.
> 
> -- Jon
> 
> 
> On 11/17/2017 03:23 AM, Lindenmaier, Goetz wrote:
> 
> 
> 	Hi,
> 
> 	please review this change. I also filed a CSR for this:
> 	http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.02/
> 	Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> 	CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> 
> 	See the webrev for a detailed description of the changes.
> 
> 	If required, I'll make break-out changes to be reviewed separately.
> 
> 	I had posted a RFR before, but improved the change to
> 	give a more complete overview of currently supported flags
> 	for the CSR:
> 	http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> October/028615.html
> 
> 	Best regards,
> 	  Goetz.
> 
> 


From goetz.lindenmaier at sap.com  Mon Nov 20 11:57:11 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 20 Nov 2017 11:57:11 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <6C0CD3C8-D6DD-4A37-97DE-F4EF2E1A2D7A@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <6C0CD3C8-D6DD-4A37-97DE-F4EF2E1A2D7A@oracle.com>
Message-ID: <5c565f49102c4d79b44d514a0227eb16@sap.com>


Hi Robert, 

thanks for looking at my change.

I'm fine with listing the flags in a different order, but 
it's ambiguous. Java itslef lists "-? -h --help" therefore
I chose this for most of the tools, too.
But just tell me how to put it.
Below, I list all the option help messages for the 
tools on linux. --help-extra is quite consistent.

Best regards,
  Goetz.
  
  
 --help-extra, -X             Print help on extra options
 --help-extra, -X
 --help-extra, -X      Print help on non-standard options and exit
 -X                   print help on extra options to the output stream
 --help-extra  print help on extra options to the output stream
 --help-extra                         Print help on extra options           
 --help-extra           Give help on extra options


-? -h --help               display this help message
-? -h --help              display this help message
-h, --help (Print this help message.)
-?, --help                   Print this help message
-? -h --help                 Print this help message
--help, -h, -?  Display command line options and exit
-? -h --help                     Print this help message
-h -? --help                  Print this help message
-? -h --help
-? -h --help          : display this help message and exit
-? -h --help       :  display this help message and exit
-? -h --help      print this help message and exit
-? | -h | --help     to print this help message
jmap -? -h --help  to print this help message
usage: jps [-? -h --help]
-? -h --help to print this help message
-? -h --help  Prints this help message.
-? -h --help print this help message
-? -h --help          Print this synopsis of standard options and exit
Use "keytool -? -h or --help" for all available commands
--help        print this help message to the output stream
-?, -h, --help                       Print this help message
-h, --help, -?                        Print this help message
-?, -h, --help                       Print this help message
-? -h --help         Print this help message and exit
-?, -h, --help                  print this help message
-?, -h, --help                print this help message
-? -h --help           Print this help message
-?, -h, --help[:compat]    Give this, or optionally the compatibility, help
[-? -h --help]              Print this help message
jstatd -?|-h|--help


> -----Original Message-----
> From: Robert Field [mailto:robert.field at oracle.com]
> Sent: Freitag, 17. November 2017 20:07
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
> dev at openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> JShell changes ?
> 
> The code change is fine.
> 
> The help change in the properties file is not consistent with the other items,
> note:        --help-extra, -X      Print help on?
>       so this should be:      ?help, -h, -?
> Or, if there is a tool-wide standard, then the ?help-extra entry should be
> changed.
> 
> The tests of ??help? should be updated to include the now documented ?-
> h? and ?-??
> 
> As Jon noted, the _ja and _zh_CN properties should not be touched.
> 
> -Robert
> 
> > On Nov 17, 2017, at 3:23 AM, Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> >
> > Hi,
> >
> > please review this change. I also filed a CSR for this:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.02/
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >
> > See the webrev for a detailed description of the changes.
> >
> > If required, I'll make break-out changes to be reviewed separately.
> >
> > I had posted a RFR before, but improved the change to
> > give a more complete overview of currently supported flags
> > for the CSR:
> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> October/028615.html
> >
> > Best regards,
> >  Goetz.
> >


From goetz.lindenmaier at sap.com  Mon Nov 20 13:41:33 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 20 Nov 2017 13:41:33 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <71c9130c-a8b6-c811-b14f-564b6f38574e@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <71c9130c-a8b6-c811-b14f-564b6f38574e@oracle.com>
Message-ID: <c8eb03f177ed4a5d90aa2c98c6168ef2@sap.com>

Hi Alan, 

thanks for looking at my change.

Thanks for pointing to JEP 293. I see my change mostly
follows its ideas.
As Jon, I don't think asking for support of -help makes sense
as it's not according to the gnu style, and it's not that
hard to get it right anyways.

I'll remove the edits to the properties files.

The deprecated tools are
  orbd, 
  wsgen
  wsimport
  schemagen
Is that correct?
I'll remove them from my change.  The test has a list of tools not to test, 
I'll add them there.

Best regards,
  Goetz.



> -----Original Message-----
> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
> Sent: Samstag, 18. November 2017 09:42
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; core-libs-
> dev at openjdk.java.net; 'compiler-dev at openjdk.java.net' <compiler-
> dev at openjdk.java.net>; serviceability-dev (serviceability-
> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> On 17/11/2017 11:23, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > please review this change. I also filed a CSR for this:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.02/
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >
> > See the webrev for a detailed description of the changes.
> >
> A question for Jon Gibbons: In JEP 293 the guideline is that tools
> should support `--help`. Do you think this should be expanded to include
> `-help`, and `-?` (and maybe `-h` where it make sense)?
> 
> As regards the webrev then the changes to the localized resources can be
> dropped. As Jon noted, we don't usually edit these directly as they are
> bulk updated/replaced by translation drops that usually happen late in
> each release.
> 
> It's not clear to me that it's wroth trying to update the JAXB, JAX-WS,
> and CORBA tools. One reason the corresponding tool modules are
> deprecated-for-removal and there is a draft JEP to remove them
> completely [1]. In addition, the JAXB ad JAX-WS tools are problematic to
> change as they are owned by upstream projects on the Java EE github -
> any changes to the code in these modules needs to coordinated to avoid
> having a fork here.
> 
> -Alan
> 
> [1] http://openjdk.java.net/jeps/8189188

From goetz.lindenmaier at sap.com  Mon Nov 20 13:46:49 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 20 Nov 2017 13:46:49 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com>
Message-ID: <f0be5806bf4442eeb5802df736210ead@sap.com>

Hi Max, 

I think there are so many tools mixing both kinds of
options, that it's rather a gain if all at least document
the same, up to date help message, than if the documentation 
is skipped for some.

After my change, all the help messages are quite similar.
I updated them to use the same wording while trying to
keep the sentence structure in accordance with the other
documented flags, see below.

Best regards,
  Goetz.


 
-? -h --help               display this help message
-? -h --help              display this help message
-h, --help (Print this help message.)
-?, --help                   Print this help message
-? -h --help                 Print this help message
--help, -h, -?  Display command line options and exit
-? -h --help                     Print this help message
-h -? --help                  Print this help message
-? -h --help
-? -h --help          : display this help message and exit
-? -h --help       :  display this help message and exit
-? -h --help      print this help message and exit
-? | -h | --help     to print this help message
jmap -? -h --help  to print this help message
usage: jps [-? -h --help]
-? -h --help to print this help message
-? -h --help  Prints this help message.
-? -h --help print this help message
-? -h --help          Print this synopsis of standard options and exit
Use "keytool -? -h or --help" for all available commands
--help        print this help message to the output stream
-?, -h, --help                       Print this help message
-h, --help, -?                        Print this help message
-?, -h, --help                       Print this help message
-? -h --help         Print this help message and exit
-?, -h, --help                  print this help message
-?, -h, --help                print this help message
-? -h --help           Print this help message
-?, -h, --help[:compat]    Give this, or optionally the compatibility, help
[-? -h --help]              Print this help message
jstatd -?|-h|--help


> -----Original Message-----
> From: Weijun Wang [mailto:weijun.wang at oracle.com]
> Sent: Sonntag, 19. November 2017 01:28
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
> dev at openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> I am OK with all commands supporting --help, but I am not sure if every tool
> should show it on the help screen if the tools's other options are still using
> the old single-"-" style. It looks like the tools are half-converted.
> 
> Is there a timetable to add "--" support to all tools?
> 
> Thanks
> Max
> 
> > On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> >
> > Hi,
> >
> > please review this change. I also filed a CSR for this:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.02/
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >
> > See the webrev for a detailed description of the changes.
> >
> > If required, I'll make break-out changes to be reviewed separately.
> >
> > I had posted a RFR before, but improved the change to
> > give a more complete overview of currently supported flags
> > for the CSR:
> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> October/028615.html
> >
> > Best regards,
> >  Goetz.
> >


From Alan.Bateman at oracle.com  Mon Nov 20 14:05:57 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 20 Nov 2017 14:05:57 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <c8eb03f177ed4a5d90aa2c98c6168ef2@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <71c9130c-a8b6-c811-b14f-564b6f38574e@oracle.com>
 <c8eb03f177ed4a5d90aa2c98c6168ef2@sap.com>
Message-ID: <191cb8f3-8c15-d98f-0650-516c1f5a51b6@oracle.com>

On 20/11/2017 13:41, Lindenmaier, Goetz wrote:
> :
>
> The deprecated tools are
>    orbd,
>    wsgen
>    wsimport
>    schemagen
> Is that correct?
>
Yes, plus xjc, idlj, servertool and tnameserv (the full list is in the 
draft JEP that I linked to).

-Alan

From weijun.wang at oracle.com  Mon Nov 20 14:48:37 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 20 Nov 2017 22:48:37 +0800
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <f0be5806bf4442eeb5802df736210ead@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com>
 <f0be5806bf4442eeb5802df736210ead@sap.com>
Message-ID: <C882395B-87CF-428B-A74D-707490930E07@oracle.com>

Hi Goetz

I understand your intention.

If the reason is that one day every tool will switch to this new style, please at least do not include kinit, klist and ktab. These Windows-only commands are meant to emulate MIT krb5 tools with the same names and we need to keep the option (and maybe the help screen) as similar as possible.

I am OK with supporting the --help option undocumented.

Thanks
Max

> On Nov 20, 2017, at 9:46 PM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi Max, 
> 
> I think there are so many tools mixing both kinds of
> options, that it's rather a gain if all at least document
> the same, up to date help message, than if the documentation 
> is skipped for some.
> 
> After my change, all the help messages are quite similar.
> I updated them to use the same wording while trying to
> keep the sentence structure in accordance with the other
> documented flags, see below.
> 
> Best regards,
>  Goetz.
> 
> 
> 
> -? -h --help               display this help message
> -? -h --help              display this help message
> -h, --help (Print this help message.)
> -?, --help                   Print this help message
> -? -h --help                 Print this help message
> --help, -h, -?  Display command line options and exit
> -? -h --help                     Print this help message
> -h -? --help                  Print this help message
> -? -h --help
> -? -h --help          : display this help message and exit
> -? -h --help       :  display this help message and exit
> -? -h --help      print this help message and exit
> -? | -h | --help     to print this help message
> jmap -? -h --help  to print this help message
> usage: jps [-? -h --help]
> -? -h --help to print this help message
> -? -h --help  Prints this help message.
> -? -h --help print this help message
> -? -h --help          Print this synopsis of standard options and exit
> Use "keytool -? -h or --help" for all available commands
> --help        print this help message to the output stream
> -?, -h, --help                       Print this help message
> -h, --help, -?                        Print this help message
> -?, -h, --help                       Print this help message
> -? -h --help         Print this help message and exit
> -?, -h, --help                  print this help message
> -?, -h, --help                print this help message
> -? -h --help           Print this help message
> -?, -h, --help[:compat]    Give this, or optionally the compatibility, help
> [-? -h --help]              Print this help message
> jstatd -?|-h|--help
> 
> 
>> -----Original Message-----
>> From: Weijun Wang [mailto:weijun.wang at oracle.com]
>> Sent: Sonntag, 19. November 2017 01:28
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
>> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
>> dev at openjdk.java.net>
>> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
>> 
>> I am OK with all commands supporting --help, but I am not sure if every tool
>> should show it on the help screen if the tools's other options are still using
>> the old single-"-" style. It looks like the tools are half-converted.
>> 
>> Is there a timetable to add "--" support to all tools?
>> 
>> Thanks
>> Max
>> 
>>> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz
>> <goetz.lindenmaier at sap.com> wrote:
>>> 
>>> Hi,
>>> 
>>> please review this change. I also filed a CSR for this:
>>> http://cr.openjdk.java.net/~goetz/wr17/8189102-
>> helpMessage/webrev.02/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
>>> 
>>> See the webrev for a detailed description of the changes.
>>> 
>>> If required, I'll make break-out changes to be reviewed separately.
>>> 
>>> I had posted a RFR before, but improved the change to
>>> give a more complete overview of currently supported flags
>>> for the CSR:
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
>> October/028615.html
>>> 
>>> Best regards,
>>> Goetz.
>>> 
> 


From paul.sandoz at oracle.com  Mon Nov 20 19:56:42 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 20 Nov 2017 11:56:42 -0800
Subject: Moving dynamic constants to 11 <was> Re: [10] RFR 8186046 Minimal
 ConstantDynamic support
In-Reply-To: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
Message-ID: <15A29A84-1420-4E69-A715-A68B2DF436AA@oracle.com>

Hi,

The schedule of dynamic constants has been adjusted, the JEP is currently proposed to target for 11.

There is risk to integrating a change such as constant dynamic this late in the 10 release schedule. Instead it's better, and more aligned with the new release process, to integrate early on into the main repository so it has time to bake.

I don?t anticipate there will be significant changes to the existing reviews in progress (code, CSRs, VM specification), so we can keep the momentum, integrate, then iterate.

Thanks,
Paul.

> On 26 Oct 2017, at 10:03, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
> 
> Hi,
> 
> Please review the following patch for minimal dynamic constant support:
> 
>  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/>
> 
>  https://bugs.openjdk.java.net/browse/JDK-8186046 <https://bugs.openjdk.java.net/browse/JDK-8186046>
>  https://bugs.openjdk.java.net/browse/JDK-8186209 <https://bugs.openjdk.java.net/browse/JDK-8186209>
> 
> This patch is based on the JDK 10 unified HotSpot repository. Testing so far looks good.
> 
> By minimal i mean just the support in the runtime for a dynamic constant pool entry to be referenced by a LDC instruction or a bootstrap method argument. Much of the work leverages the foundations built by invoke dynamic but is arguably simpler since resolution is less complex.
> 
> A small set of bootstrap methods will be proposed as a follow on issue for 10 (these are currently being refined in the amber repository).
> 
> Bootstrap method invocation has not changed (and the rules are the same for dynamic constants and indy). It is planned to enhance this in a further major release to support lazy resolution of bootstrap method arguments.
> 
> The CSR for the VM specification is here:
> 
>  https://bugs.openjdk.java.net/browse/JDK-8189199 <https://bugs.openjdk.java.net/browse/JDK-8189199>
> 
> the j.l.invoke package documentation was also updated but please consider the VM specification as the definitive "source of truth" (we may clean up this area further later on so it becomes more informative, and that may also apply to duplicative text on MethodHandles/VarHandles).
> 
> Any AoT-related work will be deferred to a future release.
> 
> ?
> 
> This patch only supports x64 platforms. There is a small set of changes specific to x64 (specifically to support null and primitives constants, as prior to this patch null was used as a sentinel for resolution and certain primitives types would never have been encountered, such as say byte).
> 
> We will need to follow up with the SPARC platform and it is hoped/anticipated that OpenJDK members responsible for other platforms (namely ARM and PPC) will separately provide patches.
> 
> ?
> 
> Many of tests rely on an experimental byte code API that supports the generation of byte code with dynamic constants.
> 
> One test uses class file bytes produced from a modified version of asmtools.  The modifications have now been pushed but a new version of asmtools need to be rolled into jtreg before the test can operate directly on asmtools information rather than embedding class file bytes directly in the test.
> 
> ?
> 
> Paul.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171120/7728480e/signature-0001.asc>

From mark.reinhold at oracle.com  Mon Nov 20 20:14:04 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 20 Nov 2017 12:14:04 -0800
Subject: Moving dynamic constants to 11 <was> Re: [10] RFR 8186046 Minimal
 ConstantDynamic support
In-Reply-To: <15A29A84-1420-4E69-A715-A68B2DF436AA@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <15A29A84-1420-4E69-A715-A68B2DF436AA@oracle.com>
Message-ID: <20171120121404.172170633@eggemoggin.niobe.net>

2017/11/20 11:56:42 -0800, paul.sandoz at oracle.com:
> The schedule of dynamic constants has been adjusted, the JEP is
> currently proposed to target for 11.
> 
> There is risk to integrating a change such as constant dynamic this
> late in the 10 release schedule. Instead it's better, and more aligned
> with the new release process, to integrate early on into the main
> repository so it has time to bake.

Thanks for the update.  It's too bad that JEP 309 won't make JDK 10,
but this sounds like the right decision.

- Mark

From vicente.romero at oracle.com  Tue Nov 21 04:10:17 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 20 Nov 2017 23:10:17 -0500
Subject: JDK 10 RFR of JDK-8191162: Use @implSpec tag for
 javax.lang.model.util visitor methods
In-Reply-To: <dc8b701b-fa9c-de13-7c74-bf666ac3165e@oracle.com>
References: <899be237-80c3-aeab-9d4f-45c66a9b02d6@oracle.com>
 <dc8b701b-fa9c-de13-7c74-bf666ac3165e@oracle.com>
Message-ID: <bfcafd68-9da7-6ffb-651b-af1c063cc60b@oracle.com>

Hi Joe,

I have reviewed the patch at 
http://cr.openjdk.java.net/~darcy/8191162.1/ and the CSR. Both look OK.

Thanks,
Vicente

On 11/19/2017 10:50 AM, joe darcy wrote:
> PS And corresponding CSR for review as well:
>
> ??? https://bugs.openjdk.java.net/browse/JDK-8191534
>
> Thanks,
>
> -Joe
>
>
> On 11/19/2017 6:49 AM, joe darcy wrote:
>> Hello,
>>
>> Please review the changes to address
>>
>> ??? JDK-8191162: Use @implSpec tag for javax.lang.model.util visitor 
>> methods
>>
>> ??? http://cr.openjdk.java.net/~darcy/8191162.1/
>> ??? http://cr.openjdk.java.net/~darcy/8191162.1-specdiff/
>>
>> As the title of the bug implies, the change attempts to more 
>> systematically use @implSpec tags in the various concrete visitor 
>> methods to separate out required behavior for the method and its 
>> overrides vs the specified behavior for a particular method in a class.
>>
>> Thanks,
>>
>> -Joe
>>
>


From joe.darcy at oracle.com  Tue Nov 21 06:34:32 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 20 Nov 2017 22:34:32 -0800
Subject: JDK 10 RFR of 8191234: TypeKindVisitor needs to handle modules,
Message-ID: <4ff2c6b3-b19f-eb87-4757-2e3663212d75@oracle.com>

Hello,

Please review the patch below and CSR for

     8191234: TypeKindVisitor needs to handle modules
     CSR: https://bugs.openjdk.java.net/browse/JDK-8191642

The module-related javax.lang.model updates in JDK 9 overlooked adding 
module support to the TypeKind family of visitors.

The treatment of TypeKind.MODULE is analogous to the how support for 
ElementKind.RESOURCE_VARIABLE was added in JDK 7 to the ElementKind 
visitors.

For now treating this fix was noreg-trivial, but I'll concede test are 
appropriate and write a few if reviewers think they are needed.

Thanks,

-Joe

diff -r 5cc5b8270cad 
src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor6.java
--- 
a/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor6.java 
Mon Nov 20 20:33:51 2017 -0800
+++ 
b/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor6.java 
Mon Nov 20 22:06:30 2017 -0800
@@ -257,7 +257,7 @@
       *
       * @implSpec This implementation dispatches to the visit method for
       * the specific {@linkplain TypeKind kind} of pseudo-type:
-     * {@code VOID}, {@code PACKAGE}, or {@code NONE}.
+     * {@code VOID}, {@code PACKAGE}, {@code MODULE}, or {@code NONE}.
       *
       * @param t {@inheritDoc}
       * @param p {@inheritDoc}
@@ -273,6 +273,9 @@
          case PACKAGE:
              return visitNoTypeAsPackage(t, p);

+        case MODULE:
+            return visitNoTypeAsModule(t, p);
+
          case NONE:
              return visitNoTypeAsNone(t, p);

@@ -308,6 +311,21 @@
      }

      /**
+     * Visits a {@link TypeKind#MODULE MODULE} pseudo-type.
+     *
+     * @implSpec This implementation calls {@code visitUnknown}.
+     *
+     * @param t the type to visit
+     * @param p a visitor-specified parameter
+     * @return  the result of {@code visitUnknown}
+     *
+     * @since 10
+     */
+    public R visitNoTypeAsModule(NoType t, P p) {
+        return visitUnknown(t, p);
+    }
+
+    /**
       * Visits a {@link TypeKind#NONE NONE} pseudo-type.
       *
       * @implSpec This implementation calls {@code defaultAction}.
diff -r 5cc5b8270cad 
src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java
--- 
a/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java 
Mon Nov 20 20:33:51 2017 -0800
+++ 
b/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java 
Mon Nov 20 22:06:30 2017 -0800
@@ -93,4 +93,20 @@
      protected TypeKindVisitor9(R defaultValue) {
          super(defaultValue);
      }
+
+    /**
+     * {@inheritDoc}
+     *
+     * @implSpec This implementation calls {@code defaultAction}.
+     *
+     * @param t {@inheritDoc}
+     * @param p {@inheritDoc}
+     * @return  the result of {@code defaultAction}
+     *
+     * @since 10
+     */
+    @Override
+    public R visitNoTypeAsModule(NoType t, P p) {
+        return defaultAction(t, p);
+    }
  }


From jonathan.gibbons at oracle.com  Tue Nov 21 19:35:28 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 21 Nov 2017 11:35:28 -0800
Subject: RFR: 8156694 javap should render annotations in a friendly way
Message-ID: <5A148000.5030207@oracle.com>

Please review a relatively simple fix for javap to write disassembled 
annotations in a reasonably
friendly form, resolving constant pool indices.

Alternate layouts were attempted, including a more javap-traditional way 
of left-right side-by-side printing,
but the difficulty of handling potentially complex annotations made this 
more trouble than it was worth.
So for now, it's a simple, easy layout, as illustrated in the new test. 
One other test was affected by the new
information, and has been updated appropriately.

-- Jon

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



From maurizio.cimadamore at oracle.com  Tue Nov 21 20:44:38 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 21 Nov 2017 20:44:38 +0000
Subject: RFR: 8156694 javap should render annotations in a friendly way
In-Reply-To: <5A148000.5030207@oracle.com>
References: <5A148000.5030207@oracle.com>
Message-ID: <d18bf8eb-9227-1508-308b-51300844c67e@oracle.com>

Looks great! Will really help for panama development ;-)

Thanks
Maurizio


On 21/11/17 19:35, Jonathan Gibbons wrote:
> Please review a relatively simple fix for javap to write disassembled 
> annotations in a reasonably
> friendly form, resolving constant pool indices.
>
> Alternate layouts were attempted, including a more javap-traditional 
> way of left-right side-by-side printing,
> but the difficulty of handling potentially complex annotations made 
> this more trouble than it was worth.
> So for now, it's a simple, easy layout, as illustrated in the new 
> test. One other test was affected by the new
> information, and has been updated appropriately.
>
> -- Jon
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8156694
> Webrev: http://cr.openjdk.java.net/~jjg/8156694/webrev.00/index.html
>
>


From sundararajan.athijegannathan at oracle.com  Wed Nov 22 02:31:05 2017
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 22 Nov 2017 08:01:05 +0530
Subject: RFR: 8156694 javap should render annotations in a friendly way
In-Reply-To: <d18bf8eb-9227-1508-308b-51300844c67e@oracle.com>
References: <5A148000.5030207@oracle.com>
 <d18bf8eb-9227-1508-308b-51300844c67e@oracle.com>
Message-ID: <5A14E169.8050406@oracle.com>

+1

PS. new test source has (c) 2014, 2016.

-Sundar

On 22/11/17, 2:14 AM, Maurizio Cimadamore wrote:
> Looks great! Will really help for panama development ;-)
>
> Thanks
> Maurizio
>
>
> On 21/11/17 19:35, Jonathan Gibbons wrote:
>> Please review a relatively simple fix for javap to write disassembled 
>> annotations in a reasonably
>> friendly form, resolving constant pool indices.
>>
>> Alternate layouts were attempted, including a more javap-traditional 
>> way of left-right side-by-side printing,
>> but the difficulty of handling potentially complex annotations made 
>> this more trouble than it was worth.
>> So for now, it's a simple, easy layout, as illustrated in the new 
>> test. One other test was affected by the new
>> information, and has been updated appropriately.
>>
>> -- Jon
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8156694
>> Webrev: http://cr.openjdk.java.net/~jjg/8156694/webrev.00/index.html
>>
>>
>

From goetz.lindenmaier at sap.com  Wed Nov 22 06:53:18 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 22 Nov 2017 06:53:18 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <C882395B-87CF-428B-A74D-707490930E07@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com>
 <f0be5806bf4442eeb5802df736210ead@sap.com>
 <C882395B-87CF-428B-A74D-707490930E07@oracle.com>
Message-ID: <ff1b4c1650cd48f28fa8d1cd38f18579@sap.com>

Hi Max, 

while removing the comments from the k-tools, I saw this:

--- a/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java	Tue Oct 10 14:39:45 2017 +0200
+++ b/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java	Tue Nov 21 13:09:17 2017 +0100
@@ -356,7 +358,6 @@
         System.out.println("\t-t \t shows keytab entry timestamps");
         System.out.println("\t-K \t shows keytab entry key value");
         System.out.println("\t-e \t shows keytab entry key type");
-        System.out.println("\nUsage: java sun.security.krb5.tools.Klist " +
-                           "-help for help.");
+        System.out.println("\n-? -h --help print this help message and exit");
     }
 }

I don't think the old comment is in the original program :) and anyways, -help
is not supported by Klist.  It prints the usage called with the flag, but just because
it prints it on any wrong flag.

So should I replace the comment here?
Or at least remove it?

Best regards,
  Goetz

> -----Original Message-----
> From: Weijun Wang [mailto:weijun.wang at oracle.com]
> Sent: Monday, November 20, 2017 3:49 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
> dev at openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> Hi Goetz
> 
> I understand your intention.
> 
> If the reason is that one day every tool will switch to this new style, please at
> least do not include kinit, klist and ktab. These Windows-only commands are
> meant to emulate MIT krb5 tools with the same names and we need to keep
> the option (and maybe the help screen) as similar as possible.
> 
> I am OK with supporting the --help option undocumented.
> 
> Thanks
> Max
> 
> > On Nov 20, 2017, at 9:46 PM, Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> >
> > Hi Max,
> >
> > I think there are so many tools mixing both kinds of
> > options, that it's rather a gain if all at least document
> > the same, up to date help message, than if the documentation
> > is skipped for some.
> >
> > After my change, all the help messages are quite similar.
> > I updated them to use the same wording while trying to
> > keep the sentence structure in accordance with the other
> > documented flags, see below.
> >
> > Best regards,
> >  Goetz.
> >
> >
> >
> > -? -h --help               display this help message
> > -? -h --help              display this help message
> > -h, --help (Print this help message.)
> > -?, --help                   Print this help message
> > -? -h --help                 Print this help message
> > --help, -h, -?  Display command line options and exit
> > -? -h --help                     Print this help message
> > -h -? --help                  Print this help message
> > -? -h --help
> > -? -h --help          : display this help message and exit
> > -? -h --help       :  display this help message and exit
> > -? -h --help      print this help message and exit
> > -? | -h | --help     to print this help message
> > jmap -? -h --help  to print this help message
> > usage: jps [-? -h --help]
> > -? -h --help to print this help message
> > -? -h --help  Prints this help message.
> > -? -h --help print this help message
> > -? -h --help          Print this synopsis of standard options and exit
> > Use "keytool -? -h or --help" for all available commands
> > --help        print this help message to the output stream
> > -?, -h, --help                       Print this help message
> > -h, --help, -?                        Print this help message
> > -?, -h, --help                       Print this help message
> > -? -h --help         Print this help message and exit
> > -?, -h, --help                  print this help message
> > -?, -h, --help                print this help message
> > -? -h --help           Print this help message
> > -?, -h, --help[:compat]    Give this, or optionally the compatibility, help
> > [-? -h --help]              Print this help message
> > jstatd -?|-h|--help
> >
> >
> >> -----Original Message-----
> >> From: Weijun Wang [mailto:weijun.wang at oracle.com]
> >> Sent: Sonntag, 19. November 2017 01:28
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
> >> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
> >> dev at openjdk.java.net>
> >> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> >>
> >> I am OK with all commands supporting --help, but I am not sure if every
> tool
> >> should show it on the help screen if the tools's other options are still using
> >> the old single-"-" style. It looks like the tools are half-converted.
> >>
> >> Is there a timetable to add "--" support to all tools?
> >>
> >> Thanks
> >> Max
> >>
> >>> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz
> >> <goetz.lindenmaier at sap.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> please review this change. I also filed a CSR for this:
> >>> http://cr.openjdk.java.net/~goetz/wr17/8189102-
> >> helpMessage/webrev.02/
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >>>
> >>> See the webrev for a detailed description of the changes.
> >>>
> >>> If required, I'll make break-out changes to be reviewed separately.
> >>>
> >>> I had posted a RFR before, but improved the change to
> >>> give a more complete overview of currently supported flags
> >>> for the CSR:
> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> >> October/028615.html
> >>>
> >>> Best regards,
> >>> Goetz.
> >>>
> >


From weijun.wang at oracle.com  Wed Nov 22 07:07:51 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 22 Nov 2017 15:07:51 +0800
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <ff1b4c1650cd48f28fa8d1cd38f18579@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com>
 <f0be5806bf4442eeb5802df736210ead@sap.com>
 <C882395B-87CF-428B-A74D-707490930E07@oracle.com>
 <ff1b4c1650cd48f28fa8d1cd38f18579@sap.com>
Message-ID: <5143F580-CDB0-4970-AC7A-038608E59FAA@oracle.com>

Hi Goetz

I would just remove it.

Thanks
Max

> On Nov 22, 2017, at 2:53 PM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi Max, 
> 
> while removing the comments from the k-tools, I saw this:
> 
> --- a/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java	Tue Oct 10 14:39:45 2017 +0200
> +++ b/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java	Tue Nov 21 13:09:17 2017 +0100
> @@ -356,7 +358,6 @@
>         System.out.println("\t-t \t shows keytab entry timestamps");
>         System.out.println("\t-K \t shows keytab entry key value");
>         System.out.println("\t-e \t shows keytab entry key type");
> -        System.out.println("\nUsage: java sun.security.krb5.tools.Klist " +
> -                           "-help for help.");
> +        System.out.println("\n-? -h --help print this help message and exit");
>     }
> }
> 
> I don't think the old comment is in the original program :) and anyways, -help
> is not supported by Klist.  It prints the usage called with the flag, but just because
> it prints it on any wrong flag.
> 
> So should I replace the comment here?
> Or at least remove it?
> 
> Best regards,
>  Goetz
> 
>> -----Original Message-----
>> From: Weijun Wang [mailto:weijun.wang at oracle.com]
>> Sent: Monday, November 20, 2017 3:49 PM
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
>> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
>> dev at openjdk.java.net>
>> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
>> 
>> Hi Goetz
>> 
>> I understand your intention.
>> 
>> If the reason is that one day every tool will switch to this new style, please at
>> least do not include kinit, klist and ktab. These Windows-only commands are
>> meant to emulate MIT krb5 tools with the same names and we need to keep
>> the option (and maybe the help screen) as similar as possible.
>> 
>> I am OK with supporting the --help option undocumented.
>> 
>> Thanks
>> Max
>> 
>>> On Nov 20, 2017, at 9:46 PM, Lindenmaier, Goetz
>> <goetz.lindenmaier at sap.com> wrote:
>>> 
>>> Hi Max,
>>> 
>>> I think there are so many tools mixing both kinds of
>>> options, that it's rather a gain if all at least document
>>> the same, up to date help message, than if the documentation
>>> is skipped for some.
>>> 
>>> After my change, all the help messages are quite similar.
>>> I updated them to use the same wording while trying to
>>> keep the sentence structure in accordance with the other
>>> documented flags, see below.
>>> 
>>> Best regards,
>>> Goetz.
>>> 
>>> 
>>> 
>>> -? -h --help               display this help message
>>> -? -h --help              display this help message
>>> -h, --help (Print this help message.)
>>> -?, --help                   Print this help message
>>> -? -h --help                 Print this help message
>>> --help, -h, -?  Display command line options and exit
>>> -? -h --help                     Print this help message
>>> -h -? --help                  Print this help message
>>> -? -h --help
>>> -? -h --help          : display this help message and exit
>>> -? -h --help       :  display this help message and exit
>>> -? -h --help      print this help message and exit
>>> -? | -h | --help     to print this help message
>>> jmap -? -h --help  to print this help message
>>> usage: jps [-? -h --help]
>>> -? -h --help to print this help message
>>> -? -h --help  Prints this help message.
>>> -? -h --help print this help message
>>> -? -h --help          Print this synopsis of standard options and exit
>>> Use "keytool -? -h or --help" for all available commands
>>> --help        print this help message to the output stream
>>> -?, -h, --help                       Print this help message
>>> -h, --help, -?                        Print this help message
>>> -?, -h, --help                       Print this help message
>>> -? -h --help         Print this help message and exit
>>> -?, -h, --help                  print this help message
>>> -?, -h, --help                print this help message
>>> -? -h --help           Print this help message
>>> -?, -h, --help[:compat]    Give this, or optionally the compatibility, help
>>> [-? -h --help]              Print this help message
>>> jstatd -?|-h|--help
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Weijun Wang [mailto:weijun.wang at oracle.com]
>>>> Sent: Sonntag, 19. November 2017 01:28
>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
>>>> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
>>>> dev at openjdk.java.net>
>>>> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
>>>> 
>>>> I am OK with all commands supporting --help, but I am not sure if every
>> tool
>>>> should show it on the help screen if the tools's other options are still using
>>>> the old single-"-" style. It looks like the tools are half-converted.
>>>> 
>>>> Is there a timetable to add "--" support to all tools?
>>>> 
>>>> Thanks
>>>> Max
>>>> 
>>>>> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz
>>>> <goetz.lindenmaier at sap.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> please review this change. I also filed a CSR for this:
>>>>> http://cr.openjdk.java.net/~goetz/wr17/8189102-
>>>> helpMessage/webrev.02/
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
>>>>> 
>>>>> See the webrev for a detailed description of the changes.
>>>>> 
>>>>> If required, I'll make break-out changes to be reviewed separately.
>>>>> 
>>>>> I had posted a RFR before, but improved the change to
>>>>> give a more complete overview of currently supported flags
>>>>> for the CSR:
>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
>>>> October/028615.html
>>>>> 
>>>>> Best regards,
>>>>> Goetz.
>>>>> 
>>> 
> 


From goetz.lindenmaier at sap.com  Wed Nov 22 07:13:39 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 22 Nov 2017 07:13:39 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <5143F580-CDB0-4970-AC7A-038608E59FAA@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com>
 <f0be5806bf4442eeb5802df736210ead@sap.com>
 <C882395B-87CF-428B-A74D-707490930E07@oracle.com>
 <ff1b4c1650cd48f28fa8d1cd38f18579@sap.com>
 <5143F580-CDB0-4970-AC7A-038608E59FAA@oracle.com>
Message-ID: <8f6273ffa9cc4b119f0004052f29c711@sap.com>

OK, thanks!

Best regards,
  Goetz.

> -----Original Message-----
> From: Weijun Wang [mailto:weijun.wang at oracle.com]
> Sent: Wednesday, November 22, 2017 8:08 AM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
> dev at openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> Hi Goetz
> 
> I would just remove it.
> 
> Thanks
> Max
> 
> > On Nov 22, 2017, at 2:53 PM, Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> >
> > Hi Max,
> >
> > while removing the comments from the k-tools, I saw this:
> >
> > ---
> a/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Kl
> ist.java	Tue Oct 10 14:39:45 2017 +0200
> > +++
> b/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Kl
> ist.java	Tue Nov 21 13:09:17 2017 +0100
> > @@ -356,7 +358,6 @@
> >         System.out.println("\t-t \t shows keytab entry timestamps");
> >         System.out.println("\t-K \t shows keytab entry key value");
> >         System.out.println("\t-e \t shows keytab entry key type");
> > -        System.out.println("\nUsage: java sun.security.krb5.tools.Klist " +
> > -                           "-help for help.");
> > +        System.out.println("\n-? -h --help print this help message and exit");
> >     }
> > }
> >
> > I don't think the old comment is in the original program :) and anyways, -
> help
> > is not supported by Klist.  It prints the usage called with the flag, but just
> because
> > it prints it on any wrong flag.
> >
> > So should I replace the comment here?
> > Or at least remove it?
> >
> > Best regards,
> >  Goetz
> >
> >> -----Original Message-----
> >> From: Weijun Wang [mailto:weijun.wang at oracle.com]
> >> Sent: Monday, November 20, 2017 3:49 PM
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
> >> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
> >> dev at openjdk.java.net>
> >> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> >>
> >> Hi Goetz
> >>
> >> I understand your intention.
> >>
> >> If the reason is that one day every tool will switch to this new style, please
> at
> >> least do not include kinit, klist and ktab. These Windows-only commands
> are
> >> meant to emulate MIT krb5 tools with the same names and we need to
> keep
> >> the option (and maybe the help screen) as similar as possible.
> >>
> >> I am OK with supporting the --help option undocumented.
> >>
> >> Thanks
> >> Max
> >>
> >>> On Nov 20, 2017, at 9:46 PM, Lindenmaier, Goetz
> >> <goetz.lindenmaier at sap.com> wrote:
> >>>
> >>> Hi Max,
> >>>
> >>> I think there are so many tools mixing both kinds of
> >>> options, that it's rather a gain if all at least document
> >>> the same, up to date help message, than if the documentation
> >>> is skipped for some.
> >>>
> >>> After my change, all the help messages are quite similar.
> >>> I updated them to use the same wording while trying to
> >>> keep the sentence structure in accordance with the other
> >>> documented flags, see below.
> >>>
> >>> Best regards,
> >>> Goetz.
> >>>
> >>>
> >>>
> >>> -? -h --help               display this help message
> >>> -? -h --help              display this help message
> >>> -h, --help (Print this help message.)
> >>> -?, --help                   Print this help message
> >>> -? -h --help                 Print this help message
> >>> --help, -h, -?  Display command line options and exit
> >>> -? -h --help                     Print this help message
> >>> -h -? --help                  Print this help message
> >>> -? -h --help
> >>> -? -h --help          : display this help message and exit
> >>> -? -h --help       :  display this help message and exit
> >>> -? -h --help      print this help message and exit
> >>> -? | -h | --help     to print this help message
> >>> jmap -? -h --help  to print this help message
> >>> usage: jps [-? -h --help]
> >>> -? -h --help to print this help message
> >>> -? -h --help  Prints this help message.
> >>> -? -h --help print this help message
> >>> -? -h --help          Print this synopsis of standard options and exit
> >>> Use "keytool -? -h or --help" for all available commands
> >>> --help        print this help message to the output stream
> >>> -?, -h, --help                       Print this help message
> >>> -h, --help, -?                        Print this help message
> >>> -?, -h, --help                       Print this help message
> >>> -? -h --help         Print this help message and exit
> >>> -?, -h, --help                  print this help message
> >>> -?, -h, --help                print this help message
> >>> -? -h --help           Print this help message
> >>> -?, -h, --help[:compat]    Give this, or optionally the compatibility, help
> >>> [-? -h --help]              Print this help message
> >>> jstatd -?|-h|--help
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Weijun Wang [mailto:weijun.wang at oracle.com]
> >>>> Sent: Sonntag, 19. November 2017 01:28
> >>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >>>> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
> >>>> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
> >>>> dev at openjdk.java.net>
> >>>> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> >>>>
> >>>> I am OK with all commands supporting --help, but I am not sure if every
> >> tool
> >>>> should show it on the help screen if the tools's other options are still
> using
> >>>> the old single-"-" style. It looks like the tools are half-converted.
> >>>>
> >>>> Is there a timetable to add "--" support to all tools?
> >>>>
> >>>> Thanks
> >>>> Max
> >>>>
> >>>>> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz
> >>>> <goetz.lindenmaier at sap.com> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> please review this change. I also filed a CSR for this:
> >>>>> http://cr.openjdk.java.net/~goetz/wr17/8189102-
> >>>> helpMessage/webrev.02/
> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >>>>>
> >>>>> See the webrev for a detailed description of the changes.
> >>>>>
> >>>>> If required, I'll make break-out changes to be reviewed separately.
> >>>>>
> >>>>> I had posted a RFR before, but improved the change to
> >>>>> give a more complete overview of currently supported flags
> >>>>> for the CSR:
> >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> >>>> October/028615.html
> >>>>>
> >>>>> Best regards,
> >>>>> Goetz.
> >>>>>
> >>>
> >


From goetz.lindenmaier at sap.com  Wed Nov 22 17:28:09 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 22 Nov 2017 17:28:09 +0000
Subject: 8189102: All tools should support -?, -h and --help
In-Reply-To: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
Message-ID: <2ab914b725d54100bb5c99c1537da1df@sap.com>

Hi,

I prepared a new webrev trying to incorporate all change requests:
 * I removed changes to non-english property files.
 * I removed help texts from ktab, kinit, klist
 * I removed changes to corba tools
 * I added test cases for new flags to tool specific tests (to the ones I spotted)
 * I added -help back to javac
I left the removal of -help from Javadoc, as Javadoc just prints the help message
anyways. 

New webrev:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/index.html

I uploaded the parts of the patch I removed within the webrev:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/help_in_property_files.patch
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/KinitKtabKlist_help_message.patch
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/corba_help_message.patch

Best regards,
  Goetz.


> -----Original Message-----
> From: serviceability-dev [mailto:serviceability-dev-
> bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
> Sent: Friday, November 17, 2017 12:23 PM
> To: core-libs-dev at openjdk.java.net; 'compiler-dev at openjdk.java.net'
> <compiler-dev at openjdk.java.net>; serviceability-dev (serviceability-
> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> Subject: RFR: 8189102: All tools should support -?, -h and --help
> 
> Hi,
> 
> please review this change. I also filed a CSR for this:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> 
> See the webrev for a detailed description of the changes.
> 
> If required, I'll make break-out changes to be reviewed separately.
> 
> I had posted a RFR before, but improved the change to
> give a more complete overview of currently supported flags
> for the CSR:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> October/028615.html
> 
> Best regards,
>   Goetz.


From joe.darcy at oracle.com  Wed Nov 22 18:37:18 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 22 Nov 2017 10:37:18 -0800
Subject: JDK 10 RFR of 8191234: TypeKindVisitor needs to handle modules,
In-Reply-To: <4ff2c6b3-b19f-eb87-4757-2e3663212d75@oracle.com>
References: <4ff2c6b3-b19f-eb87-4757-2e3663212d75@oracle.com>
Message-ID: <65e95c8e-4e2b-9754-20b1-9b4eb82c919a@oracle.com>

Webrev now with a regression test:

     http://cr.openjdk.java.net/~darcy/8191234.1/

Thanks,

-Joe

On 11/20/2017 10:34 PM, joe darcy wrote:
> Hello,
>
> Please review the patch below and CSR for
>
>     8191234: TypeKindVisitor needs to handle modules
>     CSR: https://bugs.openjdk.java.net/browse/JDK-8191642
>
> The module-related javax.lang.model updates in JDK 9 overlooked adding 
> module support to the TypeKind family of visitors.
>
> The treatment of TypeKind.MODULE is analogous to the how support for 
> ElementKind.RESOURCE_VARIABLE was added in JDK 7 to the ElementKind 
> visitors.
>
> For now treating this fix was noreg-trivial, but I'll concede test are 
> appropriate and write a few if reviewers think they are needed.
>
> Thanks,
>
> -Joe
>
> diff -r 5cc5b8270cad 
> src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor6.java
> --- 
> a/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor6.java 
> Mon Nov 20 20:33:51 2017 -0800
> +++ 
> b/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor6.java 
> Mon Nov 20 22:06:30 2017 -0800
> @@ -257,7 +257,7 @@
>       *
>       * @implSpec This implementation dispatches to the visit method for
>       * the specific {@linkplain TypeKind kind} of pseudo-type:
> -     * {@code VOID}, {@code PACKAGE}, or {@code NONE}.
> +     * {@code VOID}, {@code PACKAGE}, {@code MODULE}, or {@code NONE}.
>       *
>       * @param t {@inheritDoc}
>       * @param p {@inheritDoc}
> @@ -273,6 +273,9 @@
>          case PACKAGE:
>              return visitNoTypeAsPackage(t, p);
>
> +        case MODULE:
> +            return visitNoTypeAsModule(t, p);
> +
>          case NONE:
>              return visitNoTypeAsNone(t, p);
>
> @@ -308,6 +311,21 @@
>      }
>
>      /**
> +     * Visits a {@link TypeKind#MODULE MODULE} pseudo-type.
> +     *
> +     * @implSpec This implementation calls {@code visitUnknown}.
> +     *
> +     * @param t the type to visit
> +     * @param p a visitor-specified parameter
> +     * @return  the result of {@code visitUnknown}
> +     *
> +     * @since 10
> +     */
> +    public R visitNoTypeAsModule(NoType t, P p) {
> +        return visitUnknown(t, p);
> +    }
> +
> +    /**
>       * Visits a {@link TypeKind#NONE NONE} pseudo-type.
>       *
>       * @implSpec This implementation calls {@code defaultAction}.
> diff -r 5cc5b8270cad 
> src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java
> --- 
> a/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java 
> Mon Nov 20 20:33:51 2017 -0800
> +++ 
> b/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java 
> Mon Nov 20 22:06:30 2017 -0800
> @@ -93,4 +93,20 @@
>      protected TypeKindVisitor9(R defaultValue) {
>          super(defaultValue);
>      }
> +
> +    /**
> +     * {@inheritDoc}
> +     *
> +     * @implSpec This implementation calls {@code defaultAction}.
> +     *
> +     * @param t {@inheritDoc}
> +     * @param p {@inheritDoc}
> +     * @return  the result of {@code defaultAction}
> +     *
> +     * @since 10
> +     */
> +    @Override
> +    public R visitNoTypeAsModule(NoType t, P p) {
> +        return defaultAction(t, p);
> +    }
>  }
>


From robert.field at oracle.com  Wed Nov 22 19:20:02 2017
From: robert.field at oracle.com (Robert Field)
Date: Wed, 22 Nov 2017 11:20:02 -0800
Subject: 8189102: All tools should support -?, -h and --help
In-Reply-To: <2ab914b725d54100bb5c99c1537da1df@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <2ab914b725d54100bb5c99c1537da1df@sap.com>
Message-ID: <5A15CDE2.7010003@oracle.com>

Per jshell tool --

Thanks for adding to the test.

As to the option formatting:

  219 \    -? -h --help          Print this synopsis of standard options and exit\n\
  220 \    --help-extra, -X      Print help on non-standard options and exit\n\

The number one priority is that it is consistent: comma vs space, --option first vs last.

The number two priority is best readability.  These options are surrounded by --options, so that first seems best to me.
The comma seems clearer to me, and is used in a good percentage of the tools you listed.

So, my preference is:

  219 \    --help,-?, -h        Print this synopsis of standard options and exit\n\
  220 \    --help-extra, -X      Print help on non-standard options and exit\n\

Thanks,
Robert


On 11/22/17 09:28, Lindenmaier, Goetz wrote:
> Hi,
>
> I prepared a new webrev trying to incorporate all change requests:
>   * I removed changes to non-english property files.
>   * I removed help texts from ktab, kinit, klist
>   * I removed changes to corba tools
>   * I added test cases for new flags to tool specific tests (to the ones I spotted)
>   * I added -help back to javac
> I left the removal of -help from Javadoc, as Javadoc just prints the help message
> anyways.
>
> New webrev:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/index.html
>
> I uploaded the parts of the patch I removed within the webrev:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/help_in_property_files.patch
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/KinitKtabKlist_help_message.patch
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/corba_help_message.patch
>
> Best regards,
>    Goetz.
>
>
>> -----Original Message-----
>> From: serviceability-dev [mailto:serviceability-dev-
>> bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
>> Sent: Friday, November 17, 2017 12:23 PM
>> To: core-libs-dev at openjdk.java.net; 'compiler-dev at openjdk.java.net'
>> <compiler-dev at openjdk.java.net>; serviceability-dev (serviceability-
>> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
>> Subject: RFR: 8189102: All tools should support -?, -h and --help
>>
>> Hi,
>>
>> please review this change. I also filed a CSR for this:
>> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
>>
>> See the webrev for a detailed description of the changes.
>>
>> If required, I'll make break-out changes to be reviewed separately.
>>
>> I had posted a RFR before, but improved the change to
>> give a more complete overview of currently supported flags
>> for the CSR:
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
>> October/028615.html
>>
>> Best regards,
>>    Goetz.


From jonathan.gibbons at oracle.com  Wed Nov 22 19:42:33 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 22 Nov 2017 11:42:33 -0800
Subject: JDK 10 RFR of 8191234: TypeKindVisitor needs to handle modules,
In-Reply-To: <65e95c8e-4e2b-9754-20b1-9b4eb82c919a@oracle.com>
References: <4ff2c6b3-b19f-eb87-4757-2e3663212d75@oracle.com>
 <65e95c8e-4e2b-9754-20b1-9b4eb82c919a@oracle.com>
Message-ID: <5A15D329.10306@oracle.com>

Question ...

In TypeKindVisitor6, visitNoTypeAsModule, you specify that the return 
value is the result of visitUnknown.  That is not true of the override 
in TypeKindVisitor9.  That raises the question:  are @param and @return 
specs conceptually part of the API-spec, or part of the implSpec?

-- Jon



On 11/22/2017 10:37 AM, joe darcy wrote:
> Webrev now with a regression test:
>
>     http://cr.openjdk.java.net/~darcy/8191234.1/
>
> Thanks,
>
> -Joe
>
> On 11/20/2017 10:34 PM, joe darcy wrote:
>> Hello,
>>
>> Please review the patch below and CSR for
>>
>>     8191234: TypeKindVisitor needs to handle modules
>>     CSR: https://bugs.openjdk.java.net/browse/JDK-8191642
>>
>> The module-related javax.lang.model updates in JDK 9 overlooked 
>> adding module support to the TypeKind family of visitors.
>>
>> The treatment of TypeKind.MODULE is analogous to the how support for 
>> ElementKind.RESOURCE_VARIABLE was added in JDK 7 to the ElementKind 
>> visitors.
>>
>> For now treating this fix was noreg-trivial, but I'll concede test 
>> are appropriate and write a few if reviewers think they are needed.
>>
>> Thanks,
>>
>> -Joe
>>
>> diff -r 5cc5b8270cad 
>> src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor6.java
>> --- 
>> a/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor6.java 
>> Mon Nov 20 20:33:51 2017 -0800
>> +++ 
>> b/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor6.java 
>> Mon Nov 20 22:06:30 2017 -0800
>> @@ -257,7 +257,7 @@
>>       *
>>       * @implSpec This implementation dispatches to the visit method for
>>       * the specific {@linkplain TypeKind kind} of pseudo-type:
>> -     * {@code VOID}, {@code PACKAGE}, or {@code NONE}.
>> +     * {@code VOID}, {@code PACKAGE}, {@code MODULE}, or {@code NONE}.
>>       *
>>       * @param t {@inheritDoc}
>>       * @param p {@inheritDoc}
>> @@ -273,6 +273,9 @@
>>          case PACKAGE:
>>              return visitNoTypeAsPackage(t, p);
>>
>> +        case MODULE:
>> +            return visitNoTypeAsModule(t, p);
>> +
>>          case NONE:
>>              return visitNoTypeAsNone(t, p);
>>
>> @@ -308,6 +311,21 @@
>>      }
>>
>>      /**
>> +     * Visits a {@link TypeKind#MODULE MODULE} pseudo-type.
>> +     *
>> +     * @implSpec This implementation calls {@code visitUnknown}.
>> +     *
>> +     * @param t the type to visit
>> +     * @param p a visitor-specified parameter
>> +     * @return  the result of {@code visitUnknown}
>> +     *
>> +     * @since 10
>> +     */
>> +    public R visitNoTypeAsModule(NoType t, P p) {
>> +        return visitUnknown(t, p);
>> +    }
>> +
>> +    /**
>>       * Visits a {@link TypeKind#NONE NONE} pseudo-type.
>>       *
>>       * @implSpec This implementation calls {@code defaultAction}.
>> diff -r 5cc5b8270cad 
>> src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java
>> --- 
>> a/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java 
>> Mon Nov 20 20:33:51 2017 -0800
>> +++ 
>> b/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java 
>> Mon Nov 20 22:06:30 2017 -0800
>> @@ -93,4 +93,20 @@
>>      protected TypeKindVisitor9(R defaultValue) {
>>          super(defaultValue);
>>      }
>> +
>> +    /**
>> +     * {@inheritDoc}
>> +     *
>> +     * @implSpec This implementation calls {@code defaultAction}.
>> +     *
>> +     * @param t {@inheritDoc}
>> +     * @param p {@inheritDoc}
>> +     * @return  the result of {@code defaultAction}
>> +     *
>> +     * @since 10
>> +     */
>> +    @Override
>> +    public R visitNoTypeAsModule(NoType t, P p) {
>> +        return defaultAction(t, p);
>> +    }
>>  }
>>
>


From joe.darcy at oracle.com  Wed Nov 22 21:56:26 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 22 Nov 2017 13:56:26 -0800
Subject: JDK 10 RFR of 8191234: TypeKindVisitor needs to handle modules,
In-Reply-To: <5A15D329.10306@oracle.com>
References: <4ff2c6b3-b19f-eb87-4757-2e3663212d75@oracle.com>
 <65e95c8e-4e2b-9754-20b1-9b4eb82c919a@oracle.com> <5A15D329.10306@oracle.com>
Message-ID: <e472c4e7-3bbb-a8f8-c34e-c8bb406de0d9@oracle.com>

Hi Jon,


On 11/22/2017 11:42 AM, Jonathan Gibbons wrote:
> Question ...
>
> In TypeKindVisitor6, visitNoTypeAsModule, you specify that the return 
> value is the result of visitUnknown.  That is not true of the override 
> in TypeKindVisitor9.  That raises the question:  are @param and 
> @return specs conceptually part of the API-spec, or part of the implSpec?

Yes, that is a bit of a detail -- the method in TypeKindVisitor9.java 
does provide an explicit @return tag that doesn't @inheritDoc the spec 
from the @return in TypeKindVisitor6. So the javadoc for the classes in 
the API is correct, but there are implications for subclasses outside of 
the javax.lang.model.util.* API.

With the change as written, a subclass that overrode this visitXasY 
method would need to both provide a doc comment for the method as well 
as for the @return tag.

The javadoc tags here are treated the same way as 
ElementKind{$N}.visitVariableAsResourceVariable.

I don't know if we have a broader convention on this point.

Thanks,

-Joe

>
> -- Jon
>
>
>
> On 11/22/2017 10:37 AM, joe darcy wrote:
>> Webrev now with a regression test:
>>
>>     http://cr.openjdk.java.net/~darcy/8191234.1/
>>
>> Thanks,
>>
>> -Joe
>>
>> On 11/20/2017 10:34 PM, joe darcy wrote:
>>> Hello,
>>>
>>> Please review the patch below and CSR for
>>>
>>>     8191234: TypeKindVisitor needs to handle modules
>>>     CSR: https://bugs.openjdk.java.net/browse/JDK-8191642
>>>
>>> The module-related javax.lang.model updates in JDK 9 overlooked 
>>> adding module support to the TypeKind family of visitors.
>>>
>>> The treatment of TypeKind.MODULE is analogous to the how support for 
>>> ElementKind.RESOURCE_VARIABLE was added in JDK 7 to the ElementKind 
>>> visitors.
>>>
>>> For now treating this fix was noreg-trivial, but I'll concede test 
>>> are appropriate and write a few if reviewers think they are needed.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> diff -r 5cc5b8270cad 
>>> src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor6.java
>>> --- 
>>> a/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor6.java 
>>> Mon Nov 20 20:33:51 2017 -0800
>>> +++ 
>>> b/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor6.java 
>>> Mon Nov 20 22:06:30 2017 -0800
>>> @@ -257,7 +257,7 @@
>>>       *
>>>       * @implSpec This implementation dispatches to the visit method 
>>> for
>>>       * the specific {@linkplain TypeKind kind} of pseudo-type:
>>> -     * {@code VOID}, {@code PACKAGE}, or {@code NONE}.
>>> +     * {@code VOID}, {@code PACKAGE}, {@code MODULE}, or {@code NONE}.
>>>       *
>>>       * @param t {@inheritDoc}
>>>       * @param p {@inheritDoc}
>>> @@ -273,6 +273,9 @@
>>>          case PACKAGE:
>>>              return visitNoTypeAsPackage(t, p);
>>>
>>> +        case MODULE:
>>> +            return visitNoTypeAsModule(t, p);
>>> +
>>>          case NONE:
>>>              return visitNoTypeAsNone(t, p);
>>>
>>> @@ -308,6 +311,21 @@
>>>      }
>>>
>>>      /**
>>> +     * Visits a {@link TypeKind#MODULE MODULE} pseudo-type.
>>> +     *
>>> +     * @implSpec This implementation calls {@code visitUnknown}.
>>> +     *
>>> +     * @param t the type to visit
>>> +     * @param p a visitor-specified parameter
>>> +     * @return  the result of {@code visitUnknown}
>>> +     *
>>> +     * @since 10
>>> +     */
>>> +    public R visitNoTypeAsModule(NoType t, P p) {
>>> +        return visitUnknown(t, p);
>>> +    }
>>> +
>>> +    /**
>>>       * Visits a {@link TypeKind#NONE NONE} pseudo-type.
>>>       *
>>>       * @implSpec This implementation calls {@code defaultAction}.
>>> diff -r 5cc5b8270cad 
>>> src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java
>>> --- 
>>> a/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java 
>>> Mon Nov 20 20:33:51 2017 -0800
>>> +++ 
>>> b/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java 
>>> Mon Nov 20 22:06:30 2017 -0800
>>> @@ -93,4 +93,20 @@
>>>      protected TypeKindVisitor9(R defaultValue) {
>>>          super(defaultValue);
>>>      }
>>> +
>>> +    /**
>>> +     * {@inheritDoc}
>>> +     *
>>> +     * @implSpec This implementation calls {@code defaultAction}.
>>> +     *
>>> +     * @param t {@inheritDoc}
>>> +     * @param p {@inheritDoc}
>>> +     * @return  the result of {@code defaultAction}
>>> +     *
>>> +     * @since 10
>>> +     */
>>> +    @Override
>>> +    public R visitNoTypeAsModule(NoType t, P p) {
>>> +        return defaultAction(t, p);
>>> +    }
>>>  }
>>>
>>
>


From jonathan.gibbons at oracle.com  Wed Nov 22 23:24:08 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 22 Nov 2017 15:24:08 -0800
Subject: 8189102: All tools should support -?, -h and --help
In-Reply-To: <5A15CDE2.7010003@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <2ab914b725d54100bb5c99c1537da1df@sap.com> <5A15CDE2.7010003@oracle.com>
Message-ID: <5A160718.6050404@oracle.com>

I agree with putting the long form first, followed by single-letter forms.

Using a comma to separate alternative forms is good, leaving white space 
to separate option and arg. For example, see these lines from javac --help

   --module <module-name>, -m <module-name>
         Compile only the specified module, check timestamps
   --module-path <path>, -p <path>
         Specify where to find application modules


-- Jon

On 11/22/2017 11:20 AM, Robert Field wrote:
> Per jshell tool --
>
> Thanks for adding to the test.
>
> As to the option formatting:
>
>  219 \    -? -h --help          Print this synopsis of standard 
> options and exit\n\
>  220 \    --help-extra, -X      Print help on non-standard options and 
> exit\n\
>
> The number one priority is that it is consistent: comma vs space, 
> --option first vs last.
>
> The number two priority is best readability.  These options are 
> surrounded by --options, so that first seems best to me.
> The comma seems clearer to me, and is used in a good percentage of the 
> tools you listed.
>
> So, my preference is:
>
>  219 \    --help,-?, -h        Print this synopsis of standard options 
> and exit\n\
>  220 \    --help-extra, -X      Print help on non-standard options and 
> exit\n\
>
> Thanks,
> Robert
>
>
> On 11/22/17 09:28, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> I prepared a new webrev trying to incorporate all change requests:
>>   * I removed changes to non-english property files.
>>   * I removed help texts from ktab, kinit, klist
>>   * I removed changes to corba tools
>>   * I added test cases for new flags to tool specific tests (to the 
>> ones I spotted)
>>   * I added -help back to javac
>> I left the removal of -help from Javadoc, as Javadoc just prints the 
>> help message
>> anyways.
>>
>> New webrev:
>> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/index.html 
>>
>>
>> I uploaded the parts of the patch I removed within the webrev:
>> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/help_in_property_files.patch 
>>
>> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/KinitKtabKlist_help_message.patch 
>>
>> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/corba_help_message.patch 
>>
>>
>> Best regards,
>>    Goetz.
>>
>>
>>> -----Original Message-----
>>> From: serviceability-dev [mailto:serviceability-dev-
>>> bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
>>> Sent: Friday, November 17, 2017 12:23 PM
>>> To: core-libs-dev at openjdk.java.net; 'compiler-dev at openjdk.java.net'
>>> <compiler-dev at openjdk.java.net>; serviceability-dev (serviceability-
>>> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
>>> Subject: RFR: 8189102: All tools should support -?, -h and --help
>>>
>>> Hi,
>>>
>>> please review this change. I also filed a CSR for this:
>>> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
>>>
>>> See the webrev for a detailed description of the changes.
>>>
>>> If required, I'll make break-out changes to be reviewed separately.
>>>
>>> I had posted a RFR before, but improved the change to
>>> give a more complete overview of currently supported flags
>>> for the CSR:
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
>>> October/028615.html
>>>
>>> Best regards,
>>>    Goetz.
>


From goetz.lindenmaier at sap.com  Thu Nov 23 10:55:36 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 23 Nov 2017 10:55:36 +0000
Subject: 8189102: All tools should support -?, -h and --help
In-Reply-To: <5A160718.6050404@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <2ab914b725d54100bb5c99c1537da1df@sap.com> <5A15CDE2.7010003@oracle.com>
 <5A160718.6050404@oracle.com>
Message-ID: <29e6807373d04185b30529bffe518ee0@sap.com>

Hi,

I think this basic recommendation how to format help messages is
good.
Unfortunately the tools follow very different strategies of formatting.
Many list the shortcut first.
In the link below you can find the test output of the test in this change. It includes
all help messages of all tools affected.  (I modified the test to print
each message only once.)  Search for --help in the file:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/HelpFlagsTest2.jtr

I already fixed jshell to the recommended format.

I think in most cases the documentation of --help fits to the format.
For jmod, which has lots of -- options, I could easily establish the 
ordering proposed by you, but I would have to change "--module-path, -p", 
too.

Best regards,
  Goetz.





> -----Original Message-----
> From: Jonathan Gibbons [mailto:jonathan.gibbons at oracle.com]
> Sent: Donnerstag, 23. November 2017 00:24
> To: Robert Field <robert.field at oracle.com>; compiler-
> dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Subject: Re: 8189102: All tools should support -?, -h and --help
> 
> I agree with putting the long form first, followed by single-letter forms.
> 
> Using a comma to separate alternative forms is good, leaving white space
> to separate option and arg. For example, see these lines from javac --help
> 
>    --module <module-name>, -m <module-name>
>          Compile only the specified module, check timestamps
>    --module-path <path>, -p <path>
>          Specify where to find application modules
> 
> 
> -- Jon
> 
> On 11/22/2017 11:20 AM, Robert Field wrote:
> > Per jshell tool --
> >
> > Thanks for adding to the test.
> >
> > As to the option formatting:
> >
> >  219 \    -? -h --help          Print this synopsis of standard
> > options and exit\n\
> >  220 \    --help-extra, -X      Print help on non-standard options and
> > exit\n\
> >
> > The number one priority is that it is consistent: comma vs space,
> > --option first vs last.
> >
> > The number two priority is best readability.  These options are
> > surrounded by --options, so that first seems best to me.
> > The comma seems clearer to me, and is used in a good percentage of the
> > tools you listed.
> >
> > So, my preference is:
> >
> >  219 \    --help,-?, -h        Print this synopsis of standard options
> > and exit\n\
> >  220 \    --help-extra, -X      Print help on non-standard options and
> > exit\n\
> >
> > Thanks,
> > Robert
> >
> >
> > On 11/22/17 09:28, Lindenmaier, Goetz wrote:
> >> Hi,
> >>
> >> I prepared a new webrev trying to incorporate all change requests:
> >>   * I removed changes to non-english property files.
> >>   * I removed help texts from ktab, kinit, klist
> >>   * I removed changes to corba tools
> >>   * I added test cases for new flags to tool specific tests (to the
> >> ones I spotted)
> >>   * I added -help back to javac
> >> I left the removal of -help from Javadoc, as Javadoc just prints the
> >> help message
> >> anyways.
> >>
> >> New webrev:
> >> http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.03/index.html
> >>
> >>
> >> I uploaded the parts of the patch I removed within the webrev:
> >> http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.03/help_in_property_files.patch
> >>
> >> http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.03/KinitKtabKlist_help_message.patch
> >>
> >> http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.03/corba_help_message.patch
> >>
> >>
> >> Best regards,
> >>    Goetz.
> >>
> >>
> >>> -----Original Message-----
> >>> From: serviceability-dev [mailto:serviceability-dev-
> >>> bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
> >>> Sent: Friday, November 17, 2017 12:23 PM
> >>> To: core-libs-dev at openjdk.java.net; 'compiler-dev at openjdk.java.net'
> >>> <compiler-dev at openjdk.java.net>; serviceability-dev (serviceability-
> >>> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> >>> Subject: RFR: 8189102: All tools should support -?, -h and --help
> >>>
> >>> Hi,
> >>>
> >>> please review this change. I also filed a CSR for this:
> >>> http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.02/
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >>>
> >>> See the webrev for a detailed description of the changes.
> >>>
> >>> If required, I'll make break-out changes to be reviewed separately.
> >>>
> >>> I had posted a RFR before, but improved the change to
> >>> give a more complete overview of currently supported flags
> >>> for the CSR:
> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> >>> October/028615.html
> >>>
> >>> Best regards,
> >>>    Goetz.
> >


From tomasz.kowalczewski at gmail.com  Fri Nov 24 13:30:26 2017
From: tomasz.kowalczewski at gmail.com (Tomasz Kowalczewski)
Date: Fri, 24 Nov 2017 14:30:26 +0100
Subject: AssertionError in c.s.t.jc.comp.Modules.enter(..)
In-Reply-To: <CANTKXY=_hend2yci-6_X-z3-9pz0YkjDJaddu3Zaf_62Tf_q6Q@mail.gmail.com>
References: <CA+pBWhsG0xyhVaDHY3DE-80Ft-pKZjooKhTb+62FW-8UWj7zfQ@mail.gmail.com>
 <584EA78E.3030207@oracle.com>
 <CA+pBWhsgjcqTJO5hyDWtwoCTP2Y8deYYnsM1_xiiYw=nqU4xYQ@mail.gmail.com>
 <CANTKXY=_hend2yci-6_X-z3-9pz0YkjDJaddu3Zaf_62Tf_q6Q@mail.gmail.com>
Message-ID: <CANTKXY=QS5WCNU30+zJUO8fkT=j+U9pLetpv_Fm1yWySiPJQgw@mail.gmail.com>

I would really appreciate any comment about this.

Regards,
Tomasz Kowalczewski

On Fri, Nov 17, 2017 at 9:47 PM, Tomasz Kowalczewski <
tomasz.kowalczewski at gmail.com> wrote:

> Hi,
>
> was this issue investigated or resolved? I am trying to upgrade our
> application to Java 9 and encountered similar error why trying to compile
> using Apache Maven 3.5.2, Java version: 9.0.1, maven-compiler-plugin
> version 3.7.0.
>
> xception in thread "main" java.lang.AssertionError
> at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
> at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
> at jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:250)
> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.
> readSourceFile(JavaCompiler.java:821)
> at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$
> ImplicitCompleter.complete(JavacProcessingEnvironment.java:1510)
> at jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:633)
> at jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.
> complete(Symbol.java:1314)
> at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.
> complete(Type.java:1139)
> at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.
> getTypeArguments(Type.java:1065)
> at jdk.compiler/com.sun.tools.javac.code.Printer.
> visitClassType(Printer.java:237)
> at jdk.compiler/com.sun.tools.javac.code.Printer.
> visitClassType(Printer.java:52)
> at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.
> accept(Type.java:992)
> at jdk.compiler/com.sun.tools.javac.code.Printer.visit(Printer.java:136)
> at jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.
> formatArgument(AbstractDiagnosticFormatter.java:197)
> at jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.
> formatArguments(AbstractDiagnosticFormatter.java:165)
> at jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.
> formatMessage(BasicDiagnosticFormatter.java:111)
> at jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.
> formatMessage(BasicDiagnosticFormatter.java:67)
> at jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.
> formatArgument(AbstractDiagnosticFormatter.java:183)
> at jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.
> formatArguments(AbstractDiagnosticFormatter.java:165)
> at jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.
> formatMessage(BasicDiagnosticFormatter.java:111)
> at jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.
> formatMessage(BasicDiagnosticFormatter.java:67)
> at jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.
> getMessage(JCDiagnostic.java:771)
> at jdk.compiler/com.sun.tools.javac.api.ClientCodeWrapper$
> DiagnosticSourceUnwrapper.getMessage(ClientCodeWrapper.java:799)
> at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(
> JavaxToolsCompiler.java:131)
> at org.codehaus.plexus.compiler.javac.JavacCompiler.
> performCompile(JavacCompiler.java:174)
> at org.apache.maven.plugin.compiler.AbstractCompilerMojo.
> execute(AbstractCompilerMojo.java:1075)
> at org.apache.maven.plugin.compiler.CompilerMojo.execute(
> CompilerMojo.java:168)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(
> DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> MojoExecutor.java:146)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.
> buildProject(LifecycleModuleBuilder.java:117)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.
> buildProject(LifecycleModuleBuilder.java:81)
> at org.apache.maven.lifecycle.internal.builder.singlethreaded.
> SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.
> execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:955)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at org.codehaus.plexus.classworlds.launcher.Launcher.
> launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.
> launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.
> mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.
> main(Launcher.java:356)
>
> Regards,
> Tomasz Kowalczewski
>



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

From maurizio.cimadamore at oracle.com  Fri Nov 24 14:29:46 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 24 Nov 2017 14:29:46 +0000
Subject: RFR 8191834: Assigning a void expression to a "var" crashes the
 compiler
Message-ID: <b41ce5fa-a31e-b359-21bc-c43362840249@oracle.com>

Please review this simple patch:

http://cr.openjdk.java.net/~mcimadamore/8191834/

If the type of a 'var' initializer is void, javac silently swallows it 
and then throws an error at code gen (righteously so :-)).

I tested for other edge cases such as error types, but could not 
reproduce similar failures (as in those case we never get to Gen - 
because of some error).

Cheers
Maurizio



From jan.lahoda at oracle.com  Fri Nov 24 15:09:42 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 24 Nov 2017 16:09:42 +0100
Subject: AssertionError in c.s.t.jc.comp.Modules.enter(..)
In-Reply-To: <CANTKXY=QS5WCNU30+zJUO8fkT=j+U9pLetpv_Fm1yWySiPJQgw@mail.gmail.com>
References: <CA+pBWhsG0xyhVaDHY3DE-80Ft-pKZjooKhTb+62FW-8UWj7zfQ@mail.gmail.com>
 <584EA78E.3030207@oracle.com>
 <CA+pBWhsgjcqTJO5hyDWtwoCTP2Y8deYYnsM1_xiiYw=nqU4xYQ@mail.gmail.com>
 <CANTKXY=_hend2yci-6_X-z3-9pz0YkjDJaddu3Zaf_62Tf_q6Q@mail.gmail.com>
 <CANTKXY=QS5WCNU30+zJUO8fkT=j+U9pLetpv_Fm1yWySiPJQgw@mail.gmail.com>
Message-ID: <5A183636.7040408@oracle.com>

Hi Tomasz,

I apologize for the belated reply.

Is there a particular reproducible testcase I could try? I tried the 
original one (adjusting as it seemed necessary), and the problem didn't 
happen. So a (standalone) way to reproduce would be very helpful.

Thanks,
    Jan

On 24.11.2017 14:30, Tomasz Kowalczewski wrote:
> I would really appreciate any comment about this.
>
> Regards,
> Tomasz Kowalczewski
>
> On Fri, Nov 17, 2017 at 9:47 PM, Tomasz Kowalczewski
> <tomasz.kowalczewski at gmail.com <mailto:tomasz.kowalczewski at gmail.com>>
> wrote:
>
>     Hi,
>
>     was this issue investigated or resolved? I am trying to upgrade our
>     application to Java 9 and encountered similar error why trying to
>     compile using Apache Maven 3.5.2, Java version:
>     9.0.1, maven-compiler-plugin version 3.7.0.
>
>     xception in thread "main" java.lang.AssertionError
>     at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>     at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
>     at jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:250)
>     at
>     jdk.compiler/com.sun.tools.javac.main.JavaCompiler.readSourceFile(JavaCompiler.java:821)
>     at
>     jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$ImplicitCompleter.complete(JavacProcessingEnvironment.java:1510)
>     at
>     jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:633)
>     at
>     jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1314)
>     at
>     jdk.compiler/com.sun.tools.javac.code.Type$ClassType.complete(Type.java:1139)
>     at
>     jdk.compiler/com.sun.tools.javac.code.Type$ClassType.getTypeArguments(Type.java:1065)
>     at
>     jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType(Printer.java:237)
>     at
>     jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType(Printer.java:52)
>     at
>     jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:992)
>     at jdk.compiler/com.sun.tools.javac.code.Printer.visit(Printer.java:136)
>     at
>     jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:197)
>     at
>     jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:165)
>     at
>     jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111)
>     at
>     jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67)
>     at
>     jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:183)
>     at
>     jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:165)
>     at
>     jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111)
>     at
>     jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67)
>     at
>     jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.getMessage(JCDiagnostic.java:771)
>     at
>     jdk.compiler/com.sun.tools.javac.api.ClientCodeWrapper$DiagnosticSourceUnwrapper.getMessage(ClientCodeWrapper.java:799)
>     at
>     org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:131)
>     at
>     org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:174)
>     at
>     org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1075)
>     at
>     org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:168)
>     at
>     org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
>     at
>     org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>     at
>     org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
>     at
>     org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
>     at
>     org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
>     at
>     org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
>     at
>     org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>     at
>     org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
>     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
>     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
>     at org.apache.maven.cli.MavenCli.execute(MavenCli.java:955)
>     at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290)
>     at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
>     at
>     java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>     Method)
>     at
>     java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     at
>     java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:564)
>     at
>     org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>     at
>     org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>     at
>     org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>     at
>     org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
>
>     Regards,
>     Tomasz Kowalczewski
>
>
>
>
> --
> Tomasz Kowalczewski

From sundararajan.athijegannathan at oracle.com  Fri Nov 24 16:06:26 2017
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 24 Nov 2017 21:36:26 +0530
Subject: RFR 8191834: Assigning a void expression to a "var" crashes the
 compiler
In-Reply-To: <b41ce5fa-a31e-b359-21bc-c43362840249@oracle.com>
References: <b41ce5fa-a31e-b359-21bc-c43362840249@oracle.com>
Message-ID: <5A184382.4090302@oracle.com>

+1

-Sundar

On 24/11/17, 7:59 PM, Maurizio Cimadamore wrote:
> Please review this simple patch:
>
> http://cr.openjdk.java.net/~mcimadamore/8191834/
>
> If the type of a 'var' initializer is void, javac silently swallows it 
> and then throws an error at code gen (righteously so :-)).
>
> I tested for other edge cases such as error types, but could not 
> reproduce similar failures (as in those case we never get to Gen - 
> because of some error).
>
> Cheers
> Maurizio
>
>

From maurizio.cimadamore at oracle.com  Fri Nov 24 16:16:44 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 24 Nov 2017 16:16:44 +0000
Subject: RFR 8191834: Assigning a void expression to a "var" crashes the
 compiler
In-Reply-To: <5A184382.4090302@oracle.com>
References: <b41ce5fa-a31e-b359-21bc-c43362840249@oracle.com>
 <5A184382.4090302@oracle.com>
Message-ID: <263596bd-aa48-eb2e-5728-c08e49bdec54@oracle.com>

Pushed, thx!

Maurizio


On 24/11/17 16:06, Sundararajan Athijegannathan wrote:
> +1
>
> -Sundar
>
> On 24/11/17, 7:59 PM, Maurizio Cimadamore wrote:
>> Please review this simple patch:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8191834/
>>
>> If the type of a 'var' initializer is void, javac silently swallows 
>> it and then throws an error at code gen (righteously so :-)).
>>
>> I tested for other edge cases such as error types, but could not 
>> reproduce similar failures (as in those case we never get to Gen - 
>> because of some error).
>>
>> Cheers
>> Maurizio
>>
>>


From maurizio.cimadamore at oracle.com  Fri Nov 24 17:39:59 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 24 Nov 2017 17:39:59 +0000
Subject: RFR 8191802: Upward projection result is A<? extends Number> instead
 of A<? super Integer>
Message-ID: <5e79e2f9-19da-d726-4081-9257b9c6b241@oracle.com>

Hi,
please review the fix for JDK-8191802:

http://cr.openjdk.java.net/~mcimadamore/8191802/

This is a conformance issue with local variable type inference - the 
specification text for upper projection says this (section 4.10.5):

"The upward projection of a type T with respect to a set of restricted 
type variables is defined as follows:

 ??? [...]

 ??? If T is a parameterized class type or a parameterized interface 
type, G<A1, ..., An>, then the result is G<A1', ..., An'>, where, for 1 
? i ? n, Ai' is derived from Ai as follows:

 ??????? [...]
 ??????? If Ai is a type that mentions a restricted type variable, then 
Ai' is a wildcard. Let U be the upward projection of Ai. There are three 
cases:
*If U is not Object, and if either the declared bound of the ith 
parameter of G, Bi, mentions a type parameter of G, or Bi is not a 
subtype of U, then Ai' is an upper-bounded wildcard, ? extends U.*
 ??????????? Otherwise, if the downward projection of Ai is L, then Ai' 
is a lower-bounded wildcard, ? super L.
 ??????????? Otherwise, the downward projection of Ai is undefined and 
Ai' is an unbounded wildcard, ?."

The text in bold is not implemented accurately by javac. What javac used 
to do was simply to throw away the upper bound and favor the lower bound 
if the upper was Object.

The spec text is much more subtle and precise, allowing javac to throw 
away upper bounds that do not add any extra information w.r.t. declared 
bounds.

As a result of this change, there are few places where the compiler used 
to infer A<? extend B> (where B was same type as declared bound) and now 
it infers A<?> as per spec - this caused few changes in the jshell test 
TypeNameTest.

I've added a lvti harness test to verify the assertions in the above 
paragraph.

Cheers
Maurizio

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

From jan.lahoda at oracle.com  Fri Nov 24 18:03:04 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 24 Nov 2017 19:03:04 +0100
Subject: RFR: JDK-8133616: compiler error messages for dup single type, single
 static import switched
Message-ID: <5A185ED8.4080403@oracle.com>

Hi,

Consider code like this:
---
import java.awt.geom.Line2D.Double;
import static java.awt.geom.Path2D.Double;
---

Compiling it produces this error:
---
$ javac Test.java
Test.java:2: error: a type with the same simple name is already defined 
by the static single-type-import of Double
import static java.awt.geom.Path2D.Double;
^
1 error
---

This sounds like the first import is a static import, which is not the 
case. The proposal is to keep better track of the original import kind 
and report static/non-static more appropriately.

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

How does it look?

Thanks,
     Jan

From dtrebbien at gmail.com  Fri Nov 24 20:10:29 2017
From: dtrebbien at gmail.com (Daniel Trebbien)
Date: Fri, 24 Nov 2017 12:10:29 -0800
Subject: Misleading compiler.err.cant.apply.symbol.1 when base class
 constructor is inaccessible
Message-ID: <CABrgu5Spyv4GJD5zrTeRbOSEkBZ0_zyR3gmMc8aSPg6miC6zFQ@mail.gmail.com>

As reported here https://netbeans.org/bugzilla/show_bug.cgi?id=222487#c2
javac can produce a misleading compiler.err.cant.apply.symbol.1 error
message in cases where the base class constructor is inaccessible, either
because it is private or package-private.

Take the following two files:

// base/Base.java
package base;
public class Base {
    Base(String value) { }
}

// Derived.java
import base.Base;
public class Derived extends Base { }

javac 9.0.1 produces the following:

src/Derived.java:2: error: constructor Base in class Base cannot be applied
to given types;

public class Derived extends Base { }

       ^

  required: String

  found: no arguments

  reason: actual and formal argument lists differ in length

This is misleading because it implies that by adding a Derived constructor
to call Base(String), that the error can be fixed; however, doing so
results in a compiler.err.report.access error because the Base(String)
constructor is not accessible:

src/Derived.java:4: error: Base(String) is not public in Base; cannot be
accessed from outside package

        super(value);

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

From maurizio.cimadamore at oracle.com  Fri Nov 24 21:28:32 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 24 Nov 2017 21:28:32 +0000
Subject: Misleading compiler.err.cant.apply.symbol.1 when base class
 constructor is inaccessible
In-Reply-To: <CABrgu5Spyv4GJD5zrTeRbOSEkBZ0_zyR3gmMc8aSPg6miC6zFQ@mail.gmail.com>
References: <CABrgu5Spyv4GJD5zrTeRbOSEkBZ0_zyR3gmMc8aSPg6miC6zFQ@mail.gmail.com>
Message-ID: <c2162d62-e67f-ac1b-8bb2-0281614c3935@oracle.com>

You are right - this is a long standing behavior - in javac the 
accessibility check is done very late, typically after checking for 
applicability; on the other hand, the JLS rules out candidates very 
early in the overload resolution process, so in this case the JLS would 
say there's no constructor. I believe the spirit of the implemented 
logic was to provide more information to the user, rather than just say 
'cannot find symbol', but I agree with you that, while this normally 
works ok, in this specific case the error message ends up being misleading.

Thanks
Maurizio


On 24/11/17 20:10, Daniel Trebbien wrote:
> As reported here https://netbeans.org/bugzilla/show_bug.cgi?id=222487#c2
> javac can produce a misleading compiler.err.cant.apply.symbol.1?error 
> message in cases where the base class constructor is inaccessible, 
> either because it is private or package-private.
>
> Take the following two files:
>
> // base/Base.java
> package base;
> public class Base {
> ? ? Base(String value) { }
> }
>
> // Derived.java
> import base.Base;
> public class Derived extends Base { }
>
> javac?9.0.1 produces the following:
>
> src/Derived.java:2: error: constructor Base in class Base cannot be 
> applied to given types;
>
> public class Derived extends Base { }
>
> ^
>
> required: String
>
> found: no arguments
>
> reason: actual and formal argument lists differ in length
>
>
> This is misleading because it implies that by adding a Derived 
> constructor to call Base(String), that the error can be fixed; 
> however, doing so results in a?compiler.err.report.access error 
> because the Base(String) constructor is not accessible:
>
> src/Derived.java:4: error: Base(String) is not public in Base; cannot 
> be accessed from outside package
>
> super(value);
>
> ^
>
>

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

From dtrebbien at gmail.com  Sat Nov 25 03:31:27 2017
From: dtrebbien at gmail.com (Daniel Trebbien)
Date: Fri, 24 Nov 2017 19:31:27 -0800
Subject: Misleading compiler.err.cant.apply.symbol.1 when base class
 constructor is inaccessible
In-Reply-To: <c2162d62-e67f-ac1b-8bb2-0281614c3935@oracle.com>
References: <CABrgu5Spyv4GJD5zrTeRbOSEkBZ0_zyR3gmMc8aSPg6miC6zFQ@mail.gmail.com>
 <c2162d62-e67f-ac1b-8bb2-0281614c3935@oracle.com>
Message-ID: <CABrgu5Qbr3GBHweAY23NCFd+6rtOAF6a9cNR9R0D-y+4EnN87Q@mail.gmail.com>

Should an issue be created for this in the JDK Bug System? I don't have the
ability to do this myself.

On Fri, Nov 24, 2017 at 1:28 PM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> You are right - this is a long standing behavior - in javac the
> accessibility check is done very late, typically after checking for
> applicability; on the other hand, the JLS rules out candidates very early
> in the overload resolution process, so in this case the JLS would say
> there's no constructor. I believe the spirit of the implemented logic was
> to provide more information to the user, rather than just say 'cannot find
> symbol', but I agree with you that, while this normally works ok, in this
> specific case the error message ends up being misleading.
>
> Thanks
> Maurizio
>
> On 24/11/17 20:10, Daniel Trebbien wrote:
>
> As reported here https://netbeans.org/bugzilla/show_bug.cgi?id=222487#c2
> javac can produce a misleading compiler.err.cant.apply.symbol.1 error
> message in cases where the base class constructor is inaccessible, either
> because it is private or package-private.
>
> Take the following two files:
>
> // base/Base.java
> package base;
> public class Base {
>     Base(String value) { }
> }
>
> // Derived.java
> import base.Base;
> public class Derived extends Base { }
>
> javac 9.0.1 produces the following:
>
> src/Derived.java:2: error: constructor Base in class Base cannot be
> applied to given types;
>
> public class Derived extends Base { }
>
>        ^
>
>   required: String
>
>   found: no arguments
>
>   reason: actual and formal argument lists differ in length
>
> This is misleading because it implies that by adding a Derived constructor
> to call Base(String), that the error can be fixed; however, doing so
> results in a compiler.err.report.access error because the Base(String)
> constructor is not accessible:
>
> src/Derived.java:4: error: Base(String) is not public in Base; cannot be
> accessed from outside package
>
>         super(value);
>
>         ^
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171124/fb8b3d64/attachment.html>

From maurizio.cimadamore at oracle.com  Mon Nov 27 11:05:16 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 27 Nov 2017 11:05:16 +0000
Subject: Misleading compiler.err.cant.apply.symbol.1 when base class
 constructor is inaccessible
In-Reply-To: <CABrgu5Qbr3GBHweAY23NCFd+6rtOAF6a9cNR9R0D-y+4EnN87Q@mail.gmail.com>
References: <CABrgu5Spyv4GJD5zrTeRbOSEkBZ0_zyR3gmMc8aSPg6miC6zFQ@mail.gmail.com>
 <c2162d62-e67f-ac1b-8bb2-0281614c3935@oracle.com>
 <CABrgu5Qbr3GBHweAY23NCFd+6rtOAF6a9cNR9R0D-y+4EnN87Q@mail.gmail.com>
Message-ID: <99bf8e71-7df1-6ab6-9f64-1bb69574bb15@oracle.com>

Done

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

Maurizio


On 25/11/17 03:31, Daniel Trebbien wrote:
> Should an issue be created for this in the JDK Bug System? I don't 
> have the ability to do this myself.
>
> On Fri, Nov 24, 2017 at 1:28 PM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     You are right - this is a long standing behavior - in javac the
>     accessibility check is done very late, typically after checking
>     for applicability; on the other hand, the JLS rules out candidates
>     very early in the overload resolution process, so in this case the
>     JLS would say there's no constructor. I believe the spirit of the
>     implemented logic was to provide more information to the user,
>     rather than just say 'cannot find symbol', but I agree with you
>     that, while this normally works ok, in this specific case the
>     error message ends up being misleading.
>
>     Thanks
>     Maurizio
>
>
>     On 24/11/17 20:10, Daniel Trebbien wrote:
>>     As reported here
>>     https://netbeans.org/bugzilla/show_bug.cgi?id=222487#c2
>>     <https://netbeans.org/bugzilla/show_bug.cgi?id=222487#c2>
>>     javac can produce a misleading
>>     compiler.err.cant.apply.symbol.1?error message in cases where the
>>     base class constructor is inaccessible, either because it is
>>     private or package-private.
>>
>>     Take the following two files:
>>
>>     // base/Base.java
>>     package base;
>>     public class Base {
>>     Base(String value) { }
>>     }
>>
>>     // Derived.java
>>     import base.Base;
>>     public class Derived extends Base { }
>>
>>     javac?9.0.1 produces the following:
>>
>>     src/Derived.java:2: error: constructor Base in class Base cannot
>>     be applied to given types;
>>
>>     public class Derived extends Base { }
>>
>>     ?? ? ? ^
>>
>>     ? required: String
>>
>>     ? found: no arguments
>>
>>     ? reason: actual and formal argument lists differ in length
>>
>>
>>     This is misleading because it implies that by adding a Derived
>>     constructor to call Base(String), that the error can be fixed;
>>     however, doing so results in a?compiler.err.report.access error
>>     because the Base(String) constructor is not accessible:
>>
>>     src/Derived.java:4: error: Base(String) is not public in Base;
>>     cannot be accessed from outside package
>>
>>     ? ? ? ? super(value);
>>
>>     ? ? ? ? ^
>>
>>
>
>

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

From maurizio.cimadamore at oracle.com  Mon Nov 27 11:19:40 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 27 Nov 2017 11:19:40 +0000
Subject: RFR: JDK-8133616: compiler error messages for dup single type,
 single static import switched
In-Reply-To: <5A185ED8.4080403@oracle.com>
References: <5A185ED8.4080403@oracle.com>
Message-ID: <1b8367b1-c171-a309-1e9a-343eafecb0d6@oracle.com>

Looks good

Thanks
Maurizio


On 24/11/17 18:03, Jan Lahoda wrote:
> Hi,
>
> Consider code like this:
> ---
> import java.awt.geom.Line2D.Double;
> import static java.awt.geom.Path2D.Double;
> ---
>
> Compiling it produces this error:
> ---
> $ javac Test.java
> Test.java:2: error: a type with the same simple name is already 
> defined by the static single-type-import of Double
> import static java.awt.geom.Path2D.Double;
> ^
> 1 error
> ---
>
> This sounds like the first import is a static import, which is not the 
> case. The proposal is to keep better track of the original import kind 
> and report static/non-static more appropriately.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8133616
> Webrev: http://cr.openjdk.java.net/~jlahoda/8133616/webrev.00/
>
> How does it look?
>
> Thanks,
> ??? Jan


From maurizio.cimadamore at oracle.com  Mon Nov 27 15:09:23 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 27 Nov 2017 15:09:23 +0000
Subject: RFR 8191802: Upward projection result is A<? extends Number>
 instead of A<? super Integer>
In-Reply-To: <5e79e2f9-19da-d726-4081-9257b9c6b241@oracle.com>
References: <5e79e2f9-19da-d726-4081-9257b9c6b241@oracle.com>
Message-ID: <c681e827-3325-af06-a3fa-6309dd757e40@oracle.com>

This is an updated version of the webrev:

http://cr.openjdk.java.net/~mcimadamore/8191802-v2/

I realized that there were further discrepancies w.r.t. the spec text, 
so I handled them all at once:

* the spec has different treatment for when a type argument is a 
wildcard and for when it's a regular type - the implementation was 
treating both wildcards and regular types in the same way, which led to 
inconsistencies (see JDK-8191893). I now defined separate visitors for 
the outer projection and type argument projection parts, so that the 
code should be easier to follow.

* not all fresh types created during a projection overrode the 
'needStripping' method, which could lead to issue with type annotation 
processing

* the fact that TypeProjection extended from StructuralMapping had a 
subtle issue - on the one hand, StructuralMapping has the required logic 
to handle arrays (e.g. map component type and return new array if 
needed) - on the other hand, with projections we need to be careful - if 
the element type has no projection, then projection of the array is also 
undefined. The impl was returning an array of <null> which was then 
causing crashes inside the compiler. This is now called out explicitly.

Maurizio


On 24/11/17 17:39, Maurizio Cimadamore wrote:
>
> Hi,
> please review the fix for JDK-8191802:
>
> http://cr.openjdk.java.net/~mcimadamore/8191802/
>
> This is a conformance issue with local variable type inference - the 
> specification text for upper projection says this (section 4.10.5):
>
> "The upward projection of a type T with respect to a set of restricted 
> type variables is defined as follows:
>
> ??? [...]
>
> ??? If T is a parameterized class type or a parameterized interface 
> type, G<A1, ..., An>, then the result is G<A1', ..., An'>, where, for 
> 1 ? i ? n, Ai' is derived from Ai as follows:
>
> ??????? [...]
> ??????? If Ai is a type that mentions a restricted type variable, then 
> Ai' is a wildcard. Let U be the upward projection of Ai. There are 
> three cases:
> *If U is not Object, and if either the declared bound of the ith 
> parameter of G, Bi, mentions a type parameter of G, or Bi is not a 
> subtype of U, then Ai' is an upper-bounded wildcard, ? extends U.*
> ??????????? Otherwise, if the downward projection of Ai is L, then Ai' 
> is a lower-bounded wildcard, ? super L.
> ??????????? Otherwise, the downward projection of Ai is undefined and 
> Ai' is an unbounded wildcard, ?."
>
> The text in bold is not implemented accurately by javac. What javac 
> used to do was simply to throw away the upper bound and favor the 
> lower bound if the upper was Object.
>
> The spec text is much more subtle and precise, allowing javac to throw 
> away upper bounds that do not add any extra information w.r.t. 
> declared bounds.
>
> As a result of this change, there are few places where the compiler 
> used to infer A<? extend B> (where B was same type as declared bound) 
> and now it infers A<?> as per spec - this caused few changes in the 
> jshell test TypeNameTest.
>
> I've added a lvti harness test to verify the assertions in the above 
> paragraph.
>
> Cheers
> Maurizio
>

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

From kumar.x.srinivasan at oracle.com  Mon Nov 27 16:42:41 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 27 Nov 2017 08:42:41 -0800
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
Message-ID: <5A1C4081.2090107@oracle.com>

Hi,

I looked at some of the components I maintain, and they look good.

Wrt. the test:

1. The local variables/fields don't comply with the coding conventions, 
we have been
      following in the JDK.

2.  Hmm, someone parked a .ini file in bin directory, later removed,
      perhaps on windows simply check for .exe ? Should a check exist
      to verify if file has executable permissions ?"File.canExecute".

  171     // Returns true if the file is not a tool.
  172     static boolean notATool(String file) {
  173         file = file.toLowerCase();
  174         if (file.endsWith(".dll") ||
  175             file.endsWith(".map") ||
  176             file.endsWith(".pdb") ||
  177             file.equals("server")) {  // server subdir on windows.
  178             return true;
  179         }
  180         return false;
  181     }


3.  Typo in comment

201     // Check whether 'flag' appears in 'line' as a word of itself. I must not

s/I must/It must/


4. There is a method to check for isEnglishLocale in TestHelper, perhaps 
use it
to have the test bale out in non english locales as early as possible ?

5.  Has this been tested on all platforms ? do you need help testing it ?

Kumar


On 11/17/2017 3:23 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> please review this change. I also filed a CSR for this:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
>
> See the webrev for a detailed description of the changes.
>
> If required, I'll make break-out changes to be reviewed separately.
>
> I had posted a RFR before, but improved the change to
> give a more complete overview of currently supported flags
> for the CSR:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html
>
> Best regards,
>    Goetz.
>


From jonathan.gibbons at oracle.com  Mon Nov 27 19:27:05 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 27 Nov 2017 11:27:05 -0800
Subject: JDK 10 RFR of 8191234: TypeKindVisitor needs to handle modules,
In-Reply-To: <e472c4e7-3bbb-a8f8-c34e-c8bb406de0d9@oracle.com>
References: <4ff2c6b3-b19f-eb87-4757-2e3663212d75@oracle.com>
 <65e95c8e-4e2b-9754-20b1-9b4eb82c919a@oracle.com> <5A15D329.10306@oracle.com>
 <e472c4e7-3bbb-a8f8-c34e-c8bb406de0d9@oracle.com>
Message-ID: <5A1C6709.8090202@oracle.com>

Webrev looks OK.

-- Jon

On 11/22/2017 01:56 PM, joe darcy wrote:
> Hi Jon,
>
>
> On 11/22/2017 11:42 AM, Jonathan Gibbons wrote:
>> Question ...
>>
>> In TypeKindVisitor6, visitNoTypeAsModule, you specify that the return 
>> value is the result of visitUnknown.  That is not true of the 
>> override in TypeKindVisitor9.  That raises the question: are @param 
>> and @return specs conceptually part of the API-spec, or part of the 
>> implSpec?
>
> Yes, that is a bit of a detail -- the method in TypeKindVisitor9.java 
> does provide an explicit @return tag that doesn't @inheritDoc the spec 
> from the @return in TypeKindVisitor6. So the javadoc for the classes 
> in the API is correct, but there are implications for subclasses 
> outside of the javax.lang.model.util.* API.
>
> With the change as written, a subclass that overrode this visitXasY 
> method would need to both provide a doc comment for the method as well 
> as for the @return tag.
>
> The javadoc tags here are treated the same way as 
> ElementKind{$N}.visitVariableAsResourceVariable.
>
> I don't know if we have a broader convention on this point.
>
> Thanks,
>
> -Joe
>
>>
>> -- Jon
>>
>>
>>
>> On 11/22/2017 10:37 AM, joe darcy wrote:
>>> Webrev now with a regression test:
>>>
>>>     http://cr.openjdk.java.net/~darcy/8191234.1/
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> On 11/20/2017 10:34 PM, joe darcy wrote:
>>>> Hello,
>>>>
>>>> Please review the patch below and CSR for
>>>>
>>>>     8191234: TypeKindVisitor needs to handle modules
>>>>     CSR: https://bugs.openjdk.java.net/browse/JDK-8191642
>>>>
>>>> The module-related javax.lang.model updates in JDK 9 overlooked 
>>>> adding module support to the TypeKind family of visitors.
>>>>
>>>> The treatment of TypeKind.MODULE is analogous to the how support 
>>>> for ElementKind.RESOURCE_VARIABLE was added in JDK 7 to the 
>>>> ElementKind visitors.
>>>>
>>>> For now treating this fix was noreg-trivial, but I'll concede test 
>>>> are appropriate and write a few if reviewers think they are needed.
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>>
>>>> diff -r 5cc5b8270cad 
>>>> src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor6.java
>>>> --- 
>>>> a/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor6.java 
>>>> Mon Nov 20 20:33:51 2017 -0800
>>>> +++ 
>>>> b/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor6.java 
>>>> Mon Nov 20 22:06:30 2017 -0800
>>>> @@ -257,7 +257,7 @@
>>>>       *
>>>>       * @implSpec This implementation dispatches to the visit 
>>>> method for
>>>>       * the specific {@linkplain TypeKind kind} of pseudo-type:
>>>> -     * {@code VOID}, {@code PACKAGE}, or {@code NONE}.
>>>> +     * {@code VOID}, {@code PACKAGE}, {@code MODULE}, or {@code 
>>>> NONE}.
>>>>       *
>>>>       * @param t {@inheritDoc}
>>>>       * @param p {@inheritDoc}
>>>> @@ -273,6 +273,9 @@
>>>>          case PACKAGE:
>>>>              return visitNoTypeAsPackage(t, p);
>>>>
>>>> +        case MODULE:
>>>> +            return visitNoTypeAsModule(t, p);
>>>> +
>>>>          case NONE:
>>>>              return visitNoTypeAsNone(t, p);
>>>>
>>>> @@ -308,6 +311,21 @@
>>>>      }
>>>>
>>>>      /**
>>>> +     * Visits a {@link TypeKind#MODULE MODULE} pseudo-type.
>>>> +     *
>>>> +     * @implSpec This implementation calls {@code visitUnknown}.
>>>> +     *
>>>> +     * @param t the type to visit
>>>> +     * @param p a visitor-specified parameter
>>>> +     * @return  the result of {@code visitUnknown}
>>>> +     *
>>>> +     * @since 10
>>>> +     */
>>>> +    public R visitNoTypeAsModule(NoType t, P p) {
>>>> +        return visitUnknown(t, p);
>>>> +    }
>>>> +
>>>> +    /**
>>>>       * Visits a {@link TypeKind#NONE NONE} pseudo-type.
>>>>       *
>>>>       * @implSpec This implementation calls {@code defaultAction}.
>>>> diff -r 5cc5b8270cad 
>>>> src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java
>>>> --- 
>>>> a/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java 
>>>> Mon Nov 20 20:33:51 2017 -0800
>>>> +++ 
>>>> b/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java 
>>>> Mon Nov 20 22:06:30 2017 -0800
>>>> @@ -93,4 +93,20 @@
>>>>      protected TypeKindVisitor9(R defaultValue) {
>>>>          super(defaultValue);
>>>>      }
>>>> +
>>>> +    /**
>>>> +     * {@inheritDoc}
>>>> +     *
>>>> +     * @implSpec This implementation calls {@code defaultAction}.
>>>> +     *
>>>> +     * @param t {@inheritDoc}
>>>> +     * @param p {@inheritDoc}
>>>> +     * @return  the result of {@code defaultAction}
>>>> +     *
>>>> +     * @since 10
>>>> +     */
>>>> +    @Override
>>>> +    public R visitNoTypeAsModule(NoType t, P p) {
>>>> +        return defaultAction(t, p);
>>>> +    }
>>>>  }
>>>>
>>>
>>
>


From jonathan.gibbons at oracle.com  Mon Nov 27 20:31:11 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 27 Nov 2017 12:31:11 -0800
Subject: RFR 8189749: Devise strategy for making source level checks more
 uniform
In-Reply-To: <af46e66f-a0b7-2a65-7ca7-cecd3bbd7a43@oracle.com>
References: <af46e66f-a0b7-2a65-7ca7-cecd3bbd7a43@oracle.com>
Message-ID: <5A1C760F.4060908@oracle.com>

Mostly excellent.

Some nitpicks for your consideration:

Source.java: Do we really want to support 1.x aliases for 9, 10?

source.allowed(feature)  feels clunky; it would be better to name the 
method "allows" or "isAllowed". By itself, "allowed" feels too much like 
past tense, which may be OK for earlier releases but doesn't work for 
the current release.

The overall code is inconsistent with respect to using 
source.allowed(feature) and feature.allowedInSource(source). Of the two, 
my personal preference is for the latter; while reading the webrev, I 
was wondering whether the source.allowed(feature) calls would be better 
reversed, and was then mildly surprised when I saw later files in the 
webrev using that pattern.  But I think consistency should win out, 
whichever form you prefer to use.

Diagnostics.  javac messages are not a shining example of eloquence, but 
I do worry about "{0} not supported in -source {1}\n\", line 2608.
I think it would be better to revert to the earlier phrasing of "... are 
not supported..." and then ensure that all the feature names are plural, 
which is already mostly the case. The ones that stand out as needing to 
be fixed are: "diamond operator" and "multi-catch statement".  That 
leaves "''<>'' with anonymous inner classes" . So maybe we end up with 
just one clunky phrasing. My best suggestion would be to allow selected 
specific messages to use a custom message when the template form doesn't 
work well.

-- Jon


On 10/20/2017 11:07 AM, Maurizio Cimadamore wrote:
> Hi,
> this biggie patch allows the treatment of source level checks to be 
> more uniform. The general problem is explained in details here:
>
> https://bugs.openjdk.java.net/browse/JDK-8189749
>
> Webrev is here:
>
> http://cr.openjdk.java.net/~mcimadamore/8189749/
>
> The way I approached this, was to create a first class entity, an enum 
> called Feature. Each 'feature' has:
>
> * a min source level (e.g. what is the min source level required to 
> compile that feature, meaning that lower levels will result in errors)
> * a max source level (e.g. what is the max source level required to 
> compile that feature, meaning that higher levels will result in errors)
> * an optional resource key
>
> The first two properties are obviously used to decided if feature XYZ 
> can be used given source level N. The last property is used to 
> automate generation of source check diagnostics. Note that this patch 
> introduce a _single_ source check diagnostic:
>
> # 0: message segment (feature), 1: string (found version), 2: string 
> (expected version)
> compiler.misc.feature.not.supported.in.source=\
>    {0} not supported in -source {1}\n\
>     (use -source {2} or higher to enable {0})
>
> And then there's a bunch of feature fragments, example:
>
> compiler.misc.feature.modules=\
>     modules
>
> compiler.misc.feature.diamond.and.anon.class=\
>     ''<>'' with anonymous inner classes
>
> compiler.misc.feature.binary.lit=\
>     binary literals
>
> (and many more :-))
>
> Since each feature 'knows' its fragment, it is super easy for the 
> compiler to generate the source level check diagnostic for any 
> feature. And, if you need to add a new feature, you just need to add 
> an enum value, and wired it up with the corresponding resource key - 
> done :-)
>
> Since this change affects the way in which source check diagnostics 
> are generated, quite a lot of changes were required to adjust expected 
> output in golden files. Aside from those changes, I also addressed the 
> following issues:
>
> * JavaTokenizer was not using SOURCE_LEVEL flags for its diagnostics, 
> and it was not using the new diagnostic framework to generate errors, 
> which made the porting harder - so I've fixed that
> * CALog in Completeness analyzer required a new override for an 
> AbstractLog::error variant that was probably forgotten (this was 
> required otherwise CompletenessAnalyzerTest was failing after the 
> change above)
> * Log has a 'feature' so that diagnostics marked with the SOURCE_LEVEL 
> flag can be reported only once per source. But this check was only 
> looking at the 'head' of a diagnostic, ignoring all arguments. Since 
> now all source level check diagnostics share the same head, I needed 
> to tweak the logic to also compare arguments - or else, one source 
> level check error being reported would also disable unrelated source 
> level check diags.
>
> Then there were a bunch of mechanical translation, for instance idioms 
> such as:
>
> allowSimplifiedVarargs = source.allowSimplifiedVarargs();
>
> Were rewritten as:
>
> allowSimplifiedVarargs = source.allowed(Feature.SIMPLIFIED_VARARGS);
>
> Also, in JavacParser, this idiom:
>
> checkTypeAnnotations();
>
> has been replaced with
>
> checkSourceLevel(Feature.TYPE_ANNOTATIONS);
>
> Where checkSourceLevel is a new general routine that works on any 
> Feature.
>
> Finally, where possible, I also got rid of the various boolean flags 
> of the kind 'allowPrivateMethodInInterfaces' - if the class already 
> had a 'source' field, the boolean flag can be omitted, and the check 
> can be performed on the source object itself.
>
> Cheers
> Maurizio
>
>
>


From jan.lahoda at oracle.com  Mon Nov 27 20:52:26 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 27 Nov 2017 21:52:26 +0100
Subject: RFR 8189749: Devise strategy for making source level checks more
 uniform
In-Reply-To: <af46e66f-a0b7-2a65-7ca7-cecd3bbd7a43@oracle.com>
References: <af46e66f-a0b7-2a65-7ca7-cecd3bbd7a43@oracle.com>
Message-ID: <5A1C7B0A.6050909@oracle.com>

Seems good to me. A few comments:
-I wonder if the message construction has been discussed with L10N 
folks, if it is OK to concatenate the messages
-nit: in JavaTokenizer.java, duplicate '/**' on:
private Source source;

Jan

On 20.10.2017 20:07, Maurizio Cimadamore wrote:
> Hi,
> this biggie patch allows the treatment of source level checks to be more
> uniform. The general problem is explained in details here:
>
> https://bugs.openjdk.java.net/browse/JDK-8189749
>
> Webrev is here:
>
> http://cr.openjdk.java.net/~mcimadamore/8189749/
>
> The way I approached this, was to create a first class entity, an enum
> called Feature. Each 'feature' has:
>
> * a min source level (e.g. what is the min source level required to
> compile that feature, meaning that lower levels will result in errors)
> * a max source level (e.g. what is the max source level required to
> compile that feature, meaning that higher levels will result in errors)
> * an optional resource key
>
> The first two properties are obviously used to decided if feature XYZ
> can be used given source level N. The last property is used to automate
> generation of source check diagnostics. Note that this patch introduce a
> _single_ source check diagnostic:
>
> # 0: message segment (feature), 1: string (found version), 2: string
> (expected version)
> compiler.misc.feature.not.supported.in.source=\
>     {0} not supported in -source {1}\n\
>      (use -source {2} or higher to enable {0})
>
> And then there's a bunch of feature fragments, example:
>
> compiler.misc.feature.modules=\
>      modules
>
> compiler.misc.feature.diamond.and.anon.class=\
>      ''<>'' with anonymous inner classes
>
> compiler.misc.feature.binary.lit=\
>      binary literals
>
> (and many more :-))
>
> Since each feature 'knows' its fragment, it is super easy for the
> compiler to generate the source level check diagnostic for any feature.
> And, if you need to add a new feature, you just need to add an enum
> value, and wired it up with the corresponding resource key - done :-)
>
> Since this change affects the way in which source check diagnostics are
> generated, quite a lot of changes were required to adjust expected
> output in golden files. Aside from those changes, I also addressed the
> following issues:
>
> * JavaTokenizer was not using SOURCE_LEVEL flags for its diagnostics,
> and it was not using the new diagnostic framework to generate errors,
> which made the porting harder - so I've fixed that
> * CALog in Completeness analyzer required a new override for an
> AbstractLog::error variant that was probably forgotten (this was
> required otherwise CompletenessAnalyzerTest was failing after the change
> above)
> * Log has a 'feature' so that diagnostics marked with the SOURCE_LEVEL
> flag can be reported only once per source. But this check was only
> looking at the 'head' of a diagnostic, ignoring all arguments. Since now
> all source level check diagnostics share the same head, I needed to
> tweak the logic to also compare arguments - or else, one source level
> check error being reported would also disable unrelated source level
> check diags.
>
> Then there were a bunch of mechanical translation, for instance idioms
> such as:
>
> allowSimplifiedVarargs = source.allowSimplifiedVarargs();
>
> Were rewritten as:
>
> allowSimplifiedVarargs = source.allowed(Feature.SIMPLIFIED_VARARGS);
>
> Also, in JavacParser, this idiom:
>
> checkTypeAnnotations();
>
> has been replaced with
>
> checkSourceLevel(Feature.TYPE_ANNOTATIONS);
>
> Where checkSourceLevel is a new general routine that works on any Feature.
>
> Finally, where possible, I also got rid of the various boolean flags of
> the kind 'allowPrivateMethodInInterfaces' - if the class already had a
> 'source' field, the boolean flag can be omitted, and the check can be
> performed on the source object itself.
>
> Cheers
> Maurizio
>
>
>

From maurizio.cimadamore at oracle.com  Mon Nov 27 21:22:15 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 27 Nov 2017 21:22:15 +0000
Subject: RFR 8189749: Devise strategy for making source level checks more
 uniform
In-Reply-To: <5A1C760F.4060908@oracle.com>
References: <af46e66f-a0b7-2a65-7ca7-cecd3bbd7a43@oracle.com>
 <5A1C760F.4060908@oracle.com>
Message-ID: <34e5cca2-9617-8323-6e12-a5a7b5891858@oracle.com>

Thanks for the review - comments inline


On 27/11/17 20:31, Jonathan Gibbons wrote:
> Mostly excellent.
>
> Some nitpicks for your consideration:
>
> Source.java: Do we really want to support 1.x aliases for 9, 10?
Not fond of the aliases - but though they were needed (at least in the 
short term) as a compatibility step.
>
> source.allowed(feature)? feels clunky; it would be better to name the 
> method "allows" or "isAllowed". By itself, "allowed" feels too much 
> like past tense, which may be OK for earlier releases but doesn't work 
> for the current release.
ok
>
> The overall code is inconsistent with respect to using 
> source.allowed(feature) and feature.allowedInSource(source). Of the 
> two, my personal preference is for the latter; while reading the 
> webrev, I was wondering whether the source.allowed(feature) calls 
> would be better reversed, and was then mildly surprised when I saw 
> later files in the webrev using that pattern.? But I think consistency 
> should win out, whichever form you prefer to use.
Ok - I will make another pass on the code to iron out these consistency 
issues - I agree we should use same convention across the codebase. I 
believe source.allowXYZ has been translated to source.allowed(FEATURE) 
but the new uses in Javac parser have been translated using the 
different idiom. I agree that Feature.allowedInSource is more direct and 
more readable than the counterpart.
>
> Diagnostics.? javac messages are not a shining example of eloquence, 
> but I do worry about "{0} not supported in -source {1}\n\", line 2608.
> I think it would be better to revert to the earlier phrasing of "... 
> are not supported..." and then ensure that all the feature names are 
> plural, which is already mostly the case. The ones that stand out as 
> needing to be fixed are: "diamond operator" and "multi-catch 
> statement".? That leaves "''<>'' with anonymous inner classes" . So 
> maybe we end up with just one clunky phrasing. My best suggestion 
> would be to allow selected specific messages to use a custom message 
> when the template form doesn't work well.
Ok, I'll think of something - perhaps an enum which has PLURAL and 
SINGULAR as values which point to different errors, and each feature has 
to decide which is which.

Maurizio
>
> -- Jon
>
>
> On 10/20/2017 11:07 AM, Maurizio Cimadamore wrote:
>> Hi,
>> this biggie patch allows the treatment of source level checks to be 
>> more uniform. The general problem is explained in details here:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8189749
>>
>> Webrev is here:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8189749/
>>
>> The way I approached this, was to create a first class entity, an 
>> enum called Feature. Each 'feature' has:
>>
>> * a min source level (e.g. what is the min source level required to 
>> compile that feature, meaning that lower levels will result in errors)
>> * a max source level (e.g. what is the max source level required to 
>> compile that feature, meaning that higher levels will result in errors)
>> * an optional resource key
>>
>> The first two properties are obviously used to decided if feature XYZ 
>> can be used given source level N. The last property is used to 
>> automate generation of source check diagnostics. Note that this patch 
>> introduce a _single_ source check diagnostic:
>>
>> # 0: message segment (feature), 1: string (found version), 2: string 
>> (expected version)
>> compiler.misc.feature.not.supported.in.source=\
>> ?? {0} not supported in -source {1}\n\
>> ??? (use -source {2} or higher to enable {0})
>>
>> And then there's a bunch of feature fragments, example:
>>
>> compiler.misc.feature.modules=\
>> ??? modules
>>
>> compiler.misc.feature.diamond.and.anon.class=\
>> ??? ''<>'' with anonymous inner classes
>>
>> compiler.misc.feature.binary.lit=\
>> ??? binary literals
>>
>> (and many more :-))
>>
>> Since each feature 'knows' its fragment, it is super easy for the 
>> compiler to generate the source level check diagnostic for any 
>> feature. And, if you need to add a new feature, you just need to add 
>> an enum value, and wired it up with the corresponding resource key - 
>> done :-)
>>
>> Since this change affects the way in which source check diagnostics 
>> are generated, quite a lot of changes were required to adjust 
>> expected output in golden files. Aside from those changes, I also 
>> addressed the following issues:
>>
>> * JavaTokenizer was not using SOURCE_LEVEL flags for its diagnostics, 
>> and it was not using the new diagnostic framework to generate errors, 
>> which made the porting harder - so I've fixed that
>> * CALog in Completeness analyzer required a new override for an 
>> AbstractLog::error variant that was probably forgotten (this was 
>> required otherwise CompletenessAnalyzerTest was failing after the 
>> change above)
>> * Log has a 'feature' so that diagnostics marked with the 
>> SOURCE_LEVEL flag can be reported only once per source. But this 
>> check was only looking at the 'head' of a diagnostic, ignoring all 
>> arguments. Since now all source level check diagnostics share the 
>> same head, I needed to tweak the logic to also compare arguments - or 
>> else, one source level check error being reported would also disable 
>> unrelated source level check diags.
>>
>> Then there were a bunch of mechanical translation, for instance 
>> idioms such as:
>>
>> allowSimplifiedVarargs = source.allowSimplifiedVarargs();
>>
>> Were rewritten as:
>>
>> allowSimplifiedVarargs = source.allowed(Feature.SIMPLIFIED_VARARGS);
>>
>> Also, in JavacParser, this idiom:
>>
>> checkTypeAnnotations();
>>
>> has been replaced with
>>
>> checkSourceLevel(Feature.TYPE_ANNOTATIONS);
>>
>> Where checkSourceLevel is a new general routine that works on any 
>> Feature.
>>
>> Finally, where possible, I also got rid of the various boolean flags 
>> of the kind 'allowPrivateMethodInInterfaces' - if the class already 
>> had a 'source' field, the boolean flag can be omitted, and the check 
>> can be performed on the source object itself.
>>
>> Cheers
>> Maurizio
>>
>>
>>
>


From goetz.lindenmaier at sap.com  Tue Nov 28 08:50:22 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 28 Nov 2017 08:50:22 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <5A1C4081.2090107@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <5A1C4081.2090107@oracle.com>
Message-ID: <6d28cb7eaeb24d3daa39f78b97368a08@sap.com>

Hi Kumar, 

Thanks for looking at my change!
 
> I looked at some of the components I maintain, and they look good.
May I ask which these are? So I can account whether all parts have been 
reviewed?

> 1. The local variables/fields don't comply with the coding conventions,
> we have been
>       following in the JDK.
Removed all '_' from fields.  Anything else?  TOOLS_NOT_TO_TEST
is formatted as the similar list in VersionCheck.java.

> 2.  Hmm, someone parked a .ini file in bin directory, later removed,
>       perhaps on windows simply check for .exe ? Should a check exist
>       to verify if file has executable permissions ?"File.canExecute".
> 
>   171     // Returns true if the file is not a tool.
>   172     static boolean notATool(String file) {
>   173         file = file.toLowerCase();
>   174         if (file.endsWith(".dll") ||
>   175             file.endsWith(".map") ||
>   176             file.endsWith(".pdb") ||
>   177             file.equals("server")) {  // server subdir on windows.
>   178             return true;
>   179         }
>   180         return false;
>   181     } 
I anyways wondered why .dll + friends are in the exe directory and 
not in the lib directory.  But a check for executable file is better
than this list. Changed.

> 3.  Typo in comment
Fixed. 

> 4. There is a method to check for isEnglishLocale in TestHelper, perhaps
> use it to have the test bale out in non english locales as early as possible ?
I added a bailout at the beginning of the test. Thanks for the advice!
But thinking about this a @requires englishLocale would be useful here.
 
> 5.  Has this been tested on all platforms ? do you need help testing it ?
Our testing is on ntamd64, linuxppc64, linuxppc64le, linuxs390x, linuxx86_64,
sun_64 and aixppc64. I run the jdk jtreg tests on these platforms. I once ran 
the change with the jdk-hs repo, where we test test/hotspot/jtreg and most jck 
tests.  All passed.
I don't think this is very platform dependent (most differences are
between unix/windows) so this platform coverage should suffice 
I think.

I'll post a new webrev later on.

Best regards,
  Goetz.


> 
> Kumar
> 
> 
> On 11/17/2017 3:23 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > please review this change. I also filed a CSR for this:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.02/
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >
> > See the webrev for a detailed description of the changes.
> >
> > If required, I'll make break-out changes to be reviewed separately.
> >
> > I had posted a RFR before, but improved the change to
> > give a more complete overview of currently supported flags
> > for the CSR:
> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> October/028615.html
> >
> > Best regards,
> >    Goetz.
> >


From goetz.lindenmaier at sap.com  Tue Nov 28 11:16:45 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 28 Nov 2017 11:16:45 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <5A1C4081.2090107@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <5A1C4081.2090107@oracle.com>
Message-ID: <badb6f618f5b489ca634adb6b545b152@sap.com>

Hi,

I uploaded a new webrev:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.04/

This includes the changes 
  - to jshell requested by Robert
  - to the test as requested by Kumar.

See also incremental patch and the test output including all the
help messages referenced in the webrev.

Best regards,
  Goetz.

> -----Original Message-----
> From: Kumar Srinivasan [mailto:kumar.x.srinivasan at oracle.com]
> Sent: Montag, 27. November 2017 17:43
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: core-libs-dev at openjdk.java.net; 'compiler-dev at openjdk.java.net'
> <compiler-dev at openjdk.java.net>; serviceability-dev (serviceability-
> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> Hi,
> 
> I looked at some of the components I maintain, and they look good.
> 
> Wrt. the test:
> 
> 1. The local variables/fields don't comply with the coding conventions,
> we have been
>       following in the JDK.
> 
> 2.  Hmm, someone parked a .ini file in bin directory, later removed,
>       perhaps on windows simply check for .exe ? Should a check exist
>       to verify if file has executable permissions ?"File.canExecute".
> 
>   171     // Returns true if the file is not a tool.
>   172     static boolean notATool(String file) {
>   173         file = file.toLowerCase();
>   174         if (file.endsWith(".dll") ||
>   175             file.endsWith(".map") ||
>   176             file.endsWith(".pdb") ||
>   177             file.equals("server")) {  // server subdir on windows.
>   178             return true;
>   179         }
>   180         return false;
>   181     }
> 
> 
> 3.  Typo in comment
> 
> 201     // Check whether 'flag' appears in 'line' as a word of itself. I must not
> 
> s/I must/It must/
> 
> 
> 4. There is a method to check for isEnglishLocale in TestHelper, perhaps
> use it
> to have the test bale out in non english locales as early as possible ?
> 
> 5.  Has this been tested on all platforms ? do you need help testing it ?
> 
> Kumar
> 
> 
> On 11/17/2017 3:23 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > please review this change. I also filed a CSR for this:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.02/
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >
> > See the webrev for a detailed description of the changes.
> >
> > If required, I'll make break-out changes to be reviewed separately.
> >
> > I had posted a RFR before, but improved the change to
> > give a more complete overview of currently supported flags
> > for the CSR:
> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> October/028615.html
> >
> > Best regards,
> >    Goetz.
> >


From srikanth.adayapalam at oracle.com  Tue Nov 28 11:45:42 2017
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Tue, 28 Nov 2017 17:15:42 +0530
Subject: RFR JDK-8191969: javac produces incorrect
 RuntimeInvisibleTypeAnnotations length attribute
Message-ID: <5A1D4C66.5010605@oracle.com>


Hello,

JDK-8191969 is a JDK8u backport task created for JDK-8144185 which was 
pushed for JDK10
here: http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/0b32afcabef4

We have a request from asm tool maintainers and also from other sources 
through the sustenance channel for a backport.

Synopsis:

Basically problem arises when metadata that models the type annotations 
on a captured outer local are shared with the lambda implementation 
method's formal parameter that corresponds to the
captured outer local.

Any changes to one will invalidate the other. This is in fact what 
causes grief for asm.

However, as per the spec clarification spelled out here: 
http://mail.openjdk.java.net/pipermail/compiler-dev/2015-December/009866.html 
we should not be transmitting the annotations from the captured outer 
locals to any formal parameter that represents/reifies the captured 
outer local in a synthetic lambda implementation method.

Thus aligning to the spec, makes the problem vanish automatically.

8u webrev:

http://cr.openjdk.java.net/~sadayapalam/JDK-8191969/webrev.00/

(This is essentially the same fix pushed for jdk10, with the patch 
manually applied to jdk8u-dev)

All relevant tests are green. Please review.
Thanks in advance.
Srikanth



From jan.lahoda at oracle.com  Tue Nov 28 11:46:20 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 28 Nov 2017 12:46:20 +0100
Subject: RFR: JDK-8191981: javac crash when detecting lambda candidates
Message-ID: <5A1D4C8C.10307@oracle.com>

Hi,

Consider this code:
---
public class LambdaWithMethod {
     public static void run(Runnable r) {
         run(new Runnable() {
             public void run() {
                 put(get());
             }
         });
     }
     private static String get() { return null; }
     private static void put(String i) {}
}
---

When detecting lambda candidates, this crashes javac (please see the bug 
for full exception):
---
$ javac -XDfind=lambda /tmp/LambdaWithMethod.java
[snip]
java.lang.AssertionError: Analyzer error when processing: [snip]
at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162)
at 
jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:562)
[snip]
---

The underlying exception is:
---
java.lang.ClassCastException: 
jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation cannot 
be cast to jdk.compiler/com.sun.tools.javac.tree.JCTree$JCLambda
         at 
jdk.compiler/com.sun.tools.javac.comp.ArgumentAttr$ExplicitLambdaType.dup(ArgumentAttr.java:456)
         at 
jdk.compiler/com.sun.tools.javac.comp.ArgumentAttr.processArg(ArgumentAttr.java:237)
[snip]
---

(Full exception in the bug.)

The problem appears to be that when the trial lambda node (that replaces 
the anonymous class) is created, there is no explicit position set, and 
so the last position set is used. And the ArgumentAttr.argumentTypeCache 
uses the position as key, and so the value for "get()" is (appears to 
be) used for the lambda, which leads to the crash.

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

How does this look?

Thanks,
    Jan



From maurizio.cimadamore at oracle.com  Tue Nov 28 13:13:55 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 28 Nov 2017 13:13:55 +0000
Subject: RFR: JDK-8191981: javac crash when detecting lambda candidates
In-Reply-To: <5A1D4C8C.10307@oracle.com>
References: <5A1D4C8C.10307@oracle.com>
Message-ID: <34820328-f732-1c39-e015-da476c1f33e1@oracle.com>

Your fix looks fine - unfortunately the 
'ArguymentAttr.withLocalCacheContext' was created for this very reason, 
but I think that approach is not sufficient to fully disable the cache. 
It will simply avoid cache changes to propagate out - while here you 
want something which basically disables the cache entirely.

Maurizio


On 28/11/17 11:46, Jan Lahoda wrote:
> Hi,
>
> Consider this code:
> ---
> public class LambdaWithMethod {
> ??? public static void run(Runnable r) {
> ??????? run(new Runnable() {
> ??????????? public void run() {
> ??????????????? put(get());
> ??????????? }
> ??????? });
> ??? }
> ??? private static String get() { return null; }
> ??? private static void put(String i) {}
> }
> ---
>
> When detecting lambda candidates, this crashes javac (please see the 
> bug for full exception):
> ---
> $ javac -XDfind=lambda /tmp/LambdaWithMethod.java
> [snip]
> java.lang.AssertionError: Analyzer error when processing: [snip]
> at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162)
> at 
> jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:562)
> [snip]
> ---
>
> The underlying exception is:
> ---
> java.lang.ClassCastException: 
> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation cannot 
> be cast to jdk.compiler/com.sun.tools.javac.tree.JCTree$JCLambda
> ??????? at 
> jdk.compiler/com.sun.tools.javac.comp.ArgumentAttr$ExplicitLambdaType.dup(ArgumentAttr.java:456)
> ??????? at 
> jdk.compiler/com.sun.tools.javac.comp.ArgumentAttr.processArg(ArgumentAttr.java:237)
> [snip]
> ---
>
> (Full exception in the bug.)
>
> The problem appears to be that when the trial lambda node (that 
> replaces the anonymous class) is created, there is no explicit 
> position set, and so the last position set is used. And the 
> ArgumentAttr.argumentTypeCache uses the position as key, and so the 
> value for "get()" is (appears to be) used for the lambda, which leads 
> to the crash.
>
> Bug; https://bugs.openjdk.java.net/browse/JDK-8191981
> Proposed patch: http://cr.openjdk.java.net/~jlahoda/8191981/webrev.00
>
> How does this look?
>
> Thanks,
> ?? Jan
>
>


From maurizio.cimadamore at oracle.com  Tue Nov 28 13:42:16 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 28 Nov 2017 13:42:16 +0000
Subject: RFR: 8182758: Remove the Native-Header Generation Tool (javah)
In-Reply-To: <5A04E7F3.5000700@oracle.com>
References: <5A04E7F3.5000700@oracle.com>
Message-ID: <c830f294-3e7d-1fbc-e908-0c55e910d388@oracle.com>

Looks great. Only doubt: do we have enough tests for the javah 
replacement? I see that this patch removes several tests and, while I 
agree they don't make sense in the new, javac-driven world, I wonder if 
some of those tests should be converted in order to stress similar edge 
cases in the new counterpart. That said - the 'new' tests under 
test/tools/javac/nativeHeaders/javahComparison/ seems very 
comprehensive, so they probably already cover whatever was covered by 
the old tests.

Maurizio


On 09/11/17 23:42, Jonathan Gibbons wrote:
> Please review a fix to remove the javah tool, as previously advertised
> in JDK-8152360. (The replacement is to use the javac -h option.)
>
> Not surprisingly, most of this is removing code, with just a couple of 
> src/
> files being modified, as well as some tests.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8182758
> Webrev: http://cr.openjdk.java.net/~jjg/8182758/webrev.00/
>
> -- Jon


From jan.lahoda at oracle.com  Tue Nov 28 14:16:19 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 28 Nov 2017 15:16:19 +0100
Subject: RFR: JDK-8191981: javac crash when detecting lambda candidates
In-Reply-To: <34820328-f732-1c39-e015-da476c1f33e1@oracle.com>
References: <5A1D4C8C.10307@oracle.com>
 <34820328-f732-1c39-e015-da476c1f33e1@oracle.com>
Message-ID: <5A1D6FB3.9040607@oracle.com>

On 28.11.2017 14:13, Maurizio Cimadamore wrote:
> Your fix looks fine - unfortunately the
> 'ArguymentAttr.withLocalCacheContext' was created for this very reason,
> but I think that approach is not sufficient to fully disable the cache.
> It will simply avoid cache changes to propagate out - while here you
> want something which basically disables the cache entirely.

I think withLocalCacheContext isolates well the speculative analyzer 
attribution from the outter attribution (and vice versa). But I think 
the issue here is that inside the speculative analyzer attribution two 
distinct trees are using the same slot, which leads to the clash in the 
cache and the exception.

Jan

>
> Maurizio
>
>
> On 28/11/17 11:46, Jan Lahoda wrote:
>> Hi,
>>
>> Consider this code:
>> ---
>> public class LambdaWithMethod {
>>     public static void run(Runnable r) {
>>         run(new Runnable() {
>>             public void run() {
>>                 put(get());
>>             }
>>         });
>>     }
>>     private static String get() { return null; }
>>     private static void put(String i) {}
>> }
>> ---
>>
>> When detecting lambda candidates, this crashes javac (please see the
>> bug for full exception):
>> ---
>> $ javac -XDfind=lambda /tmp/LambdaWithMethod.java
>> [snip]
>> java.lang.AssertionError: Analyzer error when processing: [snip]
>> at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162)
>> at
>> jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:562)
>>
>> [snip]
>> ---
>>
>> The underlying exception is:
>> ---
>> java.lang.ClassCastException:
>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation cannot
>> be cast to jdk.compiler/com.sun.tools.javac.tree.JCTree$JCLambda
>>         at
>> jdk.compiler/com.sun.tools.javac.comp.ArgumentAttr$ExplicitLambdaType.dup(ArgumentAttr.java:456)
>>
>>         at
>> jdk.compiler/com.sun.tools.javac.comp.ArgumentAttr.processArg(ArgumentAttr.java:237)
>>
>> [snip]
>> ---
>>
>> (Full exception in the bug.)
>>
>> The problem appears to be that when the trial lambda node (that
>> replaces the anonymous class) is created, there is no explicit
>> position set, and so the last position set is used. And the
>> ArgumentAttr.argumentTypeCache uses the position as key, and so the
>> value for "get()" is (appears to be) used for the lambda, which leads
>> to the crash.
>>
>> Bug; https://bugs.openjdk.java.net/browse/JDK-8191981
>> Proposed patch: http://cr.openjdk.java.net/~jlahoda/8191981/webrev.00
>>
>> How does this look?
>>
>> Thanks,
>>    Jan
>>
>>
>

From maurizio.cimadamore at oracle.com  Tue Nov 28 14:19:40 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 28 Nov 2017 14:19:40 +0000
Subject: RFR 8189749: Devise strategy for making source level checks more
 uniform
In-Reply-To: <af46e66f-a0b7-2a65-7ca7-cecd3bbd7a43@oracle.com>
References: <af46e66f-a0b7-2a65-7ca7-cecd3bbd7a43@oracle.com>
Message-ID: <0d223e68-de26-1e59-adad-1f57c9d28762@oracle.com>

Updated webrev here:

http://cr.openjdk.java.net/~mcimadamore/8189749-v2/

I've included a report of the diagnostics that have been tweaked by this 
webrev here to make sure that singular vs. plural is used effectively:

http://cr.openjdk.java.net/~mcimadamore/8189749-v2/diags.html

Cheers
Maurizio


On 20/10/17 19:07, Maurizio Cimadamore wrote:
> Hi,
> this biggie patch allows the treatment of source level checks to be 
> more uniform. The general problem is explained in details here:
>
> https://bugs.openjdk.java.net/browse/JDK-8189749
>
> Webrev is here:
>
> http://cr.openjdk.java.net/~mcimadamore/8189749/
>
> The way I approached this, was to create a first class entity, an enum 
> called Feature. Each 'feature' has:
>
> * a min source level (e.g. what is the min source level required to 
> compile that feature, meaning that lower levels will result in errors)
> * a max source level (e.g. what is the max source level required to 
> compile that feature, meaning that higher levels will result in errors)
> * an optional resource key
>
> The first two properties are obviously used to decided if feature XYZ 
> can be used given source level N. The last property is used to 
> automate generation of source check diagnostics. Note that this patch 
> introduce a _single_ source check diagnostic:
>
> # 0: message segment (feature), 1: string (found version), 2: string 
> (expected version)
> compiler.misc.feature.not.supported.in.source=\
> ?? {0} not supported in -source {1}\n\
> ??? (use -source {2} or higher to enable {0})
>
> And then there's a bunch of feature fragments, example:
>
> compiler.misc.feature.modules=\
> ??? modules
>
> compiler.misc.feature.diamond.and.anon.class=\
> ??? ''<>'' with anonymous inner classes
>
> compiler.misc.feature.binary.lit=\
> ??? binary literals
>
> (and many more :-))
>
> Since each feature 'knows' its fragment, it is super easy for the 
> compiler to generate the source level check diagnostic for any 
> feature. And, if you need to add a new feature, you just need to add 
> an enum value, and wired it up with the corresponding resource key - 
> done :-)
>
> Since this change affects the way in which source check diagnostics 
> are generated, quite a lot of changes were required to adjust expected 
> output in golden files. Aside from those changes, I also addressed the 
> following issues:
>
> * JavaTokenizer was not using SOURCE_LEVEL flags for its diagnostics, 
> and it was not using the new diagnostic framework to generate errors, 
> which made the porting harder - so I've fixed that
> * CALog in Completeness analyzer required a new override for an 
> AbstractLog::error variant that was probably forgotten (this was 
> required otherwise CompletenessAnalyzerTest was failing after the 
> change above)
> * Log has a 'feature' so that diagnostics marked with the SOURCE_LEVEL 
> flag can be reported only once per source. But this check was only 
> looking at the 'head' of a diagnostic, ignoring all arguments. Since 
> now all source level check diagnostics share the same head, I needed 
> to tweak the logic to also compare arguments - or else, one source 
> level check error being reported would also disable unrelated source 
> level check diags.
>
> Then there were a bunch of mechanical translation, for instance idioms 
> such as:
>
> allowSimplifiedVarargs = source.allowSimplifiedVarargs();
>
> Were rewritten as:
>
> allowSimplifiedVarargs = source.allowed(Feature.SIMPLIFIED_VARARGS);
>
> Also, in JavacParser, this idiom:
>
> checkTypeAnnotations();
>
> has been replaced with
>
> checkSourceLevel(Feature.TYPE_ANNOTATIONS);
>
> Where checkSourceLevel is a new general routine that works on any 
> Feature.
>
> Finally, where possible, I also got rid of the various boolean flags 
> of the kind 'allowPrivateMethodInInterfaces' - if the class already 
> had a 'source' field, the boolean flag can be omitted, and the check 
> can be performed on the source object itself.
>
> Cheers
> Maurizio
>
>
>


From maurizio.cimadamore at oracle.com  Tue Nov 28 14:21:18 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 28 Nov 2017 14:21:18 +0000
Subject: RFR: JDK-8191981: javac crash when detecting lambda candidates
In-Reply-To: <5A1D6FB3.9040607@oracle.com>
References: <5A1D4C8C.10307@oracle.com>
 <34820328-f732-1c39-e015-da476c1f33e1@oracle.com>
 <5A1D6FB3.9040607@oracle.com>
Message-ID: <4c5a41fa-714b-7366-28e0-8b1ff0744eb8@oracle.com>



On 28/11/17 14:16, Jan Lahoda wrote:
> On 28.11.2017 14:13, Maurizio Cimadamore wrote:
>> Your fix looks fine - unfortunately the
>> 'ArguymentAttr.withLocalCacheContext' was created for this very reason,
>> but I think that approach is not sufficient to fully disable the cache.
>> It will simply avoid cache changes to propagate out - while here you
>> want something which basically disables the cache entirely.
>
> I think withLocalCacheContext isolates well the speculative analyzer 
> attribution from the outter attribution (and vice versa). But I think 
> the issue here is that inside the speculative analyzer attribution two 
> distinct trees are using the same slot, which leads to the clash in 
> the cache and the exception.
Sure - and as I said the patch is fine.

I guess if the cache was something other than just a Map, we could set 
it to be some object which never cached anything - forcing recomputation 
all the time - which would probably be fine for analyzer and the other 
cases where we don't care about the cache (and don't want to pollute it 
also).

Maurizio
>
> Jan
>
>>
>> Maurizio
>>
>>
>> On 28/11/17 11:46, Jan Lahoda wrote:
>>> Hi,
>>>
>>> Consider this code:
>>> ---
>>> public class LambdaWithMethod {
>>> ??? public static void run(Runnable r) {
>>> ??????? run(new Runnable() {
>>> ??????????? public void run() {
>>> ??????????????? put(get());
>>> ??????????? }
>>> ??????? });
>>> ??? }
>>> ??? private static String get() { return null; }
>>> ??? private static void put(String i) {}
>>> }
>>> ---
>>>
>>> When detecting lambda candidates, this crashes javac (please see the
>>> bug for full exception):
>>> ---
>>> $ javac -XDfind=lambda /tmp/LambdaWithMethod.java
>>> [snip]
>>> java.lang.AssertionError: Analyzer error when processing: [snip]
>>> at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162)
>>> at
>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:562) 
>>>
>>>
>>> [snip]
>>> ---
>>>
>>> The underlying exception is:
>>> ---
>>> java.lang.ClassCastException:
>>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation cannot
>>> be cast to jdk.compiler/com.sun.tools.javac.tree.JCTree$JCLambda
>>> ??????? at
>>> jdk.compiler/com.sun.tools.javac.comp.ArgumentAttr$ExplicitLambdaType.dup(ArgumentAttr.java:456) 
>>>
>>>
>>> ??????? at
>>> jdk.compiler/com.sun.tools.javac.comp.ArgumentAttr.processArg(ArgumentAttr.java:237) 
>>>
>>>
>>> [snip]
>>> ---
>>>
>>> (Full exception in the bug.)
>>>
>>> The problem appears to be that when the trial lambda node (that
>>> replaces the anonymous class) is created, there is no explicit
>>> position set, and so the last position set is used. And the
>>> ArgumentAttr.argumentTypeCache uses the position as key, and so the
>>> value for "get()" is (appears to be) used for the lambda, which leads
>>> to the crash.
>>>
>>> Bug; https://bugs.openjdk.java.net/browse/JDK-8191981
>>> Proposed patch: http://cr.openjdk.java.net/~jlahoda/8191981/webrev.00
>>>
>>> How does this look?
>>>
>>> Thanks,
>>> ?? Jan
>>>
>>>
>>


From jonathan.gibbons at oracle.com  Tue Nov 28 17:34:51 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 28 Nov 2017 09:34:51 -0800
Subject: RFR: 8182758: Remove the Native-Header Generation Tool (javah)
In-Reply-To: <c830f294-3e7d-1fbc-e908-0c55e910d388@oracle.com>
References: <5A04E7F3.5000700@oracle.com>
 <c830f294-3e7d-1fbc-e908-0c55e910d388@oracle.com>
Message-ID: <ab5c2430-112f-def7-9672-506ac858ca03@oracle.com>

Hi Maurizio,

The old tests for javah were, well, old, and at least in some cases, 
inductive ... they tested against prior behavior.

By contrast, the tests for "javac -h" were written from scratch to give 
more comprehensive coverage for the different signatures. In addition, 
"javac -h" was added in JDK 8 and has been in regular use in the main 
JDK build since then, without problems.

-- Jon


On 11/28/17 5:42 AM, Maurizio Cimadamore wrote:
> Looks great. Only doubt: do we have enough tests for the javah 
> replacement? I see that this patch removes several tests and, while I 
> agree they don't make sense in the new, javac-driven world, I wonder 
> if some of those tests should be converted in order to stress similar 
> edge cases in the new counterpart. That said - the 'new' tests under 
> test/tools/javac/nativeHeaders/javahComparison/ seems very 
> comprehensive, so they probably already cover whatever was covered by 
> the old tests.
>
> Maurizio
>
>
> On 09/11/17 23:42, Jonathan Gibbons wrote:
>> Please review a fix to remove the javah tool, as previously advertised
>> in JDK-8152360. (The replacement is to use the javac -h option.)
>>
>> Not surprisingly, most of this is removing code, with just a couple 
>> of src/
>> files being modified, as well as some tests.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8182758
>> Webrev: http://cr.openjdk.java.net/~jjg/8182758/webrev.00/
>>
>> -- Jon
>


From maurizio.cimadamore at oracle.com  Tue Nov 28 18:21:05 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 28 Nov 2017 18:21:05 +0000
Subject: RFR 8178427: NPE in Infer$CheckUpperBounds
Message-ID: <bbb547ab-509f-98d8-bab1-8bd779ccf95e@oracle.com>

Hi,
please review this patch which fixes a javac crash during inference:

http://cr.openjdk.java.net/~mcimadamore/8178427/

This crash is caused by the fact that we enter in 
PartiallyInferredMethod.check() routine with a result info that has the 
target type set to void.

This is a consequence of the fact that the overloadCheck() method for 
explicit lambdas in ArgumentAttr does not report errors when you have a 
statement lambda and the statement lambda contains a 'return' statement 
that doesn't match the expected target type - more specifically, if it's 
a 'return' w/o expression, the target type must be void; if it's a 
'return E', then the target-type must be non-void.

In JDK8 we used to carry out these checks in Attr.visitReturn (during 
speculative attr), so we never really checked the guts of the return 
expression if the expected type was void, as visitReturn would throw and 
make applicability fail.

The solution is to partially replicate the Attr.visitReturn logic in 
ArgumentAttr, to make sure that we don't end up calling checks where we 
did not use to.

Since I was there, I've simplified the logic a little bit, and made it 
more explicit.

Cheers
Maurizio


From vicente.romero at oracle.com  Tue Nov 28 18:41:03 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 28 Nov 2017 13:41:03 -0500
Subject: RFR 8178427: NPE in Infer$CheckUpperBounds
In-Reply-To: <bbb547ab-509f-98d8-bab1-8bd779ccf95e@oracle.com>
References: <bbb547ab-509f-98d8-bab1-8bd779ccf95e@oracle.com>
Message-ID: <3396849c-72ed-adf1-7ae1-f34a7022eeba@oracle.com>

looks good,

Vicente

On 11/28/2017 01:21 PM, Maurizio Cimadamore wrote:
> Hi,
> please review this patch which fixes a javac crash during inference:
>
> http://cr.openjdk.java.net/~mcimadamore/8178427/
>
> This crash is caused by the fact that we enter in 
> PartiallyInferredMethod.check() routine with a result info that has 
> the target type set to void.
>
> This is a consequence of the fact that the overloadCheck() method for 
> explicit lambdas in ArgumentAttr does not report errors when you have 
> a statement lambda and the statement lambda contains a 'return' 
> statement that doesn't match the expected target type - more 
> specifically, if it's a 'return' w/o expression, the target type must 
> be void; if it's a 'return E', then the target-type must be non-void.
>
> In JDK8 we used to carry out these checks in Attr.visitReturn (during 
> speculative attr), so we never really checked the guts of the return 
> expression if the expected type was void, as visitReturn would throw 
> and make applicability fail.
>
> The solution is to partially replicate the Attr.visitReturn logic in 
> ArgumentAttr, to make sure that we don't end up calling checks where 
> we did not use to.
>
> Since I was there, I've simplified the logic a little bit, and made it 
> more explicit.
>
> Cheers
> Maurizio
>


From vicente.romero at oracle.com  Tue Nov 28 23:14:45 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 28 Nov 2017 18:14:45 -0500
Subject: RFR 8191802: Upward projection result is A<? extends Number>
 instead of A<? super Integer>
In-Reply-To: <c681e827-3325-af06-a3fa-6309dd757e40@oracle.com>
References: <5e79e2f9-19da-d726-4081-9257b9c6b241@oracle.com>
 <c681e827-3325-af06-a3fa-6309dd757e40@oracle.com>
Message-ID: <e06190da-9139-9422-61c5-3fc479ca7c90@oracle.com>

Hi,

This one is a tough one to review, so I think that we will probably need 
a couple of iterations. As mentioned earlier today in an offline chat, 
some comments at test UpperBounds seems to don't match with the type 
expected in the annotation.

It seems to me that the code could be simplified, more self documented, 
etc, if TypeProjection::visitTypeVar was not handling type variables and 
captured type variables at the same time, it doesn't feel natural either.

At TypeArgumentProjection::visitWildcardType shouldn't we consider 
returning the same type if the wildcard doesn't contain restricted 
variables? In other words: can we guarantee that every wildcard visited 
will contain restricted variables? I'm thinking about nested cases.

kind of similar comment for TypeArgumentProjection::visitType, can we 
guarantee that every time we get to this method, we are dealing with a 
type that contains restricted variables? again I'm considering nested 
cases. We have to be more careful in this case as this could imply 
issuing an error for a case for which a projection exists.

Thanks,
Vicente

On 11/27/2017 10:09 AM, Maurizio Cimadamore wrote:
>
> This is an updated version of the webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/8191802-v2/
>
> I realized that there were further discrepancies w.r.t. the spec text, 
> so I handled them all at once:
>
> * the spec has different treatment for when a type argument is a 
> wildcard and for when it's a regular type - the implementation was 
> treating both wildcards and regular types in the same way, which led 
> to inconsistencies (see JDK-8191893). I now defined separate visitors 
> for the outer projection and type argument projection parts, so that 
> the code should be easier to follow.
>
> * not all fresh types created during a projection overrode the 
> 'needStripping' method, which could lead to issue with type annotation 
> processing
>
> * the fact that TypeProjection extended from StructuralMapping had a 
> subtle issue - on the one hand, StructuralMapping has the required 
> logic to handle arrays (e.g. map component type and return new array 
> if needed) - on the other hand, with projections we need to be careful 
> - if the element type has no projection, then projection of the array 
> is also undefined. The impl was returning an array of <null> which was 
> then causing crashes inside the compiler. This is now called out 
> explicitly.
>
> Maurizio
>
>
> On 24/11/17 17:39, Maurizio Cimadamore wrote:
>>
>> Hi,
>> please review the fix for JDK-8191802:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8191802/
>>
>> This is a conformance issue with local variable type inference - the 
>> specification text for upper projection says this (section 4.10.5):
>>
>> "The upward projection of a type T with respect to a set of 
>> restricted type variables is defined as follows:
>>
>> ??? [...]
>>
>> ??? If T is a parameterized class type or a parameterized interface 
>> type, G<A1, ..., An>, then the result is G<A1', ..., An'>, where, for 
>> 1 ? i ? n, Ai' is derived from Ai as follows:
>>
>> ??????? [...]
>> ??????? If Ai is a type that mentions a restricted type variable, 
>> then Ai' is a wildcard. Let U be the upward projection of Ai. There 
>> are three cases:
>> *If U is not Object, and if either the declared bound of the ith 
>> parameter of G, Bi, mentions a type parameter of G, or Bi is not a 
>> subtype of U, then Ai' is an upper-bounded wildcard, ? extends U.*
>> ??????????? Otherwise, if the downward projection of Ai is L, then 
>> Ai' is a lower-bounded wildcard, ? super L.
>> ??????????? Otherwise, the downward projection of Ai is undefined and 
>> Ai' is an unbounded wildcard, ?."
>>
>> The text in bold is not implemented accurately by javac. What javac 
>> used to do was simply to throw away the upper bound and favor the 
>> lower bound if the upper was Object.
>>
>> The spec text is much more subtle and precise, allowing javac to 
>> throw away upper bounds that do not add any extra information w.r.t. 
>> declared bounds.
>>
>> As a result of this change, there are few places where the compiler 
>> used to infer A<? extend B> (where B was same type as declared bound) 
>> and now it infers A<?> as per spec - this caused few changes in the 
>> jshell test TypeNameTest.
>>
>> I've added a lvti harness test to verify the assertions in the above 
>> paragraph.
>>
>> Cheers
>> Maurizio
>>
>

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

From vicente.romero at oracle.com  Wed Nov 29 02:22:41 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 28 Nov 2017 21:22:41 -0500
Subject: RFR 8191802: Upward projection result is A<? extends Number>
 instead of A<? super Integer>
In-Reply-To: <e06190da-9139-9422-61c5-3fc479ca7c90@oracle.com>
References: <5e79e2f9-19da-d726-4081-9257b9c6b241@oracle.com>
 <c681e827-3325-af06-a3fa-6309dd757e40@oracle.com>
 <e06190da-9139-9422-61c5-3fc479ca7c90@oracle.com>
Message-ID: <498838fe-c0b2-4d60-d33d-29ff87b825ad@oracle.com>



On 11/28/2017 06:14 PM, Vicente Romero wrote:
> Hi,
>
> This one is a tough one to review, so I think that we will probably 
> need a couple of iterations. As mentioned earlier today in an offline 
> chat, some comments at test UpperBounds seems to don't match with the 
> type expected in the annotation.
>
> It seems to me that the code could be simplified, more self 
> documented, etc, if TypeProjection::visitTypeVar was not handling type 
> variables and captured type variables at the same time, it doesn't 
> feel natural either.

never mind about the two below, I was checking the code again and I 
think that the case I was thinking about can't happen. I missed that 
visitor TypeProjection is invoked from TypeArgumentProjection


>
> At TypeArgumentProjection::visitWildcardType shouldn't we consider 
> returning the same type if the wildcard doesn't contain restricted 
> variables? In other words: can we guarantee that every wildcard 
> visited will contain restricted variables? I'm thinking about nested 
> cases.
>
> kind of similar comment for TypeArgumentProjection::visitType, can we 
> guarantee that every time we get to this method, we are dealing with a 
> type that contains restricted variables? again I'm considering nested 
> cases. We have to be more careful in this case as this could imply 
> issuing an error for a case for which a projection exists.
>
> Thanks,
> Vicente

Vicente

>
> On 11/27/2017 10:09 AM, Maurizio Cimadamore wrote:
>>
>> This is an updated version of the webrev:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8191802-v2/
>>
>> I realized that there were further discrepancies w.r.t. the spec 
>> text, so I handled them all at once:
>>
>> * the spec has different treatment for when a type argument is a 
>> wildcard and for when it's a regular type - the implementation was 
>> treating both wildcards and regular types in the same way, which led 
>> to inconsistencies (see JDK-8191893). I now defined separate visitors 
>> for the outer projection and type argument projection parts, so that 
>> the code should be easier to follow.
>>
>> * not all fresh types created during a projection overrode the 
>> 'needStripping' method, which could lead to issue with type 
>> annotation processing
>>
>> * the fact that TypeProjection extended from StructuralMapping had a 
>> subtle issue - on the one hand, StructuralMapping has the required 
>> logic to handle arrays (e.g. map component type and return new array 
>> if needed) - on the other hand, with projections we need to be 
>> careful - if the element type has no projection, then projection of 
>> the array is also undefined. The impl was returning an array of 
>> <null> which was then causing crashes inside the compiler. This is 
>> now called out explicitly.
>>
>> Maurizio
>>
>>
>> On 24/11/17 17:39, Maurizio Cimadamore wrote:
>>>
>>> Hi,
>>> please review the fix for JDK-8191802:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/8191802/
>>>
>>> This is a conformance issue with local variable type inference - the 
>>> specification text for upper projection says this (section 4.10.5):
>>>
>>> "The upward projection of a type T with respect to a set of 
>>> restricted type variables is defined as follows:
>>>
>>> ??? [...]
>>>
>>> ??? If T is a parameterized class type or a parameterized interface 
>>> type, G<A1, ..., An>, then the result is G<A1', ..., An'>, where, 
>>> for 1 ? i ? n, Ai' is derived from Ai as follows:
>>>
>>> ??????? [...]
>>> ??????? If Ai is a type that mentions a restricted type variable, 
>>> then Ai' is a wildcard. Let U be the upward projection of Ai. There 
>>> are three cases:
>>> *If U is not Object, and if either the declared bound of the ith 
>>> parameter of G, Bi, mentions a type parameter of G, or Bi is not a 
>>> subtype of U, then Ai' is an upper-bounded wildcard, ? extends U.*
>>> ??????????? Otherwise, if the downward projection of Ai is L, then 
>>> Ai' is a lower-bounded wildcard, ? super L.
>>> ??????????? Otherwise, the downward projection of Ai is undefined 
>>> and Ai' is an unbounded wildcard, ?."
>>>
>>> The text in bold is not implemented accurately by javac. What javac 
>>> used to do was simply to throw away the upper bound and favor the 
>>> lower bound if the upper was Object.
>>>
>>> The spec text is much more subtle and precise, allowing javac to 
>>> throw away upper bounds that do not add any extra information w.r.t. 
>>> declared bounds.
>>>
>>> As a result of this change, there are few places where the compiler 
>>> used to infer A<? extend B> (where B was same type as declared 
>>> bound) and now it infers A<?> as per spec - this caused few changes 
>>> in the jshell test TypeNameTest.
>>>
>>> I've added a lvti harness test to verify the assertions in the above 
>>> paragraph.
>>>
>>> Cheers
>>> Maurizio
>>>
>>
>

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

From vicente.romero at oracle.com  Wed Nov 29 03:25:31 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 28 Nov 2017 22:25:31 -0500
Subject: RFR 8191802: Upward projection result is A<? extends Number>
 instead of A<? super Integer>
In-Reply-To: <c681e827-3325-af06-a3fa-6309dd757e40@oracle.com>
References: <5e79e2f9-19da-d726-4081-9257b9c6b241@oracle.com>
 <c681e827-3325-af06-a3fa-6309dd757e40@oracle.com>
Message-ID: <6e8affd0-c566-8edb-18f1-34b73b752de7@oracle.com>

nit: at TypeArgumentProjection::visitType the code could be more explicit:

Type upper = t.map(TypeProjection.this, pkind);
 ?????? Type lower = t.map(TypeProjection.this, pkind.complement());

 ?????????????????????????????? ||
 ????????????????????????????? \? /
 ?????????????????????????????? \/

 ?????? Type upper = t.map(TypeProjection.this, ProjectionKind.UPWARDS);
 ?????? Type lower = t.map(TypeProjection.this, ProjectionKind.DOWNWARDS);


side: the spec says that the downward projection is a partial function 
so it could be assumed that the upward projection is a total function, 
but then at Check::checkLocalVarType an error message is issued if the 
compiler couldn't find the upward projection for a given type. If this 
is possible then the spec should be updated saying that the upward 
projection is also a partial function, if the upward projection is a 
total function and the compiler fail to find it because the initializer 
expression is incorrect, there is a self reference to the variable, 
etc., then IMO the error message should make a reference to the 
incorrect initializer expression as the root cause of the problem. The 
fact that the upward projection couldn't be determined is just a 
consequence of that and there shouldn't be an additional error message 
to state that.

Thanks,
Vicente

On 11/27/2017 10:09 AM, Maurizio Cimadamore wrote:
>
> This is an updated version of the webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/8191802-v2/
>
> I realized that there were further discrepancies w.r.t. the spec text, 
> so I handled them all at once:
>
> * the spec has different treatment for when a type argument is a 
> wildcard and for when it's a regular type - the implementation was 
> treating both wildcards and regular types in the same way, which led 
> to inconsistencies (see JDK-8191893). I now defined separate visitors 
> for the outer projection and type argument projection parts, so that 
> the code should be easier to follow.
>
> * not all fresh types created during a projection overrode the 
> 'needStripping' method, which could lead to issue with type annotation 
> processing
>
> * the fact that TypeProjection extended from StructuralMapping had a 
> subtle issue - on the one hand, StructuralMapping has the required 
> logic to handle arrays (e.g. map component type and return new array 
> if needed) - on the other hand, with projections we need to be careful 
> - if the element type has no projection, then projection of the array 
> is also undefined. The impl was returning an array of <null> which was 
> then causing crashes inside the compiler. This is now called out 
> explicitly.
>
> Maurizio
>
>
> On 24/11/17 17:39, Maurizio Cimadamore wrote:
>>
>> Hi,
>> please review the fix for JDK-8191802:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8191802/
>>
>> This is a conformance issue with local variable type inference - the 
>> specification text for upper projection says this (section 4.10.5):
>>
>> "The upward projection of a type T with respect to a set of 
>> restricted type variables is defined as follows:
>>
>> ??? [...]
>>
>> ??? If T is a parameterized class type or a parameterized interface 
>> type, G<A1, ..., An>, then the result is G<A1', ..., An'>, where, for 
>> 1 ? i ? n, Ai' is derived from Ai as follows:
>>
>> ??????? [...]
>> ??????? If Ai is a type that mentions a restricted type variable, 
>> then Ai' is a wildcard. Let U be the upward projection of Ai. There 
>> are three cases:
>> *If U is not Object, and if either the declared bound of the ith 
>> parameter of G, Bi, mentions a type parameter of G, or Bi is not a 
>> subtype of U, then Ai' is an upper-bounded wildcard, ? extends U.*
>> ??????????? Otherwise, if the downward projection of Ai is L, then 
>> Ai' is a lower-bounded wildcard, ? super L.
>> ??????????? Otherwise, the downward projection of Ai is undefined and 
>> Ai' is an unbounded wildcard, ?."
>>
>> The text in bold is not implemented accurately by javac. What javac 
>> used to do was simply to throw away the upper bound and favor the 
>> lower bound if the upper was Object.
>>
>> The spec text is much more subtle and precise, allowing javac to 
>> throw away upper bounds that do not add any extra information w.r.t. 
>> declared bounds.
>>
>> As a result of this change, there are few places where the compiler 
>> used to infer A<? extend B> (where B was same type as declared bound) 
>> and now it infers A<?> as per spec - this caused few changes in the 
>> jshell test TypeNameTest.
>>
>> I've added a lvti harness test to verify the assertions in the above 
>> paragraph.
>>
>> Cheers
>> Maurizio
>>
>

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

From maurizio.cimadamore at oracle.com  Wed Nov 29 10:33:21 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 29 Nov 2017 10:33:21 +0000
Subject: RFR 8191802: Upward projection result is A<? extends Number>
 instead of A<? super Integer>
In-Reply-To: <498838fe-c0b2-4d60-d33d-29ff87b825ad@oracle.com>
References: <5e79e2f9-19da-d726-4081-9257b9c6b241@oracle.com>
 <c681e827-3325-af06-a3fa-6309dd757e40@oracle.com>
 <e06190da-9139-9422-61c5-3fc479ca7c90@oracle.com>
 <498838fe-c0b2-4d60-d33d-29ff87b825ad@oracle.com>
Message-ID: <ee26e198-2e03-a8af-268c-e73446b9e883@oracle.com>



On 29/11/17 02:22, Vicente Romero wrote:
>
>
> On 11/28/2017 06:14 PM, Vicente Romero wrote:
>> Hi,
>>
>> This one is a tough one to review, so I think that we will probably 
>> need a couple of iterations. As mentioned earlier today in an offline 
>> chat, some comments at test UpperBounds seems to don't match with the 
>> type expected in the annotation.
>>
>> It seems to me that the code could be simplified, more self 
>> documented, etc, if TypeProjection::visitTypeVar was not handling 
>> type variables and captured type variables at the same time, it 
>> doesn't feel natural either.
>
> never mind about the two below, I was checking the code again and I 
> think that the case I was thinking about can't happen. I missed that 
> visitor TypeProjection is invoked from TypeArgumentProjection
Exactly - was about to say that :-)

Maurizio
>
>
>>
>> At TypeArgumentProjection::visitWildcardType shouldn't we consider 
>> returning the same type if the wildcard doesn't contain restricted 
>> variables? In other words: can we guarantee that every wildcard 
>> visited will contain restricted variables? I'm thinking about nested 
>> cases.
>>
>> kind of similar comment for TypeArgumentProjection::visitType, can we 
>> guarantee that every time we get to this method, we are dealing with 
>> a type that contains restricted variables? again I'm considering 
>> nested cases. We have to be more careful in this case as this could 
>> imply issuing an error for a case for which a projection exists.
>>
>> Thanks,
>> Vicente
>
> Vicente
>
>>
>> On 11/27/2017 10:09 AM, Maurizio Cimadamore wrote:
>>>
>>> This is an updated version of the webrev:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/8191802-v2/
>>>
>>> I realized that there were further discrepancies w.r.t. the spec 
>>> text, so I handled them all at once:
>>>
>>> * the spec has different treatment for when a type argument is a 
>>> wildcard and for when it's a regular type - the implementation was 
>>> treating both wildcards and regular types in the same way, which led 
>>> to inconsistencies (see JDK-8191893). I now defined separate 
>>> visitors for the outer projection and type argument projection 
>>> parts, so that the code should be easier to follow.
>>>
>>> * not all fresh types created during a projection overrode the 
>>> 'needStripping' method, which could lead to issue with type 
>>> annotation processing
>>>
>>> * the fact that TypeProjection extended from StructuralMapping had a 
>>> subtle issue - on the one hand, StructuralMapping has the required 
>>> logic to handle arrays (e.g. map component type and return new array 
>>> if needed) - on the other hand, with projections we need to be 
>>> careful - if the element type has no projection, then projection of 
>>> the array is also undefined. The impl was returning an array of 
>>> <null> which was then causing crashes inside the compiler. This is 
>>> now called out explicitly.
>>>
>>> Maurizio
>>>
>>>
>>> On 24/11/17 17:39, Maurizio Cimadamore wrote:
>>>>
>>>> Hi,
>>>> please review the fix for JDK-8191802:
>>>>
>>>> http://cr.openjdk.java.net/~mcimadamore/8191802/
>>>>
>>>> This is a conformance issue with local variable type inference - 
>>>> the specification text for upper projection says this (section 4.10.5):
>>>>
>>>> "The upward projection of a type T with respect to a set of 
>>>> restricted type variables is defined as follows:
>>>>
>>>> ??? [...]
>>>>
>>>> ??? If T is a parameterized class type or a parameterized interface 
>>>> type, G<A1, ..., An>, then the result is G<A1', ..., An'>, where, 
>>>> for 1 ? i ? n, Ai' is derived from Ai as follows:
>>>>
>>>> ??????? [...]
>>>> ??????? If Ai is a type that mentions a restricted type variable, 
>>>> then Ai' is a wildcard. Let U be the upward projection of Ai. There 
>>>> are three cases:
>>>> *If U is not Object, and if either the declared bound of the ith 
>>>> parameter of G, Bi, mentions a type parameter of G, or Bi is not a 
>>>> subtype of U, then Ai' is an upper-bounded wildcard, ? extends U.*
>>>> ??????????? Otherwise, if the downward projection of Ai is L, then 
>>>> Ai' is a lower-bounded wildcard, ? super L.
>>>> ??????????? Otherwise, the downward projection of Ai is undefined 
>>>> and Ai' is an unbounded wildcard, ?."
>>>>
>>>> The text in bold is not implemented accurately by javac. What javac 
>>>> used to do was simply to throw away the upper bound and favor the 
>>>> lower bound if the upper was Object.
>>>>
>>>> The spec text is much more subtle and precise, allowing javac to 
>>>> throw away upper bounds that do not add any extra information 
>>>> w.r.t. declared bounds.
>>>>
>>>> As a result of this change, there are few places where the compiler 
>>>> used to infer A<? extend B> (where B was same type as declared 
>>>> bound) and now it infers A<?> as per spec - this caused few changes 
>>>> in the jshell test TypeNameTest.
>>>>
>>>> I've added a lvti harness test to verify the assertions in the 
>>>> above paragraph.
>>>>
>>>> Cheers
>>>> Maurizio
>>>>
>>>
>>
>

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

From maurizio.cimadamore at oracle.com  Wed Nov 29 12:39:49 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 29 Nov 2017 12:39:49 +0000
Subject: RFR 8191802: Upward projection result is A<? extends Number>
 instead of A<? super Integer>
In-Reply-To: <6e8affd0-c566-8edb-18f1-34b73b752de7@oracle.com>
References: <5e79e2f9-19da-d726-4081-9257b9c6b241@oracle.com>
 <c681e827-3325-af06-a3fa-6309dd757e40@oracle.com>
 <6e8affd0-c566-8edb-18f1-34b73b752de7@oracle.com>
Message-ID: <239cba48-adf6-df68-ad66-f3aed4ac1735@oracle.com>



On 29/11/17 03:25, Vicente Romero wrote:
> nit: at TypeArgumentProjection::visitType the code could be more explicit:
>
> Type upper = t.map(TypeProjection.this, pkind);
> ?????? Type lower = t.map(TypeProjection.this, pkind.complement());
>
> ?????????????????????????????? ||
> ????????????????????????????? \? /
> ?????????????????????????????? \/
>
> ?????? Type upper = t.map(TypeProjection.this, ProjectionKind.UPWARDS);
> ?????? Type lower = t.map(TypeProjection.this, ProjectionKind.DOWNWARDS);

I think you are right - since that code doesn't make sense for pkind? = 
downwards (in which case we prematurely exit with the null type), the 
remainder of this method can assume that pkind = UPWARDS and 
pkind.complement() = DOWNWARDS.
>
> side: the spec says that the downward projection is a partial function 
> so it could be assumed that the upward projection is a total function, 
> but then at Check::checkLocalVarType an error message is issued if the 
> compiler couldn't find the upward projection for a given type. If this 
> is possible then the spec should be updated saying that the upward 
> projection is also a partial function, if the upward projection is a 
> total function and the compiler fail to find it because the 
> initializer expression is incorrect, there is a self reference to the 
> variable, etc., then IMO the error message should make a reference to 
> the incorrect initializer expression as the root cause of the problem. 
> The fact that the upward projection couldn't be determined is just a 
> consequence of that and there shouldn't be an additional error message 
> to state that.
upper projection is a total function - downward is not. The check you 
see in checkLocalVarType is not to check that the outcome of upward 
projection is defined (it always should be) - but is to check as to 
whether the type of the initializer expression is the null type, in 
which case it should be an error. I agree that as things are now is a 
bit messy because the code does the check AFTER the projection, but this 
is relying on the fact that the projection doesn't alter those types. 
Anyway, if it makes things clearer, I can move the check for VOID and 
NULL to _before_ the projection. Would that help?

Maurizio
>
> Thanks,
> Vicente
>
> On 11/27/2017 10:09 AM, Maurizio Cimadamore wrote:
>>
>> This is an updated version of the webrev:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8191802-v2/
>>
>> I realized that there were further discrepancies w.r.t. the spec 
>> text, so I handled them all at once:
>>
>> * the spec has different treatment for when a type argument is a 
>> wildcard and for when it's a regular type - the implementation was 
>> treating both wildcards and regular types in the same way, which led 
>> to inconsistencies (see JDK-8191893). I now defined separate visitors 
>> for the outer projection and type argument projection parts, so that 
>> the code should be easier to follow.
>>
>> * not all fresh types created during a projection overrode the 
>> 'needStripping' method, which could lead to issue with type 
>> annotation processing
>>
>> * the fact that TypeProjection extended from StructuralMapping had a 
>> subtle issue - on the one hand, StructuralMapping has the required 
>> logic to handle arrays (e.g. map component type and return new array 
>> if needed) - on the other hand, with projections we need to be 
>> careful - if the element type has no projection, then projection of 
>> the array is also undefined. The impl was returning an array of 
>> <null> which was then causing crashes inside the compiler. This is 
>> now called out explicitly.
>>
>> Maurizio
>>
>>
>> On 24/11/17 17:39, Maurizio Cimadamore wrote:
>>>
>>> Hi,
>>> please review the fix for JDK-8191802:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/8191802/
>>>
>>> This is a conformance issue with local variable type inference - the 
>>> specification text for upper projection says this (section 4.10.5):
>>>
>>> "The upward projection of a type T with respect to a set of 
>>> restricted type variables is defined as follows:
>>>
>>> ??? [...]
>>>
>>> ??? If T is a parameterized class type or a parameterized interface 
>>> type, G<A1, ..., An>, then the result is G<A1', ..., An'>, where, 
>>> for 1 ? i ? n, Ai' is derived from Ai as follows:
>>>
>>> ??????? [...]
>>> ??????? If Ai is a type that mentions a restricted type variable, 
>>> then Ai' is a wildcard. Let U be the upward projection of Ai. There 
>>> are three cases:
>>> *If U is not Object, and if either the declared bound of the ith 
>>> parameter of G, Bi, mentions a type parameter of G, or Bi is not a 
>>> subtype of U, then Ai' is an upper-bounded wildcard, ? extends U.*
>>> ??????????? Otherwise, if the downward projection of Ai is L, then 
>>> Ai' is a lower-bounded wildcard, ? super L.
>>> ??????????? Otherwise, the downward projection of Ai is undefined 
>>> and Ai' is an unbounded wildcard, ?."
>>>
>>> The text in bold is not implemented accurately by javac. What javac 
>>> used to do was simply to throw away the upper bound and favor the 
>>> lower bound if the upper was Object.
>>>
>>> The spec text is much more subtle and precise, allowing javac to 
>>> throw away upper bounds that do not add any extra information w.r.t. 
>>> declared bounds.
>>>
>>> As a result of this change, there are few places where the compiler 
>>> used to infer A<? extend B> (where B was same type as declared 
>>> bound) and now it infers A<?> as per spec - this caused few changes 
>>> in the jshell test TypeNameTest.
>>>
>>> I've added a lvti harness test to verify the assertions in the above 
>>> paragraph.
>>>
>>> Cheers
>>> Maurizio
>>>
>>
>

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

From vicente.romero at oracle.com  Wed Nov 29 12:58:13 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 29 Nov 2017 07:58:13 -0500
Subject: RFR 8191802: Upward projection result is A<? extends Number>
 instead of A<? super Integer>
In-Reply-To: <239cba48-adf6-df68-ad66-f3aed4ac1735@oracle.com>
References: <5e79e2f9-19da-d726-4081-9257b9c6b241@oracle.com>
 <c681e827-3325-af06-a3fa-6309dd757e40@oracle.com>
 <6e8affd0-c566-8edb-18f1-34b73b752de7@oracle.com>
 <239cba48-adf6-df68-ad66-f3aed4ac1735@oracle.com>
Message-ID: <b3c33235-840a-d2a6-31d6-690f8dd42ac8@oracle.com>



On 11/29/2017 07:39 AM, Maurizio Cimadamore wrote:
>
>
>
> On 29/11/17 03:25, Vicente Romero wrote:
>> nit: at TypeArgumentProjection::visitType the code could be more 
>> explicit:
>>
>> Type upper = t.map(TypeProjection.this, pkind);
>> ?????? Type lower = t.map(TypeProjection.this, pkind.complement());
>>
>> ?????????????????????????????? ||
>> ????????????????????????????? \? /
>> ?????????????????????????????? \/
>>
>> ?????? Type upper = t.map(TypeProjection.this, ProjectionKind.UPWARDS);
>> ?????? Type lower = t.map(TypeProjection.this, ProjectionKind.DOWNWARDS);
>
> I think you are right - since that code doesn't make sense for pkind? 
> = downwards (in which case we prematurely exit with the null type), 
> the remainder of this method can assume that pkind = UPWARDS and 
> pkind.complement() = DOWNWARDS.
>>
>> side: the spec says that the downward projection is a partial 
>> function so it could be assumed that the upward projection is a total 
>> function, but then at Check::checkLocalVarType an error message is 
>> issued if the compiler couldn't find the upward projection for a 
>> given type. If this is possible then the spec should be updated 
>> saying that the upward projection is also a partial function, if the 
>> upward projection is a total function and the compiler fail to find 
>> it because the initializer expression is incorrect, there is a self 
>> reference to the variable, etc., then IMO the error message should 
>> make a reference to the incorrect initializer expression as the root 
>> cause of the problem. The fact that the upward projection couldn't be 
>> determined is just a consequence of that and there shouldn't be an 
>> additional error message to state that.
> upper projection is a total function - downward is not. The check you 
> see in checkLocalVarType is not to check that the outcome of upward 
> projection is defined (it always should be) - but is to check as to 
> whether the type of the initializer expression is the null type, in 
> which case it should be an error. I agree that as things are now is a 
> bit messy because the code does the check AFTER the projection, but 
> this is relying on the fact that the projection doesn't alter those 
> types. Anyway, if it makes things clearer, I can move the check for 
> VOID and NULL to _before_ the projection. Would that help?

yes I think that moving the check before the projection would make more 
sense

>
> Maurizio

Vicente

>>
>> Thanks,
>> Vicente
>>
>> On 11/27/2017 10:09 AM, Maurizio Cimadamore wrote:
>>>
>>> This is an updated version of the webrev:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/8191802-v2/
>>>
>>> I realized that there were further discrepancies w.r.t. the spec 
>>> text, so I handled them all at once:
>>>
>>> * the spec has different treatment for when a type argument is a 
>>> wildcard and for when it's a regular type - the implementation was 
>>> treating both wildcards and regular types in the same way, which led 
>>> to inconsistencies (see JDK-8191893). I now defined separate 
>>> visitors for the outer projection and type argument projection 
>>> parts, so that the code should be easier to follow.
>>>
>>> * not all fresh types created during a projection overrode the 
>>> 'needStripping' method, which could lead to issue with type 
>>> annotation processing
>>>
>>> * the fact that TypeProjection extended from StructuralMapping had a 
>>> subtle issue - on the one hand, StructuralMapping has the required 
>>> logic to handle arrays (e.g. map component type and return new array 
>>> if needed) - on the other hand, with projections we need to be 
>>> careful - if the element type has no projection, then projection of 
>>> the array is also undefined. The impl was returning an array of 
>>> <null> which was then causing crashes inside the compiler. This is 
>>> now called out explicitly.
>>>
>>> Maurizio
>>>
>>>
>>> On 24/11/17 17:39, Maurizio Cimadamore wrote:
>>>>
>>>> Hi,
>>>> please review the fix for JDK-8191802:
>>>>
>>>> http://cr.openjdk.java.net/~mcimadamore/8191802/
>>>>
>>>> This is a conformance issue with local variable type inference - 
>>>> the specification text for upper projection says this (section 4.10.5):
>>>>
>>>> "The upward projection of a type T with respect to a set of 
>>>> restricted type variables is defined as follows:
>>>>
>>>> ??? [...]
>>>>
>>>> ??? If T is a parameterized class type or a parameterized interface 
>>>> type, G<A1, ..., An>, then the result is G<A1', ..., An'>, where, 
>>>> for 1 ? i ? n, Ai' is derived from Ai as follows:
>>>>
>>>> ??????? [...]
>>>> ??????? If Ai is a type that mentions a restricted type variable, 
>>>> then Ai' is a wildcard. Let U be the upward projection of Ai. There 
>>>> are three cases:
>>>> *If U is not Object, and if either the declared bound of the ith 
>>>> parameter of G, Bi, mentions a type parameter of G, or Bi is not a 
>>>> subtype of U, then Ai' is an upper-bounded wildcard, ? extends U.*
>>>> ??????????? Otherwise, if the downward projection of Ai is L, then 
>>>> Ai' is a lower-bounded wildcard, ? super L.
>>>> ??????????? Otherwise, the downward projection of Ai is undefined 
>>>> and Ai' is an unbounded wildcard, ?."
>>>>
>>>> The text in bold is not implemented accurately by javac. What javac 
>>>> used to do was simply to throw away the upper bound and favor the 
>>>> lower bound if the upper was Object.
>>>>
>>>> The spec text is much more subtle and precise, allowing javac to 
>>>> throw away upper bounds that do not add any extra information 
>>>> w.r.t. declared bounds.
>>>>
>>>> As a result of this change, there are few places where the compiler 
>>>> used to infer A<? extend B> (where B was same type as declared 
>>>> bound) and now it infers A<?> as per spec - this caused few changes 
>>>> in the jshell test TypeNameTest.
>>>>
>>>> I've added a lvti harness test to verify the assertions in the 
>>>> above paragraph.
>>>>
>>>> Cheers
>>>> Maurizio
>>>>
>>>
>>
>

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

From aph at redhat.com  Wed Nov 29 15:25:42 2017
From: aph at redhat.com (Andrew Haley)
Date: Wed, 29 Nov 2017 15:25:42 +0000
Subject: RFR(preliminary): JDK-8190428 Minimal Constant Dynamic support
 for AArch64
In-Reply-To: <14f01d52-49e6-08d9-f5fa-c37499a104c1@bell-sw.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <14f01d52-49e6-08d9-f5fa-c37499a104c1@bell-sw.com>
Message-ID: <4b1a8079-a579-6c64-cb59-e30ff4f86d65@redhat.com>

On 29/11/17 14:30, Dmitry Samersov wrote:
> Everybody,
> 
> Please review a port of Minimal Constant Dynamic patch to AArch64 platform.
> 
> http://cr.openjdk.java.net/~dsamersoff/JDK-8190428.condy/webrev.03/
> 
> Any comments are much appreciated.

These lines should not be in macroAssembler:

1778 void MacroAssembler::load_float(Address src) {
1779   ldrs(v0, src);
1780 }
1781
1782 void MacroAssembler::load_double(Address src) {
1783   ldrd(v0, src);
1784 }
1785

 598   // Load float value from 'address'. The value is loaded onto the FPU stack.
 599   void load_float(Address src);
 600   void load_double(Address src);
 601

I realize that we're not at all consistent about this stuff, but
we don't need it in macroAssembler.  It can go in interp_masm.

This is a bit odd:

 464   { // Check for the null sentinel.
 465     // If we just called the VM, that already did the mapping for us,
 466     // but it's harmless to retry.
 467     Label notNull;
 468
 469     // Store null_sentinel address to get its value later
 470     __ movptr(rarg, (uintptr_t)Universe::the_null_sentinel_addr());
 471     __ ldr(tmp, rarg);

I think this one should be ldr(tmp, Address(rarg));

 472     __ cmp(result, tmp);
 473     __ br(Assembler::NE, notNull);
 474     __ mov(result, 0);  // NULL object reference
 475     __ bind(notNull);
 476

The rest of it looks fine.  Thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From maurizio.cimadamore at oracle.com  Wed Nov 29 16:43:12 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 29 Nov 2017 16:43:12 +0000
Subject: RFR 8191802: Upward projection result is A<? extends Number>
 instead of A<? super Integer>
In-Reply-To: <c681e827-3325-af06-a3fa-6309dd757e40@oracle.com>
References: <5e79e2f9-19da-d726-4081-9257b9c6b241@oracle.com>
 <c681e827-3325-af06-a3fa-6309dd757e40@oracle.com>
Message-ID: <0e657f3e-8b0e-a1b9-2988-613133ac14ba@oracle.com>

Here's another update:

http://cr.openjdk.java.net/~mcimadamore/8191802-v3/

* fixed the comments in the test UpperBounds.java
* used explicit UPWARDS and DOWNWARDS instead of 
pkind/pkind.complement() in TypeArgumentProjection::visitType
* moved the check for VOID/NULL in Check::checkLocalVarType

Maurizio


On 27/11/17 15:09, Maurizio Cimadamore wrote:
>
> This is an updated version of the webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/8191802-v2/
>
> I realized that there were further discrepancies w.r.t. the spec text, 
> so I handled them all at once:
>
> * the spec has different treatment for when a type argument is a 
> wildcard and for when it's a regular type - the implementation was 
> treating both wildcards and regular types in the same way, which led 
> to inconsistencies (see JDK-8191893). I now defined separate visitors 
> for the outer projection and type argument projection parts, so that 
> the code should be easier to follow.
>
> * not all fresh types created during a projection overrode the 
> 'needStripping' method, which could lead to issue with type annotation 
> processing
>
> * the fact that TypeProjection extended from StructuralMapping had a 
> subtle issue - on the one hand, StructuralMapping has the required 
> logic to handle arrays (e.g. map component type and return new array 
> if needed) - on the other hand, with projections we need to be careful 
> - if the element type has no projection, then projection of the array 
> is also undefined. The impl was returning an array of <null> which was 
> then causing crashes inside the compiler. This is now called out 
> explicitly.
>
> Maurizio
>
>
> On 24/11/17 17:39, Maurizio Cimadamore wrote:
>>
>> Hi,
>> please review the fix for JDK-8191802:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8191802/
>>
>> This is a conformance issue with local variable type inference - the 
>> specification text for upper projection says this (section 4.10.5):
>>
>> "The upward projection of a type T with respect to a set of 
>> restricted type variables is defined as follows:
>>
>> ??? [...]
>>
>> ??? If T is a parameterized class type or a parameterized interface 
>> type, G<A1, ..., An>, then the result is G<A1', ..., An'>, where, for 
>> 1 ? i ? n, Ai' is derived from Ai as follows:
>>
>> ??????? [...]
>> ??????? If Ai is a type that mentions a restricted type variable, 
>> then Ai' is a wildcard. Let U be the upward projection of Ai. There 
>> are three cases:
>> *If U is not Object, and if either the declared bound of the ith 
>> parameter of G, Bi, mentions a type parameter of G, or Bi is not a 
>> subtype of U, then Ai' is an upper-bounded wildcard, ? extends U.*
>> ??????????? Otherwise, if the downward projection of Ai is L, then 
>> Ai' is a lower-bounded wildcard, ? super L.
>> ??????????? Otherwise, the downward projection of Ai is undefined and 
>> Ai' is an unbounded wildcard, ?."
>>
>> The text in bold is not implemented accurately by javac. What javac 
>> used to do was simply to throw away the upper bound and favor the 
>> lower bound if the upper was Object.
>>
>> The spec text is much more subtle and precise, allowing javac to 
>> throw away upper bounds that do not add any extra information w.r.t. 
>> declared bounds.
>>
>> As a result of this change, there are few places where the compiler 
>> used to infer A<? extend B> (where B was same type as declared bound) 
>> and now it infers A<?> as per spec - this caused few changes in the 
>> jshell test TypeNameTest.
>>
>> I've added a lvti harness test to verify the assertions in the above 
>> paragraph.
>>
>> Cheers
>> Maurizio
>>
>

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

From vicente.romero at oracle.com  Wed Nov 29 17:20:23 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 29 Nov 2017 12:20:23 -0500
Subject: RFR 8191802: Upward projection result is A<? extends Number>
 instead of A<? super Integer>
In-Reply-To: <0e657f3e-8b0e-a1b9-2988-613133ac14ba@oracle.com>
References: <5e79e2f9-19da-d726-4081-9257b9c6b241@oracle.com>
 <c681e827-3325-af06-a3fa-6309dd757e40@oracle.com>
 <0e657f3e-8b0e-a1b9-2988-613133ac14ba@oracle.com>
Message-ID: <c484b30e-8bd5-5d28-27dd-0026992d1717@oracle.com>

looks good,

Thanks,
Vicente

On 11/29/2017 11:43 AM, Maurizio Cimadamore wrote:
>
> Here's another update:
>
> http://cr.openjdk.java.net/~mcimadamore/8191802-v3/
>
> * fixed the comments in the test UpperBounds.java
> * used explicit UPWARDS and DOWNWARDS instead of 
> pkind/pkind.complement() in TypeArgumentProjection::visitType
> * moved the check for VOID/NULL in Check::checkLocalVarType
>
> Maurizio
>
>
> On 27/11/17 15:09, Maurizio Cimadamore wrote:
>>
>> This is an updated version of the webrev:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8191802-v2/
>>
>> I realized that there were further discrepancies w.r.t. the spec 
>> text, so I handled them all at once:
>>
>> * the spec has different treatment for when a type argument is a 
>> wildcard and for when it's a regular type - the implementation was 
>> treating both wildcards and regular types in the same way, which led 
>> to inconsistencies (see JDK-8191893). I now defined separate visitors 
>> for the outer projection and type argument projection parts, so that 
>> the code should be easier to follow.
>>
>> * not all fresh types created during a projection overrode the 
>> 'needStripping' method, which could lead to issue with type 
>> annotation processing
>>
>> * the fact that TypeProjection extended from StructuralMapping had a 
>> subtle issue - on the one hand, StructuralMapping has the required 
>> logic to handle arrays (e.g. map component type and return new array 
>> if needed) - on the other hand, with projections we need to be 
>> careful - if the element type has no projection, then projection of 
>> the array is also undefined. The impl was returning an array of 
>> <null> which was then causing crashes inside the compiler. This is 
>> now called out explicitly.
>>
>> Maurizio
>>
>>
>> On 24/11/17 17:39, Maurizio Cimadamore wrote:
>>>
>>> Hi,
>>> please review the fix for JDK-8191802:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/8191802/
>>>
>>> This is a conformance issue with local variable type inference - the 
>>> specification text for upper projection says this (section 4.10.5):
>>>
>>> "The upward projection of a type T with respect to a set of 
>>> restricted type variables is defined as follows:
>>>
>>> ??? [...]
>>>
>>> ??? If T is a parameterized class type or a parameterized interface 
>>> type, G<A1, ..., An>, then the result is G<A1', ..., An'>, where, 
>>> for 1 ? i ? n, Ai' is derived from Ai as follows:
>>>
>>> ??????? [...]
>>> ??????? If Ai is a type that mentions a restricted type variable, 
>>> then Ai' is a wildcard. Let U be the upward projection of Ai. There 
>>> are three cases:
>>> *If U is not Object, and if either the declared bound of the ith 
>>> parameter of G, Bi, mentions a type parameter of G, or Bi is not a 
>>> subtype of U, then Ai' is an upper-bounded wildcard, ? extends U.*
>>> ??????????? Otherwise, if the downward projection of Ai is L, then 
>>> Ai' is a lower-bounded wildcard, ? super L.
>>> ??????????? Otherwise, the downward projection of Ai is undefined 
>>> and Ai' is an unbounded wildcard, ?."
>>>
>>> The text in bold is not implemented accurately by javac. What javac 
>>> used to do was simply to throw away the upper bound and favor the 
>>> lower bound if the upper was Object.
>>>
>>> The spec text is much more subtle and precise, allowing javac to 
>>> throw away upper bounds that do not add any extra information w.r.t. 
>>> declared bounds.
>>>
>>> As a result of this change, there are few places where the compiler 
>>> used to infer A<? extend B> (where B was same type as declared 
>>> bound) and now it infers A<?> as per spec - this caused few changes 
>>> in the jshell test TypeNameTest.
>>>
>>> I've added a lvti harness test to verify the assertions in the above 
>>> paragraph.
>>>
>>> Cheers
>>> Maurizio
>>>
>>
>

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

From maurizio.cimadamore at oracle.com  Wed Nov 29 17:38:34 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 29 Nov 2017 17:38:34 +0000
Subject: RFR 8191802: Upward projection result is A<? extends Number>
 instead of A<? super Integer>
In-Reply-To: <c484b30e-8bd5-5d28-27dd-0026992d1717@oracle.com>
References: <5e79e2f9-19da-d726-4081-9257b9c6b241@oracle.com>
 <c681e827-3325-af06-a3fa-6309dd757e40@oracle.com>
 <0e657f3e-8b0e-a1b9-2988-613133ac14ba@oracle.com>
 <c484b30e-8bd5-5d28-27dd-0026992d1717@oracle.com>
Message-ID: <6a49b291-3b5c-fb8a-d94d-df7a86dd9ab2@oracle.com>

Thanks - pushed

Maurizio


On 29/11/17 17:20, Vicente Romero wrote:
> looks good,
>
> Thanks,
> Vicente
>
> On 11/29/2017 11:43 AM, Maurizio Cimadamore wrote:
>>
>> Here's another update:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8191802-v3/
>>
>> * fixed the comments in the test UpperBounds.java
>> * used explicit UPWARDS and DOWNWARDS instead of 
>> pkind/pkind.complement() in TypeArgumentProjection::visitType
>> * moved the check for VOID/NULL in Check::checkLocalVarType
>>
>> Maurizio
>>
>>
>> On 27/11/17 15:09, Maurizio Cimadamore wrote:
>>>
>>> This is an updated version of the webrev:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/8191802-v2/
>>>
>>> I realized that there were further discrepancies w.r.t. the spec 
>>> text, so I handled them all at once:
>>>
>>> * the spec has different treatment for when a type argument is a 
>>> wildcard and for when it's a regular type - the implementation was 
>>> treating both wildcards and regular types in the same way, which led 
>>> to inconsistencies (see JDK-8191893). I now defined separate 
>>> visitors for the outer projection and type argument projection 
>>> parts, so that the code should be easier to follow.
>>>
>>> * not all fresh types created during a projection overrode the 
>>> 'needStripping' method, which could lead to issue with type 
>>> annotation processing
>>>
>>> * the fact that TypeProjection extended from StructuralMapping had a 
>>> subtle issue - on the one hand, StructuralMapping has the required 
>>> logic to handle arrays (e.g. map component type and return new array 
>>> if needed) - on the other hand, with projections we need to be 
>>> careful - if the element type has no projection, then projection of 
>>> the array is also undefined. The impl was returning an array of 
>>> <null> which was then causing crashes inside the compiler. This is 
>>> now called out explicitly.
>>>
>>> Maurizio
>>>
>>>
>>> On 24/11/17 17:39, Maurizio Cimadamore wrote:
>>>>
>>>> Hi,
>>>> please review the fix for JDK-8191802:
>>>>
>>>> http://cr.openjdk.java.net/~mcimadamore/8191802/
>>>>
>>>> This is a conformance issue with local variable type inference - 
>>>> the specification text for upper projection says this (section 4.10.5):
>>>>
>>>> "The upward projection of a type T with respect to a set of 
>>>> restricted type variables is defined as follows:
>>>>
>>>> ??? [...]
>>>>
>>>> ??? If T is a parameterized class type or a parameterized interface 
>>>> type, G<A1, ..., An>, then the result is G<A1', ..., An'>, where, 
>>>> for 1 ? i ? n, Ai' is derived from Ai as follows:
>>>>
>>>> ??????? [...]
>>>> ??????? If Ai is a type that mentions a restricted type variable, 
>>>> then Ai' is a wildcard. Let U be the upward projection of Ai. There 
>>>> are three cases:
>>>> *If U is not Object, and if either the declared bound of the ith 
>>>> parameter of G, Bi, mentions a type parameter of G, or Bi is not a 
>>>> subtype of U, then Ai' is an upper-bounded wildcard, ? extends U.*
>>>> ??????????? Otherwise, if the downward projection of Ai is L, then 
>>>> Ai' is a lower-bounded wildcard, ? super L.
>>>> ??????????? Otherwise, the downward projection of Ai is undefined 
>>>> and Ai' is an unbounded wildcard, ?."
>>>>
>>>> The text in bold is not implemented accurately by javac. What javac 
>>>> used to do was simply to throw away the upper bound and favor the 
>>>> lower bound if the upper was Object.
>>>>
>>>> The spec text is much more subtle and precise, allowing javac to 
>>>> throw away upper bounds that do not add any extra information 
>>>> w.r.t. declared bounds.
>>>>
>>>> As a result of this change, there are few places where the compiler 
>>>> used to infer A<? extend B> (where B was same type as declared 
>>>> bound) and now it infers A<?> as per spec - this caused few changes 
>>>> in the jshell test TypeNameTest.
>>>>
>>>> I've added a lvti harness test to verify the assertions in the 
>>>> above paragraph.
>>>>
>>>> Cheers
>>>> Maurizio
>>>>
>>>
>>
>

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

From robert.field at oracle.com  Wed Nov 29 18:31:16 2017
From: robert.field at oracle.com (Robert Field)
Date: Wed, 29 Nov 2017 10:31:16 -0800
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <badb6f618f5b489ca634adb6b545b152@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <5A1C4081.2090107@oracle.com> <badb6f618f5b489ca634adb6b545b152@sap.com>
Message-ID: <9F5BAA92-7186-4046-B67C-61FBFF540497@oracle.com>

Thumbs up for JShell changes.

-Robert

> On Nov 28, 2017, at 3:16 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi,
> 
> I uploaded a new webrev:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.04/
> 
> This includes the changes 
>  - to jshell requested by Robert
>  - to the test as requested by Kumar.
> 
> See also incremental patch and the test output including all the
> help messages referenced in the webrev.
> 
> Best regards,
>  Goetz.
> 
>> -----Original Message-----
>> From: Kumar Srinivasan [mailto:kumar.x.srinivasan at oracle.com]
>> Sent: Montag, 27. November 2017 17:43
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> Cc: core-libs-dev at openjdk.java.net; 'compiler-dev at openjdk.java.net'
>> <compiler-dev at openjdk.java.net>; serviceability-dev (serviceability-
>> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
>> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
>> 
>> Hi,
>> 
>> I looked at some of the components I maintain, and they look good.
>> 
>> Wrt. the test:
>> 
>> 1. The local variables/fields don't comply with the coding conventions,
>> we have been
>>      following in the JDK.
>> 
>> 2.  Hmm, someone parked a .ini file in bin directory, later removed,
>>      perhaps on windows simply check for .exe ? Should a check exist
>>      to verify if file has executable permissions ?"File.canExecute".
>> 
>>  171     // Returns true if the file is not a tool.
>>  172     static boolean notATool(String file) {
>>  173         file = file.toLowerCase();
>>  174         if (file.endsWith(".dll") ||
>>  175             file.endsWith(".map") ||
>>  176             file.endsWith(".pdb") ||
>>  177             file.equals("server")) {  // server subdir on windows.
>>  178             return true;
>>  179         }
>>  180         return false;
>>  181     }
>> 
>> 
>> 3.  Typo in comment
>> 
>> 201     // Check whether 'flag' appears in 'line' as a word of itself. I must not
>> 
>> s/I must/It must/
>> 
>> 
>> 4. There is a method to check for isEnglishLocale in TestHelper, perhaps
>> use it
>> to have the test bale out in non english locales as early as possible ?
>> 
>> 5.  Has this been tested on all platforms ? do you need help testing it ?
>> 
>> Kumar
>> 
>> 
>> On 11/17/2017 3:23 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>> 
>>> please review this change. I also filed a CSR for this:
>>> http://cr.openjdk.java.net/~goetz/wr17/8189102-
>> helpMessage/webrev.02/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
>>> 
>>> See the webrev for a detailed description of the changes.
>>> 
>>> If required, I'll make break-out changes to be reviewed separately.
>>> 
>>> I had posted a RFR before, but improved the change to
>>> give a more complete overview of currently supported flags
>>> for the CSR:
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
>> October/028615.html
>>> 
>>> Best regards,
>>>   Goetz.
>>> 
> 


From goetz.lindenmaier at sap.com  Thu Nov 30 09:18:54 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 30 Nov 2017 09:18:54 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <9F5BAA92-7186-4046-B67C-61FBFF540497@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <5A1C4081.2090107@oracle.com> <badb6f618f5b489ca634adb6b545b152@sap.com>
 <9F5BAA92-7186-4046-B67C-61FBFF540497@oracle.com>
Message-ID: <f0767add3acc4cbc960ffa6603abe020@sap.com>

Thanks, Robert!

Best regards,
  Goetz.

> -----Original Message-----
> From: Robert Field [mailto:robert.field at oracle.com]
> Sent: Mittwoch, 29. November 2017 19:31
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: Kumar Srinivasan <kumar.x.srinivasan at oracle.com>; serviceability-dev
> (serviceability-dev at openjdk.java.net) <serviceability-
> dev at openjdk.java.net>; compiler-dev at openjdk.java.net; core-libs-
> dev at openjdk.java.net
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> Thumbs up for JShell changes.
> 
> -Robert
> 
> > On Nov 28, 2017, at 3:16 AM, Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> >
> > Hi,
> >
> > I uploaded a new webrev:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.04/
> >
> > This includes the changes
> >  - to jshell requested by Robert
> >  - to the test as requested by Kumar.
> >
> > See also incremental patch and the test output including all the
> > help messages referenced in the webrev.
> >
> > Best regards,
> >  Goetz.
> >
> >> -----Original Message-----
> >> From: Kumar Srinivasan [mailto:kumar.x.srinivasan at oracle.com]
> >> Sent: Montag, 27. November 2017 17:43
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >> Cc: core-libs-dev at openjdk.java.net; 'compiler-dev at openjdk.java.net'
> >> <compiler-dev at openjdk.java.net>; serviceability-dev (serviceability-
> >> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> >> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> >>
> >> Hi,
> >>
> >> I looked at some of the components I maintain, and they look good.
> >>
> >> Wrt. the test:
> >>
> >> 1. The local variables/fields don't comply with the coding conventions,
> >> we have been
> >>      following in the JDK.
> >>
> >> 2.  Hmm, someone parked a .ini file in bin directory, later removed,
> >>      perhaps on windows simply check for .exe ? Should a check exist
> >>      to verify if file has executable permissions ?"File.canExecute".
> >>
> >>  171     // Returns true if the file is not a tool.
> >>  172     static boolean notATool(String file) {
> >>  173         file = file.toLowerCase();
> >>  174         if (file.endsWith(".dll") ||
> >>  175             file.endsWith(".map") ||
> >>  176             file.endsWith(".pdb") ||
> >>  177             file.equals("server")) {  // server subdir on windows.
> >>  178             return true;
> >>  179         }
> >>  180         return false;
> >>  181     }
> >>
> >>
> >> 3.  Typo in comment
> >>
> >> 201     // Check whether 'flag' appears in 'line' as a word of itself. I must not
> >>
> >> s/I must/It must/
> >>
> >>
> >> 4. There is a method to check for isEnglishLocale in TestHelper, perhaps
> >> use it
> >> to have the test bale out in non english locales as early as possible ?
> >>
> >> 5.  Has this been tested on all platforms ? do you need help testing it ?
> >>
> >> Kumar
> >>
> >>
> >> On 11/17/2017 3:23 AM, Lindenmaier, Goetz wrote:
> >>> Hi,
> >>>
> >>> please review this change. I also filed a CSR for this:
> >>> http://cr.openjdk.java.net/~goetz/wr17/8189102-
> >> helpMessage/webrev.02/
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >>>
> >>> See the webrev for a detailed description of the changes.
> >>>
> >>> If required, I'll make break-out changes to be reviewed separately.
> >>>
> >>> I had posted a RFR before, but improved the change to
> >>> give a more complete overview of currently supported flags
> >>> for the CSR:
> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> >> October/028615.html
> >>>
> >>> Best regards,
> >>>   Goetz.
> >>>
> >


From jan.lahoda at oracle.com  Thu Nov 30 16:15:05 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 30 Nov 2017 17:15:05 +0100
Subject: RFR JDK-8191969: javac produces incorrect
 RuntimeInvisibleTypeAnnotations length attribute
In-Reply-To: <5A1D4C66.5010605@oracle.com>
References: <5A1D4C66.5010605@oracle.com>
Message-ID: <5A202E89.9090808@oracle.com>

To me, looks OK, but unfortunately I not a jdk8u Reviewer.

Jan

On 28.11.2017 12:45, Srikanth wrote:
>
> Hello,
>
> JDK-8191969 is a JDK8u backport task created for JDK-8144185 which was
> pushed for JDK10
> here: http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/0b32afcabef4
>
> We have a request from asm tool maintainers and also from other sources
> through the sustenance channel for a backport.
>
> Synopsis:
>
> Basically problem arises when metadata that models the type annotations
> on a captured outer local are shared with the lambda implementation
> method's formal parameter that corresponds to the
> captured outer local.
>
> Any changes to one will invalidate the other. This is in fact what
> causes grief for asm.
>
> However, as per the spec clarification spelled out here:
> http://mail.openjdk.java.net/pipermail/compiler-dev/2015-December/009866.html
> we should not be transmitting the annotations from the captured outer
> locals to any formal parameter that represents/reifies the captured
> outer local in a synthetic lambda implementation method.
>
> Thus aligning to the spec, makes the problem vanish automatically.
>
> 8u webrev:
>
> http://cr.openjdk.java.net/~sadayapalam/JDK-8191969/webrev.00/
>
> (This is essentially the same fix pushed for jdk10, with the patch
> manually applied to jdk8u-dev)
>
> All relevant tests are green. Please review.
> Thanks in advance.
> Srikanth
>
>

From cushon at google.com  Thu Nov 30 19:04:55 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 30 Nov 2017 11:04:55 -0800
Subject: spec clarification: type annotations on static nested types
Message-ID: <CAL4QsgtuZj7ynAguJoKGSZzabLMZZZQ6pumub1AJvJ2HrLe-gA@mail.gmail.com>

JVMS 9 4.7.20.2-A says that a type_path_kind value of 1 is used to indicate
a type annotation "is deeper in a nested type". I believe this should be
"deeper in a *non-static* nested type". A comment in JDK-8027263 confirms
that type path entries are used for inner classes, but not for static
nested classes.

Example:

```
import static java.lang.annotation.ElementType.TYPE_USE;
import static java.lang.annotation.RetentionPolicy.RUNTIME;

import java.lang.annotation.Retention;
import java.lang.annotation.Target;
import java.lang.reflect.AnnotatedType;
import java.util.Arrays;

class T {
  @Retention(RUNTIME)
  @Target(TYPE_USE)
  @interface A {}

  class One {}

  static class Two {}

  void f(@A One x) {}

  void g(@A Two x) {}

  public static void main(String[] args) throws Exception {
    debug(T.class.getDeclaredMethod("f",
One.class).getAnnotatedParameterTypes()[0]);
    debug(T.class.getDeclaredMethod("g",
Two.class).getAnnotatedParameterTypes()[0]);
  }

  static void debug(AnnotatedType type) {
    System.err.println("type annotations: " +
Arrays.toString(type.getAnnotations()));
    System.err.println(
        "owner type annotations: "
        + Arrays.toString(type.getAnnotatedOwnerType().getAnnotations()));
  }
}
```

Using type_path_kind=1 for inner classes, but not for static member
classes, is consistent with current javac behaviour. In the example, the
type path for the annotation on `@A One` is `[INNER_TYPE]` (One is an inner
class), and the type path for the annotation on `@A Two` is empty (Two is a
static member class):

$ javap -v T
...
  void f(T$One);
...
    RuntimeVisibleTypeAnnotations:
      0: #31(): METHOD_FORMAL_PARAMETER, param_index=0,
location=[INNER_TYPE]
...
  void g(T$Two);
...
    RuntimeVisibleTypeAnnotations:
      0: #31(): METHOD_FORMAL_PARAMETER, param_index=0

Using type_path_kind=1 for inner classes is not consistent with the current
behaviour of core reflection. sun.reflect.annotation.AnnotatedTypeFactory
adjusts type paths in the implementation of getAnnotatedOwnerType() for
AnnotatedType and AnnotatedParameterizedType, and when handling
ParameterizedTypes in nestingForType, without considering whether the
nested type is static. This leads to apparently incorrect results for
getAnnotations(). Note that the type annotations on `@A Two` are reported
as being on both `Two` and its enclosing type `T`:

$ javac T.java && java T.
# `@A One`
type annotations: [@T$A()]
owner type annotations: []
# `@A Two`
type annotations: [@T$A()]
owner type annotations: [@T$A()]

My questions are:
* if my understanding of JVMS 9 4.7.20.2-A is correct, can the spec be
updated to clarify that type_path_kind=1 means "deeper in a non-static
nested type", not "deeper in a nested type"?
* is javac's output for this example correct, and if so is this a bug in
AnnotatedTypeFactory?

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