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

[Alan Bateman]

Thanks for going through the changes, a few comment/replies below.


On 28/11/2016 22:22, Paul Sandoz wrote:

:


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.
Yeah, it's something that I've been looking at too, mostly trying to 
decide whether to reject all array types for now. It is possible to 
specify an array class to Lookup::in but there are issues, it triggers 
at least one one assert that needs attention.




(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.
Thanks, this is clean-up that wasn't done after going through several 
iterations.





:}

Replace with

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


  532 Set requiresTransitive= new HashSet<>();

Formating glitch for “=“


Thanks.




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).

I agree, this could cause a problem in some extreme scenario.




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.
When all loaded then the characteristics come from ArrayList's 
spliterator and so will be ORDERED|SIZED|SUBSIZED. For consistency then 
we limit the above to ORDERED. I've been tempted to do more here but I 
think we need to get some real world usage of this method to see if 
anything is needed (esp. when the #providers is usually small).




:


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() ?

The stream elements are Provider rather than S so it could be 
stream().findFirst().map(Provider::get). The reason it was based on 
iterator is because it pre-dates stream but looking at it now then maybe 
findFirst() should go away as it's trivial to do with the new stream method.


-Alan

Migrating to uses from an existing module system

[Thomas Watson]

I have a usecase where I am attempting to map an existing module system's 
class loaders to JPMS modules by using the Layer API.  In this case the 
existing module system is OSGi.  I have run into an issue when an existing 
OSGi bundle contains code that uses the ServiceLoader.  For the sake of 
discussion the existing code could look like this:

ServiceLoader sl = 
ServiceLoader.load(PrintServiceLookup.class);
System.out.println(sl.findFirst().orElseGet(() -> {return 
null;}));

Without mapping OSGi to JPMS modules this code works fine.  This is 
because the code ends up being loaded by an unnamed module for which JPMS 
assumes is allowed to use any service through the ServiceLoader.  But once 
I map the OSGi bundle class loader to a JPMS module the code above fails 
to work with an exception:

java.util.ServiceConfigurationError: javax.print.PrintServiceLookup: 
module test.service.loader does not declare `uses`

Is there any way around this?  I know there is an addUses method, and I 
also know that I can generate ModuleDescriptors for my Layer that specify 
a proper uses requirement.  But that would require a code scan to discover 
all possible calls to the ServiceLoader in order to declare the uses.

Tom

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

[Mandy Chung]

Thanks Lois.

I removed the blank line.

Mandy

> On Nov 28, 2016, at 6:32 AM, Lois Foltan  wrote:
> 
> 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 

hg: jigsaw/jake/hotspot: Remove blank line - review comment from Lois

[mandy . chung]

Changeset: 85448216fe28
Author:mchung
Date:  2016-11-29 13:36 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/85448216fe28

Remove blank line - review comment from Lois

! src/share/vm/classfile/javaClasses.cpp

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

[Dmitry Samersoff]

Karen,

Sorry for delay. I was on vacation last week.

I plan to review the changes tomorrow.

-Dmitry

On 2016-11-28 17:47, Karen Kinnear wrote:
> Alan,
> 
> I reviewed all the hotspot runtime changes
>  - except the tests (Christian will review those)
>  - and jvmti - which Dmitry Samersoff will review.
> 
> They look good.
> 
> thanks,
> Karen
> 
>> On Nov 28, 2016, at 9:32 AM, Lois Foltan  wrote:
>>
>> 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 

testing for a class having been loaded

[Alan Snyder]

Prior to JDK 9, it was possible (using setAccessible) to ask a ClassLoader 
whether a class with a given name had been loaded without actually forcing it 
to be loaded.

This hack will not work in JDK9, so I am wondering if there is a way to do this?

If not, can someone explain why it would be a bad thing to be able to do this?

Here is my use case:

I have two classes, A and B, that have been designed to be aware of each other, 
but are packaged in separate JAR files or modules that can be loaded 
independently. My goal is for these classes to make a runtime connection with 
each other, but only if both have been loaded by the application.

If each class can at load (initialization) time test whether the other has been 
loaded, then they can use reflection to make that connection.

All of the other solutions I have thought of require yet a third 
class/interface C that is separately packaged and loaded by both A and B. This 
is feasible, but seems unnecessary.

  Alan

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

[Christian Tornqvist]

Hi Alan,

I've reviewed the test changes for Hotspot and they look good.

Thanks,
Christian

-Original Message-
From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-boun...@openjdk.java.net] 
On Behalf Of Alan Bateman
Sent: Thursday, November 24, 2016 10:25 AM
To: jigsaw-dev ; 
hotspot-runtime-...@openjdk.java.net runtime 
; compiler-...@openjdk.java.net
Subject: Code review for jigsaw/jake -> jdk9/dev sync up

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 

