From bsrbnd at gmail.com  Sun Apr  3 11:16:32 2016
From: bsrbnd at gmail.com (bsrbnd)
Date: Sun, 3 Apr 2016 13:16:32 +0200
Subject: Symbolic annotation processor
In-Reply-To: <CAEgw74BERMwvfAzXJEu_W6daN1L+tJABmBWGNu9q38+taOHorQ@mail.gmail.com>
References: <CAEgw74BztdzFb7ZcgHs4rvWtD8aqKdn_TSGuZjFtidyaUyHAYw@mail.gmail.com>
	<CAEgw74BERMwvfAzXJEu_W6daN1L+tJABmBWGNu9q38+taOHorQ@mail.gmail.com>
Message-ID: <CAEgw74BE3r36KAX2aVs9B0tJ30T_4H9=yq2pAC7=DvOSm7YHaw@mail.gmail.com>

Hi,

I wrote a simple genetic programming example (a symbolic regression)
using SymProc, here:
https://github.com/bsrbnd/draft/blob/master/src/examples/GeneticProgramming.java

As we can see, symbolic programming could be also the basements for
functional programming.
Notice, for example, the ease of the computation of the integral of
the absolute difference between two functions:

private Double fitness(Symbol<?> $f) throws Exception {
    return integral(LOWER_BOUND, UPPER_BOUND,
$abs.apply($sub.apply($f,$target)));
}

Regards,

Bernard

2016-03-17 12:26 GMT+01:00 bsrbnd <bsrbnd at gmail.com>:
> Hi,
>
> After a very fast and superficial reading of the JLS, I wrote some
> jtreg tests for points that might be impacted
> by the symbolic-processor. Source code of the tests, grouped in two
> files for more readability, can be found at:
> https://github.com/bsrbnd/draft/tree/master/src/tests
>
> Some of them show a bit more precisely the benefit of incorporating in
> some way the symbolic programming paradigm
> (the ability to manipulate the symbols of a language) to enhance the
> reflection (and perhaps even more...).
>
> As generics are earased during runtime, it could be hard to get the
> reflective elements of members using generics
> heavily (and even harder to maintain).
> Consider the following example inspired by JLS8, chapter 4.4:
>
> class MyTypeVariable {
>     public static class C {}
>     public static interface I {}
>
>     @Symbolic private <T extends C & I> void myMethod(T t, T[] u) {}
> }
>
> Without the symbolic view of members, you have to write something like
> the following to get the reflective object:
> Method m = MyTypeVariable.class.getDeclaredMethod("myMethod",
> MyTypeVariable.C.class,
> MyTypeVariable.C[].class));
>
> But, with the symbolic-processor, you delegate the generics and
> erasures handling to the compiler:
> Method m = MyTypeVariable.$myMethod.reflect();
>
> This is, of course, easier to write and to maintain.
>
> I've also tried to go further with this paradigm by introducing
> dynamically constructed symbolic expressions
> (a bit like LISP does) and evaluate them on a particular instance, for example:
>
> class DynamicExpression {
>     @Symbolic private Integer a = 3;
>     @Symbolic private Integer b = 2;
>     @Symbolic private Integer c = 1;
>
>     @Symbolic public Integer add(Integer i, Integer j) {return i + j;}
>     @Symbolic public Integer sub(Integer i, Integer j) {return i - j;}
> }
>
> MethodSymbol $symbolicExpression = $add.apply($a, $sub.apply($b, $c));
> Integer d = (Integer)$symbolicExpression.evaluate(new DynamicExpression());
>
> This expression evaluates naturally to 4 for this instance.
>
> The full running example can be found at:
> https://github.com/bsrbnd/draft/blob/master/src/examples/DynamicExpression.java
>
> Symbolic expressions could be useful for evolutionary algorithms used
> in genetic programming, where dynamic
> expressions are iteratively crossed-over and mutated to find the best
> approximation of a solution.
>
> I hope that I didn't miss anything in the JLS and that something like
> this hasn't already been incorporated
> in any existing project.
>
> Regards,
>
> Bernard
>
> 2015-12-10 14:50 GMT+01:00 bsrbnd <bsrbnd at gmail.com>:
>> Hi,
>>
>> Following our discussion (October 2015), I wrote an
>> annotation-processor (only a draft for now) that gives a symbolic view
>> of class members, for example:
>> @Symbolic private Object myField;
>> @Symbolic("_") private void myMethod(Object param) {}
>>
>> We can either access the name or the reflective object of members the
>> following way:
>> String name = $myField.toString(); // $ is the default prefix
>> Method m = _myMethod.reflect(); // _ is a custom prefix, useful for
>> overloaded identifiers
>>
>> You can find a simple example here:
>> https://github.com/bsrbnd/draft/blob/master/src/examples/Example.java
>>
>> Full source code of the annotation-processor prototype is given there:
>> https://github.com/bsrbnd/draft
>>
>> Comments are welcome, but I know this is probably not the right
>> mailing-list for that.
>>
>> Regards,
>>
>> Bernard

From jonathan.gibbons at oracle.com  Mon Apr  4 18:47:18 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 04 Apr 2016 11:47:18 -0700
Subject: RFR: 8153416 unexport javah from jdk.compiler module
Message-ID: <5702B6B6.1070004@oracle.com>

This patch removes com.sun.tools.javah from the set of packages exported 
from jdk.compiler, and updates the @modules tag of tests that use the 
entry point, either directly, or via ToolBox JavahTask.

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

-- Jon


From mandy.chung at oracle.com  Mon Apr  4 18:58:12 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 4 Apr 2016 11:58:12 -0700
Subject: RFR: 8153416 unexport javah from jdk.compiler module
In-Reply-To: <5702B6B6.1070004@oracle.com>
References: <5702B6B6.1070004@oracle.com>
Message-ID: <BF05A726-63E9-4220-A564-46B6A174F2BD@oracle.com>


> On Apr 4, 2016, at 11:47 AM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> This patch removes com.sun.tools.javah from the set of packages exported from jdk.compiler, and updates the @modules tag of tests that use the entry point, either directly, or via ToolBox JavahTask.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8153416
> Webrev: http://cr.openjdk.java.net/~jjg/8153416/webrev.00

Thanks for fixing this.  Looks good.

com.sun.tools.javah is never an exported package and it?s a bug in module-info.java when it was first added.

Mandy


From steve.drach at oracle.com  Tue Apr  5 21:02:01 2016
From: steve.drach at oracle.com (Steve Drach)
Date: Tue, 5 Apr 2016 14:02:01 -0700
Subject: RFR 8149757:Implement Multi-Release jar aware JavacFileManager for
	javac
Message-ID: <ABE754D4-F784-4B85-974E-71C96BB01826@oracle.com>

Hi,

Please review the changes required to make javac and the StandardJavaFileManager multi-release jar aware.  For javac, the version of the classes in a multi-release.jar is selected by the -release (or -target) command line option, or if the option is not present, javac?s default policy is used to select the version ? typically the runtime version (i.e. version 9 is selected for JDK 9).  For the StandardJavaFileManager, the version is selected with the handleOption method.  See the tests for more detail.

issue: https://bugs.openjdk.java.net/browse/JDK-8149757 <https://bugs.openjdk.java.net/browse/JDK-8149757>
webrev: http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html <http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html>

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

From jose.cornado at gmail.com  Tue Apr  5 21:15:04 2016
From: jose.cornado at gmail.com (=?UTF-8?Q?Jos=C3=A9_Cornado?=)
Date: Tue, 5 Apr 2016 15:15:04 -0600
Subject: jcov template usage
Message-ID: <CAKGaNaUhUDt5dh-75r6wW6_=2O8kez90tWoz_Oq8Jmp+rFZ_WA@mail.gmail.com>

Hello!

I am trying to include jcov as a part of a tool (an ide plugin) and I was
wondering how to use the template.xml lists.

Is there a way to tell jcov to instrument coverage for an specific method?

-- 
Jos? Cornado

--

home: http://www.efekctive.com
blog:   http://blogging.efekctive.com
----------------------

Everything has been said before, but since nobody listens we have to keep
going back and beginning all over again.

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

From jonathan.gibbons at oracle.com  Tue Apr  5 22:39:28 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 05 Apr 2016 15:39:28 -0700
Subject: jcov template usage
In-Reply-To: <CAKGaNaUhUDt5dh-75r6wW6_=2O8kez90tWoz_Oq8Jmp+rFZ_WA@mail.gmail.com>
References: <CAKGaNaUhUDt5dh-75r6wW6_=2O8kez90tWoz_Oq8Jmp+rFZ_WA@mail.gmail.com>
Message-ID: <57043EA0.5080209@oracle.com>

Jos?,

You would probably do better posting your question to the JCov folk over 
on the jcov-dev at openjdk.java.net list.

-- Jon


On 04/05/2016 02:15 PM, Jos? Cornado wrote:
> Hello!
>
> I am trying to include jcov as a part of a tool (an ide plugin) and I 
> was wondering how to use the template.xml lists.
>
> Is there a way to tell jcov to instrument coverage for an specific 
> method?
>
> -- 
> Jos? Cornado
>
> --
>
> home: http://www.efekctive.com
> blog: http://blogging.efekctive.com
> ----------------------
>
> Everything has been said before, but since nobody listens we have to 
> keep going back and beginning all over again.
>
> Andre Gide


From jonathan.gibbons at oracle.com  Wed Apr  6 18:23:27 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 06 Apr 2016 11:23:27 -0700
Subject: RFR 8149757:Implement Multi-Release jar aware JavacFileManager
	for javac
In-Reply-To: <ABE754D4-F784-4B85-974E-71C96BB01826@oracle.com>
References: <ABE754D4-F784-4B85-974E-71C96BB01826@oracle.com>
Message-ID: <5705541F.1020804@oracle.com>

Steve,

The most noticeable ickiness is the following string bashing on the name 
of the Target enum constant,

  249             List<String> list = List.of(target.toString().replace("JDK1_", ""));

It's not wrong, but it is fragile, as we've already considered renaming 
Target.JDK1_9 to Target.JDK9.

A somewhat more robust solution would be to use a regex [1]:

  249             List<String> list = List.of(target.toString().replaceAll("^JDK(1_)?", ""));

The gold-star solution would be to have a method on Target to return the 
MR-version number.

-- Jon

[1] 
http://blog.codinghorror.com/regular-expressions-now-you-have-two-problems/


On 04/05/2016 02:02 PM, Steve Drach wrote:
> Hi,
>
> Please review the changes required to make javac and the 
> StandardJavaFileManager multi-release jar aware.  For javac, the 
> version of the classes in a multi-release.jar is selected by the 
> -release (or -target) command line option, or if the option is not 
> present, javac?s default policy is used to select the version ? 
> typically the runtime version (i.e. version 9 is selected for JDK 9). 
>  For the StandardJavaFileManager, the version is selected with the 
> handleOption method.  See the tests for more detail.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8149757
> webrev: http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html 
> <http://cr.openjdk.java.net/%7Esdrach/8149757/webrev/index.html>
>
> Thank you,
> Steve

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

From jan.lahoda at oracle.com  Wed Apr  6 18:40:17 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 6 Apr 2016 20:40:17 +0200
Subject: RFR 8149757:Implement Multi-Release jar aware JavacFileManager
	for javac
In-Reply-To: <ABE754D4-F784-4B85-974E-71C96BB01826@oracle.com>
References: <ABE754D4-F784-4B85-974E-71C96BB01826@oracle.com>
Message-ID: <57055811.2070203@oracle.com>

-where there consideration on how this will work with other file 
managers? (Esp. given the instanceof in Main?) The other file manager 
may be a relatively simple wrapper over the JavacFileManager (an example 
would be:
http://hg.openjdk.java.net/jdk9/dev/langtools/file/329ae120e365/src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java
)

Seems to me that maybe using isSupportedOption("multi-release") instead 
of the instanceof would provide a more seemless integration.

-why is JavacFileManager.getJarFSProvider() needed? Shouldn't
FileSystems.newFileSystem(realPath, env);
be enough? (Calling an SPI directly from an API client seems suspicious 
to me.)

-for Jon's comment on converting Target to a number, JDKPlatformProvider 
uses:
Integer.toString(target.ordinal() - Target.JDK1_1.ordinal() + 1)

But a method on Target providing the number would be better, of course.

Jan

On 5.4.2016 23:02, Steve Drach wrote:
> Hi,
>
> Please review the changes required to make javac and the
> StandardJavaFileManager multi-release jar aware.  For javac, the version
> of the classes in a multi-release.jar is selected by the -release (or
> -target) command line option, or if the option is not present, javac?s
> default policy is used to select the version ? typically the runtime
> version (i.e. version 9 is selected for JDK 9).  For the
> StandardJavaFileManager, the version is selected with the handleOption
> method.  See the tests for more detail.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8149757
> webrev: http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html
>
> Thank you,
> Steve

From steve.drach at oracle.com  Wed Apr  6 19:13:13 2016
From: steve.drach at oracle.com (Steve Drach)
Date: Wed, 6 Apr 2016 12:13:13 -0700
Subject: RFR 8149757:Implement Multi-Release jar aware JavacFileManager
	for javac
In-Reply-To: <57055811.2070203@oracle.com>
References: <ABE754D4-F784-4B85-974E-71C96BB01826@oracle.com>
	<57055811.2070203@oracle.com>
Message-ID: <0636BC81-AB3A-4EF6-819E-B1A1AA797A6F@oracle.com>

Hi,

Thanks for the comments.  For the moment, ?stay tuned?, I?ll have to figure out how to do some of this.  I?m not very familiar with the code.

> On Apr 6, 2016, at 11:40 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
> 
> -where there consideration on how this will work with other file managers? (Esp. given the instanceof in Main?) The other file manager may be a relatively simple wrapper over the JavacFileManager (an example would be:
> http://hg.openjdk.java.net/jdk9/dev/langtools/file/329ae120e365/src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java
> )
> 
> Seems to me that maybe using isSupportedOption("multi-release") instead of the instanceof would provide a more seemless integration.
> 
> -why is JavacFileManager.getJarFSProvider() needed? Shouldn't
> FileSystems.newFileSystem(realPath, env);
> be enough? (Calling an SPI directly from an API client seems suspicious to me.)
> 
> -for Jon's comment on converting Target to a number, JDKPlatformProvider uses:
> Integer.toString(target.ordinal() - Target.JDK1_1.ordinal() + 1)
> 
> But a method on Target providing the number would be better, of course.
> 
> Jan
> 
> On 5.4.2016 23:02, Steve Drach wrote:
>> Hi,
>> 
>> Please review the changes required to make javac and the
>> StandardJavaFileManager multi-release jar aware.  For javac, the version
>> of the classes in a multi-release.jar is selected by the -release (or
>> -target) command line option, or if the option is not present, javac?s
>> default policy is used to select the version ? typically the runtime
>> version (i.e. version 9 is selected for JDK 9).  For the
>> StandardJavaFileManager, the version is selected with the handleOption
>> method.  See the tests for more detail.
>> 
>> issue: https://bugs.openjdk.java.net/browse/JDK-8149757
>> webrev: http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html
>> 
>> Thank you,
>> Steve


From jonathan.gibbons at oracle.com  Wed Apr  6 20:13:12 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 06 Apr 2016 13:13:12 -0700
Subject: RFR 8149757:Implement Multi-Release jar aware JavacFileManager
	for javac
In-Reply-To: <57055811.2070203@oracle.com>
References: <ABE754D4-F784-4B85-974E-71C96BB01826@oracle.com>
	<57055811.2070203@oracle.com>
Message-ID: <57056DD8.1060401@oracle.com>



On 04/06/2016 11:40 AM, Jan Lahoda wrote:
> -where there consideration on how this will work with other file 
> managers? (Esp. given the instanceof in Main?) The other file manager 
> may be a relatively simple wrapper over the JavacFileManager (an 
> example would be:
> http://hg.openjdk.java.net/jdk9/dev/langtools/file/329ae120e365/src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java 
>
> )
>
> Seems to me that maybe using isSupportedOption("multi-release") 
> instead of the instanceof would provide a more seemless integration.

Yes, but ...  this reduces to a previously unsolved problem (which we're 
working on.)   We have no precedent at this point for mandating options 
on StandardJavaFileManager, or even the half-way point of, if you 
support this option, here's what the semantics might be.   Yeah, we 
don't even currently do it for -classpath, -sourcepath etc.

Currently, the thinking is that the code path is primarily for the 
command line usage, when we know it will be JavacFileManager.  If you're 
in the API and using your own custom file manager, you can configure the 
file manager directly.


>
> -why is JavacFileManager.getJarFSProvider() needed? Shouldn't
> FileSystems.newFileSystem(realPath, env);
> be enough? (Calling an SPI directly from an API client seems 
> suspicious to me.)

If I recall correctly, the NIO2 API design forced this one. The method 
you are referring to does not exist. There is only one that takes a URI, 
and that has very different semantics.  So we had to go with the method 
on the provider, hence the use of getJarFSProvider.


>
> -for Jon's comment on converting Target to a number, 
> JDKPlatformProvider uses:
> Integer.toString(target.ordinal() - Target.JDK1_1.ordinal() + 1)

Using ordinals is almost as bad as using strings ;-)  In general, the 
practice in langtools has been to avoid use of .ordinal where possible.

>
> But a method on Target providing the number would be better, of course.
>
> Jan
>
> On 5.4.2016 23:02, Steve Drach wrote:
>> Hi,
>>
>> Please review the changes required to make javac and the
>> StandardJavaFileManager multi-release jar aware.  For javac, the version
>> of the classes in a multi-release.jar is selected by the -release (or
>> -target) command line option, or if the option is not present, javac?s
>> default policy is used to select the version ? typically the runtime
>> version (i.e. version 9 is selected for JDK 9).  For the
>> StandardJavaFileManager, the version is selected with the handleOption
>> method.  See the tests for more detail.
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8149757
>> webrev: http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html
>>
>> Thank you,
>> Steve


