Re: #VersionsInModuleNames too restrictive (cuts of too much)

2016-09-26 Thread Alan Bateman
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:

#VersionsInModuleNames too restrictive (cuts of too much)

2016-09-26 Thread Martin Lehmann
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

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

2016-09-26 Thread Eric Johnson
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

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

2016-09-26 Thread Andrew Dinn
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 >>

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

2016-09-26 Thread Remi Forax
+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 / >

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

2016-09-26 Thread Alan Bateman
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

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

2016-09-26 Thread Andrew Dinn
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: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

2016-09-26 Thread Alan Bateman
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

Re: Class names in java.lang.Module

2016-09-26 Thread Jochen Theodorou
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

Re: Class names in java.lang.Module

2016-09-26 Thread Stephen Colebourne
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]

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

2016-09-26 Thread Stephen Colebourne
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

Re: Class names in java.lang.Module

2016-09-26 Thread Alan Bateman
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.

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

2016-09-26 Thread Alan Bateman
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