Re: RFR: 8159523. Fix tests depending on absence of -limitmods in VM arguments.

2016-10-11 Thread Alexandre (Shura) Iline
> On Oct 11, 2016, at 1:35 PM, Alexandre (Shura) Iline > wrote: > > >> On Oct 10, 2016, at 2:54 AM, Alan Bateman wrote: >> >> On 07/10/2016 21:24, Alexandre (Shura) Iline wrote: >> >>> Hi, >>> >>> Please review a fix for

Re: RFR: 8159523. Fix tests depending on absence of -limitmods in VM arguments.

2016-10-11 Thread Alexandre (Shura) Iline
> On Oct 10, 2016, at 2:54 AM, Alan Bateman wrote: > > On 07/10/2016 21:24, Alexandre (Shura) Iline wrote: > >> Hi, >> >> Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8159523 >> >> To recap what has happened in the past. >> >> 1. An attempt was

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

2016-10-11 Thread John Rose
On Sep 29, 2016, at 2:29 AM, Remi Forax wrote: > > This bug only talk about the callee side, i.e. accessing to a non accessible > class by a framework. > The other part, the caller side, is to have a way to emit a call that send > the caller lookup to a framework, > the easy

Re: Module names - related to #ModuleNameSyntax

2016-10-11 Thread Robert Scholte
One thing that is missing here is that you can only control the direct dependencies, you cannot control the transitive dependencies. To complete the example: module com.mycompany:foo-utils { requires guava; // automodule from google } but we also have module com.acme:bar-utils { requires

Re: Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports

2016-10-11 Thread Stephen Colebourne
On 11 October 2016 at 16:14, wrote: > A couple of other problems I see with Colebourne's approach: > > - The only way to allow an exported API package to be used reflectively > is to expose it for deep reflection. That requires typing another > directive and,

hg: jigsaw/jake/jdk: 5 new changesets

2016-10-11 Thread alan . bateman
Changeset: df7ccf4aeb8f Author:alanb Date: 2016-10-07 12:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/df7ccf4aeb8f Fixed typo in Class.getResource comment ! src/java.base/share/classes/java/lang/Class.java Changeset: 44f3fff212d5 Author:alanb Date:

Lack of "export dynamic" requires to export everything for existing frameworks

2016-10-11 Thread Nikita Lipsky
I believe it would be better to introduce a concept of "privileged module" instead of introducing "weak module" concept. "privileged module" can reflect on any unexported (and exported) type of other resolved modules of a layer that it belongs to. In addition, we can introduce command line flags