From jonathan.gibbons at oracle.com  Wed Apr  6 20:14:31 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 06 Apr 2016 13:14:31 -0700
Subject: RFR 8149757:Implement Multi-Release jar aware JavacFileManager
	for javac
In-Reply-To: <0636BC81-AB3A-4EF6-819E-B1A1AA797A6F@oracle.com>
References: <ABE754D4-F784-4B85-974E-71C96BB01826@oracle.com>
	<57055811.2070203@oracle.com>
	<0636BC81-AB3A-4EF6-819E-B1A1AA797A6F@oracle.com>
Message-ID: <57056E27.3020500@oracle.com>

Steve,

At this point, I would be prepared to accept the review, unless you want 
to tweak the string bashing and add/use a method on Target.

-- Jon

On 04/06/2016 12:13 PM, Steve Drach wrote:
> Hi,
>
> Thanks for the comments.  For the moment, ?stay tuned?, I?ll have to figure out how to do some of this.  I?m not very familiar with the code.
>
>> On Apr 6, 2016, at 11:40 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>>
>> -where there consideration on how this will work with other file managers? (Esp. given the instanceof in Main?) The other file manager may be a relatively simple wrapper over the JavacFileManager (an example would be:
>> http://hg.openjdk.java.net/jdk9/dev/langtools/file/329ae120e365/src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java
>> )
>>
>> Seems to me that maybe using isSupportedOption("multi-release") instead of the instanceof would provide a more seemless integration.
>>
>> -why is JavacFileManager.getJarFSProvider() needed? Shouldn't
>> FileSystems.newFileSystem(realPath, env);
>> be enough? (Calling an SPI directly from an API client seems suspicious to me.)
>>
>> -for Jon's comment on converting Target to a number, JDKPlatformProvider uses:
>> Integer.toString(target.ordinal() - Target.JDK1_1.ordinal() + 1)
>>
>> But a method on Target providing the number would be better, of course.
>>
>> Jan
>>
>> On 5.4.2016 23:02, Steve Drach wrote:
>>> Hi,
>>>
>>> Please review the changes required to make javac and the
>>> StandardJavaFileManager multi-release jar aware.  For javac, the version
>>> of the classes in a multi-release.jar is selected by the -release (or
>>> -target) command line option, or if the option is not present, javac?s
>>> default policy is used to select the version ? typically the runtime
>>> version (i.e. version 9 is selected for JDK 9).  For the
>>> StandardJavaFileManager, the version is selected with the handleOption
>>> method.  See the tests for more detail.
>>>
>>> issue: https://bugs.openjdk.java.net/browse/JDK-8149757
>>> webrev: http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html
>>>
>>> Thank you,
>>> Steve


From steve.drach at oracle.com  Wed Apr  6 20:22:37 2016
From: steve.drach at oracle.com (Steve Drach)
Date: Wed, 6 Apr 2016 13:22:37 -0700
Subject: RFR 8149757:Implement Multi-Release jar aware JavacFileManager
	for javac
In-Reply-To: <57056DD8.1060401@oracle.com>
References: <ABE754D4-F784-4B85-974E-71C96BB01826@oracle.com>
	<57055811.2070203@oracle.com> <57056DD8.1060401@oracle.com>
Message-ID: <490E496E-C4AA-40CD-8615-58C2A5008496@oracle.com>


>> -why is JavacFileManager.getJarFSProvider() needed? Shouldn't
>> FileSystems.newFileSystem(realPath, env);
>> be enough? (Calling an SPI directly from an API client seems suspicious to me.)
> 
> If I recall correctly, the NIO2 API design forced this one. The method you are referring to does not exist. There is only one that takes a URI, and that has very different semantics.  So we had to go with the method on the provider, hence the use of getJarFSProvider.

That?s correct.







> 
> 
>> 
>> -for Jon's comment on converting Target to a number, JDKPlatformProvider uses:
>> Integer.toString(target.ordinal() - Target.JDK1_1.ordinal() + 1)
> 
> Using ordinals is almost as bad as using strings ;-)  In general, the practice in langtools has been to avoid use of .ordinal where possible.
> 
>> 
>> But a method on Target providing the number would be better, of course.
>> 
>> Jan
>> 
>> On 5.4.2016 23:02, Steve Drach wrote:
>>> Hi,
>>> 
>>> Please review the changes required to make javac and the
>>> StandardJavaFileManager multi-release jar aware.  For javac, the version
>>> of the classes in a multi-release.jar is selected by the -release (or
>>> -target) command line option, or if the option is not present, javac?s
>>> default policy is used to select the version ? typically the runtime
>>> version (i.e. version 9 is selected for JDK 9).  For the
>>> StandardJavaFileManager, the version is selected with the handleOption
>>> method.  See the tests for more detail.
>>> 
>>> issue: https://bugs.openjdk.java.net/browse/JDK-8149757
>>> webrev: http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html
>>> 
>>> Thank you,
>>> Steve
> 


From steve.drach at oracle.com  Wed Apr  6 20:23:33 2016
From: steve.drach at oracle.com (Steve Drach)
Date: Wed, 6 Apr 2016 13:23:33 -0700
Subject: RFR 8149757:Implement Multi-Release jar aware JavacFileManager
	for javac
In-Reply-To: <57056E27.3020500@oracle.com>
References: <ABE754D4-F784-4B85-974E-71C96BB01826@oracle.com>
	<57055811.2070203@oracle.com>
	<0636BC81-AB3A-4EF6-819E-B1A1AA797A6F@oracle.com>
	<57056E27.3020500@oracle.com>
Message-ID: <7E5A1008-6A2A-40E2-8426-56D850DC1FCA@oracle.com>

Let me see what I can do with Target.  It would be nicer.

> On Apr 6, 2016, at 1:14 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Steve,
> 
> At this point, I would be prepared to accept the review, unless you want to tweak the string bashing and add/use a method on Target.
> 
> -- Jon
> 
> On 04/06/2016 12:13 PM, Steve Drach wrote:
>> Hi,
>> 
>> Thanks for the comments.  For the moment, ?stay tuned?, I?ll have to figure out how to do some of this.  I?m not very familiar with the code.
>> 
>>> On Apr 6, 2016, at 11:40 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>>> 
>>> -where there consideration on how this will work with other file managers? (Esp. given the instanceof in Main?) The other file manager may be a relatively simple wrapper over the JavacFileManager (an example would be:
>>> http://hg.openjdk.java.net/jdk9/dev/langtools/file/329ae120e365/src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java
>>> )
>>> 
>>> Seems to me that maybe using isSupportedOption("multi-release") instead of the instanceof would provide a more seemless integration.
>>> 
>>> -why is JavacFileManager.getJarFSProvider() needed? Shouldn't
>>> FileSystems.newFileSystem(realPath, env);
>>> be enough? (Calling an SPI directly from an API client seems suspicious to me.)
>>> 
>>> -for Jon's comment on converting Target to a number, JDKPlatformProvider uses:
>>> Integer.toString(target.ordinal() - Target.JDK1_1.ordinal() + 1)
>>> 
>>> But a method on Target providing the number would be better, of course.
>>> 
>>> Jan
>>> 
>>> On 5.4.2016 23:02, Steve Drach wrote:
>>>> Hi,
>>>> 
>>>> Please review the changes required to make javac and the
>>>> StandardJavaFileManager multi-release jar aware.  For javac, the version
>>>> of the classes in a multi-release.jar is selected by the -release (or
>>>> -target) command line option, or if the option is not present, javac?s
>>>> default policy is used to select the version ? typically the runtime
>>>> version (i.e. version 9 is selected for JDK 9).  For the
>>>> StandardJavaFileManager, the version is selected with the handleOption
>>>> method.  See the tests for more detail.
>>>> 
>>>> issue: https://bugs.openjdk.java.net/browse/JDK-8149757
>>>> webrev: http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html
>>>> 
>>>> Thank you,
>>>> Steve
> 


From steve.drach at oracle.com  Wed Apr  6 23:00:19 2016
From: steve.drach at oracle.com (Steve Drach)
Date: Wed, 6 Apr 2016 16:00:19 -0700
Subject: RFR 8149757:Implement Multi-Release jar aware JavacFileManager
	for javac
In-Reply-To: <ABE754D4-F784-4B85-974E-71C96BB01826@oracle.com>
References: <ABE754D4-F784-4B85-974E-71C96BB01826@oracle.com>
Message-ID: <C491D9D4-075E-4F96-9B9D-91AE9E1FE03C@oracle.com>

Hi,

I?ve updated the webrev to include a new method on Target as suggested.

Steve

> On Apr 5, 2016, at 2:02 PM, Steve Drach <steve.drach at oracle.com> wrote:
> 
> Hi,
> 
> Please review the changes required to make javac and the StandardJavaFileManager multi-release jar aware.  For javac, the version of the classes in a multi-release.jar is selected by the -release (or -target) command line option, or if the option is not present, javac?s default policy is used to select the version ? typically the runtime version (i.e. version 9 is selected for JDK 9).  For the StandardJavaFileManager, the version is selected with the handleOption method.  See the tests for more detail.
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8149757 <https://bugs.openjdk.java.net/browse/JDK-8149757>
> webrev: http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html <http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html>
> 
> Thank you,
> Steve

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

From jonathan.gibbons at oracle.com  Wed Apr  6 23:17:17 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 06 Apr 2016 16:17:17 -0700
Subject: RFR 8149757:Implement Multi-Release jar aware JavacFileManager
	for javac
In-Reply-To: <C491D9D4-075E-4F96-9B9D-91AE9E1FE03C@oracle.com>
References: <ABE754D4-F784-4B85-974E-71C96BB01826@oracle.com>
	<C491D9D4-075E-4F96-9B9D-91AE9E1FE03C@oracle.com>
Message-ID: <570598FD.4000005@oracle.com>

OK, good enough; at least the use of .ordinal is confined within the 
enum itself.

To be accurate, you are not making "the StandardJavaFileManager" 
multi-release jar aware.   StandardJavaFileManager is an interface that 
may have many different implementations.  You are making one particular 
implementation, the one provided by javac, multi-release aware.

-- Jon


On 04/06/2016 04:00 PM, Steve Drach wrote:
> Hi,
>
> I?ve updated the webrev to include a new method on Target as suggested.
>
> Steve
>
>> On Apr 5, 2016, at 2:02 PM, Steve Drach <steve.drach at oracle.com 
>> <mailto:steve.drach at oracle.com>> wrote:
>>
>> Hi,
>>
>> Please review the changes required to make javac and the 
>> StandardJavaFileManager multi-release jar aware.  For javac, the 
>> version of the classes in a multi-release.jar is selected by the 
>> -release (or -target) command line option, or if the option is not 
>> present, javac?s default policy is used to select the version ? 
>> typically the runtime version (i.e. version 9 is selected for JDK 9). 
>>  For the StandardJavaFileManager, the version is selected with the 
>> handleOption method.  See the tests for more detail.
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8149757
>> webrev: http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html 
>> <http://cr.openjdk.java.net/%7Esdrach/8149757/webrev/index.html>
>>
>> Thank you,
>> Steve
>

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

From steve.drach at oracle.com  Wed Apr  6 23:36:55 2016
From: steve.drach at oracle.com (Steve Drach)
Date: Wed, 6 Apr 2016 16:36:55 -0700
Subject: RFR 8149757:Implement Multi-Release jar aware JavacFileManager
	for javac
In-Reply-To: <570598FD.4000005@oracle.com>
References: <ABE754D4-F784-4B85-974E-71C96BB01826@oracle.com>
	<C491D9D4-075E-4F96-9B9D-91AE9E1FE03C@oracle.com>
	<570598FD.4000005@oracle.com>
Message-ID: <2C164069-8CA3-4179-B768-A2094164712A@oracle.com>

> OK, good enough; at least the use of .ordinal is confined within the enum itself.
> 
> To be accurate, you are not making "the StandardJavaFileManager" multi-release jar aware.   StandardJavaFileManager is an interface that may have many different implementations.  You are making one particular implementation, the one provided by javac, multi-release aware.

Yes, I understand.  Sloppy wording ? again.

> 
> -- Jon
> 
> 
> On 04/06/2016 04:00 PM, Steve Drach wrote:
>> Hi,
>> 
>> I?ve updated the webrev to include a new method on Target as suggested.
>> 
>> Steve
>> 
>>> On Apr 5, 2016, at 2:02 PM, Steve Drach <steve.drach at oracle.com <mailto:steve.drach at oracle.com>> wrote:
>>> 
>>> Hi,
>>> 
>>> Please review the changes required to make javac and the StandardJavaFileManager multi-release jar aware.  For javac, the version of the classes in a multi-release.jar is selected by the -release (or -target) command line option, or if the option is not present, javac?s default policy is used to select the version ? typically the runtime version (i.e. version 9 is selected for JDK 9).  For the StandardJavaFileManager, the version is selected with the handleOption method.  See the tests for more detail.
>>> 
>>> issue: https://bugs.openjdk.java.net/browse/JDK-8149757 <https://bugs.openjdk.java.net/browse/JDK-8149757>
>>> webrev: http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html <http://cr.openjdk.java.net/%7Esdrach/8149757/webrev/index.html>
>>> 
>>> Thank you,
>>> Steve
>> 
> 

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

From jan.lahoda at oracle.com  Thu Apr  7 05:37:36 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 7 Apr 2016 07:37:36 +0200
Subject: RFR 8149757:Implement Multi-Release jar aware JavacFileManager
	for javac
In-Reply-To: <57056DD8.1060401@oracle.com>
References: <ABE754D4-F784-4B85-974E-71C96BB01826@oracle.com>
	<57055811.2070203@oracle.com> <57056DD8.1060401@oracle.com>
Message-ID: <5705F220.8090904@oracle.com>

On 6.4.2016 22:13, Jonathan Gibbons wrote:
>> -why is JavacFileManager.getJarFSProvider() needed? Shouldn't
>> FileSystems.newFileSystem(realPath, env);
>> be enough? (Calling an SPI directly from an API client seems
>> suspicious to me.)
>
> If I recall correctly, the NIO2 API design forced this one. The method
> you are referring to does not exist. There is only one that takes a URI,
> and that has very different semantics.  So we had to go with the method
> on the provider, hence the use of getJarFSProvider.

Ooops, sorry, I keep forgetting that.

Jan

From steve.drach at oracle.com  Thu Apr  7 22:24:46 2016
From: steve.drach at oracle.com (Steve Drach)
Date: Thu, 7 Apr 2016 15:24:46 -0700
Subject: RFR 8149757:Implement Multi-Release jar aware JavacFileManager
	for javac
Message-ID: <786E8922-0D4A-41D9-9983-79A0F75C242F@oracle.com>

Hi,

This is a new webrev incorporating several changes that both Jon and Jan suggested.

issue: https://bugs.openjdk.java.net/browse/JDK-8149757 <https://bugs.openjdk.java.net/browse/JDK-8149757>
webrev: http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html <http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html>

Thank you,
Steve

> Please review the changes required to make javac and the StandardJavaFileManager multi-release jar aware.  For javac, the version of the classes in a multi-release.jar is selected by the -release (or -target) command line option, or if the option is not present, javac?s default policy is used to select the version ? typically the runtime version (i.e. version 9 is selected for JDK 9).  For the StandardJavaFileManager, the version is selected with the handleOption method.  See the tests for more detail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160407/9e145d6f/attachment-0001.html>

From cushon at google.com  Fri Apr  8 17:35:49 2016
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 8 Apr 2016 10:35:49 -0700
Subject: references to non-static types from annotations
Message-ID: <CAL4QsguxmdiTEi0WFbdZAHiHvgZcC5YsXCeBx=kpZ-5CfpSEJQ@mail.gmail.com>

javac fails to reject references to non-static classes inside annotations,
and instead produces invalid output.

Example:

class Test<T> {
  @Retention(RetentionPolicy.RUNTIME) @interface A { Class<?> value(); }
  @A(I.class) interface C {}
  class I {}
  public static void main(String[] args) {
    System.err.println(Arrays.toString(C.class.getAnnotations()));
  }
}

The reference to I.class in `@A(I.class) interface C {}` refers to the
non-static type Test<T>.I, but the annotation is a static context. The
compiler produces this attribute for the annotation:

$ javap -v -private 'Test$C'
...
   #9 = Utf8               LTest$A;
  #10 = Utf8               value
  #13 = Utf8               LTest<TT;>.I;
...
RuntimeVisibleAnnotations:
  0: #9(#10=c#13)

JVMS 4.7.16.1 requires a class_info_index to be the index of a Utf8_info
representing a return descriptor, and `LTest<TT;>.I;` is not a legal return
descriptor.

The bytecode is rejected when read during reflection, and during subsequent
compilations:

$ javac Test.java && java Test
Exception in thread "main" java.lang.ClassCastException:
sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl cannot be cast
to java.lang.Class
at
sun.reflect.annotation.AnnotationParser.toClass(AnnotationParser.java:448)
at
sun.reflect.annotation.AnnotationParser.parseSig(AnnotationParser.java:441)

$ javac -implicit:none Other.java
Other.java:1: error: cannot access C
class Other { Class<?> clazz = Test.C.class; }
                                   ^
  bad class file: ./Test$C.class
    undeclared type variable: T
    Please remove or make sure it appears in the correct subdirectory of
the classpath.

Recording that a static context is being entered in HeaderPhase before
calling annotateLater fixes the bug, and doesn't break any existing tests.
The compatibility impact of the fix is minimal: I tried patching javac and
building a large code base, and only found a single instance of the problem.

If the proposed fix sounds reasonable, I'd be happy to clean up the patch
for review.

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