Services and Bindings - expected usage scenarios

[Pisarev, Vitaliy]

Another best practices question.

I am aware that the ServiceLoader API is not new to Java. What's new in Java 9 
is that is has been put forward to the front of the stage and it is now very 
easy
for a service provider to register a service.

The thing is that up until now, the ServiceLoader was a relatively low level 
component, primarily used by infrastructure components that loaded plugins that 
implemented various java specs.
It is no surprise than that the ServiceLoader is something that very few ever 
heard of.

Is it the intent of project Jigsaw that the service loader becomes a central 
and ubiquitous mechanism in the day to day work of plain old java developers?
As far as I am concerned, it is a very useful tool even when I do not have a 
plugin architecture and just want a module to expose a certain service via an 
interface without having to jump throw hooks
in order to provide the consumer a way to instantiate it..

Which leads me to the next question: is the returned instance a singleton or a 
prototype?

hg: jigsaw/jake/hotspot: JVMTI AddModuleExports/AddModuleOpens should not intern strings

[alan . bateman]

Changeset: 6f8d3c3028bb
Author:sspitsyn
Date:  2016-11-29 09:18 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6f8d3c3028bb

JVMTI AddModuleExports/AddModuleOpens should not intern strings

! src/share/vm/prims/jvmtiEnv.cpp

RE: Services and Bindings - expected usage scenarios

[Pisarev, Vitaliy]

Remi, good point on the Class.forName. I guess that the main difference is that 
Class.forName requires the concrete type - it is up to the consumer to specify 
(and know) the serviceprovider,
 whereas the SL resolves a request for an interface and the consumer remains 
oblivious of the identity of the provider. In this sense I am referring to the 
ServiceLoader as a ServiceLocator.  

-Original Message-
From: Remi Forax [mailto:fo...@univ-mlv.fr] 
Sent: יום ג 29 נובמבר 2016 21:38
To: Pisarev, Vitaliy 
Cc: jigsaw-dev@openjdk.java.net
Subject: Re: Services and Bindings - expected usage scenarios

DI and SL are two user APIs of a glorified Map between a type and a factory of 
the corresponding runtime type.
DI uses a meta-protocol based on annotations (or javadoc comments :) ) while SL 
uses a more classical API.

The ServiceLoader API is not a Service Locator, the configuration is exposed 
and known statically. With the right jlink plugin you can even never call the 
ServiceLoader API at runtime.

With your definition, is the Classloader API/Class.forName is a Service Locator 
?
and until we can access to invokedynamic in Java which is the only true way to 
implement meta-protocols in Java, all DIs/SLs will suck.

regards,
Rémi

- Mail original -
> De: "Vitaliy Pisarev" 
> À: "mark reinhold" 
> Cc: jigsaw-dev@openjdk.java.net
> Envoyé: Mardi 29 Novembre 2016 18:30:29
> Objet: RE: Services and Bindings - expected usage scenarios

