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 way to do that is t
On 09/29/2016 07:31 AM, Peter Levart wrote:
Hi David,
I'm not the one to answer your queries, but may I ask you some questions
about your requirements and also give some comments...
On 09/28/2016 02:13 PM, David M. Lloyd wrote:
Hi all, I've been requested to ask if the OpenJDK development team
Hi David,
I'm not the one to answer your queries, but may I ask you some questions
about your requirements and also give some comments...
On 09/28/2016 02:13 PM, David M. Lloyd wrote:
Hi all, I've been requested to ask if the OpenJDK development team
have had a chance to review this email, an
ot;Andrew Dinn"
> Cc: "jigsaw-dev"
> Envoyé: Mercredi 28 Septembre 2016 20:09:00
> Objet: Re: Alternative mechanism for reflective access control
> (#ReflectiveAccessToNonExportedTypes /
> #AwkwardStrongEncapsulation)
> On 28/09/2016 13:22, Andrew Dinn wr
On 28/09/16 19:09, Alan Bateman wrote:
> On 28/09/2016 13:22, Andrew Dinn wrote:
>> I'd be happy to try to conduct such an experiment. Can you provide links
>> to the relevant JIRAs.
> The javadoc for MethodsHandes.Lookup is probably the best place to
> start, assuming you haven't used it before. T
On 09/28/2016 07:01 AM, Alan Bateman wrote:
On 28/09/2016 10:37, Gunnar Morling wrote:
:
I don't think that is what those folks asking about using the SM had
in mind.
Rather, the idea would be - IIUC - to grant code in module B (say an
ORM tool) reflective access to non-exported (and of cours
On 28/09/2016 13:22, Andrew Dinn wrote:
:
I'd be happy to try to conduct such an experiment. Can you provide links
to the relevant JIRAs.
The javadoc for MethodsHandes.Lookup is probably the best place to
start, assuming you haven't used it before. This has a good section to
explain how access
On Wed, Sep 28, 2016 at 1:01 PM, Alan Bateman wrote:
> On 28/09/2016 10:37, Gunnar Morling wrote:
>
>> :
>>
>> I don't think that is what those folks asking about using the SM had in
>> mind.
>>
>> Rather, the idea would be - IIUC - to grant code in module B (say an ORM
>> tool) reflective access
On 28/09/16 13:01, Alan Bateman wrote:
> In general then I think that we need to find ways to reduce the use of
> setAccessible over time. We really need a long term plan to degrade,
> deprecate and eventually remove it. This would of course mean working on
> some challenging problems and use-cases
Hi all, I've been requested to ask if the OpenJDK development team have
had a chance to review this email, and when we might expect a response.
Thanks!
On 09/21/2016 11:39 AM, David M. Lloyd wrote:
In our internal discussion of the proposal for
#ReflectiveAccessToNonExportedTypes, we discussed
On 28/09/2016 10:37, Gunnar Morling wrote:
:
I don't think that is what those folks asking about using the SM had
in mind.
Rather, the idea would be - IIUC - to grant code in module B (say an
ORM tool) reflective access to non-exported (and of course exported)
types in module A (say a modu
On 09/28/2016 04:37 AM, Gunnar Morling wrote:
If I'm compiling a class A that has a reference to a member in type B
then do you really want the compiler calling into a security manager to
ask if this access is allowed?
I don't think that is what those folks asking about using the SM had in
min
On 09/28/2016 05:31 AM, Gunnar Morling wrote:
David,
there is too much existing work out there, and the requirements go far
beyond
what can be satisfied by these simple questions.
What are examples for such requirements? I.e. what from the list of your
requirements cannot be mapped to the m
David,
> there is too much existing work out there, and the requirements go far
beyond
> what can be satisfied by these simple questions.
What are examples for such requirements? I.e. what from the list of your
requirements cannot be mapped to the mechanism suggested by Stephen? I find
his propos
> If I'm compiling a class A that has a reference to a member in type B
> then do you really want the compiler calling into a security manager to
> ask if this access is allowed?
I don't think that is what those folks asking about using the SM had in
mind.
Rather, the idea would be - IIUC - to g
Hi Stephen,
I just want to point out that this isn't a proposal per se. I don't
advocate any particular syntax, nor recommendation for patterns that
users should use. This is merely a set of requirements that we (Red
Hat) have identified as necessary in order to enable the widest range of
e
On 27/09/16 12:34, Alan Bateman wrote:
> On the specific topic of using the security manager to do JLS and JVMS
> specified access checks then it doesn't make any sense to me. If I'm
> compiling a class A that has a reference to a member in type B then do
> you really want the compiler calling into
On 26/09/2016 17:37, Andrew Dinn wrote:
:
That's very good to hear, because your previous phrasing certainly
brought that commitment into question. As I am afraid does your
continued unwillingness to provide motivation for why the current Jigsaw
implementation operates in the way it does.
n.b.
On 27.09.2016 13:01, dalibor topic wrote:
On 27.09.2016 12:03, Andrew Dinn wrote:
Yes we could use braces instead of a
belt, but why do we /need/ braces when we can already wear a belt?
I don't think that it's an either one or another proposition,
Although the developing fashion sense in
On 27.09.2016 12:03, Andrew Dinn wrote:
Yes we could use braces instead of a
belt, but why do we /need/ braces when we can already wear a belt?
I don't think that it's an either one or another proposition,
Although the developing fashion sense in some countries dictated going
with either on
- Mail original -
> De: "Andrew Dinn"
> À: "Alan Bateman"
> Cc: jigsaw-dev@openjdk.java.net
> Envoyé: Lundi 26 Septembre 2016 13:36:46
> Objet: Re: Alternative mechanism for reflective access control
> (#ReflectiveAccessToNonExporte
On 27/09/16 10:27, dalibor topic wrote:
> On 26.09.2016 18:37, Andrew Dinn wrote:
[snip]
>> I think those involved in this discussion already know all that you have
>> stated here regarding /what/ this project is doing. The present question
>> is /why/ is something that it is doing needed.
>
> P
On 26.09.2016 18:37, Andrew Dinn wrote:
On 26/09/16 14:19, Alan Bateman wrote:
On 26/09/2016 12:36, Andrew Dinn wrote:
:
I addressed that in the text you snipped. The one point of relevance is
that which the original poster asked about:
-- Why do we need Jigsaw to constrain access control
On 26.09.2016 05:50, GREGG WONDERLY wrote:
What’s odd, is that you are still trying to block access to reflective
access to the “open JDK”.
If it’s really open
The term "open" in the context of community names typically refers to
open source, as defined by the Open Source Definition, which
On 9/25/16 8:50 PM, GREGG WONDERLY wrote:
I still, like others seem to, find it amazingly odd, that the security manager,
existing basis for access control is not still what would count.
I'm with you there. I'm fascinated that this thread has triggered
references to the "legacy" security manage
On 26/09/16 14:19, Alan Bateman wrote:
> On 26/09/2016 12:36, Andrew Dinn wrote:
>
>> :
>> I addressed that in the text you snipped. The one point of relevance is
>> that which the original poster asked about:
>>
>>-- Why do we need Jigsaw to constrain access control when we can do so
>> using
+1
Rémi
- Mail original -
> De: "Stephen Colebourne"
> À: "jigsaw-dev"
> Envoyé: Lundi 26 Septembre 2016 12:11:58
> Objet: Re: Alternative mechanism for reflective access control
> (#ReflectiveAccessToNonExportedTypes /
> #AwkwardSt
On 26/09/2016 12:36, Andrew Dinn wrote:
:
I addressed that in the text you snipped. The one point of relevance is
that which the original poster asked about:
-- Why do we need Jigsaw to constrain access control when we can do so
using a security manager?
Do you (or anyone else involved in d
On 26/09/16 12:11, Alan Bateman wrote:
> On 26/09/2016 10:28, Andrew Dinn wrote:
>
>> :
>> I'm sorry, Alan ,but I think that is disingenuous. When we see "access
>> control" on this list all of us really ought to bear in mind what have
>> been the de facto access control mechanisms for many JDK re
On 26/09/2016 10:28, Andrew Dinn wrote:
:
I'm sorry, Alan ,but I think that is disingenuous. When we see "access
control" on this list all of us really ought to bear in mind what have
been the de facto access control mechanisms for many JDK releases and
many more years. There are two such levels
Having read this proposal a number of times, and considering how the
talks explained things at JavaOne, I have come to the conclusion that
this proposal is too complex. FWIW, I like the idea that a module
should be able to declare that it needs reflective access from its
users, however given that t
On 26/09/16 09:19, Alan Bateman wrote:
> On 26/09/2016 04:50, GREGG WONDERLY wrote:
>
>> I still, like others seem to, find it amazingly odd, that the security
>> manager, existing basis for access control is not still what would
>> count. I understand that the JDK itself is not deployed with a
>
On 26/09/2016 04:50, GREGG WONDERLY wrote:
I still, like others seem to, find it amazingly odd, that the security manager,
existing basis for access control is not still what would count. I understand
that the JDK itself is not deployed with a security manager impl in most cases,
and thus th
I still, like others seem to, find it amazingly odd, that the security manager,
existing basis for access control is not still what would count. I understand
that the JDK itself is not deployed with a security manager impl in most cases,
and thus there would be no access context for the securit
In our internal discussion of the proposal for
#ReflectiveAccessToNonExportedTypes, we discussed the ins and outs of
various behaviors and have come up with a few ideas or starting points
for solutions that we think would be more workable in conjunction with
existing middleware (ours and others
35 matches
Mail list logo