> On Dec 18, 2015, at 4:44 PM, Alex Buckley wrote:
...
> So let's recap full power lookups:
>
> - Start with an arbitrary class in an arbitrary module calling
> MethodHandles.Lookup.lookup() to get a "full power" lookup object L. L's
> lookup modes are PUBLIC + QUALIFIED + MODULE + PROTECTED +
On 12/18/2015 12:20 AM, John Rose wrote:
On Dec 17, 2015, at 6:01 PM, John Rose mailto:john.r.r...@oracle.com>> wrote:
I think I would prefer case 2. The user model is PUBLIC is the
weakest (non-empty) access mode available to bytecode behaviors. As
such it respects the LC's position in the mod
On Dec 17, 2015, at 6:01 PM, John Rose wrote:
>
> I think I would prefer case 2. The user model is PUBLIC is the weakest
> (non-empty) access
> mode available to bytecode behaviors. As such it respects the LC's position
> in the module
> graph, and excludes module-private, package-private, an
On Dec 17, 2015, lookup modest 12:44 PM, Alex Buckley
wrote:
>
> … please consider the following design:
>
> - PUBLIC lookup mode means:
>
> Any 'public' type of any package exported unconditionally by the package's
> module.
Accessing those is the uniquely special power of PL=publicLookup,
On Dec 14, 2015, at 7:02 AM, Alan Bateman wrote:
> ...
> In graph terms then the vertices in the readability graph are the modules. A
> directed edge from module M to module M2 means that M reads M2. The graph is
> mutable in that edges can be added via the API at runtime. Code in module M
> ca
Hi John,
On 12/11/2015 12:38 PM, John Rose wrote:
That's fine. There are two main use cases for Lookup.in,
neither of which require the tracking of long chains of L.in(A/B/C…).
A. Agent with full-power lookup wants to invoke another agent with the lookup,
but wants to limit access, because he
On 11/12/2015 20:38, John Rose wrote:
:
2. downward monotonic
2a. L.in(A) never has more privileges than L (for all L, A)
2b. L.in(A) never has more privileges than a full power lookup on A
(for all L, A)
2c. as a corollary, a chain L.in(A).in(B).in(C)… has no more
privileges than L or an
On Dec 11, 2015, at 6:02 AM, Alan Bateman wrote:
>
> John,
>
> Thanks for jumping in on this and the guidance. Comments inline.
Nice, thanks.
>
>
> On 10/12/2015 23:08, John Rose wrote:
>>
>> This stuff makes my head hurt, but I'm fine with any semantics that
>> preserves the following:
>>
John,
Thanks for jumping in on this and the guidance. Comments inline.
On 10/12/2015 23:08, John Rose wrote:
This stuff makes my head hurt, but I'm fine with any semantics that
preserves the following:
1. full power: MethodHandles.lookup() has the same privileges as
(non-constructor) byte
On 10/12/2015 19:20, stanislav lukyanov wrote:
This is connected to the second part of the question (2).
If access to readable modules were allowed only if MODULE bit is set,
transition from A to B would be safe, since only one transition could
be made (actually, same as it is now, but not fro
On Dec 10, 2015, at 11:20 AM, stanislav lukyanov
wrote:
>
> Alan,
> thanks for the comments!
> Please see below.
>
> On 10.12.2015 1:16, Alan Bateman wrote:
>>
>> On 09/12/2015 14:54, stanislav lukyanov wrote:
>>>
>>> 1) Lookup.in() javadoc says
>>> "If the lookup for this Lookup is in a name
Alan,
thanks for the comments!
Please see below.
On 10.12.2015 1:16, Alan Bateman wrote:
On 09/12/2015 14:54, stanislav lukyanov wrote:
1) Lookup.in() javadoc says
"If the lookup for this Lookup is in a named module, and the new
lookup class is in a different
module M, then no members, not e
On 09/12/2015 14:54, stanislav lukyanov wrote:
1) Lookup.in() javadoc says
"If the lookup for this Lookup is in a named module, and the new
lookup class is in a different
module M, then no members, not even public members in M's exported
packages, will be accessible"
However, it seems to be
Hi Alan and Jigsaw Team,
I have questions regarding Jigsaw-related updates in MethodHandles.Lookup.
1) Lookup.in() javadoc says
"If the lookup for this Lookup is in a named module, and the new lookup
class is in a different
module M, then no members, not even public members in M's exported
pac
14 matches
Mail list logo
