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 26/09/2016 18:19, Martin Lehmann wrote:
Hi all,
the new #VersionsInModuleNames seems to be active in JDK9 b136 already.
Switching to b136 breaks the build in one of our examples of our Java9
Jigsaw example suite, cf Github:
https://github.com/accso/java9-jigsaw-examples/tree/master/jigsaw-ex
Hi all,
the new #VersionsInModuleNames seems to be active in JDK9 b136 already.
Switching to b136 breaks the build in one of our examples of our Java9
Jigsaw example suite, cf Github:
https://github.com/accso/java9-jigsaw-examples/tree/master/jigsaw-examples/e
xample_automatic-module-logging
In
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 /
> #AwkwardStrongEncapsulation)
> Having read this proposal
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
On 26.09.2016 11:25, Neil Bartlett wrote:
Module is already in the name: “java.lang.module.Configuration”. Wouldn’t
“java.lang.module.ModuleConfiguration” look really odd?
ah, you mean like List is enough for java.util.List and java.awt.List?
Configuration is a really common name in project
Most coding only uses the simple name, not the fully qualified one,
and Configuration does occur in other projects [1].
The original poster referred to the package, where Configuration is
the only non-exception class that does not have "Module" in the name
[2].
Stephen
[1]
https://commons.apach
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
>
Module is already in the name: “java.lang.module.Configuration”. Wouldn’t
“java.lang.module.ModuleConfiguration” look really odd?
Neil
> On 21 Sep 2016, at 16:18, Stephen Colebourne wrote:
>
> I had the same thought while watching the slides. Configuration is
> certainly a class name that exis
On 21/09/2016 12:45, Richard Opalka wrote:
+1
I'd also propose FindException -> ModuleNotFoundException
Keep in mind that find/findAll throw FindException for a slew of
reasons, the "not found" case is just one.
-Alan.
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
16 matches
Mail list logo