From alex.buckley at oracle.com  Wed Apr 13 17:15:53 2016
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 13 Apr 2016 10:15:53 -0700
Subject: references to non-static types from annotations
In-Reply-To: <CAL4QsguxmdiTEi0WFbdZAHiHvgZcC5YsXCeBx=kpZ-5CfpSEJQ@mail.gmail.com>
References: <CAL4QsguxmdiTEi0WFbdZAHiHvgZcC5YsXCeBx=kpZ-5CfpSEJQ@mail.gmail.com>
Message-ID: <570E7EC9.2080607@oracle.com>

On 4/8/2016 10:35 AM, Liam Miller-Cushon wrote:
> javac fails to reject references to non-static classes inside
> annotations, and instead produces invalid output.
>
> Example:
>
> class Test<T> {
>    @Retention(RetentionPolicy.RUNTIME) @interface A { Class<?> value(); }
>    @A(I.class) interface C {}
>    class I {}
>    public static void main(String[] args) {
>      System.err.println(Arrays.toString(C.class.getAnnotations()));
>    }
> }
>
> The reference to I.class in `@A(I.class) interface C {}` refers to the
> non-static type Test<T>.I, but the annotation is a static context.

To clarify, JLS 9.7.1 does not prohibit an annotation element in a 
static context from referring to a non-static class. I don't see why 
such a prohibition would be necessary, yet it sounds like you want javac 
to reject @A(I.class).

The emission of an invalid return descriptor for class_info_index is 
"just" a javac issue, due to not erasing the fully qualified generic 
type of I. If the class literal does the erasure itself -- 
@A(Test.I.class) interface C {} -- then the program compiles and runs 
without error.

Alex

> The compiler produces this attribute for the annotation:
>
> $ javap -v -private 'Test$C'
> ...
>     #9 = Utf8               LTest$A;
>    #10 = Utf8               value
>    #13 = Utf8               LTest<TT;>.I;
> ...
> RuntimeVisibleAnnotations:
>    0: #9(#10=c#13)
>
> JVMS 4.7.16.1 requires a class_info_index to be the index of a Utf8_info
> representing a return descriptor, and `LTest<TT;>.I;` is not a legal
> return descriptor.
>
> The bytecode is rejected when read during reflection, and during
> subsequent compilations:
>
> $ javac Test.java && java Test
> Exception in thread "main" java.lang.ClassCastException:
> sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl cannot be
> cast to java.lang.Class
> at
> sun.reflect.annotation.AnnotationParser.toClass(AnnotationParser.java:448)
> at
> sun.reflect.annotation.AnnotationParser.parseSig(AnnotationParser.java:441)
>
> $ javac -implicit:none Other.java
> Other.java:1: error: cannot access C
> class Other { Class<?> clazz = Test.C.class; }
>                                     ^
>    bad class file: ./Test$C.class
>      undeclared type variable: T
>      Please remove or make sure it appears in the correct subdirectory
> of the classpath.
>
> Recording that a static context is being entered in HeaderPhase before
> calling annotateLater fixes the bug, and doesn't break any existing
> tests. The compatibility impact of the fix is minimal: I tried patching
> javac and building a large code base, and only found a single instance
> of the problem.
>
> If the proposed fix sounds reasonable, I'd be happy to clean up the
> patch for review.
>
> Thanks,
> Liam

From cushon at google.com  Wed Apr 13 17:37:50 2016
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 13 Apr 2016 10:37:50 -0700
Subject: references to non-static types from annotations
In-Reply-To: <570E7EC9.2080607@oracle.com>
References: <CAL4QsguxmdiTEi0WFbdZAHiHvgZcC5YsXCeBx=kpZ-5CfpSEJQ@mail.gmail.com>
	<570E7EC9.2080607@oracle.com>
Message-ID: <CAL4QsguNf1OG5dVLnC=7axBOT+JsBwk_-kRhiXkHt9MkmuTCwA@mail.gmail.com>

On Wed, Apr 13, 2016 at 10:15 AM, Alex Buckley <alex.buckley at oracle.com>
wrote:

>
> To clarify, JLS 9.7.1 does not prohibit an annotation element in a static
> context from referring to a non-static class. I don't see why such a
> prohibition would be necessary, yet it sounds like you want javac to reject
> @A(I.class).
>
> The emission of an invalid return descriptor for class_info_index is
> "just" a javac issue, due to not erasing the fully qualified generic type
> of I. If the class literal does the erasure itself -- @A(Test.I.class)
> interface C {} -- then the program compiles and runs without error.


Thanks for clarifying. I assumed it was supposed to be consistent with
other expressions in static contexts. Is it correct that the following is
currently rejected?

class Test<T> {
  class I {}
  static final Class<?> C = I.class;
}

error: non-static class Test.I cannot be referenced from a static context
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160413/2a9f5fcc/attachment.html>

From alex.buckley at oracle.com  Wed Apr 13 17:57:39 2016
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 13 Apr 2016 10:57:39 -0700
Subject: references to non-static types from annotations
In-Reply-To: <CAL4QsguNf1OG5dVLnC=7axBOT+JsBwk_-kRhiXkHt9MkmuTCwA@mail.gmail.com>
References: <CAL4QsguxmdiTEi0WFbdZAHiHvgZcC5YsXCeBx=kpZ-5CfpSEJQ@mail.gmail.com>
	<570E7EC9.2080607@oracle.com>
	<CAL4QsguNf1OG5dVLnC=7axBOT+JsBwk_-kRhiXkHt9MkmuTCwA@mail.gmail.com>
Message-ID: <570E8893.30208@oracle.com>

On 4/13/2016 10:37 AM, Liam Miller-Cushon wrote:
> On Wed, Apr 13, 2016 at 10:15 AM, Alex Buckley <alex.buckley at oracle.com
> <mailto:alex.buckley at oracle.com>> wrote:
>
>
>     To clarify, JLS 9.7.1 does not prohibit an annotation element in a
>     static context from referring to a non-static class. I don't see why
>     such a prohibition would be necessary, yet it sounds like you want
>     javac to reject @A(I.class).
>
>     The emission of an invalid return descriptor for class_info_index is
>     "just" a javac issue, due to not erasing the fully qualified generic
>     type of I. If the class literal does the erasure itself --
>     @A(Test.I.class) interface C {} -- then the program compiles and
>     runs without error.
>
> Thanks for clarifying. I assumed it was supposed to be consistent with
> other expressions in static contexts.

I know what you mean, but the fact that I can write @A(Test.I.class) 
today means making it consistent would be a serious source incompatibility.

> Is it correct that the following is currently rejected?
>
> class Test<T> {
>    class I {}
>    static final Class<?> C = I.class;
> }
>
> error: non-static class Test.I cannot be referenced from a static context

Good question. This program should not be rejected. No JLS rule 
prohibits I.class in a static context. Static contexts pertain mostly to 
object creation and constructor invocation, but a class literal is a 
rather different kind of expression. Again, the program compiles and 
runs without error if the source code mentions Test.I.class rather than 
I.class.

Alex

From cushon at google.com  Wed Apr 13 18:12:37 2016
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 13 Apr 2016 11:12:37 -0700
Subject: references to non-static types from annotations
In-Reply-To: <570E8893.30208@oracle.com>
References: <CAL4QsguxmdiTEi0WFbdZAHiHvgZcC5YsXCeBx=kpZ-5CfpSEJQ@mail.gmail.com>
	<570E7EC9.2080607@oracle.com>
	<CAL4QsguNf1OG5dVLnC=7axBOT+JsBwk_-kRhiXkHt9MkmuTCwA@mail.gmail.com>
	<570E8893.30208@oracle.com>
Message-ID: <CAL4QsgsPt56o6f-7Ty1mk0HA-LOJ_mHowezz7-SMW_Y+uLB0UA@mail.gmail.com>

On Wed, Apr 13, 2016 at 10:57 AM, Alex Buckley <alex.buckley at oracle.com>
wrote:

> I know what you mean, but the fact that I can write @A(Test.I.class) today
> means making it consistent would be a serious source incompatibility.
>
> Is it correct that the following is currently rejected?
>>
>> class Test<T> {
>>    class I {}
>>    static final Class<?> C = I.class;
>> }
>>
>> error: non-static class Test.I cannot be referenced from a static context
>>
>
> Good question. This program should not be rejected. No JLS rule prohibits
> I.class in a static context. Static contexts pertain mostly to object
> creation and constructor invocation, but a class literal is a rather
> different kind of expression. Again, the program compiles and runs without
> error if the source code mentions Test.I.class rather than I.class.
>

I had wondered if that was deliberate, because `Test.I` makes the erasure
explicit and `I` does not. But I suppose the class literal makes that
explicit anyways.

And I don't think it would be a significant incompatibility, for what it's
worth. I only found a single example of this in our codebase, and ecj
already rejects @A(I.class).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160413/7448b7c2/attachment-0001.html>

From daniel.smith at oracle.com  Wed Apr 13 18:16:24 2016
From: daniel.smith at oracle.com (Dan Smith)
Date: Wed, 13 Apr 2016 12:16:24 -0600
Subject: Call for Speakers -- 2016 JVM Language Summit
Message-ID: <24FD249B-570E-4D7B-9BAE-D3191BAE464D@oracle.com>

CALL FOR SPEAKERS -- JVM LANGUAGE SUMMIT, AUGUST 2016

We are pleased to announce the 2016 JVM Language Summit to be held at Oracle's Santa Clara campus on August 1-3, 2016. Registration is now open for speaker submissions and will remain open through May 23, 2016. There is no registration fee for speakers.

A limited number of early registration slots are also available for regular attendees.

The JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. We will share our experiences as creators of both the JVM and programming languages for the JVM. We also welcome non-JVM developers of similar technologies to attend or speak on their runtime, VM, or language of choice.

Presentations will be recorded and made available to the public.

This event is being organized by language and JVM engineers -- no marketers involved! So bring your slide rules and be prepared for some seriously geeky discussions.

Format

The summit is held in a single classroom-style room to support direct communication between participants. About 100-120 attendees are expected.

The schedule consists of a single track of traditional presentations (about 7 each day) interspersed with less-formal multitrack "workshop" discussion groups (2-3 each day) and, possibly, impromptu "lightning talks."

Workshops will be less structured than in the past, favoring an open discussion format with only a small amount of prepared material. Thus, rather than collecting workshop abstracts from speakers, we're asking each registrant to suggest a few topics of interest. After choosing the most popular topics, we'll ask some registrants if they'd like to act as discussion leaders.

Instructions for Speaker Registration

If you'd like to give a presentation, please register as a Speaker and include a detailed abstract. Speaker registration will remain open through May 23. There is no fee. See below for help preparing your abstract and talk. You will be notified about whether your proposal has been accepted; if not, you will be able to register as a regular attendee.

For a successful speaker submission, please note the following:

- All talks should be deeply technical, given by designers and implementors to designers and implementors. We all speak bytecode here!

- Each talk, we hope and expect, will inform the audience, in detail, about the state of the art of language design or implementation on the JVM, or will explore the present and future capabilities of the JVM itself. (Some will do so indirectly by discussing non-JVM technologies.)

- Know your audience: attendees may not be likely to ever use your specific language or tool, but could learn something from your interactions with the JVM. A broad goal of the summit is to inspire us to work together on JVM-based technologies that enable a rich ecosystem at higher layers.

To register:
register.jvmlangsummit.com

For further information:
jvmlangsummit.com

Questions:
inquire2016 at jvmlangsummit.com


From alex.buckley at oracle.com  Wed Apr 13 18:29:01 2016
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 13 Apr 2016 11:29:01 -0700
Subject: references to non-static types from annotations
In-Reply-To: <CAL4QsgsPt56o6f-7Ty1mk0HA-LOJ_mHowezz7-SMW_Y+uLB0UA@mail.gmail.com>
References: <CAL4QsguxmdiTEi0WFbdZAHiHvgZcC5YsXCeBx=kpZ-5CfpSEJQ@mail.gmail.com>
	<570E7EC9.2080607@oracle.com>
	<CAL4QsguNf1OG5dVLnC=7axBOT+JsBwk_-kRhiXkHt9MkmuTCwA@mail.gmail.com>
	<570E8893.30208@oracle.com>
	<CAL4QsgsPt56o6f-7Ty1mk0HA-LOJ_mHowezz7-SMW_Y+uLB0UA@mail.gmail.com>
Message-ID: <570E8FED.1050606@oracle.com>

On 4/13/2016 11:12 AM, Liam Miller-Cushon wrote:
> On Wed, Apr 13, 2016 at 10:57 AM, Alex Buckley <alex.buckley at oracle.com
> <mailto:alex.buckley at oracle.com>> wrote:
>
>     I know what you mean, but the fact that I can write @A(Test.I.class)
>     today means making it consistent would be a serious source
>     incompatibility.
>
> And I don't think it would be a significant incompatibility, for what
> it's worth. I only found a single example of this in our codebase, and
> ecj already rejects @A(I.class).

A class-valued annotation element that refers to an inner class is 
relatively unusual, but there's no reason to restrict it when this is 
plainly a compiler scope bug (I versus Test.I).

I should have noted earlier that an annotation is never in a static 
context per se -- only a statement or expression can be in a static 
context. Annotations are inherently "static" even when applied to 
clearly non-static source constructs such as the declaration of an 
instance variable in a top level class -- the annotation's elements are 
still on the hook to refer solely to "static things" (constant 
expressions, enum constants, and the special case of a class literal).

Alex

From cushon at google.com  Wed Apr 13 23:35:04 2016
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 13 Apr 2016 16:35:04 -0700
Subject: references to non-static types from annotations
In-Reply-To: <570E8FED.1050606@oracle.com>
References: <CAL4QsguxmdiTEi0WFbdZAHiHvgZcC5YsXCeBx=kpZ-5CfpSEJQ@mail.gmail.com>
	<570E7EC9.2080607@oracle.com>
	<CAL4QsguNf1OG5dVLnC=7axBOT+JsBwk_-kRhiXkHt9MkmuTCwA@mail.gmail.com>
	<570E8893.30208@oracle.com>
	<CAL4QsgsPt56o6f-7Ty1mk0HA-LOJ_mHowezz7-SMW_Y+uLB0UA@mail.gmail.com>
	<570E8FED.1050606@oracle.com>
Message-ID: <CAL4QsguyW2U1sbEhj9mj+rzFFOA81fUm79rJz5whm+HRspsHLQ@mail.gmail.com>

Thanks for the explanation.

Would anyone be willing to file the bug? I'd still like to contribute a fix.

On Wed, Apr 13, 2016 at 11:29 AM, Alex Buckley <alex.buckley at oracle.com>
wrote:

> On 4/13/2016 11:12 AM, Liam Miller-Cushon wrote:
>
>> On Wed, Apr 13, 2016 at 10:57 AM, Alex Buckley <alex.buckley at oracle.com
>> <mailto:alex.buckley at oracle.com>> wrote:
>>
>>     I know what you mean, but the fact that I can write @A(Test.I.class)
>>     today means making it consistent would be a serious source
>>     incompatibility.
>>
>> And I don't think it would be a significant incompatibility, for what
>> it's worth. I only found a single example of this in our codebase, and
>> ecj already rejects @A(I.class).
>>
>
> A class-valued annotation element that refers to an inner class is
> relatively unusual, but there's no reason to restrict it when this is
> plainly a compiler scope bug (I versus Test.I).
>
> I should have noted earlier that an annotation is never in a static
> context per se -- only a statement or expression can be in a static
> context. Annotations are inherently "static" even when applied to clearly
> non-static source constructs such as the declaration of an instance
> variable in a top level class -- the annotation's elements are still on the
> hook to refer solely to "static things" (constant expressions, enum
> constants, and the special case of a class literal).
>
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160413/f37ec479/attachment.html>

From stuart.marks at oracle.com  Thu Apr 14 01:59:00 2016
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 13 Apr 2016 18:59:00 -0700
Subject: Fwd: RFR(m): 8145468 deprecations for java.lang
In-Reply-To: <570EF756.2090602@oracle.com>
References: <570EF756.2090602@oracle.com>
Message-ID: <570EF964.5030106@oracle.com>

I've just posted the following review request to core-libs-dev. Some of the 
warnings cleanup work occurs in the langtools repo, so it seems that I should 
post it here as well. Please review.

Thanks,

s'marks



-------- Forwarded Message --------
Subject: RFR(m): 8145468 deprecations for java.lang
Date: Wed, 13 Apr 2016 18:50:14 -0700
From: Stuart Marks <stuart.marks at oracle.com>
To: core-libs-dev <core-libs-dev at openjdk.java.net>

Hi all,

Please review this first round of deprecation changes for the java.lang package.
This changeset includes the following:

  - a set of APIs being newly deprecated
  - a set of already-deprecated APIs that are "upgraded" to forRemoval=true
  - addition of the "since" element to all deprecations
  - cleanup of some of the warnings caused by new deprecations

Webrevs:

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

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

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

The newly deprecated APIs include all of the constructors for the boxed
primitives. We don't intend to remove these yet, so they don't declare a value
for the forRemoval element, implying the default value of false. The
constructors being deprecated are as follows:

   Boolean(boolean)
   Boolean(String)
   Byte(byte)
   Byte(String)
   Character(char)
   Double(double)
   Double(String)
   Float(float)
   Float(double)
   Float(String)
   Integer(int)
   Integer(String)
   Long(long)
   Long(String)
   Short(short)
   Short(String)

