> 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
> 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
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
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
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,
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:
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