hg: jigsaw/jake/nashorn: requires jtreg 4.2 b04

[mandy . chung]

Changeset: 527b3a15b412
Author:mchung
Date:  2016-11-28 21:43 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/527b3a15b412

requires jtreg 4.2 b04

! test/TEST.ROOT

hg: jigsaw/jake/jdk: requires jtreg 4.2 b04

[mandy . chung]

Changeset: b7ddd95fd610
Author:mchung
Date:  2016-11-28 21:42 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b7ddd95fd610

requires jtreg 4.2 b04

! test/TEST.ROOT

hg: jigsaw/jake/langtools: requires jtreg 4.2 b04

[mandy . chung]

Changeset: dd31ba802575
Author:mchung
Date:  2016-11-28 21:43 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/dd31ba802575

requires jtreg 4.2 b04

! test/TEST.ROOT

hg: jigsaw/jake/hotspot: requires jtreg 4.2 b04

[mandy . chung]

Changeset: e9fe2fec61f7
Author:mchung
Date:  2016-11-28 21:43 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e9fe2fec61f7

requires jtreg 4.2 b04

! test/TEST.ROOT

hg: jigsaw/jake: requires jtreg 4.2 b04

[mandy . chung]

Changeset: 51f97296402c
Author:mchung
Date:  2016-11-28 21:43 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/51f97296402c

requires jtreg 4.2 b04

! common/conf/jib-profiles.js

Re: Code review for jigsaw/jake -> jdk9/dev sync up

[Paul Sandoz]

For the JDK patch:

MethodHandles
—

 176 public static Lookup privateLookupIn(Class targetClass, Lookup 
lookup) throws IllegalAccessException {
 177 SecurityManager sm = System.getSecurityManager();
 178 if (sm != null) sm.checkPermission(ACCESS_PERMISSION);
 179 if (targetClass.isPrimitive())
 180 throw new IllegalArgumentException(targetClass + " is a 
primitive class");
 181 Module targetModule = targetClass.getModule();
 182 Module callerModule = lookup.lookupClass().getModule();
 183 if (callerModule != targetModule && targetModule.isNamed()) {
 184 if (!callerModule.canRead(targetModule))
 185 throw new IllegalAccessException(callerModule + " does not 
read " + targetModule);
 186 Class clazz = targetClass;
 187 while (clazz.isArray()) {
 188 clazz = clazz.getComponentType();
 189 }

What happens if you pass a primitive array?

I think you need to specify what happens if an array class is passed and how 
the target class is obtained, and an IAE if the "element type" of the array is 
a primitive class.

(Separately i am looking forward to using this method to replace some Unsafe 
usages between Thread and other classes within the base module.)


ModuleDescriptor
—

 241 private  Stream toStringStream(Set s) {
 242 return s.stream().map(e -> e.toString().toLowerCase());
 243 }
 244
 245 private  String toString(Set mods, String what) {
 246 return (Stream.concat(toStringStream(mods), Stream.of(what)))
 247 .collect(Collectors.joining(" "));
 248 }

The above occurs three times. Suggest moving to the enclosing class as package 
private static methods.


Resolver
—

 449 for (Configuration parent: parents) {
 450 Optional om = 
parent.findModule(dn);
 451 if (om.isPresent()) {
 452 other = om.get().reference();
 453 break;
 454 }
 455 }

Replace with

  ResolvedModule rm = findInParent(dm);
  if (rm != null)
other = rm.reference();


 532 Set requiresTransitive= new HashSet<>();

Formating glitch for “=“


ServiceLoader
—

1331 @Override
1332 @SuppressWarnings("unchecked")
1333 public boolean tryAdvance(Consumer> action) {
1334 if (ServiceLoader.this.reloadCount != expectedReloadCount)
1335 throw new ConcurrentModificationException();
1336 Provider next = null;
1337 if (index < loadedProviders.size()) {
1338 next = (Provider) loadedProviders.get(index);
1339 } else if (iterator.hasNext()) {
1340 next = iterator.next();
1341 } else {
1342 loadedAllProviders = true;
1343 }
1344 index++;

Move the index increment into the top if block, thereby it only gets increment 
appropriately (no crazy overflow possible).


1353 @Override
1354 public int characteristics() {
1355 // need to decide on DISTINCT
1356 // not IMMUTABLE as structural interference possible
1357 return Spliterator.ORDERED + Spliterator.NONNULL;
1358 }

Should probably be consistent (subset of) with the characteristics reported for 
loadedProviders.stream(), thus DISTINCT would not be appropriate in this case 
unless you changed the optimal case of when all providers are loaded.



1552 public Optional findFirst() {
1553 Iterator iterator = iterator();
1554 if (iterator.hasNext()) {
1555 return Optional.of(iterator.next());
1556 } else {
1557 return Optional.empty();
1558 }
1559 }

 return stream().findFirst() ?


Paul.

> On 24 Nov 2016, at 07:25, Alan Bateman  wrote:
> 
> Folks on jigsaw-dev will know that we are on a mission to bring the changes 
> accumulated in the jake forest to jdk9/dev. We can think of this as a refresh 
> of the module system in JDK 9, the last big refresh was in May with many 
> small updates since then.
> 
> The focus this time is to bring the changes that are tied to JSR issues into 
> jdk9/dev, specifically the issues that are tracked on the JSR issues list [1] 
> as:
> 
> #CompileTimeDependences
> #AddExportsInManifest
> #ClassFileModuleName
> #ClassFileAccPublic
> #ServiceLoaderEnhancements
> #ResourceEncapsulation/#ClassFilesAsResources
> #ReflectiveAccessToNonExportedTypes
> #AwkwardStrongEncapsulation
> #ReadabilityAddedByLayerCreator
> #IndirectQualifiedReflectiveAccess (partial)
> #VersionsInModuleNames
> #NonHierarchicalLayers
> #ModuleAnnotations/#ModuleDeprecation
> #ReflectiveAccessByInstrumentationAgents
> 
> Some of these issues are not "Resolved" yet, meaning there is still ongoing 
> 

Re: Code review for jigsaw/jake -> jdk9/dev sync up

[Jonathan Gibbons]

On 11/28/16 3:28 AM, Maurizio Cimadamore wrote:

Hi,
the langtools code looks generally ok. Few questions:

* Why doesn't 'open' get its own directive in Directive.java - instead 
of relying on a 'mode' set on an export directive?
I agree that "opens" leveraging a type named "Exports..." is 
particularly irksome. If we don't come up with a common supertype, I 
think we should clone the code.


* ClassReader: should we have checks regarding an open module 
containing no open directives in the classfile? This seems to be 
called out in the spec [1] - see section 2.2


* At some point we should investigate better sharing strategy between 
ClassReader and ModuleNameReader
Maybe, but ModuleNameReader is supposed to be a simple light weight 
class reader, just good enough to get the name. It is invoked from the 
file manager world, and so does not (should not) access anything to do 
with Symbols. If we eventually rewrite ClassReader to sit on top of a 
new lower-level abstraction, then maybe we can share code some more.




* Names.dynamic seems unused

* I note that the classfile attribute name changes are not captured in 
the spec (but I might be referring to a slightly older version).


Maurizio

[1] - http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html#jigsaw-2.2






On 24/11/16 15:25, Alan Bateman wrote:
Folks on jigsaw-dev will know that we are on a mission to bring the 
changes accumulated in the jake forest to jdk9/dev. We can think of 
this as a refresh of the module system in JDK 9, the last big refresh 
was in May with many small updates since then.


The focus this time is to bring the changes that are tied to JSR 
issues into jdk9/dev, specifically the issues that are tracked on the 
JSR issues list [1] as:


#CompileTimeDependences
#AddExportsInManifest
#ClassFileModuleName
#ClassFileAccPublic
#ServiceLoaderEnhancements
#ResourceEncapsulation/#ClassFilesAsResources
#ReflectiveAccessToNonExportedTypes
#AwkwardStrongEncapsulation
#ReadabilityAddedByLayerCreator
#IndirectQualifiedReflectiveAccess (partial)
#VersionsInModuleNames
#NonHierarchicalLayers
#ModuleAnnotations/#ModuleDeprecation
#ReflectiveAccessByInstrumentationAgents

Some of these issues are not "Resolved" yet, meaning there is still 
ongoing discussion on the EG mailing list. That is okay, there is 
nothing final here. If there are changes to these proposals then the 
implementation changes will follow. Also, as I said in a mail to 
jigsaw-dev yesterday [2], is that we will keep the jake forest open 
for ongoing prototyping and iteration, also ongoing implementation 
improvements where iteration or bake time is important.


For the code review then the focus is therefore on sanity checking 
the changes that we would like to bring into jdk9/dev. We will not 
use this review thread to debate alternative designs or other big 
implementation changes that are more appropriate to bake in jake.


To get going, I've put the webrevs with a snapshot of the changes in 
jake here:

http://cr.openjdk.java.net/~alanb/8169069/0/

The changes are currently sync'ed against jdk-9+146 and will be 
rebased (and re-tested) against jdk9/dev prior to integration. There 
are a number of small changes that need to be added to this in the 
coming days, I will refresh the webrev every few days to take account 
of these updates.



A few important points to mention, even if you aren't reviewing the 
changes:


1. This refresh requires a new version of jtreg to run the tests. The 
changes for this new version are in the code-tools/jtreg repository 
and the plan is to tag a new build (jtreg4.2-b04) next week. Once the 
tag has been added then we'll update the requiredVersion property in 
each TEST.ROOT to force everyone to update.


2. For developers trying out modules with the main line JDK 9 builds 
then be aware that `requires public` changes to `requires transitive` 
and the `provides` clause changes to require all providers for a 
specific service type to be in the same clause. Also be aware that 
the binary form of the module declaration (module-info.class) changes 
so you will need to recompile any modules.


3. Those running existing code on JDK 9 and ignoring modules will 
need to be aware of a disruptive change in this refresh. The 
disruptive change is #AwkwardStrongEncapsulation where 
setAccessible(true) is changed so that it can't be used to break into 
non-public fields/methods of JDK classes. This change is going to 
expose a lot of hacks in existing code. We plan to send mail to 
jdk9-dev in advance of this integration to create awareness of this 
change. As per the original introduction of strong encapsulation then 
command line options (and now the manifest of application JAR files) 
can be used to keep existing code working. The new option is 
`--add-opens` to open a package in a module for deep reflection by 
other modules. As an example, if you find yourself with code that 
hacks into the private `comparator` field in 

hg: jigsaw/jake/langtools: Reject module-info classfiles for open modules that have non-zero number of opens directives.

[jan . lahoda]

Changeset: 425abd8ac1eb
Author:jlahoda
Date:  2016-11-28 21:08 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/425abd8ac1eb

Reject module-info classfiles for open modules that have non-zero number of 
opens directives.

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/diags/examples.not-yet.txt
! test/tools/javac/modules/OpenModulesTest.java

Re: How many modules per jar?

[Alex Buckley]

If you're writing new code, then packaging each module into its own JAR 
file (a "modular JAR") is the right thing to do.


If you're modularizing old code that is already delivered as JAR files, 
then you might have some difficulties. One difficulty is cyclic 
dependencies between code in different JAR files. Another difficulty is 
the same package being "split" over multiple JAR files. Modules don't 
allow cyclic dependencies between themselves, nor split packages, and if 
you can't declare the modules then you can't make any modular JARs. This 
is covered in "Project Jigsaw: Under The Hood" at 
http://openjdk.java.net/projects/jigsaw/talks/#j1-2016.


One good thing to look at in your lecture is the JDK module graph shown 
in JEP 200 and summarized on the Project Jigsaw page.


Alex

On 11/27/2016 10:28 AM, Pisarev, Vitaliy wrote:

I am not sure I hit the right mailing list, kindly redirect me if
needed.

I am preparing a lecture for my team about the new module system and
wondering whether there is already a set of best practices around
this.

For example: should we host each module in a separate jar or should a
jar contain more than one module if the list is cohesive enough?

Thanks, Vitaliy.

hg: jigsaw/jake/jdk: 4 new changesets

[alan . bateman]

Changeset: 8a69f4602580
Author:alanb
Date:  2016-11-28 15:25 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8a69f4602580

Expand test for open modules and packages

! test/jdk/modules/open/Basic.java

Changeset: b71703fea51b
Author:alanb
Date:  2016-11-28 15:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b71703fea51b

Review comments/suggestions from Peter Levart

! src/java.base/share/classes/java/lang/module/Resolver.java
! src/java.base/share/classes/java/util/ServiceLoader.java

Changeset: e5045d4d7da2
Author:alanb
Date:  2016-11-28 15:30 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e5045d4d7da2

More review comments/typos

! src/java.base/share/classes/java/lang/SuppressWarnings.java
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/util/ServiceLoader.java

Changeset: 653b130d825d
Author:alanb
Date:  2016-11-28 18:21 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/653b130d825d

Merge

Re: Can't call certain accessible methods using reflection

[Michael Rasmussen]

It might be worth noting that invoking it using MethodHandles works:
MethodHandle mh = MethodHandles.lookup().findVirtual(Public.class, "m",
MethodType.methodType(void.class));
mh.invoke(p);

/Michael

On 28 November 2016 at 15:17, Jochen Theodorou  wrote:

>
>
> On 28.11.2016 12:23, Peter Levart wrote:
> [...]
>
>> // Module m1:
>>
>> module m1 {
>> exports pkg1;
>> }
>>
>> package internal;
>> public class InternalImpl {
>> public void m() {
>> System.out.println("m()");
>> }
>> }
>>
>> package pkg1;
>> public class Public extends internal.InternalImpl {
>> }
>>
>
> is it legal for an exported class to "expose" an internal class in the
> class signature? I would have assumed this will fail compilation
>
>
>>
>> // Module m2:
>>
>> module m2 {
>> requires m1;
>> }
>>
>> package pkg2;
>> import pkg1.Public;
>> import java.lang.reflect.Method;
>> public class Main {
>> public static void main(String[] args) throws Exception
>> Public p = new Public();
>> // using bytecode
>> p.m();
>> // using reflection
>> Method m = Public.class.getMethod("m");
>> m.invoke(p);
>> // IllegalAccessException: class pkg2.Main (in module m2) cannot
>> access class internal.InternalImpl (in module m1) because module m1 does
>> not export internal to module m2
>> }
>> }
>>
>
> most likely p.m() will do invokevirtual P#m(), while
> Public.class.getMethod("m") will return a Method with the declaring class
> being internal.InternalImpl.
>
> bye Jochen
>

Re: Code review for jigsaw/jake -> jdk9/dev sync up

[Maurizio Cimadamore]

On 28/11/16 14:53, Jan Lahoda wrote:

Thanks for the comments Maurizio.

On 28.11.2016 12:28, Maurizio Cimadamore wrote:

Hi,
the langtools code looks generally ok. Few questions:

* Why doesn't 'open' get its own directive in Directive.java - instead
of relying on a 'mode' set on an export directive?


It seemed to me that having two directive interfaces in the API for 
directives that have the same structure was unnecessary (as we don't 
have MethodElement and ConstructorElement, but just ExecutableElement, 
or TypeElement that represents a class, an interface, an annotation 
type or an enum type).


If you think it would be better to have separate interfaces for 
exports and opens, I am OK with that as well.
I agree that it would be redundant - perhaps the two directive can both 
share a common superclass which defines the common fields? I said that 
because it looks like for everything else, 'opens' and 'exports' are 
really two separate directives, with separate bytecode encodings and 
such (that is, the Module attribute has separate entries for 'opens' and 
'exports').




* ClassReader: should we have checks regarding an open module containing
no open directives in the classfile? This seems to be called out in the
spec [1] - see section 2.2


I think such checks would be fine, working on a patch.

ok




* At some point we should investigate better sharing strategy between
ClassReader and ModuleNameReader

* Names.dynamic seems unused


Fixed:
http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8156e205fcb4

Thanks

Maurizio

Jan



* I note that the classfile attribute name changes are not captured in
the spec (but I might be referring to a slightly older version).

Maurizio

[1] - http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html#jigsaw-2.2






On 24/11/16 15:25, Alan Bateman wrote:

Folks on jigsaw-dev will know that we are on a mission to bring the
changes accumulated in the jake forest to jdk9/dev. We can think of
this as a refresh of the module system in JDK 9, the last big refresh
was in May with many small updates since then.

The focus this time is to bring the changes that are tied to JSR
issues into jdk9/dev, specifically the issues that are tracked on the
JSR issues list [1] as:

#CompileTimeDependences
#AddExportsInManifest
#ClassFileModuleName
#ClassFileAccPublic
#ServiceLoaderEnhancements
#ResourceEncapsulation/#ClassFilesAsResources
#ReflectiveAccessToNonExportedTypes
#AwkwardStrongEncapsulation
#ReadabilityAddedByLayerCreator
#IndirectQualifiedReflectiveAccess (partial)
#VersionsInModuleNames
#NonHierarchicalLayers
#ModuleAnnotations/#ModuleDeprecation
#ReflectiveAccessByInstrumentationAgents

Some of these issues are not "Resolved" yet, meaning there is still
ongoing discussion on the EG mailing list. That is okay, there is
nothing final here. If there are changes to these proposals then the
implementation changes will follow. Also, as I said in a mail to
jigsaw-dev yesterday [2], is that we will keep the jake forest open
for ongoing prototyping and iteration, also ongoing implementation
improvements where iteration or bake time is important.

For the code review then the focus is therefore on sanity checking the
changes that we would like to bring into jdk9/dev. We will not use
this review thread to debate alternative designs or other big
implementation changes that are more appropriate to bake in jake.

To get going, I've put the webrevs with a snapshot of the changes in
jake here:
http://cr.openjdk.java.net/~alanb/8169069/0/

The changes are currently sync'ed against jdk-9+146 and will be
rebased (and re-tested) against jdk9/dev prior to integration. There
are a number of small changes that need to be added to this in the
coming days, I will refresh the webrev every few days to take account
of these updates.


A few important points to mention, even if you aren't reviewing the
changes:

1. This refresh requires a new version of jtreg to run the tests. The
changes for this new version are in the code-tools/jtreg repository
and the plan is to tag a new build (jtreg4.2-b04) next week. Once the
tag has been added then we'll update the requiredVersion property in
each TEST.ROOT to force everyone to update.

2. For developers trying out modules with the main line JDK 9 builds
then be aware that `requires public` changes to `requires transitive`
and the `provides` clause changes to require all providers for a
specific service type to be in the same clause. Also be aware that the
binary form of the module declaration (module-info.class) changes so
you will need to recompile any modules.

3. Those running existing code on JDK 9 and ignoring modules will need
to be aware of a disruptive change in this refresh. The disruptive
change is #AwkwardStrongEncapsulation where setAccessible(true) is
changed so that it can't be used to break into non-public
fields/methods of JDK classes. This change is going to expose a lot of
hacks in existing code. We plan to send mail to 

Re: Code review for jigsaw/jake -> jdk9/dev sync up

[Jan Lahoda]

Thanks for the comments Maurizio.

On 28.11.2016 12:28, Maurizio Cimadamore wrote:

Hi,
the langtools code looks generally ok. Few questions:

* Why doesn't 'open' get its own directive in Directive.java - instead
of relying on a 'mode' set on an export directive?


It seemed to me that having two directive interfaces in the API for 
directives that have the same structure was unnecessary (as we don't 
have MethodElement and ConstructorElement, but just ExecutableElement, 
or TypeElement that represents a class, an interface, an annotation type 
or an enum type).


If you think it would be better to have separate interfaces for exports 
and opens, I am OK with that as well.




* ClassReader: should we have checks regarding an open module containing
no open directives in the classfile? This seems to be called out in the
spec [1] - see section 2.2


I think such checks would be fine, working on a patch.



* At some point we should investigate better sharing strategy between
ClassReader and ModuleNameReader

* Names.dynamic seems unused


Fixed:
http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8156e205fcb4

Jan



* I note that the classfile attribute name changes are not captured in
the spec (but I might be referring to a slightly older version).

Maurizio

[1] - http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html#jigsaw-2.2






On 24/11/16 15:25, Alan Bateman wrote:

Folks on jigsaw-dev will know that we are on a mission to bring the
changes accumulated in the jake forest to jdk9/dev. We can think of
this as a refresh of the module system in JDK 9, the last big refresh
was in May with many small updates since then.

The focus this time is to bring the changes that are tied to JSR
issues into jdk9/dev, specifically the issues that are tracked on the
JSR issues list [1] as:

#CompileTimeDependences
#AddExportsInManifest
#ClassFileModuleName
#ClassFileAccPublic
#ServiceLoaderEnhancements
#ResourceEncapsulation/#ClassFilesAsResources
#ReflectiveAccessToNonExportedTypes
#AwkwardStrongEncapsulation
#ReadabilityAddedByLayerCreator
#IndirectQualifiedReflectiveAccess (partial)
#VersionsInModuleNames
#NonHierarchicalLayers
#ModuleAnnotations/#ModuleDeprecation
#ReflectiveAccessByInstrumentationAgents

Some of these issues are not "Resolved" yet, meaning there is still
ongoing discussion on the EG mailing list. That is okay, there is
nothing final here. If there are changes to these proposals then the
implementation changes will follow. Also, as I said in a mail to
jigsaw-dev yesterday [2], is that we will keep the jake forest open
for ongoing prototyping and iteration, also ongoing implementation
improvements where iteration or bake time is important.

For the code review then the focus is therefore on sanity checking the
changes that we would like to bring into jdk9/dev. We will not use
this review thread to debate alternative designs or other big
implementation changes that are more appropriate to bake in jake.

To get going, I've put the webrevs with a snapshot of the changes in
jake here:
http://cr.openjdk.java.net/~alanb/8169069/0/

The changes are currently sync'ed against jdk-9+146 and will be
rebased (and re-tested) against jdk9/dev prior to integration. There
are a number of small changes that need to be added to this in the
coming days, I will refresh the webrev every few days to take account
of these updates.


A few important points to mention, even if you aren't reviewing the
changes:

1. This refresh requires a new version of jtreg to run the tests. The
changes for this new version are in the code-tools/jtreg repository
and the plan is to tag a new build (jtreg4.2-b04) next week. Once the
tag has been added then we'll update the requiredVersion property in
each TEST.ROOT to force everyone to update.

2. For developers trying out modules with the main line JDK 9 builds
then be aware that `requires public` changes to `requires transitive`
and the `provides` clause changes to require all providers for a
specific service type to be in the same clause. Also be aware that the
binary form of the module declaration (module-info.class) changes so
you will need to recompile any modules.

3. Those running existing code on JDK 9 and ignoring modules will need
to be aware of a disruptive change in this refresh. The disruptive
change is #AwkwardStrongEncapsulation where setAccessible(true) is
changed so that it can't be used to break into non-public
fields/methods of JDK classes. This change is going to expose a lot of
hacks in existing code. We plan to send mail to jdk9-dev in advance of
this integration to create awareness of this change. As per the
original introduction of strong encapsulation then command line
options (and now the manifest of application JAR files) can be used to
keep existing code working. The new option is `--add-opens` to open a
package in a module for deep reflection by other modules. As an
example, if you find yourself with code that hacks into the private
`comparator` 

Re: Code review for jigsaw/jake -> jdk9/dev sync up

[Sundararajan Athijegannathan]

Reviewed Nashorn changes. All fine.

-Sundar


On 11/28/2016 8:17 PM, Chris Hegarty wrote:
> On 24 Nov 2016, at 15:25, Alan Bateman  wrote:
>> ...
>> To get going, I've put the webrevs with a snapshot of the changes in jake 
>> here:
>>http://cr.openjdk.java.net/~alanb/8169069/0/
> Overall this look very good. I ran through most of the changes in the jdk 
> repo,
> just a few small comments.
>
> 1) SuppressWarnings.java  typo element - > elementS
>
>   38  * However, note that if a warning is suppressed in a {@code
>   39  * module-info} file, the suppression applies to elementS within the
>   40  * file and not to types contained within the module.
>
> 2) jartool Main.java
>   Maybe concealedPackages should have a comment about its use ( it is
>   used in the Validator, and not by Main at all ).
>
> 3) MethodHandles.java privateLookupIn
>   It might be clearer if the third bullet used {@code lookup}, or 'caller 
> lookup’, or ‘given lookup'?
>  
>   The CALLER lookup has the {@link Lookup#MODULE MODULE} lookup mode.
>
> 4) ServiceLoader
> {@code ExtendedCodecsFactory}
>   111  * will be treated as a provider factory and {@code
>   112  * ExtendedCodecsFactory.provider()} will be invoked to INSTANTIATE the
>   113  * provider.
>
>   Is 'instantiate' strictly true here? Should it simply be ‘return'
>
>   206  *  If a named module declares more than one provider then the 
> providers
>   207  * are located in the order that they appear in the {@code 
> provides} table of
>   208  * the {@code Module} class file attribute ({@code 
> module-info.class}).   
>
>   Wow. I assume the JLS, or otherwise, will specify that the order in which 
> the 
>   providers are listed in the module-info be preserved, no? Maybe this item 
> could
>   mention that. The class file reference can still be kept, but seems a bit 
> low-level
>   for developers.
>
> -Chris.

Re: Code review for jigsaw/jake -> jdk9/dev sync up

[Chris Hegarty]

On 24 Nov 2016, at 15:25, Alan Bateman  wrote:
> 
> ...
> To get going, I've put the webrevs with a snapshot of the changes in jake 
> here:
>http://cr.openjdk.java.net/~alanb/8169069/0/

Overall this look very good. I ran through most of the changes in the jdk repo,
just a few small comments.

1) SuppressWarnings.java  typo element - > elementS

  38  * However, note that if a warning is suppressed in a {@code
  39  * module-info} file, the suppression applies to elementS within the
  40  * file and not to types contained within the module.