> Thank you mark, this goes far to answer my question.
> 
> I do want to ask you 3 follow-up questions:
> 
> You mentioned that an Application that does not use DI (rare sight 
> nowadays) is definitely encouraged to use ServiceLoader for achieving 
> low coupling between modules. But ServiceLoader is effectively an 
> implementation of the Service Locator pattern, a pattern that is 
> usually counter to DI.
> There is a whole lot of debate between the DI camp and the SL camp 
> online (each claiming the other is an anti-pattern), and it seems that DI is 
> winning.
> 
> By promoting the SL pattern, aren’t you effectively taking a stand in 
> this debate? An SL proponent might say: "Look! The Java architects 
> actually made it part of the language! so it must be superior to DI"
> But of course the validity (or-invalidity) of this sentence comes from 
> your intent, not from the fact.
> 
> Also- what would you say to an application that does use a DI 
> framework? would you say that using an SL in this constellation is 
> inferior or would you justify cases where DI and SL can be applied in 
> conjunction?
> 
> Finally, it seems to me that the gaols of Jigsaw as stated in the JSR 
> are fully met even without the service provider clause in the module 
> declaration.
> Seeing that each feature in the language is astoundingly expensive, 
> you must have had very strong incentive to push for this direction. I 
> wonder what was it that drove you to include this?
> 
> 
> -Original Message-
> From: mark.reinh...@oracle.com [mailto:mark.reinh...@oracle.com]
> Sent: יום ג 29 נובמבר 2016 18:10
> To: Pisarev, Vitaliy 
> Cc: jigsaw-dev@openjdk.java.net
> Subject: Re: Services and Bindings - expected usage scenarios
> 
> 2016/11/29 6:54:35 -0800, vitaliy.pisa...@hpe.com:
>> ...
>> 
>> I am looking at the great features in Java 9 and I know that we are 
>> going to "jump" on the new module system with all the encapsulation 
>> it gives us.  But I and my fellow Architects are very unsure what to 
>> think of the ServiceLoader.
>> 
>> Some of the push-back I get is that it is a "low level component"
>> meant for authors of infrastructure libraries.  Others tell me to 
>> forget about using the ServiceLoader as a Service Locator and stick 
>> to good old Spring. Yet others tell me that the Java Expert group has 
>> actually taken a stand in the "Dependency Injection vs ServiceLocator"
>> debate, by streamlining the ServiceLocator pattern instead of going 
>> with JDK level Dependency Injection.
>> 
>> Discussions are heated, and I figured to go to the source instead of 
>> deducing our own conclusions with so little information.
> 
> I agree largely with what Rémi wrote nearby, though I'd put it a bit 
> differently.
> 
> The Java SE Platform does not, itself, do Dependency Injection, and it 
> almost certainly never will.  Not every application needs DI.
> 
> Java SE should, however, provide the primitives needed by all types of 
> applications, including those that use DI frameworks built on top of it.
> SE modules can therefore identify service users and providers, and the 
> existing SE ServiceLoader API has been enhanced accordingly.
> 
> If you're writing an application without a DI framework but have a 
> need for loose coupling between modules then you should use the 
> ServiceLoader API directly.  If you're using a DI framework then we 
> hope that, over time, DI 

hg: jigsaw/jake/langtools: disentangle exports and opens in javac

[jonathan . gibbons]

Changeset: 55e9018d9f89
Author:jjg
Date:  2016-11-29 17:21 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/55e9018d9f89

disentangle exports and opens in javac

! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java
! src/jdk.compiler/share/classes/com/sun/source/tree/ExportsTree.java
+ src/jdk.compiler/share/classes/com/sun/source/tree/OpensTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java
! src/jdk.compiler/share/classes/com/sun/source/util/SimpleTreeVisitor.java
! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeScanner.java
+ test/tools/javac/diags/examples/ConflictingOpens/exported/Class.java
+ test/tools/javac/diags/examples/ConflictingOpens/module-info.java
+ test/tools/javac/diags/examples/ConflictingOpensToModule/module-info.java
+ test/tools/javac/diags/examples/ConflictingOpensToModule/opened/Class.java
! test/tools/javac/modules/ModuleInfoTest.java
! test/tools/javac/tree/TreeKindTest.java

RE: Services and Bindings - expected usage scenarios

[Pisarev, Vitaliy]

What about the intent behind how are developers supposed to use this tool?