The methods being deprecated with forRemoval=true are listed below. All of these
methods have already been deprecated. They are all ill-defined, or they don't
work, or they don't do anything useful.

   Runtime.getLocalizedInputStream(InputStream)
   Runtime.getLocalizedOutputStream(OutputStream)
   Runtime.runFinalizersOnExit(boolean)
   SecurityManager.checkAwtEventQueueAccess()
   SecurityManager.checkMemberAccess(Class<?>, int)
   SecurityManager.checkSystemClipboardAccess()
   SecurityManager.checkTopLevelWindow(Object)
   System.runFinalizersOnExit(boolean)
   Thread.countStackFrames()
   Thread.destroy()
   Thread.stop(Throwable)

Most of the files in the changeset are cleanups. Some of them are simply the
addition of the "since" element to the @Deprecated annotation, to indicate the
version in which the API became deprecated.

The rest of the changes are cleanup of warnings that were created by the
deprecation of the boxed primitive constructors. There are a total of a couple
hundred such uses sprinkled around the JDK. I've taken care of a portion of
them, with the exception of the java.desktop module, which alone has over 100
uses of boxed primitive constructors. I've disabled deprecation warnings for the
java.desktop module for the time being; these uses can be cleaned up later. I've
filed JDK-8154213 to cover this cleanup task.

For the warnings cleanups I did, I mostly did conversions of the form:

    new Double(dval)

to

    Double.valueOf(dval)

This is a very safe transformation. It changes the behavior only in the cases
where the code relies on getting a new instance of the box object instead of one
that might come out of a cache. I didn't see any such code (and I should hope
there's no such code in the JDK!).

I applied autoboxing only sparingly, in the cases where it was an obviously safe
thing to do, or where nearby code already uses autoboxing. Autoboxing actually
generates a call to the appropriate valueOf() method, so the bytecode would be
the same in most cases. The only difference is clutter in the source code. On
the other hand, there's some risk in converting to autoboxing, as the implicitly
autoboxed type might end up different from an explicit call to valueOf(). This
isn't always obvious, so that's why I mostly avoided autoboxing.

Thanks,

s'marks




From maurizio.cimadamore at oracle.com  Thu Apr 14 10:20:56 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 14 Apr 2016 11:20:56 +0100
Subject: Fwd: RFR(m): 8145468 deprecations for java.lang
In-Reply-To: <570EF964.5030106@oracle.com>
References: <570EF756.2090602@oracle.com> <570EF964.5030106@oracle.com>
Message-ID: <570F6F08.2070300@oracle.com>

Looks good - thanks!

Maurizio

On 14/04/16 02:59, Stuart Marks wrote:
> I've just posted the following review request to core-libs-dev. Some 
> of the warnings cleanup work occurs in the langtools repo, so it seems 
> that I should post it here as well. Please review.
>
> Thanks,
>
> s'marks
>
>
>
> -------- Forwarded Message --------
> Subject: RFR(m): 8145468 deprecations for java.lang
> Date: Wed, 13 Apr 2016 18:50:14 -0700
> From: Stuart Marks <stuart.marks at oracle.com>
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>
> Hi all,
>
> Please review this first round of deprecation changes for the 
> java.lang package.
> This changeset includes the following:
>
>  - a set of APIs being newly deprecated
>  - a set of already-deprecated APIs that are "upgraded" to 
> forRemoval=true
>  - addition of the "since" element to all deprecations
>  - cleanup of some of the warnings caused by new deprecations
>
> Webrevs:
>
>   http://cr.openjdk.java.net/~smarks/reviews/8145468/webrev.0.jdk/
>
> http://cr.openjdk.java.net/~smarks/reviews/8145468/webrev.0.langtools/
>
>   http://cr.openjdk.java.net/~smarks/reviews/8145468/webrev.0.top/
>
> The newly deprecated APIs include all of the constructors for the boxed
> primitives. We don't intend to remove these yet, so they don't declare 
> a value
> for the forRemoval element, implying the default value of false. The
> constructors being deprecated are as follows:
>
>   Boolean(boolean)
>   Boolean(String)
>   Byte(byte)
>   Byte(String)
>   Character(char)
>   Double(double)
>   Double(String)
>   Float(float)
>   Float(double)
>   Float(String)
>   Integer(int)
>   Integer(String)
>   Long(long)
>   Long(String)
>   Short(short)
>   Short(String)
>
> The methods being deprecated with forRemoval=true are listed below. 
> All of these
> methods have already been deprecated. They are all ill-defined, or 
> they don't
> work, or they don't do anything useful.
>
>   Runtime.getLocalizedInputStream(InputStream)
>   Runtime.getLocalizedOutputStream(OutputStream)
>   Runtime.runFinalizersOnExit(boolean)
>   SecurityManager.checkAwtEventQueueAccess()
>   SecurityManager.checkMemberAccess(Class<?>, int)
>   SecurityManager.checkSystemClipboardAccess()
>   SecurityManager.checkTopLevelWindow(Object)
>   System.runFinalizersOnExit(boolean)
>   Thread.countStackFrames()
>   Thread.destroy()
>   Thread.stop(Throwable)
>
> Most of the files in the changeset are cleanups. Some of them are 
> simply the
> addition of the "since" element to the @Deprecated annotation, to 
> indicate the
> version in which the API became deprecated.
>
> The rest of the changes are cleanup of warnings that were created by the
> deprecation of the boxed primitive constructors. There are a total of 
> a couple
> hundred such uses sprinkled around the JDK. I've taken care of a 
> portion of
> them, with the exception of the java.desktop module, which alone has 
> over 100
> uses of boxed primitive constructors. I've disabled deprecation 
> warnings for the
> java.desktop module for the time being; these uses can be cleaned up 
> later. I've
> filed JDK-8154213 to cover this cleanup task.
>
> For the warnings cleanups I did, I mostly did conversions of the form:
>
>    new Double(dval)
>
> to
>
>    Double.valueOf(dval)
>
> This is a very safe transformation. It changes the behavior only in 
> the cases
> where the code relies on getting a new instance of the box object 
> instead of one
> that might come out of a cache. I didn't see any such code (and I 
> should hope
> there's no such code in the JDK!).
>
> I applied autoboxing only sparingly, in the cases where it was an 
> obviously safe
> thing to do, or where nearby code already uses autoboxing. Autoboxing 
> actually
> generates a call to the appropriate valueOf() method, so the bytecode 
> would be
> the same in most cases. The only difference is clutter in the source 
> code. On
> the other hand, there's some risk in converting to autoboxing, as the 
> implicitly
> autoboxed type might end up different from an explicit call to 
> valueOf(). This
> isn't always obvious, so that's why I mostly avoided autoboxing.
>
> Thanks,
>
> s'marks
>
>
>


From alex.buckley at oracle.com  Thu Apr 14 19:24:14 2016
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 14 Apr 2016 12:24:14 -0700
Subject: references to non-static types from annotations
In-Reply-To: <CAL4QsguyW2U1sbEhj9mj+rzFFOA81fUm79rJz5whm+HRspsHLQ@mail.gmail.com>
References: <CAL4QsguxmdiTEi0WFbdZAHiHvgZcC5YsXCeBx=kpZ-5CfpSEJQ@mail.gmail.com>
	<570E7EC9.2080607@oracle.com>
	<CAL4QsguNf1OG5dVLnC=7axBOT+JsBwk_-kRhiXkHt9MkmuTCwA@mail.gmail.com>
	<570E8893.30208@oracle.com>
	<CAL4QsgsPt56o6f-7Ty1mk0HA-LOJ_mHowezz7-SMW_Y+uLB0UA@mail.gmail.com>
	<570E8FED.1050606@oracle.com>
	<CAL4QsguyW2U1sbEhj9mj+rzFFOA81fUm79rJz5whm+HRspsHLQ@mail.gmail.com>
Message-ID: <570FEE5E.50008@oracle.com>

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

On 4/13/2016 4:35 PM, Liam Miller-Cushon wrote:
> Thanks for the explanation.
>
> Would anyone be willing to file the bug? I'd still like to contribute a fix.
>
> On Wed, Apr 13, 2016 at 11:29 AM, Alex Buckley <alex.buckley at oracle.com
> <mailto:alex.buckley at oracle.com>> wrote:
>
>     On 4/13/2016 11:12 AM, Liam Miller-Cushon wrote:
>
>         On Wed, Apr 13, 2016 at 10:57 AM, Alex Buckley
>         <alex.buckley at oracle.com <mailto:alex.buckley at oracle.com>
>         <mailto:alex.buckley at oracle.com
>         <mailto:alex.buckley at oracle.com>>> wrote:
>
>              I know what you mean, but the fact that I can write
>         @A(Test.I.class)
>              today means making it consistent would be a serious source
>              incompatibility.
>
>         And I don't think it would be a significant incompatibility, for
>         what
>         it's worth. I only found a single example of this in our
>         codebase, and
>         ecj already rejects @A(I.class).
>
>
>     A class-valued annotation element that refers to an inner class is
>     relatively unusual, but there's no reason to restrict it when this
>     is plainly a compiler scope bug (I versus Test.I).
>
>     I should have noted earlier that an annotation is never in a static
>     context per se -- only a statement or expression can be in a static
>     context. Annotations are inherently "static" even when applied to
>     clearly non-static source constructs such as the declaration of an
>     instance variable in a top level class -- the annotation's elements
>     are still on the hook to refer solely to "static things" (constant
>     expressions, enum constants, and the special case of a class literal).
>
>     Alex
>
>

From jan.lahoda at oracle.com  Fri Apr 15 09:47:24 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 15 Apr 2016 11:47:24 +0200
Subject: RFR: 8154283: Check for clash between package and class not working
	when package in a different module
Message-ID: <5710B8AC.3030406@oracle.com>

Hi,

Please review the following fix. When checking for package-class clash, 
all packages visible from the given module should be checked, not only 
packages in the given module. Also, cleaning up a forgotten related 
field in MemberEnter.

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

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

Thanks,
    Jan

From yuzhihong at gmail.com  Sat Apr 16 14:57:29 2016
From: yuzhihong at gmail.com (Ted Yu)
Date: Sat, 16 Apr 2016 07:57:29 -0700
Subject: ExceptionInInitializerError
Message-ID: <CALte62yC_P_t4vbuEV2UBfWau_zQvfaOLx2JE_4+7vtceMUFnQ@mail.gmail.com>

Hi,
We run hbase snapshot on Azure Data Lake with openjdk 1.7_95.

For on-going snapshot, we observed the following:

http://pastebin.com/Kig0mMwN


This is the related field from SnapshotProtos class:

  private static

    com.google.protobuf.GeneratedMessage.FieldAccessorTable

      internal_static_hbase_pb_SnapshotDataManifest_fieldAccessorTable;

My question is:

would the ExceptionInInitializerError from above snippet lead to the
following (running in same JVM):

2016-04-15 18:24:59,262 ERROR [MASTER_TABLE_OPERATIONS-10.0.0.84:16000-0]
executor.EventHandler: Caught throwable while processing event
C_M_SNAPSHOT_TABLE

java.lang.NoClassDefFoundError: Could not initialize class
org.apache.hadoop.hbase.protobuf.generated.SnapshotProtos

  at
org.apache.hadoop.hbase.protobuf.generated.SnapshotProtos$SnapshotDataManifest.internalGetFieldAccessorTable(SnapshotProtos.java:3883)

  at
com.google.protobuf.GeneratedMessage.getDescriptorForType(GeneratedMessage.java:98)

  at
com.google.protobuf.AbstractMessage$Builder.findMissingFields(AbstractMessage.java:789)

  at
com.google.protobuf.AbstractMessage$Builder.findMissingFields(AbstractMessage.java:780)

  at
com.google.protobuf.AbstractMessage$Builder.newUninitializedMessageException(AbstractMessage.java:770)

  at
com.google.protobuf.AbstractMessage.newUninitializedMessageException(AbstractMessage.java:237)

  at
com.google.protobuf.AbstractParser.newUninitializedMessageException(AbstractParser.java:57)

  at
com.google.protobuf.AbstractParser.checkMessageInitialized(AbstractParser.java:71)

  at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:217)

  at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:223)

  at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:49)

  at
org.apache.hadoop.hbase.protobuf.generated.SnapshotProtos$SnapshotDataManifest.parseFrom(SnapshotProtos.java:4094)

  at
org.apache.hadoop.hbase.snapshot.SnapshotManifest.readDataManifest(SnapshotManifest.java:433)

  at
org.apache.hadoop.hbase.snapshot.SnapshotManifest.load(SnapshotManifest.java:273)

  at
org.apache.hadoop.hbase.snapshot.SnapshotManifest.open(SnapshotManifest.java:119)

  at
org.apache.hadoop.hbase.master.snapshot.MasterSnapshotVerifier.verifySnapshot(MasterSnapshotVerifier.java:108)

  at
org.apache.hadoop.hbase.master.snapshot.TakeSnapshotHandler.process(TakeSnapshotHandler.java:200)


You can find related source code at
https://github.com/apache/hbase/tree/master/hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated

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

From wieland at testingtech.com  Mon Apr 18 08:30:39 2016
From: wieland at testingtech.com (Jacob Wieland)
Date: Mon, 18 Apr 2016 10:30:39 +0200
Subject: Ridiculously low restrictions on class files
Message-ID: <CAFS6XfSYPNzN7VZgjp_0EbwLM8RW02Jzs+Bx4-rcaEPpJpj=aA@mail.gmail.com>

Hello folks,

is there any plan in the future to get rid of the ridiculously low barriers
restricting the current class-format that seem to be a relic from a
different (low-memory) age and are not very future-proof?

Up till now, I have run into the following shortcomings that, at the
moment, a lot of annoying workarounds have to be found for:
- only 64KB per method (with no way of knowing how much source code will
produce how much byte-code, this is a nightmare when generating Java source
code)
  => especially for the anonymous constructor, if a class has a lot of
members. As the initialization needs to be split into methods called by the
constructor, it is no longer possible to declare these fields final, even
though they should be
- only 64K class members
- only 64K constant pool (which is especially annoying when using inner
classes as for each such class, a constant seems to be reserved)
 => need to split code of methods containing constants into lots of
runnable-wrappers

Alternatively, javac could be amended to generate byte-code according to
the class-restrictions so that every correct Java source code is also
compileable, but this is probably a higher feat of engineering than
"simply" raising the barriers.

BR,

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

From alex.buckley at oracle.com  Mon Apr 18 17:19:47 2016
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 18 Apr 2016 10:19:47 -0700
Subject: ExceptionInInitializerError
In-Reply-To: <CALte62yC_P_t4vbuEV2UBfWau_zQvfaOLx2JE_4+7vtceMUFnQ@mail.gmail.com>
References: <CALte62yC_P_t4vbuEV2UBfWau_zQvfaOLx2JE_4+7vtceMUFnQ@mail.gmail.com>
Message-ID: <57151733.6050807@oracle.com>

Ted, compiler-dev is for discussing javac, but your problem below 
doesn't appear related to javac or the JVM or the JDK.

Alex

On 4/16/2016 7:57 AM, Ted Yu wrote:
> Hi,
> We run hbase snapshot on Azure Data Lake with openjdk 1.7_95.
>
> For on-going snapshot, we observed the following:
>
> http://pastebin.com/Kig0mMwN
>
>
> This is the related field from SnapshotProtos class:
>
> privatestatic
>
>      com.google.protobuf.GeneratedMessage.FieldAccessorTable
>
> internal_static_hbase_pb_SnapshotDataManifest_fieldAccessorTable;
>
> My question is:
>
> would the ExceptionInInitializerError from above snippet lead to the
> following (running in same JVM):
>
> 2016-04-15 18:24:59,262 ERROR
> [MASTER_TABLE_OPERATIONS-10.0.0.84:16000-0] executor.EventHandler:
> Caught throwable while processing event C_M_SNAPSHOT_TABLE
>
> java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.hadoop.hbase.protobuf.generated.SnapshotProtos
>
>    at
> org.apache.hadoop.hbase.protobuf.generated.SnapshotProtos$SnapshotDataManifest.internalGetFieldAccessorTable(SnapshotProtos.java:3883)
>
>    at
> com.google.protobuf.GeneratedMessage.getDescriptorForType(GeneratedMessage.java:98)
>
>    at
> com.google.protobuf.AbstractMessage$Builder.findMissingFields(AbstractMessage.java:789)
>
>    at
> com.google.protobuf.AbstractMessage$Builder.findMissingFields(AbstractMessage.java:780)
>
>    at
> com.google.protobuf.AbstractMessage$Builder.newUninitializedMessageException(AbstractMessage.java:770)
>
>    at
> com.google.protobuf.AbstractMessage.newUninitializedMessageException(AbstractMessage.java:237)
>
>    at
> com.google.protobuf.AbstractParser.newUninitializedMessageException(AbstractParser.java:57)
>
>    at
> com.google.protobuf.AbstractParser.checkMessageInitialized(AbstractParser.java:71)
>
>    at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:217)
>
>    at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:223)
>
>    at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:49)
>
>    at
> org.apache.hadoop.hbase.protobuf.generated.SnapshotProtos$SnapshotDataManifest.parseFrom(SnapshotProtos.java:4094)
>
>    at
> org.apache.hadoop.hbase.snapshot.SnapshotManifest.readDataManifest(SnapshotManifest.java:433)
>
>    at
> org.apache.hadoop.hbase.snapshot.SnapshotManifest.load(SnapshotManifest.java:273)
>
>    at
> org.apache.hadoop.hbase.snapshot.SnapshotManifest.open(SnapshotManifest.java:119)
>
>    at
> org.apache.hadoop.hbase.master.snapshot.MasterSnapshotVerifier.verifySnapshot(MasterSnapshotVerifier.java:108)
>
>    at
> org.apache.hadoop.hbase.master.snapshot.TakeSnapshotHandler.process(TakeSnapshotHandler.java:200)
>
>
> You can find related source code at
> https://github.com/apache/hbase/tree/master/hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated
>
> Thanks
>

From cushon at google.com  Mon Apr 18 23:43:34 2016
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 18 Apr 2016 16:43:34 -0700
Subject: RFR 8154270: javac wrongly rejects some class literals as annotation
	element values