2) jartool Main.java
  Maybe concealedPackages should have a comment about its use ( it is
  used in the Validator, and not by Main at all ).

3) MethodHandles.java privateLookupIn
  It might be clearer if the third bullet used {@code lookup}, or 'caller 
lookup’, or ‘given lookup'?
 
  The CALLER lookup has the {@link Lookup#MODULE MODULE} lookup mode.

4) ServiceLoader
{@code ExtendedCodecsFactory}
  111  * will be treated as a provider factory and {@code
  112  * ExtendedCodecsFactory.provider()} will be invoked to INSTANTIATE the
  113  * provider.

  Is 'instantiate' strictly true here? Should it simply be ‘return'

  206  *  If a named module declares more than one provider then the 
providers
  207  * are located in the order that they appear in the {@code provides} 
table of
  208  * the {@code Module} class file attribute ({@code 
module-info.class}).   

  Wow. I assume the JLS, or otherwise, will specify that the order in which the 
  providers are listed in the module-info be preserved, no? Maybe this item 
could
  mention that. The class file reference can still be kept, but seems a bit 
low-level
  for developers.

-Chris.

hg: jigsaw/jake/hotspot: 8170397: hotspot gc/stress/gcbasher tests fail in Jake

[harold . seigel]

Changeset: 756aeaa66545
Author:hseigel
Date:  2016-11-28 09:30 -0500
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/756aeaa66545