For example, when Optional was introduced in Java 8, it was specified that it 
is intended to be used as a methods return type. And people should not
use it as class member or method argument, even though the compiler will not 
prevent them to. 

Here is a language feature that comes with guidelines as to how it is intended 
to be used.

Can you tell me how the expert group envisions usage of the ServiceLoader in 
Java 9, with reference to the original question (and any other thing you can 
add with regard to this).

-Original Message-
From: Alan Bateman [mailto:alan.bate...@oracle.com] 
Sent: יום ג 29 נובמבר 2016 14:06
To: Pisarev, Vitaliy ; jigsaw-dev@openjdk.java.net
Subject: Re: Services and Bindings - expected usage scenarios

On 29/11/2016 11:35, Pisarev, Vitaliy wrote:

> Another best practices question.
>
> I am aware that the ServiceLoader API is not new to Java. What's new 
> in Java 9 is that is has been put forward to the front of the stage and it is 
> now very easy for a service provider to register a service.
>
> The thing is that up until now, the ServiceLoader was a relatively low level 
> component, primarily used by infrastructure components that loaded plugins 
> that implemented various java specs.
> It is no surprise than that the ServiceLoader is something that very few ever 
> heard of.
>
> Is it the intent of project Jigsaw that the service loader becomes a central 
> and ubiquitous mechanism in the day to day work of plain old java developers?
> As far as I am concerned, it is a very useful tool even when I do not 
> have a plugin architecture and just want a module to expose a certain service 
> via an interface without having to jump throw hooks in order to provide the 
> consumer a way to instantiate it..
>
> Which leads me to the next question: is the returned instance a singleton or 
> a prototype?
Services are a first class part of the module system but are a somewhat 
advanced topic. The ServiceLoader API is part of the story but arguably just a 
small aspect when compared to the architectural and design issues involved in 
moving to services, loose coupling, and improved SoC.

Provider factories can implement singletons where needed, the details are in 
the javadoc [1].

-Alan

[1] http://download.java.net/java/jigsaw/docs/api/index.html

Re: Services and Bindings - expected usage scenarios

[Alan Bateman]

On 29/11/2016 11:35, Pisarev, Vitaliy wrote:


Another best practices question.

I am aware that the ServiceLoader API is not new to Java. What's new in Java 9 
is that is has been put forward to the front of the stage and it is now very 
easy
for a service provider to register a service.

The thing is that up until now, the ServiceLoader was a relatively low level 
component, primarily used by infrastructure components that loaded plugins that 
implemented various java specs.
It is no surprise than that the ServiceLoader is something that very few ever 
heard of.

Is it the intent of project Jigsaw that the service loader becomes a central 
and ubiquitous mechanism in the day to day work of plain old java developers?
As far as I am concerned, it is a very useful tool even when I do not have a 
plugin architecture and just want a module to expose a certain service via an 
interface without having to jump throw hooks
in order to provide the consumer a way to instantiate it..

Which leads me to the next question: is the returned instance a singleton or a 
prototype?
Services are a first class part of the module system but are a somewhat 
advanced topic. The ServiceLoader API is part of the story but arguably 
just a small aspect when compared to the architectural and design issues 
involved in moving to services, loose coupling, and improved SoC.


Provider factories can implement singletons where needed, the details 
are in the javadoc [1].


-Alan

[1] http://download.java.net/java/jigsaw/docs/api/index.html

Re: Services and Bindings - expected usage scenarios

[Alan Bateman]

On 29/11/2016 13:13, Pisarev, Vitaliy wrote:


What about the intent behind how are developers supposed to use this tool?

For example, when Optional was introduced in Java 8, it was specified that it 
is intended to be used as a methods return type. And people should not
use it as class member or method argument, even though the compiler will not 
prevent them to.

Here is a language feature that comes with guidelines as to how it is intended 
to be used.

Can you tell me how the expert group envisions usage of the ServiceLoader in 
Java 9, with reference to the original question (and any other thing you can 
add with regard to this).

Have you looked at Alex's presentation on "Modules and Services" from 
JavaOne 2016 [1]?