Message-ID: <CAL4QsgvREVvxX2yhtVPGYjXwFoqV-N+RLJ9nPGf=FAUDeZ4ttw@mail.gmail.com>

Hi,

Please review the attached fix for JDK-8154270.

issue: https://bugs.openjdk.java.net/browse/JDK-8154270

Thanks,
Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160418/710fd0dd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8154270.patch
Type: text/x-patch
Size: 3054 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160418/710fd0dd/8154270.patch>

From jonathan.gibbons at oracle.com  Tue Apr 19 01:32:19 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 18 Apr 2016 18:32:19 -0700
Subject: RFR: 8154504 javac tests fail after JDK API is deprecated
Message-ID: <57158AA3.60709@oracle.com>

Some tests fail after the deprecations added in
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/92280897299f
https://bugs.openjdk.java.net/browse/JDK-8145468

This review addresses those failures.   There are many otrher instances 
of 'new Integer([0-9]+)' in the repo, but which do not cause test 
failures. They can be handled separately.

Bug: https://bugs.openjdk.java.net/browse/JDK-8154504
Review: http://cr.openjdk.java.net/~jjg/8154504/webrev.00/index.html

-- Jon

From joe.darcy at oracle.com  Tue Apr 19 01:36:41 2016
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 18 Apr 2016 18:36:41 -0700
Subject: RFR: 8154504 javac tests fail after JDK API is deprecated
In-Reply-To: <57158AA3.60709@oracle.com>
References: <57158AA3.60709@oracle.com>
Message-ID: <57158BA9.2070704@oracle.com>

Looks good Jon; thanks,

-Joe

On 4/18/2016 6:32 PM, Jonathan Gibbons wrote:
> Some tests fail after the deprecations added in
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/92280897299f
> https://bugs.openjdk.java.net/browse/JDK-8145468
>
> This review addresses those failures.   There are many otrher 
> instances of 'new Integer([0-9]+)' in the repo, but which do not cause 
> test failures. They can be handled separately.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8154504
> Review: http://cr.openjdk.java.net/~jjg/8154504/webrev.00/index.html
>
> -- Jon


From stuart.marks at oracle.com  Tue Apr 19 03:31:41 2016
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 18 Apr 2016 20:31:41 -0700
Subject: RFR: 8154504 javac tests fail after JDK API is deprecated
In-Reply-To: <57158AA3.60709@oracle.com>
References: <57158AA3.60709@oracle.com>
Message-ID: <5715A69D.80302@oracle.com>

Thanks for cleaning up after me!

s'marks

On 4/18/16 6:32 PM, Jonathan Gibbons wrote:
> Some tests fail after the deprecations added in
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/92280897299f
> https://bugs.openjdk.java.net/browse/JDK-8145468
>
> This review addresses those failures.   There are many otrher instances of 'new
> Integer([0-9]+)' in the repo, but which do not cause test failures. They can be
> handled separately.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8154504
> Review: http://cr.openjdk.java.net/~jjg/8154504/webrev.00/index.html
>
> -- Jon

From cushon at google.com  Thu Apr 21 15:57:57 2016
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 21 Apr 2016 08:57:57 -0700
Subject: MethodSymbol.implementedIn
Message-ID: <CAL4QsgsOcyim=TKvLjcmuJ+B_H3=D2kyKkDRzZeq9TssUuuweA@mail.gmail.com>

Hi, I have a question about MethodSymbol.implementedIn:
http://hg.openjdk.java.net/jdk9/dev/langtools/file/9b37d0f28609/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java#l1620

I think the FIXME about using subst() is incorrect, Types.memberType takes
care of that.

But testing that the return types are the same still looks wrong, because
it doesn't handle implementations with covariant return types.

I'm not sure why implementedIn is testing return types at all: it calls
MethodSymbol.overrides, which checks return types.

So perhaps the call to isSameType in implementedIn can just be removed?
Deleting it doesn't break any tests.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160421/857f4178/attachment.html>

From maurizio.cimadamore at oracle.com  Thu Apr 21 16:19:47 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 21 Apr 2016 17:19:47 +0100
Subject: MethodSymbol.implementedIn
In-Reply-To: <CAL4QsgsOcyim=TKvLjcmuJ+B_H3=D2kyKkDRzZeq9TssUuuweA@mail.gmail.com>
References: <CAL4QsgsOcyim=TKvLjcmuJ+B_H3=D2kyKkDRzZeq9TssUuuweA@mail.gmail.com>
Message-ID: <5718FDA3.4070305@oracle.com>

Is the method even used? My IDE says it's only used recursively within 
the same method...

Maurizio

On 21/04/16 16:57, Liam Miller-Cushon wrote:
> Hi, I have a question about MethodSymbol.implementedIn:
> http://hg.openjdk.java.net/jdk9/dev/langtools/file/9b37d0f28609/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java#l1620
>
> I think the FIXME about using subst() is incorrect, Types.memberType 
> takes care of that.
>
> But testing that the return types are the same still looks wrong, 
> because it doesn't handle implementations with covariant return types.
>
> I'm not sure why implementedIn is testing return types at all: it 
> calls MethodSymbol.overrides, which checks return types.
>
> So perhaps the call to isSameType in implementedIn can just be 
> removed? Deleting it doesn't break any tests.


From cushon at google.com  Thu Apr 21 16:25:41 2016
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 21 Apr 2016 09:25:41 -0700
Subject: MethodSymbol.implementedIn
In-Reply-To: <5718FDA3.4070305@oracle.com>
References: <CAL4QsgsOcyim=TKvLjcmuJ+B_H3=D2kyKkDRzZeq9TssUuuweA@mail.gmail.com>
	<5718FDA3.4070305@oracle.com>
Message-ID: <CAL4Qsgt=L+HZ0uppYh1nbsBbFQfAURJp6TrE2yYkHCTfSz9PNg@mail.gmail.com>

Oh, good question. There was a single usage in TransTypes that was recently
deleted: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2a83d2947323

So can the method be removed?

On Thu, Apr 21, 2016 at 9:19 AM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Is the method even used? My IDE says it's only used recursively within the
> same method...
>
> Maurizio
>
>
> On 21/04/16 16:57, Liam Miller-Cushon wrote:
>
>> Hi, I have a question about MethodSymbol.implementedIn:
>>
>> http://hg.openjdk.java.net/jdk9/dev/langtools/file/9b37d0f28609/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java#l1620
>>
>> I think the FIXME about using subst() is incorrect, Types.memberType
>> takes care of that.
>>
>> But testing that the return types are the same still looks wrong, because
>> it doesn't handle implementations with covariant return types.
>>
>> I'm not sure why implementedIn is testing return types at all: it calls
>> MethodSymbol.overrides, which checks return types.
>>
>> So perhaps the call to isSameType in implementedIn can just be removed?
>> Deleting it doesn't break any tests.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160421/d173b518/attachment.html>

From maurizio.cimadamore at oracle.com  Thu Apr 21 20:49:21 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 21 Apr 2016 21:49:21 +0100
Subject: MethodSymbol.implementedIn
In-Reply-To: <CAL4Qsgt=L+HZ0uppYh1nbsBbFQfAURJp6TrE2yYkHCTfSz9PNg@mail.gmail.com>
References: <CAL4QsgsOcyim=TKvLjcmuJ+B_H3=D2kyKkDRzZeq9TssUuuweA@mail.gmail.com>
	<5718FDA3.4070305@oracle.com>
	<CAL4Qsgt=L+HZ0uppYh1nbsBbFQfAURJp6TrE2yYkHCTfSz9PNg@mail.gmail.com>
Message-ID: <57193CD1.2020501@oracle.com>



On 21/04/16 17:25, Liam Miller-Cushon wrote:
> Oh, good question. There was a single usage in TransTypes that was 
> recently deleted: 
> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2a83d2947323
>
> So can the method be removed?
I think so (yayy!)

Maurizio
>
> On Thu, Apr 21, 2016 at 9:19 AM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     Is the method even used? My IDE says it's only used recursively
>     within the same method...
>
>     Maurizio
>
>
>     On 21/04/16 16:57, Liam Miller-Cushon wrote:
>
>         Hi, I have a question about MethodSymbol.implementedIn:
>         http://hg.openjdk.java.net/jdk9/dev/langtools/file/9b37d0f28609/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java#l1620
>
>         I think the FIXME about using subst() is incorrect,
>         Types.memberType takes care of that.
>
>         But testing that the return types are the same still looks
>         wrong, because it doesn't handle implementations with
>         covariant return types.
>
>         I'm not sure why implementedIn is testing return types at all:
>         it calls MethodSymbol.overrides, which checks return types.
>
>         So perhaps the call to isSameType in implementedIn can just be
>         removed? Deleting it doesn't break any tests.
>
>
>

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

From maurizio.cimadamore at oracle.com  Thu Apr 21 20:58:59 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 21 Apr 2016 21:58:59 +0100
Subject: RFR 8154270: javac wrongly rejects some class literals as
	annotation element values
In-Reply-To: <CAL4QsgvREVvxX2yhtVPGYjXwFoqV-N+RLJ9nPGf=FAUDeZ4ttw@mail.gmail.com>
References: <CAL4QsgvREVvxX2yhtVPGYjXwFoqV-N+RLJ9nPGf=FAUDeZ4ttw@mail.gmail.com>
Message-ID: <57193F13.4030004@oracle.com>

Hi Liam,
the fix looks good - few comments:

* since the issue can be exposed in two ways (reflection and separate 
compilation), I'd like to see two tests; you have one for reflection - 
having also the other for separate compilation would be great (since 
that area tends to get neglected)

* I'm not a lawyer - and I'm not sure whether the copyright header in 
your test is correct ;-)

Thanks!
Maurizio


On 19/04/16 00:43, Liam Miller-Cushon wrote:
> Hi,
>
> Please review the attached fix for JDK-8154270.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8154270
>
> Thanks,
> Liam


From cushon at google.com  Thu Apr 21 23:59:28 2016
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 21 Apr 2016 16:59:28 -0700
Subject: RFR 8154270: javac wrongly rejects some class literals as
	annotation element values
In-Reply-To: <57193F13.4030004@oracle.com>
References: <CAL4QsgvREVvxX2yhtVPGYjXwFoqV-N+RLJ9nPGf=FAUDeZ4ttw@mail.gmail.com>
	<57193F13.4030004@oracle.com>
Message-ID: <CAL4QsguHtvKFgGSYRCdQga0ovN1eGFLLud_D7iSAUdYcaM+89A@mail.gmail.com>

Thanks for the review! The updated patch is attached.


> * since the issue can be exposed in two ways (reflection and separate
> compilation), I'd like to see two tests; you have one for reflection -
> having also the other for separate compilation would be great (since that
> area tends to get neglected)


To confirm, do you mean the "javac -implicit:none Other.java" example in
the original thread? I added that to the test.

I also thought about testing against a bad class file, but that doesn't
exercise anything in the patch and I don't have a good way to generate a
class with the problem (ASM won't write classes with this issue, and now
javac won't either).


> * I'm not a lawyer - and I'm not sure whether the copyright header in your
> test is correct ;-)


Oops. Any concerns with using the same header (except for the date) as
this:
http://hg.openjdk.java.net/jdk9/dev/jdk/file/c0f3840e225a/test/java/util/zip/EntryCount64k.java
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160421/eedb094d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8154270.patch
Type: text/x-patch
Size: 4702 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160421/eedb094d/8154270-0001.patch>

From jonathan.gibbons at oracle.com  Mon Apr 25 20:10:03 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 25 Apr 2016 13:10:03 -0700
Subject: RFR: 8154283: Check for clash between package and class not
	working when package in a different module
In-Reply-To: <5710B8AC.3030406@oracle.com>
References: <5710B8AC.3030406@oracle.com>
Message-ID: <571E799B.7030504@oracle.com>

In test, line 273, suggest capitalize "package" embedded in method name.
Strange indentation on line 290

Otherwise OK.

-- Jon

On 04/15/2016 02:47 AM, Jan Lahoda wrote:
> Hi,
>
> Please review the following fix. When checking for package-class 
> clash, all packages visible from the given module should be checked, 
> not only packages in the given module. Also, cleaning up a forgotten 
> related field in MemberEnter.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8154283
>
> Webrev:
> http://cr.openjdk.java.net/~jlahoda/8154283/webrev.00/
>
> Thanks,
>    Jan


From stuart.marks at oracle.com  Mon Apr 25 23:14:55 2016
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 25 Apr 2016 16:14:55 -0700
Subject: Fwd: RFR(m): 8140281 deprecate Optional.get()
In-Reply-To: <b7382ded-5669-7c92-f1f9-bec45a1f36a5@oracle.com>
References: <b7382ded-5669-7c92-f1f9-bec45a1f36a5@oracle.com>
Message-ID: <1282fc0c-2d92-be13-d95e-9486cd556146@oracle.com>

One of the changes in the langtools webrev

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

is in the compiler. Please review.

Thanks,

s'marks


-------- Forwarded Message --------
Subject: RFR(m): 8140281 deprecate Optional.get()
Date: Mon, 25 Apr 2016 16:05:13 -0700
From: Stuart Marks <stuart.marks at oracle.com>
To: core-libs-dev <core-libs-dev at openjdk.java.net>

Hi all,

Please review these webrevs that deprecate Optional.get() and to replace it with 
Optional.getWhenPresent(). The corresponding changes are also applied to 
OptionalDouble.getAsDouble(), OptionalInt.getAsInt(), and OptionalLong.getAsLong().

Unlike most deprecations, this isn't about the function or the utility of some 
API, it's about the name. The solution is basically to rename the API. The 
problem is that "get" shows up as the "obvious" choice in things like IDE code 
completion, leading to code that mishandles empty Optionals. Typical Stack 
Overflow discourse runs something like this:

      Q: what do I do with this Optional thing

      A: just call get()

      Q: thanks, it works!

Of course, it works until it doesn't.

Examining the JDK's use of Optional.get(), I didn't see very many cases that 
called get() without first checking for the presence of a value. But I did see 
quite a number of cases like this:

      if (opt.isPresent()) {
          doSomething(opt.get());
      } else {
          doSomethingElse();
      }

In many of these cases, the code could be refactored to use other Optional 
methods such as filter(), map(), or ifPresent().

In any case this reinforces the contention that use of get() leads to poor code.

For this changeset, in just about all cases I've simply replaced the call to 
get() with a call to getWhenPresent(). In a couple cases I replaced the stream calls

      .filter(Optional::isPresent).map(Optional::get)

with

      .flatMap(Optional::stream)

which I hope will become the new idiom for unwrapping a stream of Optionals.