8170397: hotspot gc/stress/gcbasher tests fail in Jake
Summary: Don't parse "module-info.class" files
Reviewed-by: alanb

! test/gc/stress/gcbasher/TestGCBasher.java

Re: Code review for jigsaw/jake -> jdk9/dev sync up

[Lois Foltan]

Hi Alan,

I have reviewed the hotspot changes and they look good.  Minor nit, 
src/share/vm/classfile/javaClasses.cpp only differs by the addition of a 
blank line.


Thanks,
Lois

On 11/24/2016 10:25 AM, Alan Bateman wrote:
Folks on jigsaw-dev will know that we are on a mission to bring the 
changes accumulated in the jake forest to jdk9/dev. We can think of 
this as a refresh of the module system in JDK 9, the last big refresh 
was in May with many small updates since then.


The focus this time is to bring the changes that are tied to JSR 
issues into jdk9/dev, specifically the issues that are tracked on the 
JSR issues list [1] as:


#CompileTimeDependences
#AddExportsInManifest
#ClassFileModuleName
#ClassFileAccPublic
#ServiceLoaderEnhancements
#ResourceEncapsulation/#ClassFilesAsResources
#ReflectiveAccessToNonExportedTypes
#AwkwardStrongEncapsulation
#ReadabilityAddedByLayerCreator
#IndirectQualifiedReflectiveAccess (partial)
#VersionsInModuleNames
#NonHierarchicalLayers
#ModuleAnnotations/#ModuleDeprecation
#ReflectiveAccessByInstrumentationAgents