-Alan

[1] http://openjdk.java.net/projects/jigsaw/talks/#j1-2016

Re: Services and Bindings - expected usage scenarios

[Jochen Theodorou]

I am not of the expert group, but I would like to give a partial answer.

Let us think of a kind of plugin architecture. There is a public 
interface from your framework and there are other modules that are going 
to provide plugins by implementing that interface. Now assume the 
framework will also instantiate the plugin. This is a problem, because 
normally a plugin is an implementation detail and its only public aspect 
is supposed to be the interface it implements. But to create an instance 
of it, you need to execute a constructor, which would then originate in 
private API.


Thus the ServiceLoader API and the module logic and descriptor got 
extended to support this.


bye Jochen

On 29.11.2016 14:13, Pisarev, Vitaliy wrote:


What about the intent behind how are developers supposed to use this tool?

For example, when Optional was introduced in Java 8, it was specified that it 
is intended to be used as a methods return type. And people should not
use it as class member or method argument, even though the compiler will not 
prevent them to.

Here is a language feature that comes with guidelines as to how it is intended 
to be used.

Can you tell me how the expert group envisions usage of the ServiceLoader in 
Java 9, with reference to the original question (and any other thing you can 
add with regard to this).

-Original Message-
From: Alan Bateman [mailto:alan.bate...@oracle.com]
Sent: יום ג 29 נובמבר 2016 14:06
To: Pisarev, Vitaliy ; jigsaw-dev@openjdk.java.net
Subject: Re: Services and Bindings - expected usage scenarios

On 29/11/2016 11:35, Pisarev, Vitaliy wrote:


Another best practices question.

I am aware that the ServiceLoader API is not new to Java. What's new
in Java 9 is that is has been put forward to the front of the stage and it is 
now very easy for a service provider to register a service.

The thing is that up until now, the ServiceLoader was a relatively low level 
component, primarily used by infrastructure components that loaded plugins that 
implemented various java specs.
It is no surprise than that the ServiceLoader is something that very few ever 
heard of.

Is it the intent of project Jigsaw that the service loader becomes a central 
and ubiquitous mechanism in the day to day work of plain old java developers?
As far as I am concerned, it is a very useful tool even when I do not
have a plugin architecture and just want a module to expose a certain service 
via an interface without having to jump throw hooks in order to provide the 
consumer a way to instantiate it..

Which leads me to the next question: is the returned instance a singleton or a 
prototype?

Services are a first class part of the module system but are a somewhat 
advanced topic. The ServiceLoader API is part of the story but arguably just a 
small aspect when compared to the architectural and design issues involved in 
moving to services, loose coupling, and improved SoC.

Provider factories can implement singletons where needed, the details are in 
the javadoc [1].

-Alan

[1] http://download.java.net/java/jigsaw/docs/api/index.html

RE: Services and Bindings - expected usage scenarios

[Pisarev, Vitaliy]

Yes I have. In fact I've watched the entire series and am following this very 
closely for a time now.
The lecture clearly explains the mechanics and how this works and what we *can* 
do with it, but less about what we *should* (and shouldn’t) do with it. 

I am a System Architect in a very large scale project. As such I have a lot of 
influence on the way and the speed our product assimilates new features.
(For example, I made sure everybody is proficient in lambda/streams even before 
Java 8 was GA so the adoption was smooth and very fast).

I am looking at the great features in Java 9 and I know that we are going to 
"jump" on the new module system with all the encapsulation it gives us.
But I and my fellow Architects are very unsure what to think of the 
ServiceLoader. 

Some of the push-back I get is that it is a "low level component" meant for 
authors of infrastructure libraries. 
Others tell me to forget about using the ServiceLoader as a Service Locator and 
stick
to good old Spring. Yet others tell me that the Java Expert group has actually 
taken a stand in the "Dependency Injection vs ServiceLocator" debate, by 
streamlining 
the ServiceLocator pattern instead of going with JDK level Dependency Injection.

Discussions are heated, and I figured to go to the source instead of deducing 
our own conclusions with so little information.