While many cases could be cleaned up further, I didn't change them. The reasons 
are that I didn't want to spend too much time putting code cleanup into the 
critical path of this changeset (I'd be happy to help later); doing so would 
create potential conflicts with code coming in from the Jigsaw forest; and there 
are non-obvious places where converting from a conditional to one of the 
lambda-based methods could cause performance problems at startup.

There are also a few cases where simplification is prevented because it would 
end up causing the resulting lambda expressions to throw checked exceptions. :-(

Webrevs here:

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

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

Thanks,

s'marks

From jonathan.gibbons at oracle.com  Mon Apr 25 23:27:41 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 25 Apr 2016 16:27:41 -0700
Subject: Fwd: RFR(m): 8140281 deprecate Optional.get()
In-Reply-To: <1282fc0c-2d92-be13-d95e-9486cd556146@oracle.com>
References: <b7382ded-5669-7c92-f1f9-bec45a1f36a5@oracle.com>
	<1282fc0c-2d92-be13-d95e-9486cd556146@oracle.com>
Message-ID: <571EA7ED.4080609@oracle.com>

Enter.java:
It's pretty ugly that the recommended usage is to have to add a 
SuppressWarnings for a reasonable and valid use of Optional.get.

Are you sure this is the API you want?

-- Jon


On 04/25/2016 04:14 PM, Stuart Marks wrote:
> One of the changes in the langtools webrev
>
> http://cr.openjdk.java.net/~smarks/reviews/8140281/webrev.0.langtools/
>
> is in the compiler. Please review.
>
> Thanks,
>
> s'marks
>
>
> -------- Forwarded Message --------
> Subject: RFR(m): 8140281 deprecate Optional.get()
> Date: Mon, 25 Apr 2016 16:05:13 -0700
> From: Stuart Marks <stuart.marks at oracle.com>
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>
> Hi all,
>
> Please review these webrevs that deprecate Optional.get() and to 
> replace it with Optional.getWhenPresent(). The corresponding changes 
> are also applied to OptionalDouble.getAsDouble(), 
> OptionalInt.getAsInt(), and OptionalLong.getAsLong().
>
> Unlike most deprecations, this isn't about the function or the utility 
> of some API, it's about the name. The solution is basically to rename 
> the API. The problem is that "get" shows up as the "obvious" choice in 
> things like IDE code completion, leading to code that mishandles empty 
> Optionals. Typical Stack Overflow discourse runs something like this:
>
>      Q: what do I do with this Optional thing
>
>      A: just call get()
>
>      Q: thanks, it works!
>
> Of course, it works until it doesn't.
>
> Examining the JDK's use of Optional.get(), I didn't see very many 
> cases that called get() without first checking for the presence of a 
> value. But I did see quite a number of cases like this:
>
>      if (opt.isPresent()) {
>          doSomething(opt.get());
>      } else {
>          doSomethingElse();
>      }
>
> In many of these cases, the code could be refactored to use other 
> Optional methods such as filter(), map(), or ifPresent().
>
> In any case this reinforces the contention that use of get() leads to 
> poor code.
>
> For this changeset, in just about all cases I've simply replaced the 
> call to get() with a call to getWhenPresent(). In a couple cases I 
> replaced the stream calls
>
>      .filter(Optional::isPresent).map(Optional::get)
>
> with
>
>      .flatMap(Optional::stream)
>
> which I hope will become the new idiom for unwrapping a stream of 
> Optionals.
>
> While many cases could be cleaned up further, I didn't change them. 
> The reasons are that I didn't want to spend too much time putting code 
> cleanup into the critical path of this changeset (I'd be happy to help 
> later); doing so would create potential conflicts with code coming in 
> from the Jigsaw forest; and there are non-obvious places where 
> converting from a conditional to one of the lambda-based methods could 
> cause performance problems at startup.
>
> There are also a few cases where simplification is prevented because 
> it would end up causing the resulting lambda expressions to throw 
> checked exceptions. :-(
>
> Webrevs here:
>
> http://cr.openjdk.java.net/~smarks/reviews/8140281/webrev.0.langtools/
>
> http://cr.openjdk.java.net/~smarks/reviews/8140281/webrev.0.jdk/
>
> Thanks,
>
> s'marks


From stuart.marks at oracle.com  Mon Apr 25 23:37:14 2016
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 25 Apr 2016 16:37:14 -0700
Subject: Fwd: RFR(m): 8140281 deprecate Optional.get()
In-Reply-To: <571EA7ED.4080609@oracle.com>
References: <b7382ded-5669-7c92-f1f9-bec45a1f36a5@oracle.com>
	<1282fc0c-2d92-be13-d95e-9486cd556146@oracle.com>
	<571EA7ED.4080609@oracle.com>
Message-ID: <0cdc0050-8508-2be5-8e25-35fbad98d024@oracle.com>



On 4/25/16 4:27 PM, Jonathan Gibbons wrote:
> Enter.java:
> It's pretty ugly that the recommended usage is to have to add a SuppressWarnings
> for a reasonable and valid use of Optional.get.
>
> Are you sure this is the API you want?

Ah, I had neglected to explain this one, sorry.

In the majority cases, uses of get() can be refactored away to use one of the 
other Optional methods.

In just about all the remaining cases, the code should use the replacement 
method getWhenPresent(), which has the same semantics as the current get() call. 
This is called for if lambdas should be avoided because of startup performance, 
or because of checked exceptions, or if it's provable from context that a value 
is always present.

The case of Enter.java is a special one; it gets compiled with the boot 
libraries (JDK 8) and getWhenPresent() doesn't exist in those. It doesn't 
generate a warning though. But as you explained to me the other day, this code 
is later recompiled against the JDK 9 libraries, and in that case it does 
generate the warning.

So for this case I think calling get() with @SuppressWarnings is the way to 
proceed. I opted to extract a local variable and put @SW on it, in order to 
minimize its scope, but if you prefer an alternative I'd be happy to change it.

s'marks

From jonathan.gibbons at oracle.com  Mon Apr 25 23:43:58 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 25 Apr 2016 16:43:58 -0700
Subject: Fwd: RFR(m): 8140281 deprecate Optional.get()
In-Reply-To: <0cdc0050-8508-2be5-8e25-35fbad98d024@oracle.com>
References: <b7382ded-5669-7c92-f1f9-bec45a1f36a5@oracle.com>
	<1282fc0c-2d92-be13-d95e-9486cd556146@oracle.com>
	<571EA7ED.4080609@oracle.com>
	<0cdc0050-8508-2be5-8e25-35fbad98d024@oracle.com>
Message-ID: <571EABBE.8040606@oracle.com>

OK.

The best I can say is that I disagree with the underlying change (to 
deprecate Optional.get) but that if the API change is generally agreed 
to, then I reluctantly agree with the edit here.

The bug needs a noreg-label.

-- jon



On 04/25/2016 04:37 PM, Stuart Marks wrote:
>
>
> On 4/25/16 4:27 PM, Jonathan Gibbons wrote:
>> Enter.java:
>> It's pretty ugly that the recommended usage is to have to add a 
>> SuppressWarnings
>> for a reasonable and valid use of Optional.get.
>>
>> Are you sure this is the API you want?
>
> Ah, I had neglected to explain this one, sorry.
>
> In the majority cases, uses of get() can be refactored away to use one 
> of the other Optional methods.
>
> In just about all the remaining cases, the code should use the 
> replacement method getWhenPresent(), which has the same semantics as 
> the current get() call. This is called for if lambdas should be 
> avoided because of startup performance, or because of checked 
> exceptions, or if it's provable from context that a value is always 
> present.
>
> The case of Enter.java is a special one; it gets compiled with the 
> boot libraries (JDK 8) and getWhenPresent() doesn't exist in those. It 
> doesn't generate a warning though. But as you explained to me the 
> other day, this code is later recompiled against the JDK 9 libraries, 
> and in that case it does generate the warning.
>
> So for this case I think calling get() with @SuppressWarnings is the 
> way to proceed. I opted to extract a local variable and put @SW on it, 
> in order to minimize its scope, but if you prefer an alternative I'd 
> be happy to change it.
>
> s'marks


From ali.ebrahimi1781 at gmail.com  Tue Apr 26 06:26:43 2016
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Tue, 26 Apr 2016 10:56:43 +0430
Subject: Fwd: RFR(m): 8140281 deprecate Optional.get()
In-Reply-To: <571EABBE.8040606@oracle.com>
References: <b7382ded-5669-7c92-f1f9-bec45a1f36a5@oracle.com>
	<1282fc0c-2d92-be13-d95e-9486cd556146@oracle.com>
	<571EA7ED.4080609@oracle.com>
	<0cdc0050-8508-2be5-8e25-35fbad98d024@oracle.com>
	<571EABBE.8040606@oracle.com>
Message-ID: <CAA0cW5Bg9P3BSriad06-9LN=Q84i+O6W=ejywTZ=ygy6XEZ9kg@mail.gmail.com>

Hi,
I agree with Jon, Vitaly,
I think the name Optional completely describe its intents and semantics so
I don't think we need more descriptive method name here.
Optional === may be have value
So
Optional.get === may be return value

Therefore, I think this all effort doesn't add any (or enough) value, So
isn't worth of it (from resource POV).
Done side: The all current source codes that uses this method when
compiling with java9 get dozen of warnings.

On Tue, Apr 26, 2016 at 4:13 AM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> OK.
>
> The best I can say is that I disagree with the underlying change (to
> deprecate Optional.get) but that if the API change is generally agreed to,
> then I reluctantly agree with the edit here.
>
> The bug needs a noreg-label.
>
> -- jon
>
>
>
>
> On 04/25/2016 04:37 PM, Stuart Marks wrote:
>
>>
>>
>> On 4/25/16 4:27 PM, Jonathan Gibbons wrote:
>>
>>> Enter.java:
>>> It's pretty ugly that the recommended usage is to have to add a
>>> SuppressWarnings
>>> for a reasonable and valid use of Optional.get.
>>>
>>> Are you sure this is the API you want?
>>>
>>
>> Ah, I had neglected to explain this one, sorry.
>>
>> In the majority cases, uses of get() can be refactored away to use one of
>> the other Optional methods.
>>
>> In just about all the remaining cases, the code should use the
>> replacement method getWhenPresent(), which has the same semantics as the
>> current get() call. This is called for if lambdas should be avoided because
>> of startup performance, or because of checked exceptions, or if it's
>> provable from context that a value is always present.
>>
>> The case of Enter.java is a special one; it gets compiled with the boot
>> libraries (JDK 8) and getWhenPresent() doesn't exist in those. It doesn't
>> generate a warning though. But as you explained to me the other day, this
>> code is later recompiled against the JDK 9 libraries, and in that case it
>> does generate the warning.
>>
>> So for this case I think calling get() with @SuppressWarnings is the way
>> to proceed. I opted to extract a local variable and put @SW on it, in order
>> to minimize its scope, but if you prefer an alternative I'd be happy to
>> change it.
>>
>> s'marks
>>
>
>


-- 

Best Regards,
Ali Ebrahimi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160426/6a74ae63/attachment-0001.html>

From jan.lahoda at oracle.com  Tue Apr 26 07:38:21 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 26 Apr 2016 09:38:21 +0200
Subject: RFR(s): JDK-8155026: javac grants implied readability to explicit
	modules
Message-ID: <571F1AED.2090906@oracle.com>

Hi,

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

Fix/webrev:
http://cr.openjdk.java.net/~jlahoda/8155026/webrev.00/index.html

Thanks,
     Jan

From forax at univ-mlv.fr  Tue Apr 26 09:13:26 2016
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 26 Apr 2016 09:13:26 +0000
Subject: Fwd: RFR(m): 8140281 deprecate Optional.get()
In-Reply-To: <CAA0cW5Bg9P3BSriad06-9LN=Q84i+O6W=ejywTZ=ygy6XEZ9kg@mail.gmail.com>
References: <b7382ded-5669-7c92-f1f9-bec45a1f36a5@oracle.com>
	<1282fc0c-2d92-be13-d95e-9486cd556146@oracle.com>
	<571EA7ED.4080609@oracle.com>
	<0cdc0050-8508-2be5-8e25-35fbad98d024@oracle.com>
	<571EABBE.8040606@oracle.com>
	<CAA0cW5Bg9P3BSriad06-9LN=Q84i+O6W=ejywTZ=ygy6XEZ9kg@mail.gmail.com>
Message-ID: <EAC24459-0020-4653-8E28-0FF1BDDD630F@univ-mlv.fr>

I agree with Jon, Vitaly and Ali,
get is good candidate to @Bikeshed not for @Deprecated.

R?mi


Le 26 avril 2016 08:26:43 CEST, Ali Ebrahimi <ali.ebrahimi1781 at gmail.com> a ?crit :
>Hi,
>I agree with Jon, Vitaly,
>I think the name Optional completely describe its intents and semantics
>so
>I don't think we need more descriptive method name here.
>Optional === may be have value
>So
>Optional.get === may be return value
>
>Therefore, I think this all effort doesn't add any (or enough) value,
>So
>isn't worth of it (from resource POV).
>Done side: The all current source codes that uses this method when
>compiling with java9 get dozen of warnings.
>
>On Tue, Apr 26, 2016 at 4:13 AM, Jonathan Gibbons <
>jonathan.gibbons at oracle.com> wrote:
>
>> OK.
>>
>> The best I can say is that I disagree with the underlying change (to
>> deprecate Optional.get) but that if the API change is generally
>agreed to,
>> then I reluctantly agree with the edit here.
>>
>> The bug needs a noreg-label.
>>
>> -- jon
>>
>>
>>
>>
>> On 04/25/2016 04:37 PM, Stuart Marks wrote:
>>
>>>
>>>
>>> On 4/25/16 4:27 PM, Jonathan Gibbons wrote:
>>>
>>>> Enter.java:
>>>> It's pretty ugly that the recommended usage is to have to add a
>>>> SuppressWarnings
>>>> for a reasonable and valid use of Optional.get.
>>>>
>>>> Are you sure this is the API you want?
>>>>
>>>
>>> Ah, I had neglected to explain this one, sorry.
>>>
>>> In the majority cases, uses of get() can be refactored away to use
>one of
>>> the other Optional methods.
>>>
>>> In just about all the remaining cases, the code should use the
>>> replacement method getWhenPresent(), which has the same semantics as
>the
>>> current get() call. This is called for if lambdas should be avoided
>because
>>> of startup performance, or because of checked exceptions, or if it's
>>> provable from context that a value is always present.
>>>
>>> The case of Enter.java is a special one; it gets compiled with the
>boot
>>> libraries (JDK 8) and getWhenPresent() doesn't exist in those. It
>doesn't
>>> generate a warning though. But as you explained to me the other day,
>this
>>> code is later recompiled against the JDK 9 libraries, and in that
>case it
>>> does generate the warning.
>>>
>>> So for this case I think calling get() with @SuppressWarnings is the
>way
>>> to proceed. I opted to extract a local variable and put @SW on it,
>in order
>>> to minimize its scope, but if you prefer an alternative I'd be happy
>to
>>> change it.
>>>
>>> s'marks
>>>
>>
>>


From jeremymanson at google.com  Wed Apr 27 13:24:50 2016
From: jeremymanson at google.com (Jeremy Manson)
Date: Wed, 27 Apr 2016 06:24:50 -0700
Subject: RFR 8154270: javac wrongly rejects some class literals as
	annotation element values
In-Reply-To: <CAL4QsguHtvKFgGSYRCdQga0ovN1eGFLLud_D7iSAUdYcaM+89A@mail.gmail.com>
References: <CAL4QsgvREVvxX2yhtVPGYjXwFoqV-N+RLJ9nPGf=FAUDeZ4ttw@mail.gmail.com>
	<57193F13.4030004@oracle.com>
	<CAL4QsguHtvKFgGSYRCdQga0ovN1eGFLLud_D7iSAUdYcaM+89A@mail.gmail.com>
Message-ID: <CAPYFHW3252P1Mt+oscipApoo05AMF-8u0730ebKCc-1MAaJW4A@mail.gmail.com>

FWIW, it is correct for new files we contribute to have Google copyright.
As Liam points out, we've done that before in multiple places.

It doesn't make any difference to the GPL or Oracle's ability to relicense.

Jeremy

On Thu, Apr 21, 2016 at 4:59 PM, Liam Miller-Cushon <cushon at google.com>
wrote:

> Thanks for the review! The updated patch is attached.
>
>
>> * since the issue can be exposed in two ways (reflection and separate
>> compilation), I'd like to see two tests; you have one for reflection -
>> having also the other for separate compilation would be great (since that
>> area tends to get neglected)
>
>
> To confirm, do you mean the "javac -implicit:none Other.java" example in
> the original thread? I added that to the test.
>
> I also thought about testing against a bad class file, but that doesn't
> exercise anything in the patch and I don't have a good way to generate a
> class with the problem (ASM won't write classes with this issue, and now
> javac won't either).
>
>
>> * I'm not a lawyer - and I'm not sure whether the copyright header in
>> your test is correct ;-)
>
>
> Oops. Any concerns with using the same header (except for the date) as
> this:
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/c0f3840e225a/test/java/util/zip/EntryCount64k.java
> ?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160427/84fb9bcd/attachment.html>

From jonathan.gibbons at oracle.com  Wed Apr 27 15:00:03 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 27 Apr 2016 08:00:03 -0700
Subject: RFR 8154270: javac wrongly rejects some class literals as
	annotation element values
In-Reply-To: <CAPYFHW3252P1Mt+oscipApoo05AMF-8u0730ebKCc-1MAaJW4A@mail.gmail.com>
References: <CAL4QsgvREVvxX2yhtVPGYjXwFoqV-N+RLJ9nPGf=FAUDeZ4ttw@mail.gmail.com>	<57193F13.4030004@oracle.com>	<CAL4QsguHtvKFgGSYRCdQga0ovN1eGFLLud_D7iSAUdYcaM+89A@mail.gmail.com>
	<CAPYFHW3252P1Mt+oscipApoo05AMF-8u0730ebKCc-1MAaJW4A@mail.gmail.com>
Message-ID: <5720D3F3.7080408@oracle.com>

Yes, I verified that as well, so we're good to push the patch.

-- jon

On 04/27/2016 06:24 AM, Jeremy Manson wrote:
> FWIW, it is correct for new files we contribute to have Google 
> copyright.  As Liam points out, we've done that before in multiple 
> places.
>
> It doesn't make any difference to the GPL or Oracle's ability to 
> relicense.
>
> Jeremy
>
> On Thu, Apr 21, 2016 at 4:59 PM, Liam Miller-Cushon <cushon at google.com 
> <mailto:cushon at google.com>> wrote:
>
>     Thanks for the review! The updated patch is attached.
>
>         * since the issue can be exposed in two ways (reflection and
>         separate compilation), I'd like to see two tests; you have one
>         for reflection - having also the other for separate
>         compilation would be great (since that area tends to get
>         neglected)
>
>
>     To confirm, do you mean the "javac -implicit:none Other.java"
>     example in the original thread? I added that to the test.
>
>     I also thought about testing against a bad class file, but that
>     doesn't exercise anything in the patch and I don't have a good way
>     to generate a class with the problem (ASM won't write classes with
>     this issue, and now javac won't either).
>
>         * I'm not a lawyer - and I'm not sure whether the copyright
>         header in your test is correct ;-)
>
>
>     Oops. Any concerns with using the same header (except for the
>     date) as this:
>     http://hg.openjdk.java.net/jdk9/dev/jdk/file/c0f3840e225a/test/java/util/zip/EntryCount64k.java?
>
>

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

From joe.darcy at oracle.com  Wed Apr 27 21:27:59 2016
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 27 Apr 2016 14:27:59 -0700
Subject: JDK 9 RFR of JDK-8155516: Suppress warnings from uses of deprecated
	Class.newInstance langtools
Message-ID: <57212EDF.6060602@oracle.com>

Hello,

As part of the effort to address

     JDK-6850612: Deprecate Class.newInstance since it violates the 
checked exception language contract

the uses of Class.newInstance in the langtools repo have to be address 
in some way, either by suppressing the resulting warning or by 
refactoring the code to use other recommended idioms.

Please review the fix for

     JDK-8155516: Suppress warnings from uses of deprecated 
Class.newInstance langtools
     http://cr.openjdk.java.net/~darcy/8155516.0/

which takes the suppression approach.

Patch below.

Thanks,

-Joe

--- old/src/java.compiler/share/classes/javax/tools/ToolProvider.java 
2016-04-27 14:16:21.269126143 -0700
+++ new/src/java.compiler/share/classes/javax/tools/ToolProvider.java 
2016-04-27 14:16:21.177126140 -0700
@@ -123,7 +123,9 @@
      private static <T> T getSystemTool(Class<T> clazz, String 
moduleName, String className) {
          if (useLegacy) {
              try {
-                return Class.forName(className, true, 
ClassLoader.getSystemClassLoader()).asSubclass(clazz).newInstance();
+                @SuppressWarnings("deprecation")
+                T result = Class.forName(className, true, 
ClassLoader.getSystemClassLoader()).asSubclass(clazz).newInstance();
+                return result;
              } catch (ReflectiveOperationException e) {
                  throw new Error(e);
              }
--- 
old/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 
2016-04-27 14:16:21.573126153 -0700
+++ 
new/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 
2016-04-27 14:16:21.489126150 -0700
@@ -282,6 +282,7 @@

          if (options.isSet(XPRINT)) {
              try {
+                @SuppressWarnings("deprecation")
                  Processor processor = 
PrintingProcessor.class.newInstance();
                  processorIterator = List.of(processor).iterator();
              } catch (Throwable t) {
@@ -549,8 +550,9 @@
                          try {
                              Class<?> processorClass = 
processorCL.loadClass(processorName);
                              ensureReadable(processorClass);
-                            processor =
-                                (Processor) (processorClass.newInstance());
+                            @SuppressWarnings("deprecation")
+                            Object tmp = processorClass.newInstance();
+                            processor = (Processor) tmp;
                          } catch (ClassNotFoundException cnfe) {
                              log.error("proc.processor.not.found", 
processorName);
                              return false;
--- 
old/src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Option.java 
2016-04-27 14:16:21.881126163 -0700
+++ 
new/src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Option.java 
2016-04-27 14:16:21.797126161 -0700
@@ -151,6 +151,7 @@
              // Construct transformer
              try {
                  Class<?> trCls = Class.forName(classname);
+                @SuppressWarnings("deprecation")
                  Transformer transformer = (Transformer) 
trCls.newInstance();
                  transformer.setExtra(extra);
                  helper.addTransformer(suffix, transformer);
--- 
old/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java 
2016-04-27 14:16:22.181126173 -0700
+++ 
new/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java 
2016-04-27 14:16:22.097126171 -0700
@@ -247,6 +247,7 @@
              tagClassLoader = fileManager.getClassLoader(TAGLET_PATH);
              Class<?> customTagClass = tagClassLoader.loadClass(classname);
              ensureReadable(customTagClass);
+            @SuppressWarnings("deprecation")
              Object instance = customTagClass.newInstance();
              Taglet newLegacy = new 
UserTaglet((jdk.javadoc.doclet.taglet.Taglet)instance);
              String tname = newLegacy.getName();
--- 
old/src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java 
2016-04-27 14:16:22.481126183 -0700
+++ 
new/src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java 
2016-04-27 14:16:22.393126180 -0700
@@ -252,7 +252,9 @@
              initMessager();
              messager.setLocale(locale);
              try {
-                doclet = (Doclet) docletClass.newInstance();
+                @SuppressWarnings("deprecation")
+                Object o = docletClass.newInstance();
+                doclet = (Doclet) o;
              } catch (InstantiationException | IllegalAccessException 
exc) {
                  exc.printStackTrace();
                  if (!apiMode) {


From jonathan.gibbons at oracle.com  Wed Apr 27 23:21:26 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 27 Apr 2016 16:21:26 -0700
Subject: JDK 9 RFR of JDK-8155516: Suppress warnings from uses of
	deprecated Class.newInstance langtools
In-Reply-To: <57212EDF.6060602@oracle.com>
References: <57212EDF.6060602@oracle.com>
Message-ID: <57214976.1000704@oracle.com>

What is the recommended approach for avoiding the issue, as compared to 
sweeping it under the carpet?

-- Jon


On 04/27/2016 02:27 PM, Joseph D. Darcy wrote:
> Hello,
>
> As part of the effort to address
>
>     JDK-6850612: Deprecate Class.newInstance since it violates the 
> checked exception language contract
>
> the uses of Class.newInstance in the langtools repo have to be address 
> in some way, either by suppressing the resulting warning or by 
> refactoring the code to use other recommended idioms.
>
> Please review the fix for
>
>     JDK-8155516: Suppress warnings from uses of deprecated 
> Class.newInstance langtools
>     http://cr.openjdk.java.net/~darcy/8155516.0/
>
> which takes the suppression approach.
>
> Patch below.
>
> Thanks,
>
> -Joe
>
> --- old/src/java.compiler/share/classes/javax/tools/ToolProvider.java 
> 2016-04-27 14:16:21.269126143 -0700
> +++ new/src/java.compiler/share/classes/javax/tools/ToolProvider.java 
> 2016-04-27 14:16:21.177126140 -0700
> @@ -123,7 +123,9 @@
>      private static <T> T getSystemTool(Class<T> clazz, String 
> moduleName, String className) {
>          if (useLegacy) {
>              try {
> -                return Class.forName(className, true, 
> ClassLoader.getSystemClassLoader()).asSubclass(clazz).newInstance();
> +                @SuppressWarnings("deprecation")
> +                T result = Class.forName(className, true, 
> ClassLoader.getSystemClassLoader()).asSubclass(clazz).newInstance();
> +                return result;
>              } catch (ReflectiveOperationException e) {
>                  throw new Error(e);
>              }
> --- 
> old/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 
> 2016-04-27 14:16:21.573126153 -0700
> +++ 
> new/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 
> 2016-04-27 14:16:21.489126150 -0700
> @@ -282,6 +282,7 @@
>
>          if (options.isSet(XPRINT)) {
>              try {
> +                @SuppressWarnings("deprecation")
>                  Processor processor = 
> PrintingProcessor.class.newInstance();
>                  processorIterator = List.of(processor).iterator();
>              } catch (Throwable t) {
> @@ -549,8 +550,9 @@
>                          try {
>                              Class<?> processorClass = 
> processorCL.loadClass(processorName);
>                              ensureReadable(processorClass);
> -                            processor =
> -                                (Processor) 
> (processorClass.newInstance());
> +                            @SuppressWarnings("deprecation")
> +                            Object tmp = processorClass.newInstance();
> +                            processor = (Processor) tmp;
>                          } catch (ClassNotFoundException cnfe) {
>                              log.error("proc.processor.not.found", 
> processorName);
>                              return false;
> --- 
> old/src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Option.java 
> 2016-04-27 14:16:21.881126163 -0700
> +++ 
> new/src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Option.java 
> 2016-04-27 14:16:21.797126161 -0700
> @@ -151,6 +151,7 @@
>              // Construct transformer
>              try {
>                  Class<?> trCls = Class.forName(classname);
> +                @SuppressWarnings("deprecation")
>                  Transformer transformer = (Transformer) 
> trCls.newInstance();
>                  transformer.setExtra(extra);
>                  helper.addTransformer(suffix, transformer);
> --- 
> old/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java 
> 2016-04-27 14:16:22.181126173 -0700
> +++ 
> new/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java 
> 2016-04-27 14:16:22.097126171 -0700
> @@ -247,6 +247,7 @@
>              tagClassLoader = fileManager.getClassLoader(TAGLET_PATH);
>              Class<?> customTagClass = 
> tagClassLoader.loadClass(classname);
>              ensureReadable(customTagClass);
> +            @SuppressWarnings("deprecation")
>              Object instance = customTagClass.newInstance();
>              Taglet newLegacy = new 
> UserTaglet((jdk.javadoc.doclet.taglet.Taglet)instance);
>              String tname = newLegacy.getName();
> --- 
> old/src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java 
> 2016-04-27 14:16:22.481126183 -0700
> +++ 
> new/src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java 
> 2016-04-27 14:16:22.393126180 -0700
> @@ -252,7 +252,9 @@
>              initMessager();
>              messager.setLocale(locale);
>              try {
> -                doclet = (Doclet) docletClass.newInstance();
> +                @SuppressWarnings("deprecation")
> +                Object o = docletClass.newInstance();
> +                doclet = (Doclet) o;
>              } catch (InstantiationException | IllegalAccessException 
> exc) {
>                  exc.printStackTrace();
>                  if (!apiMode) {
>


From jonathan.gibbons at oracle.com  Wed Apr 27 23:59:55 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 27 Apr 2016 16:59:55 -0700
Subject: JDK 9 RFR of JDK-8155516: Suppress warnings from uses of
	deprecated Class.newInstance langtools
In-Reply-To: <57214976.1000704@oracle.com>
References: <57212EDF.6060602@oracle.com> <57214976.1000704@oracle.com>
Message-ID: <5721527B.5060509@oracle.com>

Joe,

I guess this is OK for now, but as a general policy for langtools, I 
hope we are not going to see @SuppressWarnings proliferating throughout 
the code.  If a method has been deprecated, it is presumably for a good 
reason (<cough> Optional.get </cough>) and there should in general be a 
replacement, and we should endeavor to improve the quality of the code 
base by using the recommended replacements, rather than perpetuating the 
sins of our predecessors.

As for @SuppressWarnings, the review yesterday had a credible use of the 
annotation insofar as the replacement method was not available in JDK 8, 
which (for the duration of JDK 9 development) is our bootstrap compiler.

For all of Stuart's protestations that these are not breaking changes, 
we are sure doing a lot of high priority reacting to non-breaking changes!

-- Jon

On 04/27/2016 04:21 PM, Jonathan Gibbons wrote:
> What is the recommended approach for avoiding the issue, as compared 
> to sweeping it under the carpet?
>
> -- Jon
>
>
> On 04/27/2016 02:27 PM, Joseph D. Darcy wrote:
>> Hello,
>>
>> As part of the effort to address
>>
>>     JDK-6850612: Deprecate Class.newInstance since it violates the 
>> checked exception language contract
>>
>> the uses of Class.newInstance in the langtools repo have to be 
>> address in some way, either by suppressing the resulting warning or 
>> by refactoring the code to use other recommended idioms.
>>
>> Please review the fix for
>>
>>     JDK-8155516: Suppress warnings from uses of deprecated 
>> Class.newInstance langtools
>>     http://cr.openjdk.java.net/~darcy/8155516.0/
>>
>> which takes the suppression approach.
>>
>> Patch below.
>>
>> Thanks,
>>
>> -Joe
>>
>> --- old/src/java.compiler/share/classes/javax/tools/ToolProvider.java 
>> 2016-04-27 14:16:21.269126143 -0700
>> +++ new/src/java.compiler/share/classes/javax/tools/ToolProvider.java 
>> 2016-04-27 14:16:21.177126140 -0700
>> @@ -123,7 +123,9 @@
>>      private static <T> T getSystemTool(Class<T> clazz, String 
>> moduleName, String className) {
>>          if (useLegacy) {
>>              try {
>> -                return Class.forName(className, true, 
>> ClassLoader.getSystemClassLoader()).asSubclass(clazz).newInstance();
>> +                @SuppressWarnings("deprecation")
>> +                T result = Class.forName(className, true, 
>> ClassLoader.getSystemClassLoader()).asSubclass(clazz).newInstance();
>> +                return result;
>>              } catch (ReflectiveOperationException e) {
>>                  throw new Error(e);
>>              }
>> --- 
>> old/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 
>> 2016-04-27 14:16:21.573126153 -0700
>> +++ 
>> new/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 
>> 2016-04-27 14:16:21.489126150 -0700
>> @@ -282,6 +282,7 @@
>>
>>          if (options.isSet(XPRINT)) {
>>              try {
>> +                @SuppressWarnings("deprecation")
>>                  Processor processor = 
>> PrintingProcessor.class.newInstance();
>>                  processorIterator = List.of(processor).iterator();
>>              } catch (Throwable t) {
>> @@ -549,8 +550,9 @@
>>                          try {
>>                              Class<?> processorClass = 
>> processorCL.loadClass(processorName);
>>                              ensureReadable(processorClass);
>> -                            processor =
>> -                                (Processor) 
>> (processorClass.newInstance());
>> +                            @SuppressWarnings("deprecation")
>> +                            Object tmp = processorClass.newInstance();
>> +                            processor = (Processor) tmp;
>>                          } catch (ClassNotFoundException cnfe) {
>> log.error("proc.processor.not.found", processorName);
>>                              return false;
>> --- 
>> old/src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Option.java 
>> 2016-04-27 14:16:21.881126163 -0700
>> +++ 
>> new/src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Option.java 
>> 2016-04-27 14:16:21.797126161 -0700
>> @@ -151,6 +151,7 @@
>>              // Construct transformer
>>              try {
>>                  Class<?> trCls = Class.forName(classname);
>> +                @SuppressWarnings("deprecation")
>>                  Transformer transformer = (Transformer) 
>> trCls.newInstance();
>>                  transformer.setExtra(extra);
>>                  helper.addTransformer(suffix, transformer);
>> --- 
>> old/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java 
>> 2016-04-27 14:16:22.181126173 -0700
>> +++ 
>> new/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java 
>> 2016-04-27 14:16:22.097126171 -0700
>> @@ -247,6 +247,7 @@
>>              tagClassLoader = fileManager.getClassLoader(TAGLET_PATH);
>>              Class<?> customTagClass = 
>> tagClassLoader.loadClass(classname);
>>              ensureReadable(customTagClass);
>> +            @SuppressWarnings("deprecation")
>>              Object instance = customTagClass.newInstance();
>>              Taglet newLegacy = new 
>> UserTaglet((jdk.javadoc.doclet.taglet.Taglet)instance);
>>              String tname = newLegacy.getName();
>> --- 
>> old/src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java 2016-04-27 
>> 14:16:22.481126183 -0700
>> +++ 
>> new/src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java 2016-04-27 
>> 14:16:22.393126180 -0700
>> @@ -252,7 +252,9 @@
>>              initMessager();
>>              messager.setLocale(locale);
>>              try {
>> -                doclet = (Doclet) docletClass.newInstance();
>> +                @SuppressWarnings("deprecation")
>> +                Object o = docletClass.newInstance();
>> +                doclet = (Doclet) o;
>>              } catch (InstantiationException | IllegalAccessException 
>> exc) {
>>                  exc.printStackTrace();
>>                  if (!apiMode) {
>>
>


From cushon at google.com  Thu Apr 28 00:50:24 2016
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 27 Apr 2016 17:50:24 -0700
Subject: 'byfile' compilation policy
Message-ID: <CAL4Qsgs91m_J_-z_aEzU_t6d+iie_Ur3rPDdpjheAjWve7VXgQ@mail.gmail.com>

Hi, I encountered an issue with the 'byfile' compilation policy. Desugaring
adds additional ordering constraints so superclasses get desugared first
[1]. That causes classes to be processed separately from their compilation
unit, and breaks the ordering specified for byfile.

[1]
http://hg.openjdk.java.net/jdk9/dev/langtools/file/2aa0433e0add/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java#l1428

Demo:

$ cat A.java
class One extends Three {}
class Two {}

$ cat B.java
class Three {}
class Four extends Two {}

$ javac -XDcompilePolicy=byfile -XDverboseCompilePolicy A.java B.java
[attribute One]
[attribute Two]
[flow One]
[flow Two]
// desugaring One starts, but it depends on Three
[attribute Three]
[flow Three]
[desugar Three]
// resume desugaring One
[desugar One]
[desugar Two]
[generate code One]
[generate code Two]
// Four is compiled separately from its compilation unit
[attribute Four]
[flow Four]
[desugar Four]
[generate code Three]
[generate code Four]

We're using byfile because it allows analyzing an entire compilation unit
after attribution and before any lowering, like 'simple' but with similar
performance to 'todo'. I think using simple might be fine, but I haven't
done any performance analysis yet.

Changing byfile to process entire compilation units in a group and also
desugar supertypes first appears to be impossible, because there could be
cycles.

A partial fix might be to change desugar's handling of dependencies so a
dependency's entire compilation unit goes through flow, before the
dependency is desugared. That would result in something like:

[attribute One]
[attribute Two]
[flow One]
[flow Two]
// desugaring One starts, but it depends on Three
// perform attr and flow on Three and Four together
[attribute Three]
[attribute Four]
[flow Three]
[flow Four]
// now desugar just Three
[desugar Three]
// resume desugaring One
[desugar One]
[desugar Two]
[generate code One]
[generate code Two]
// Four is desugared separately from its compilation unit
[desugar Four]
[generate code Three]
[generate code Four]

Does the partial fix sound worthwhile?

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

From maurizio.cimadamore at oracle.com  Thu Apr 28 08:55:02 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 28 Apr 2016 09:55:02 +0100
Subject: 'byfile' compilation policy
In-Reply-To: <CAL4Qsgs91m_J_-z_aEzU_t6d+iie_Ur3rPDdpjheAjWve7VXgQ@mail.gmail.com>
References: <CAL4Qsgs91m_J_-z_aEzU_t6d+iie_Ur3rPDdpjheAjWve7VXgQ@mail.gmail.com>
Message-ID: <5721CFE6.7020600@oracle.com>

Hi Liam,
the approach you put forward seems sensible; one alternate approach 
would be to let the entire compilation unit through until Gen if a 
dependency is encountered rather than stopping at desugar - but I assume 
that's what you said it's problematic because of cycles?

A meta-question: is it still worthwhile to have separate compilation 
policies? I see that at least two of them (ATTR_ONLY and CHECK_ONLY) can 
probably be replaced by other options (i.e. -XDshouldStop) - are there 
significant use cases out there relying on either byfile or simple? 
Given that, as it has been observed, javac will need to bypass the 
compilation policy anyway to guarantee the correctness of the generated 
code (i.e. that supertypes are desugared before subtypes) - can a client 
really blindly rely on the assumption that a compilation policy does 
what it says on the tin?

Maurizio

On 28/04/16 01:50, Liam Miller-Cushon wrote:
> Hi, I encountered an issue with the 'byfile' compilation policy. 
> Desugaring adds additional ordering constraints so superclasses get 
> desugared first [1]. That causes classes to be processed separately 
> from their compilation unit, and breaks the ordering specified for byfile.
>
> [1] 
> http://hg.openjdk.java.net/jdk9/dev/langtools/file/2aa0433e0add/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java#l1428
>
> Demo:
>
> $ cat A.java
> class One extends Three {}
> class Two {}
>
> $ cat B.java
> class Three {}
> class Four extends Two {}
>
> $ javac -XDcompilePolicy=byfile -XDverboseCompilePolicy A.java B.java
> [attribute One]
> [attribute Two]
> [flow One]
> [flow Two]
> // desugaring One starts, but it depends on Three
> [attribute Three]
> [flow Three]
> [desugar Three]
> // resume desugaring One
> [desugar One]
> [desugar Two]
> [generate code One]
> [generate code Two]
> // Four is compiled separately from its compilation unit
> [attribute Four]
> [flow Four]
> [desugar Four]
> [generate code Three]
> [generate code Four]
>
> We're using byfile because it allows analyzing an entire compilation 
> unit after attribution and before any lowering, like 'simple' but with 
> similar performance to 'todo'. I think using simple might be fine, but 
> I haven't done any performance analysis yet.
>
> Changing byfile to process entire compilation units in a group and 
> also desugar supertypes first appears to be impossible, because there 
> could be cycles.
>
> A partial fix might be to change desugar's handling of dependencies so 
> a dependency's entire compilation unit goes through flow, before the 
> dependency is desugared. That would result in something like:
>
> [attribute One]
> [attribute Two]
> [flow One]
> [flow Two]
> // desugaring One starts, but it depends on Three
> // perform attr and flow on Three and Four together
> [attribute Three]
> [attribute Four]
> [flow Three]
> [flow Four]
> // now desugar just Three
> [desugar Three]
> // resume desugaring One
> [desugar One]
> [desugar Two]
> [generate code One]
> [generate code Two]
> // Four is desugared separately from its compilation unit
> [desugar Four]
> [generate code Three]
> [generate code Four]
>
> Does the partial fix sound worthwhile?
>
> Thanks,


From eaftan at google.com  Thu Apr 28 17:24:03 2016
From: eaftan at google.com (Eddie Aftandilian)
Date: Thu, 28 Apr 2016 10:24:03 -0700
Subject: 'byfile' compilation policy
In-Reply-To: <5721CFE6.7020600@oracle.com>
References: <CAL4Qsgs91m_J_-z_aEzU_t6d+iie_Ur3rPDdpjheAjWve7VXgQ@mail.gmail.com>
	<5721CFE6.7020600@oracle.com>
Message-ID: <CA+7OGVp6=FgySBOZEDZGfO8-28AuCjiKO0NQnDgffqkm0B81ng@mail.gmail.com>

The reason we use the BYFILE policy is because for Error Prone (
github.com/google/error-prone) we want to analyze a whole compilation unit
at once.  Our analyses assume that the AST being analyzed has completed
flow but has not yet been desugared.  So if you have a compilation unit
with more than one top-level class, and one of them has proceeded past
flow, then we can't analyze it.

As Liam mentioned, the SIMPLE policy should work for our use case, but we'd
be interested to hear if you have other suggestions to solve our problem.

On Thu, Apr 28, 2016 at 1:55 AM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi Liam,
> the approach you put forward seems sensible; one alternate approach would
> be to let the entire compilation unit through until Gen if a dependency is
> encountered rather than stopping at desugar - but I assume that's what you
> said it's problematic because of cycles?
>
> A meta-question: is it still worthwhile to have separate compilation
> policies? I see that at least two of them (ATTR_ONLY and CHECK_ONLY) can
> probably be replaced by other options (i.e. -XDshouldStop) - are there
> significant use cases out there relying on either byfile or simple? Given
> that, as it has been observed, javac will need to bypass the compilation
> policy anyway to guarantee the correctness of the generated code (i.e. that
> supertypes are desugared before subtypes) - can a client really blindly
> rely on the assumption that a compilation policy does what it says on the
> tin?
>
> Maurizio
>
>
> On 28/04/16 01:50, Liam Miller-Cushon wrote:
>
>> Hi, I encountered an issue with the 'byfile' compilation policy.
>> Desugaring adds additional ordering constraints so superclasses get
>> desugared first [1]. That causes classes to be processed separately from
>> their compilation unit, and breaks the ordering specified for byfile.
>>
>> [1]
>> http://hg.openjdk.java.net/jdk9/dev/langtools/file/2aa0433e0add/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java#l1428
>>
>> Demo:
>>
>> $ cat A.java
>> class One extends Three {}
>> class Two {}
>>
>> $ cat B.java
>> class Three {}
>> class Four extends Two {}
>>
>> $ javac -XDcompilePolicy=byfile -XDverboseCompilePolicy A.java B.java
>> [attribute One]
>> [attribute Two]
>> [flow One]
>> [flow Two]
>> // desugaring One starts, but it depends on Three
>> [attribute Three]
>> [flow Three]
>> [desugar Three]
>> // resume desugaring One
>> [desugar One]
>> [desugar Two]
>> [generate code One]
>> [generate code Two]
>> // Four is compiled separately from its compilation unit
>> [attribute Four]
>> [flow Four]
>> [desugar Four]
>> [generate code Three]
>> [generate code Four]
>>
>> We're using byfile because it allows analyzing an entire compilation unit
>> after attribution and before any lowering, like 'simple' but with similar
>> performance to 'todo'. I think using simple might be fine, but I haven't
>> done any performance analysis yet.
>>
>> Changing byfile to process entire compilation units in a group and also
>> desugar supertypes first appears to be impossible, because there could be
>> cycles.
>>
>> A partial fix might be to change desugar's handling of dependencies so a
>> dependency's entire compilation unit goes through flow, before the
>> dependency is desugared. That would result in something like:
>>
>> [attribute One]
>> [attribute Two]
>> [flow One]
>> [flow Two]
>> // desugaring One starts, but it depends on Three
>> // perform attr and flow on Three and Four together
>> [attribute Three]
>> [attribute Four]
>> [flow Three]
>> [flow Four]
>> // now desugar just Three
>> [desugar Three]
>> // resume desugaring One
>> [desugar One]
>> [desugar Two]
>> [generate code One]
>> [generate code Two]
>> // Four is desugared separately from its compilation unit
>> [desugar Four]
>> [generate code Three]
>> [generate code Four]
>>
>> Does the partial fix sound worthwhile?
>>
>> Thanks,
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160428/adb6dd11/attachment.html>

From cushon at google.com  Thu Apr 28 17:43:45 2016
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 28 Apr 2016 10:43:45 -0700
Subject: 'byfile' compilation policy
In-Reply-To: <5721CFE6.7020600@oracle.com>
References: <CAL4Qsgs91m_J_-z_aEzU_t6d+iie_Ur3rPDdpjheAjWve7VXgQ@mail.gmail.com>
	<5721CFE6.7020600@oracle.com>
Message-ID: <CAL4Qsgu-5A4NBeWkdHd6ad0MP_RpY8MOHFuAOWYD7TTi6pNb1Q@mail.gmail.com>

On Thu, Apr 28, 2016 at 1:55 AM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi Liam,
> the approach you put forward seems sensible; one alternate approach would
> be to let the entire compilation unit through until Gen if a dependency is
> encountered rather than stopping at desugar - but I assume that's what you
> said it's problematic because of cycles?
>

Right, the repro in my original message is an example of that. The
compilation units are: [One, Two] and [Three, Four], and the superclass
dependencies are: One -> Three, Four -> Two. So we can linearize the
classes to group by compilation unit, or so the superclasses are
encountered first, but not both.


> A meta-question: is it still worthwhile to have separate compilation
> policies? I see that at least two of them (ATTR_ONLY and CHECK_ONLY) can
> probably be replaced by other options (i.e. -XDshouldStop) - are there
> significant use cases out there relying on either byfile or simple? Given
> that, as it has been observed, javac will need to bypass the compilation
> policy anyway to guarantee the correctness of the generated code (i.e. that
> supertypes are desugared before subtypes) - can a client really blindly
> rely on the assumption that a compilation policy does what it says on the
> tin?


Consolidating the existing policies sounds like a good idea to me. I
haven't seen any uses of ATTR_ONLY or CHECK_ONLY. Using bytodo isn't great
for our purposes for the reasons Eddie described. In a previous thread [1]
it was mentioned that byfile was originally supposed to become the default.
Maybe it's time to consider replacing bytodo?

[1]
http://mail.openjdk.java.net/pipermail/compiler-dev/2015-August/009748.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160428/5542d539/attachment.html>

From jonathan.gibbons at oracle.com  Thu Apr 28 18:20:40 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 28 Apr 2016 11:20:40 -0700
Subject: 'byfile' compilation policy
In-Reply-To: <CAL4Qsgu-5A4NBeWkdHd6ad0MP_RpY8MOHFuAOWYD7TTi6pNb1Q@mail.gmail.com>
References: <CAL4Qsgs91m_J_-z_aEzU_t6d+iie_Ur3rPDdpjheAjWve7VXgQ@mail.gmail.com>	<5721CFE6.7020600@oracle.com>
	<CAL4Qsgu-5A4NBeWkdHd6ad0MP_RpY8MOHFuAOWYD7TTi6pNb1Q@mail.gmail.com>
Message-ID: <57225478.9030009@oracle.com>



On 04/28/2016 10:43 AM, Liam Miller-Cushon wrote:
> On Thu, Apr 28, 2016 at 1:55 AM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     Hi Liam,
>     the approach you put forward seems sensible; one alternate
>     approach would be to let the entire compilation unit through until
>     Gen if a dependency is encountered rather than stopping at desugar
>     - but I assume that's what you said it's problematic because of
>     cycles?
>
>
> Right, the repro in my original message is an example of that. The 
> compilation units are: [One, Two] and [Three, Four], and the 
> superclass dependencies are: One -> Three, Four -> Two. So we can 
> linearize the classes to group by compilation unit, or so the 
> superclasses are encountered first, but not both.
>
>     A meta-question: is it still worthwhile to have separate
>     compilation policies? I see that at least two of them (ATTR_ONLY
>     and CHECK_ONLY) can probably be replaced by other options (i.e.
>     -XDshouldStop) - are there significant use cases out there relying
>     on either byfile or simple? Given that, as it has been observed,
>     javac will need to bypass the compilation policy anyway to
>     guarantee the correctness of the generated code (i.e. that
>     supertypes are desugared before subtypes) - can a client really
>     blindly rely on the assumption that a compilation policy does what
>     it says on the tin?
>
>
> Consolidating the existing policies sounds like a good idea to me. I 
> haven't seen any uses of ATTR_ONLY or CHECK_ONLY. Using bytodo isn't 
> great for our purposes for the reasons Eddie described. In a previous 
> thread [1] it was mentioned that byfile was originally supposed to 
> become the default. Maybe it's time to consider replacing bytodo?
>
> [1] 
> http://mail.openjdk.java.net/pipermail/compiler-dev/2015-August/009748.html

bytodo was the original JDK5-era policy, and yes, byfile was a step 
towards trying to support an "all or nothing" policy for a compilation 
unit. If we can reasonably make that work, I think it would be good to 
make it the default and maybe eventually, the only variant.

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

From cushon at google.com  Thu Apr 28 18:37:11 2016
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 28 Apr 2016 11:37:11 -0700
Subject: 'byfile' compilation policy
In-Reply-To: <57225478.9030009@oracle.com>
References: <CAL4Qsgs91m_J_-z_aEzU_t6d+iie_Ur3rPDdpjheAjWve7VXgQ@mail.gmail.com>
	<5721CFE6.7020600@oracle.com>
	<CAL4Qsgu-5A4NBeWkdHd6ad0MP_RpY8MOHFuAOWYD7TTi6pNb1Q@mail.gmail.com>
	<57225478.9030009@oracle.com>
Message-ID: <CAL4QsgvJ87+GbWVt1UiCZvQW4ALY2DyAZOLfKPUMSQQbYvC1CA@mail.gmail.com>

On Thu, Apr 28, 2016 at 11:20 AM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> bytodo was the original JDK5-era policy, and yes, byfile was a step
> towards trying to support an "all or nothing" policy for a compilation
> unit. If we can reasonably make that work, I think it would be good to make
> it the default and maybe eventually, the only variant.


That sounds great from our perspective!

Would anyone be willing to donate bug filing and code review time to this?
I could get started by fixing the issue in this thread, addressing
JDK-8134117, and deleting ATTR_ONLY and CHECK_ONLY.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160428/56d6c74b/attachment-0001.html>

From jonathan.gibbons at oracle.com  Thu Apr 28 20:02:40 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 28 Apr 2016 13:02:40 -0700
Subject: 'byfile' compilation policy
In-Reply-To: <CAL4QsgvJ87+GbWVt1UiCZvQW4ALY2DyAZOLfKPUMSQQbYvC1CA@mail.gmail.com>
References: <CAL4Qsgs91m_J_-z_aEzU_t6d+iie_Ur3rPDdpjheAjWve7VXgQ@mail.gmail.com>
	<5721CFE6.7020600@oracle.com>
	<CAL4Qsgu-5A4NBeWkdHd6ad0MP_RpY8MOHFuAOWYD7TTi6pNb1Q@mail.gmail.com>
	<57225478.9030009@oracle.com>
	<CAL4QsgvJ87+GbWVt1UiCZvQW4ALY2DyAZOLfKPUMSQQbYvC1CA@mail.gmail.com>
Message-ID: <57226C60.2040009@oracle.com>



On 04/28/2016 11:37 AM, Liam Miller-Cushon wrote:
> On Thu, Apr 28, 2016 at 11:20 AM, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     bytodo was the original JDK5-era policy, and yes, byfile was a
>     step towards trying to support an "all or nothing" policy for a
>     compilation unit. If we can reasonably make that work, I think it
>     would be good to make it the default and maybe eventually, the
>     only variant.
>
>
> That sounds great from our perspective!
>
> Would anyone be willing to donate bug filing and code review time to 
> this? I could get started by fixing the issue in this thread, 
> addressing JDK-8134117, and deleting ATTR_ONLY and CHECK_ONLY.

https://bugs.openjdk.java.net/browse/JDK-8155674
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160428/6f806c25/attachment.html>

From maurizio.cimadamore at oracle.com  Thu Apr 28 20:40:13 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 28 Apr 2016 21:40:13 +0100
Subject: 'byfile' compilation policy
In-Reply-To: <CAL4Qsgu-5A4NBeWkdHd6ad0MP_RpY8MOHFuAOWYD7TTi6pNb1Q@mail.gmail.com>
References: <CAL4Qsgs91m_J_-z_aEzU_t6d+iie_Ur3rPDdpjheAjWve7VXgQ@mail.gmail.com>
	<5721CFE6.7020600@oracle.com>
	<CAL4Qsgu-5A4NBeWkdHd6ad0MP_RpY8MOHFuAOWYD7TTi6pNb1Q@mail.gmail.com>
Message-ID: <5722752D.6060305@oracle.com>

On a separate note, we already discussed how the need for ordering 
compilation units is somehow an artifact of the lossy way in which 
TransTypes massages trees; we are planning to remediate that in Valhalla 
- and I think once we do that, we'll be in a much better position to 
truly support byfile, w/o the need of special machinery (yayy!)

Maurizio

On 28/04/16 18:43, Liam Miller-Cushon wrote:
> On Thu, Apr 28, 2016 at 1:55 AM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     Hi Liam,
>     the approach you put forward seems sensible; one alternate
>     approach would be to let the entire compilation unit through until
>     Gen if a dependency is encountered rather than stopping at desugar
>     - but I assume that's what you said it's problematic because of
>     cycles?
>
>
> Right, the repro in my original message is an example of that. The 
> compilation units are: [One, Two] and [Three, Four], and the 
> superclass dependencies are: One -> Three, Four -> Two. So we can 
> linearize the classes to group by compilation unit, or so the 
> superclasses are encountered first, but not both.
>
>     A meta-question: is it still worthwhile to have separate
>     compilation policies? I see that at least two of them (ATTR_ONLY
>     and CHECK_ONLY) can probably be replaced by other options (i.e.
>     -XDshouldStop) - are there significant use cases out there relying
>     on either byfile or simple? Given that, as it has been observed,
>     javac will need to bypass the compilation policy anyway to
>     guarantee the correctness of the generated code (i.e. that
>     supertypes are desugared before subtypes) - can a client really
>     blindly rely on the assumption that a compilation policy does what
>     it says on the tin?
>
>
> Consolidating the existing policies sounds like a good idea to me. I 
> haven't seen any uses of ATTR_ONLY or CHECK_ONLY. Using bytodo isn't 
> great for our purposes for the reasons Eddie described. In a previous 
> thread [1] it was mentioned that byfile was originally supposed to 
> become the default. Maybe it's time to consider replacing bytodo?
>
> [1] 
> http://mail.openjdk.java.net/pipermail/compiler-dev/2015-August/009748.html

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

From steve.drach at oracle.com  Tue Apr  5 16:32:58 2016
From: steve.drach at oracle.com (Steve Drach)
Date: Tue, 05 Apr 2016 16:32:58 -0000
Subject: RFR 8149757:Implement Multi-Release jar aware JavacFileManager for
	javac
Message-ID: <63B271F4-F1DB-4280-B6F2-5E755FDCF92C@oracle.com>

Hi,

Please review the changes required to make javac and the StandardJavaFileManager multi-release jar aware.  For javac, the version of the classes in a multi-release.jar is selected by the -release (or -target) command line option, or if the option is not present, the runtime version is selected.  For the StandardJavaFileManager, the version is selected with the handleOption method.  See the tests for more detail.

issue: https://bugs.openjdk.java.net/browse/JDK-8149757 <https://bugs.openjdk.java.net/browse/JDK-8149757>
webrev: http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html <http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html>

Thank you,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160405/4a6559f9/attachment.html>