Some of these issues are not "Resolved" yet, meaning there is still 
ongoing discussion on the EG mailing list. That is okay, there is 
nothing final here. If there are changes to these proposals then the 
implementation changes will follow. Also, as I said in a mail to 
jigsaw-dev yesterday [2], is that we will keep the jake forest open 
for ongoing prototyping and iteration, also ongoing implementation 
improvements where iteration or bake time is important.


For the code review then the focus is therefore on sanity checking the 
changes that we would like to bring into jdk9/dev. We will not use 
this review thread to debate alternative designs or other big 
implementation changes that are more appropriate to bake in jake.


To get going, I've put the webrevs with a snapshot of the changes in 
jake here:

http://cr.openjdk.java.net/~alanb/8169069/0/

The changes are currently sync'ed against jdk-9+146 and will be 
rebased (and re-tested) against jdk9/dev prior to integration. There 
are a number of small changes that need to be added to this in the 
coming days, I will refresh the webrev every few days to take account 
of these updates.



A few important points to mention, even if you aren't reviewing the 
changes:


1. This refresh requires a new version of jtreg to run the tests. The 
changes for this new version are in the code-tools/jtreg repository 
and the plan is to tag a new build (jtreg4.2-b04) next week. Once the 
tag has been added then we'll update the requiredVersion property in 
each TEST.ROOT to force everyone to update.


2. For developers trying out modules with the main line JDK 9 builds 
then be aware that `requires public` changes to `requires transitive` 
and the `provides` clause changes to require all providers for a 
specific service type to be in the same clause. Also be aware that the 
binary form of the module declaration (module-info.class) changes so 
you will need to recompile any modules.


3. Those running existing code on JDK 9 and ignoring modules will need 
to be aware of a disruptive change in this refresh. The disruptive 
change is #AwkwardStrongEncapsulation where setAccessible(true) is 
changed so that it can't be used to break into non-public 
fields/methods of JDK classes. This change is going to expose a lot of 
hacks in existing code. We plan to send mail to jdk9-dev in advance of 
this integration to create awareness of this change. As per the 
original introduction of strong encapsulation then command line 
options (and now the manifest of application JAR files) can be used to 
keep existing code working. The new option is `--add-opens` to open a 
package in a module for deep reflection by other modules. As an 
example, if you find yourself with code that hacks into the private 
`comparator` field in java.util.TreeMap then running with `--add-opens 
java.base/java.util=ALL-UNNAMED` will keep that code working.



A few miscellaneous notes for those that are reviewing:

1. We have some temporary/transition code in the top-level repo to 
deal with the importing of the JavaFX modules. This will be removed 
once the changes are in JDK 9 for the OpenJFX project to use.


2. In the jdk repo then it's important to understand that the module 
system is initialized at startup and there are many places where we 
need to keep startup performance in mind. This sometimes means less 
elegant code than might be used if startup wasn't such a big concern.


3. The changes in the jaxws repo make use of new APIs that means the 
code doesn't compile with JDK 7 or JDK 8. Our intention is to work 
with the JAXB and JAX-WS maintainers to address the issues in the 
upstream project and then bring those changes into jdk9/dev to replace 
the patches that we are forced to push for the short term.


4. You will see several tests where the value of the @modules tag has 
`:open` or `:+open`. This is new jtreg speak. The former 

Re: Can't call certain accessible methods using reflection

[Jochen Theodorou]

On 28.11.2016 12:23, Peter Levart wrote:
[...]

// Module m1:

module m1 {
exports pkg1;
}

package internal;
public class InternalImpl {
public void m() {
System.out.println("m()");
}
}