-Original Message-
From: Alan Bateman [mailto:alan.bate...@oracle.com] 
Sent: יום ג 29 נובמבר 2016 15:24
To: Pisarev, Vitaliy ; jigsaw-dev@openjdk.java.net
Subject: Re: Services and Bindings - expected usage scenarios

On 29/11/2016 13:13, Pisarev, Vitaliy wrote:

> What about the intent behind how are developers supposed to use this tool?
>
> For example, when Optional was introduced in Java 8, it was specified 
> that it is intended to be used as a methods return type. And people should 
> not use it as class member or method argument, even though the compiler will 
> not prevent them to.
>
> Here is a language feature that comes with guidelines as to how it is 
> intended to be used.
>
> Can you tell me how the expert group envisions usage of the ServiceLoader in 
> Java 9, with reference to the original question (and any other thing you can 
> add with regard to this).
>
Have you looked at Alex's presentation on "Modules and Services" from JavaOne 
2016 [1]?

-Alan

[1] http://openjdk.java.net/projects/jigsaw/talks/#j1-2016

Re: Services and Bindings - expected usage scenarios

[Remi Forax]

Hi Vitaliy,

> Is it the intent of project Jigsaw that the service loader becomes a central 
> and
> ubiquitous mechanism in the day to day work of plain old java developers?

You make my day with that sentence :)

More seriously, there are two parts in a dependency injection (DI) mechanism.
The first part, is the user interface, how to get an implementation of a 
service in a field, a parameter, etc. Most of us use libraries that use 
annotations like @Inject and are happy with that. 
The second part is how a DI mechanism gather the implementations of a service, 
here each framework is different even if crawling the code of the whole 
application seems a popular idea.

In a jigsaw world, crawling the whole application make less sense.
It means that:
- the code that crawls the application code has to have some special rights
- after having crawled the whole application, the DI may stop the application 
because there are no implementation of a service.
  So the application can stop at runtime due to a configuration issue.

What the Java Platform Module Spec propose is:
 - to define the directives provides/uses in the module-info makes them part of 
the configuration that can be checked at deployment time. 
 - to enhance the ServiceLoader to 'publish' an implementation of a service 
even if the service impl is not visible.

So in my opinion, the ServiceLoader is not something most of the Java devs will 
interact with directly, but something DI libraries will use internally.

regards,
Rémi

- Mail original -
> De: "Vitaliy Pisarev" 
> À: jigsaw-dev@openjdk.java.net
> Envoyé: Mardi 29 Novembre 2016 12:35:54
> Objet: Services and Bindings - expected usage scenarios

> Another best practices question.
> 
> I am aware that the ServiceLoader API is not new to Java. What's new in Java 9
> is that is has been put forward to the front of the stage and it is now very
> easy
> for a service provider to register a service.
> 
> The thing is that up until now, the ServiceLoader was a relatively low level
> component, primarily used by infrastructure components that loaded plugins 
> that
> implemented various java specs.
> It is no surprise than that the ServiceLoader is something that very few ever
> heard of.
> 
> Is it the intent of project Jigsaw that the service loader becomes a central 
> and
> ubiquitous mechanism in the day to day work of plain old java developers?
> As far as I am concerned, it is a very useful tool even when I do not have a
> plugin architecture and just want a module to expose a certain service via an
> interface without having to jump throw hooks
> in order to provide the consumer a way to instantiate it..
> 
> Which leads me to the next question: is the returned instance a singleton or a
> prototype?

Re: Services and Bindings - expected usage scenarios

[mark . reinhold]

2016/11/29 6:54:35 -0800, vitaliy.pisa...@hpe.com:
> ...
> 
> I am looking at the great features in Java 9 and I know that we are
> going to "jump" on the new module system with all the encapsulation it
> gives us.  But I and my fellow Architects are very unsure what to
> think of the ServiceLoader.
> 
> Some of the push-back I get is that it is a "low level component"
> meant for authors of infrastructure libraries.  Others tell me to
> forget about using the ServiceLoader as a Service Locator and stick to
> good old Spring. Yet others tell me that the Java Expert group has
> actually taken a stand in the "Dependency Injection vs ServiceLocator"
> debate, by streamlining the ServiceLocator pattern instead of going
> with JDK level Dependency Injection.
> 
> Discussions are heated, and I figured to go to the source instead of
> deducing our own conclusions with so little information.