package pkg1;
public class Public extends internal.InternalImpl {
}


is it legal for an exported class to "expose" an internal class in the 
class signature? I would have assumed this will fail compilation





// Module m2:

module m2 {
requires m1;
}

package pkg2;
import pkg1.Public;
import java.lang.reflect.Method;
public class Main {
public static void main(String[] args) throws Exception
Public p = new Public();
// using bytecode
p.m();
// using reflection
Method m = Public.class.getMethod("m");
m.invoke(p);
// IllegalAccessException: class pkg2.Main (in module m2) cannot
access class internal.InternalImpl (in module m1) because module m1 does
not export internal to module m2
}
}


most likely p.m() will do invokevirtual P#m(), while 
Public.class.getMethod("m") will return a Method with the declaring 
class being internal.InternalImpl.


bye Jochen

Re: Replacement for JDK8 APIs

[Stéphane Nicoll]

On Mon, Nov 28, 2016 at 11:49 AM, Alan Bateman 
wrote:

> On 28/11/2016 10:36, Stéphane Nicoll wrote:
>
> Peter,
>>
>> Thanks a lot, that helped! [1]
>>
>> Cheers,
>> S.
>>
>> [1]
>> https://github.com/spring-projects/spring-boot/commit/e15b3e
>> 463f312524495349673a16cb67cfaa2eae
>>
>> The reflection has come up a number of things so great that Peter tracked
> this down.
>
> So I'm curious why this code uses core reflection. Is it because it
> sometimes runs on the JRE that didn't have javac implementation (or
> jdk.compiler module in JDK 9).


Eclipse users usually use the eclipse compiler and the annotation processor
is supposed to kick in in the IDE as well. When you generate the meta-data
in eclipse, default values are not available which is annoying. Again,
we're not happy _at all_ with that code and would prefer to use some
standard contract from javax.lang.model.

I'll ask on compiler-dev if there is a better way.

Thanks!
S.



>
>
> -Alan
>

hg: jigsaw/jake/langtools: Removing 'dynamic' name, which is not needed anymore

[jan . lahoda]

Changeset: 8156e205fcb4
Author:jlahoda
Date:  2016-11-28 13:02 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8156e205fcb4

Removing 'dynamic' name, which is not needed anymore

! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java

Re: Code review for jigsaw/jake -> jdk9/dev sync up

[Maurizio Cimadamore]

Hi,
the langtools code looks generally ok. Few questions:

* Why doesn't 'open' get its own directive in Directive.java - instead 
of relying on a 'mode' set on an export directive?


* ClassReader: should we have checks regarding an open module containing 
no open directives in the classfile? This seems to be called out in the 
spec [1] - see section 2.2


* At some point we should investigate better sharing strategy between 
ClassReader and ModuleNameReader


* Names.dynamic seems unused

* I note that the classfile attribute name changes are not captured in 
the spec (but I might be referring to a slightly older version).


Maurizio

[1] - http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html#jigsaw-2.2






On 24/11/16 15:25, Alan Bateman wrote:
Folks on jigsaw-dev will know that we are on a mission to bring the 
changes accumulated in the jake forest to jdk9/dev. We can think of 
this as a refresh of the module system in JDK 9, the last big refresh 
was in May with many small updates since then.


The focus this time is to bring the changes that are tied to JSR 
issues into jdk9/dev, specifically the issues that are tracked on the 
JSR issues list [1] as:


#CompileTimeDependences
#AddExportsInManifest
#ClassFileModuleName
#ClassFileAccPublic
#ServiceLoaderEnhancements
#ResourceEncapsulation/#ClassFilesAsResources
#ReflectiveAccessToNonExportedTypes
#AwkwardStrongEncapsulation
#ReadabilityAddedByLayerCreator
#IndirectQualifiedReflectiveAccess (partial)
#VersionsInModuleNames
#NonHierarchicalLayers
#ModuleAnnotations/#ModuleDeprecation
#ReflectiveAccessByInstrumentationAgents

Some of these issues are not "Resolved" yet, meaning there is still 
ongoing discussion on the EG mailing list. That is okay, there is 
nothing final here. If there are changes to these proposals then the 
implementation changes will follow. Also, as I said in a mail to 
jigsaw-dev yesterday [2], is that we will keep the jake forest open 
for ongoing prototyping and iteration, also ongoing implementation 
improvements where iteration or bake time is important.


For the code review then the focus is therefore on sanity checking the 
changes that we would like to bring into jdk9/dev. We will not use 
this review thread to debate alternative designs or other big 
implementation changes that are more appropriate to bake in jake.


To get going, I've put the webrevs with a snapshot of the changes in 
jake here:

http://cr.openjdk.java.net/~alanb/8169069/0/

The changes are currently sync'ed against jdk-9+146 and will be 
rebased (and re-tested) against jdk9/dev prior to integration. There 
are a number of small changes that need to be added to this in the 
coming days, I will refresh the webrev every few days to take account 
of these updates.



A few important points to mention, even if you aren't reviewing the 
changes:


1. This refresh requires a new version of jtreg to run the tests. The 
changes for this new version are in the code-tools/jtreg repository 
and the plan is to tag a new build (jtreg4.2-b04) next week. Once the 
tag has been added then we'll update the requiredVersion property in 
each TEST.ROOT to force everyone to update.


2. For developers trying out modules with the main line JDK 9 builds 
then be aware that `requires public` changes to `requires transitive` 
and the `provides` clause changes to require all providers for a 
specific service type to be in the same clause. Also be aware that the 
binary form of the module declaration (module-info.class) changes so 
you will need to recompile any modules.


3. Those running existing code on JDK 9 and ignoring modules will need 
to be aware of a disruptive change in this refresh. The disruptive 
change is #AwkwardStrongEncapsulation where setAccessible(true) is 
changed so that it can't be used to break into non-public 
fields/methods of JDK classes. This change is going to expose a lot of 
hacks in existing code. We plan to send mail to jdk9-dev in advance of 
this integration to create awareness of this change. As per the 
original introduction of strong encapsulation then command line 
options (and now the manifest of application JAR files) can be used to 
keep existing code working. The new option is `--add-opens` to open a 
package in a module for deep reflection by other modules. As an 
example, if you find yourself with code that hacks into the private 
`comparator` field in java.util.TreeMap then running with `--add-opens 
java.base/java.util=ALL-UNNAMED` will keep that code working.



A few miscellaneous notes for those that are reviewing:

1. We have some temporary/transition code in the top-level repo to 
deal with the importing of the JavaFX modules. This will be removed 
once the changes are in JDK 9 for the OpenJFX project to use.