I agree largely with what Rémi wrote nearby, though I'd put it a bit
differently.

The Java SE Platform does not, itself, do Dependency Injection, and it
almost certainly never will.  Not every application needs DI.

Java SE should, however, provide the primitives needed by all types of
applications, including those that use DI frameworks built on top of it.
SE modules can therefore identify service users and providers, and the
existing SE ServiceLoader API has been enhanced accordingly.

If you're writing an application without a DI framework but have a need
for loose coupling between modules then you should use the ServiceLoader
API directly.  If you're using a DI framework then we hope that, over
time, DI frameworks will leverage the ServiceLoader API as appropriate.
That change is, however, not something that those of us who work on the
module system can make ourselves; we can only enable and encourage it.

- Mark

hg: jigsaw/jake/jdk: 3 new changesets

[alan . bateman]

Changeset: 364508692927
Author:alanb
Date:  2016-11-29 13:59 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/364508692927

jar --print-module-descriptor should handle open module/packages

! src/jdk.jartool/share/classes/sun/tools/jar/Main.java

Changeset: 471f9aaac991
Author:alanb
Date:  2016-11-29 14:00 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/471f9aaac991

Disallow array classes for now

! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! 
test/java/lang/invoke/MethodHandles/privateLookupIn/test/p/PrivateLookupInTests.java

Changeset: c759df7225d6
Author:alanb
Date:  2016-11-29 14:05 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c759df7225d6

More cleanups based on review comments

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

hg: jigsaw/jake/jdk: Add --{help, help-extra, version, full-version, show-version} launcher options to print to stdout

[mark . reinhold]

Changeset: 9e5ecc1ee202
Author:mr
Date:  2016-11-29 07:35 -0800
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9e5ecc1ee202

Add --{help,help-extra,version,full-version,show-version} launcher options to 
print to stdout

! src/java.base/share/classes/java/lang/VersionProps.java.template
! src/java.base/share/classes/sun/launcher/resources/launcher.properties
! src/java.base/share/native/libjli/java.c
! src/java.base/share/native/libjli/java.h
+ test/tools/launcher/InfoStreams.java

hg: jigsaw/jake: Adjusted workaround for javafx import with new module-info format

[erik . joelsson]

Changeset: 891ed56bc4da
Author:erikj
Date:  2016-11-29 17:52 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/891ed56bc4da

Adjusted workaround for javafx import with new module-info format

! make/common/Modules.gmk

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

[Andrey Nazarov]

Hi,

I’ve reviewed Langtools code.

There are various comment “//TODO”, “//FIXME”, “//XXX”. I think they should be 
revised. May be issues should be filed to track them.
Unused import at 37 import java.io.IOException; in 
langtools/test/tools/javac/modules/ModuleInfoTest.java
ASCII graphics issue at 64 line in test/tools/javac/modules/GraphsTest.java
Unused builder method in langtools/test/tools/lib/toolbox/ModuleBuilder.java
159 public ModuleBuilder exportsDynamicPrivate(String pkg) {
141 public ModuleBuilder exportsDynamic(String pkg) {
179 public ModuleBuilder exportsDynamicTo(String pkg, String module) {
199 public ModuleBuilder exportsDynamicPrivateTo(String pkg, String module) 
{

Javadoc is used instead of comment 
langtools/test/tools/javac/modules/AnnotationsOnModules.java
 /**
  25  * @test



—Andrey
> On 24 Nov 2016, at 18: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. 

hg: jigsaw/jake/jdk: Fixed typo in javadoc

[alan . bateman]

Changeset: 32c356a9f79c
Author:alanb
Date:  2016-11-29 17:41 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/32c356a9f79c

Fixed typo in javadoc

! src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java