2. In the jdk repo then it's important to understand that the module 
system is initialized at startup and there are many places where we 
need to keep startup performance in mind. This sometimes means less 

Can't call certain accessible methods using reflection

[Peter Levart]

Hi,

I encountered a situation in which calling a method using reflection is 
not possible, while the same method can be called with bytecode instruction.


Here's an example:

// Module m1:

module m1 {
exports pkg1;
}

package internal;
public class InternalImpl {
public void m() {
System.out.println("m()");
}
}

package pkg1;
public class Public extends internal.InternalImpl {
}


// Module m2:

module m2 {
requires m1;
}

package pkg2;
import pkg1.Public;
import java.lang.reflect.Method;
public class Main {
public static void main(String[] args) throws Exception
Public p = new Public();
// using bytecode
p.m();
// using reflection
Method m = Public.class.getMethod("m");
m.invoke(p);
// IllegalAccessException: class pkg2.Main (in module m2) 
cannot access class internal.InternalImpl (in module m1) because module 
m1 does not export internal to module m2

}
}


Similar situation would arise if Public class extended a package-private 
class containing public method m(). But in this case javac helps 
reflection by creating a bridge method in Public class which just 
delegates to super. I don't know if it would be wise to expect the same 
from javac for subclasses of public classes in non-exported packages or 
packages that are exported to just certain modules?


Regards, Peter

Re: Code review for jigsaw/jake -> jdk9/dev sync up

[Alan Bateman]

On 27/11/2016 11:15, Peter Levart wrote:

Hi Alan,

Overall this looks very good. I noticed a couple of nits...

Thanks for going through the changes.


:

So should Provider rather declare the following?

Class type();

Or alternatively, should ServiceLoader rather declare the following?

public Stream> stream();
Well spotted, this should be Class. We could change the 
return of stream too but that might be more awkward to work with.



:

Now that there can be multiple parents of some configuration, those 
parents can have common parents, but since you iterate the transitive 
configurations of each individual parent in isolation, you can 
encounter a common "diamond" configuration multiple times. Logically 
all is well since you collect the required modules into Sets so 
multiplicity is taken care of. But this is not very optimal from 
algorithm point. It would be better to 1st make a stream of unique 
configurations of all parents:
Fair comment, we haven't done any performance work for the multi parent 
scenario yet, mostly because #NonHierarchicalLayers is niche and there 
are still some open questions on how parents should be searched.


So we can change this as you suggest except that it regresses startup, 
this is the reason for skipping Configuration.empty(). However we 
support both so I'll get that change in so that the more elegant code is 
used when creating dynamic configurations.


-Alan

Re: Replacement for JDK8 APIs

[Alan Bateman]

On 28/11/2016 10:36, Stéphane Nicoll wrote:


Peter,

Thanks a lot, that helped! [1]

Cheers,
S.

[1]
https://github.com/spring-projects/spring-boot/commit/e15b3e463f312524495349673a16cb67cfaa2eae

The reflection has come up a number of things so great that Peter 
tracked this down.


So I'm curious why this code uses core reflection. Is it because it 
sometimes runs on the JRE that didn't have javac implementation (or 
jdk.compiler module in JDK 9).


-Alan

Re: Replacement for JDK8 APIs

[Stéphane Nicoll]

Peter,

Thanks a lot, that helped! [1]

Cheers,
S.

[1]
https://github.com/spring-projects/spring-boot/commit/e15b3e463f312524495349673a16cb67cfaa2eae

On Mon, Nov 28, 2016 at 10:50 AM, Peter Levart 
wrote:

>
>
> On 11/28/2016 10:39 AM, Peter Levart wrote:
>
>> final class Trees extends ReflectionWrapper {
>>
>> private Trees(Object instance) {
>> super(com.sun.source.util.Trees.class, instance);
>> }
>>
>
> ...ah, you would probably want to use 
> Class.forName("com.sun.source.util.Trees")
> above...
>
> Peter
>
>

Re: Replacement for JDK8 APIs

[Peter Levart]

On 11/28/2016 10:39 AM, Peter Levart wrote:

final class Trees extends ReflectionWrapper {

private Trees(Object instance) {
super(com.sun.source.util.Trees.class, instance);
} 


...ah, you would probably want to use 
Class.forName("com.sun.source.util.Trees") above...


Peter

Re: Replacement for JDK8 APIs

[Peter Levart]

Hi Stephan,

I thin this is a classical problem with reflection access checking that 
existed before jigsaw, but is now encountered even more frequently. The 
problem is that your ReflectionWrapper, given an instnace of some 
object, takes its runtime Class and searches methods in that class. The 
runtime class of the object may not be accessible to the world (i.e. the 
ReflectionWrapper). When you search for a method in such class you may 
end up with a Method object that represents the method declared in such 
inaccessible class (in your example, this seems to be 
com.sun.tools.javac.api.JavacTrees::getTree(Element)). Access checks for 
such method then fail, because com.sun.tools.javac.api.JavacTrees is not 
publicly accessible (it is in a non-exported package).


I recommend that you modify your ReflectionWrapper so that it takes a 
"Class type" parameter in addition to the "Object instance" and then use 
this "type" (which should always represent some publicly accessible 
supertype of the runtime type of the instance) to search for methods...


ReflectionWrapper(Class type, Object instance) {
this.type = type;
this.instance = type.cast(instance);
}


And then:

final class Trees extends ReflectionWrapper {

private Trees(Object instance) {
super(com.sun.source.util.Trees.class, instance);
}

...


I think this should work.


Regards, Peter


On 11/28/2016 09:41 AM, Stéphane Nicoll wrote:

Jon,

We invoke `com.sun.source.util.Trees#instance(ProcessingEnvironment)`
reflectively[1] as this class may not be available. This gives us access to
`Tree` that we handle reflectively as well[2]. There is no reference
anywhere to com.sun.tools.javac.api.JavacTrees in our codebase so I guess
this exception is an attempt of us invoking that method reflectively?

In any case, that's what we ended up doing to retrieve the init value of
fields in an annotation processor. If there is any other way using a public
API, I am more happy than replace that code. Should I raise that question
on compiler-dev?

Thanks a lot,
S.




[1]
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-tools/spring-boot-configuration-processor/src/main/java/org/springframework/boot/configurationprocessor/fieldvalues/javac/Trees.java#L41-L46
[2]
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-tools/spring-boot-configuration-processor/src/main/java/org/springframework/boot/configurationprocessor/fieldvalues/javac/Tree.java


On Sun, Nov 27, 2016 at 4:57 PM, Jonathan Gibbons <
jonathan.gibb...@oracle.com> wrote:


Stéphan,

You say you are using com.sun.tools.javac.api.JavacTrees. Although that
class is not exported from jdk.compiler, it is an implementation of the
interface com.sun.source.util.Trees, which is exported.  Is the interface
sufficient to your needs? If not, what methods are you calling?

-- Jon



On 11/27/16 1:16 AM, Stéphane Nicoll wrote:


Hey,

Thanks for all the feedback so far. Any idea about the annotation
processor
question? Is there a dedicated dev list for it maybe?

Thank you,
S.


On Thu, Nov 24, 2016 at 3:22 PM, Stéphane Nicoll 
wrote:

Hi,

I am working on the Spring Boot project[1] and I am trying to make sure
our codebase compiles with the current JDK9 build[2]. So far I've hit two
major issues:

We use "sun.misc.VMSupport" to retrieve the port being used by the Java
remote debugging. You can find the actual code in
RemoteDebugPortProvider[3]

We have an annotation processor that inspects all classes annotated with
@ConfigurationProperties and generates some meta-data about them. One
important piece of this is to extract the default value assigned to
fields.
Consider the following example

@ConfigurationProperties
public class Foo {

private static final String DEFAULT_NAME = "name";

private String name = DEFAULT_NAME;

private Integer counter = 42;

private List hosts = Collections.singletonList("localhost");


}

What we've build is a visitor that navigates to those elements and
extracts the default values assigned to each field, including navigating
to
parent element (the "name" constant there) or inferring value from method
parameters ("localhost"). The  current code relies on a feature of the
JDK
that is no longer exported[4]:


java.lang.IllegalAccessException: class org.springframework.boot.
configurationprocessor.fieldvalues.javac.Trees cannot access class
com.sun.tools.javac.api.JavacTrees (in module jdk.compiler) because
module jdk.compiler does not export com.sun.tools.javac.api to unnamed
module @5a7fe64


Does anybody has some insight as how we could migrate those two use
cases?
In particular, the second use case could be implemented with a contract
of
javax.lang.model but we haven't found how to do it.

Thank you,
S.



[1] https://github.com/spring-projects/spring-boot
[2] 

Re: Replacement for JDK8 APIs

[Stéphane Nicoll]

Jon,

We invoke `com.sun.source.util.Trees#instance(ProcessingEnvironment)`
reflectively[1] as this class may not be available. This gives us access to
`Tree` that we handle reflectively as well[2]. There is no reference
anywhere to com.sun.tools.javac.api.JavacTrees in our codebase so I guess
this exception is an attempt of us invoking that method reflectively?

In any case, that's what we ended up doing to retrieve the init value of
fields in an annotation processor. If there is any other way using a public
API, I am more happy than replace that code. Should I raise that question
on compiler-dev?

Thanks a lot,
S.




[1]
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-tools/spring-boot-configuration-processor/src/main/java/org/springframework/boot/configurationprocessor/fieldvalues/javac/Trees.java#L41-L46
[2]
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-tools/spring-boot-configuration-processor/src/main/java/org/springframework/boot/configurationprocessor/fieldvalues/javac/Tree.java


On Sun, Nov 27, 2016 at 4:57 PM, Jonathan Gibbons <
jonathan.gibb...@oracle.com> wrote:

> Stéphan,
>
> You say you are using com.sun.tools.javac.api.JavacTrees. Although that
> class is not exported from jdk.compiler, it is an implementation of the
> interface com.sun.source.util.Trees, which is exported.  Is the interface
> sufficient to your needs? If not, what methods are you calling?
>
> -- Jon
>
>
>
> On 11/27/16 1:16 AM, Stéphane Nicoll wrote:
>
>> Hey,
>>
>> Thanks for all the feedback so far. Any idea about the annotation
>> processor
>> question? Is there a dedicated dev list for it maybe?
>>
>> Thank you,
>> S.
>>
>>
>> On Thu, Nov 24, 2016 at 3:22 PM, Stéphane Nicoll 
>> wrote:
>>
>> Hi,
>>>
>>> I am working on the Spring Boot project[1] and I am trying to make sure
>>> our codebase compiles with the current JDK9 build[2]. So far I've hit two
>>> major issues:
>>>
>>> We use "sun.misc.VMSupport" to retrieve the port being used by the Java
>>> remote debugging. You can find the actual code in
>>> RemoteDebugPortProvider[3]
>>>
>>> We have an annotation processor that inspects all classes annotated with
>>> @ConfigurationProperties and generates some meta-data about them. One
>>> important piece of this is to extract the default value assigned to
>>> fields.
>>> Consider the following example
>>>
>>> @ConfigurationProperties
>>> public class Foo {
>>>
>>>private static final String DEFAULT_NAME = "name";
>>>
>>>private String name = DEFAULT_NAME;
>>>
>>>private Integer counter = 42;
>>>
>>>private List hosts = Collections.singletonList("localhost");
>>>
>>>
>>> }
>>>
>>> What we've build is a visitor that navigates to those elements and
>>> extracts the default values assigned to each field, including navigating
>>> to
>>> parent element (the "name" constant there) or inferring value from method
>>> parameters ("localhost"). The  current code relies on a feature of the
>>> JDK
>>> that is no longer exported[4]:
>>>
>>>
>>> java.lang.IllegalAccessException: class org.springframework.boot.
>>> configurationprocessor.fieldvalues.javac.Trees cannot access class
>>> com.sun.tools.javac.api.JavacTrees (in module jdk.compiler) because
>>> module jdk.compiler does not export com.sun.tools.javac.api to unnamed
>>> module @5a7fe64
>>> 
>>>
>>> Does anybody has some insight as how we could migrate those two use
>>> cases?
>>> In particular, the second use case could be implemented with a contract
>>> of
>>> javax.lang.model but we haven't found how to do it.
>>>
>>> Thank you,
>>> S.
>>>
>>>
>>>
>>> [1] https://github.com/spring-projects/spring-boot
>>> [2] https://github.com/spring-projects/spring-boot/issues/7226
>>> [3] https://github.com/spring-projects/spring-boot/blob/
>>> master/spring-boot-devtools/src/main/java/org/
>>> springframework/boot/devtools/tunnel/server/RemoteDebugPortProvider.java
>>> [4] https://github.com/spring-projects/spring-boot/blob/
>>> master/spring-boot-tools/spring-boot-configuration-
>>> processor/src/main/java/org/springframework/boot/configurationprocessor/
>>> fieldvalues/javac/Trees.java
>>>
>>>
>>>
>>>
>>>
>>>
>