Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

(Finally getting back to this thread, now that vacation season is over.) 2016/7/21 10:01:11 -0700, jason.gre...@redhat.com: > On Jul 18, 2016, at 4:30 PM, mark.reinh...@oracle.com wrote: >> 2016/7/13 20:27:45 -0700, jason.gre...@redhat.com: >>> ... >>> >>> Sorry for the confusion, what I was

Re: Widespread use of reflection, [was Feedback on proposal for #ReflectiveAccessToNonExportedTypes]

On 27.07.2016 13:28, Stephen Colebourne wrote: In summary, restricting reflection/setAccessible would effectively be signing the death warrant of Java As entertaining as it is to read Cassandric ruminations about the imminent death of Java (and almost nothing [0] says 'Summer is here,

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

On 23/07/2016 01:32, Jason Greene wrote: : This was intended to mirror the same structure as the original example as well: A exports dynamic bar, and B exports bar, and also all modules are following a class loader per module paradigm. I had a follow-up that corrected this, it should have

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

Hi, Just one thougt... It seems that visibility of resources should be governed by some module policy. It is becoming apparent that global visibility of resources where only class loader delegation matters can sometimes be a problem. OTOH, totally encapsulating all resources is also not

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

> On Jul 21, 2016, at 3:45 PM, Alan Bateman wrote: > > Just a few comments on the examples posed in the last mail. Thanks! > > > On 21/07/2016 18:01, Jason Greene wrote: >> : >> That would help, but there is also class visibility issues that would need >> to be

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

Just a few comments on the examples posed in the last mail. On 21/07/2016 18:01, Jason Greene wrote: : That would help, but there is also class visibility issues that would need to be addressed as well. Example 1 (Ambiguous class names): Both A and B export “bar”, and both define

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

> On Jul 21, 2016, at 12:01 PM, Jason Greene wrote: > > >> On Jul 18, 2016, at 4:30 PM, mark.reinh...@oracle.com wrote: >> > > Hi Mark, Thanks for the reply. I have snipped out portions to make it easier > to follow the thread. > >>> >>> I agree they are certainly

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

> On Jul 18, 2016, at 4:30 PM, mark.reinh...@oracle.com wrote: > Hi Mark, Thanks for the reply. I have snipped out portions to make it easier to follow the thread. >> >> I agree they are certainly intermixed elements of a system, but I’d also >> argue IoC is pervasive in SE applications as

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

2016/7/13 16:15:33 -0700, peter.lev...@gmail.com: > On 07/13/2016 11:47 PM, mark.reinh...@oracle.com wrote: >> ... >> >> If the container is set up to provide, e.g., Hibernate to this particular >> application, then it could narrow the accessibility of the entity classes >> by rewriting the above

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

2016/7/13 20:27:45 -0700, jason.gre...@redhat.com: > Thanks for you reply! My thoughts are inline. I apologize in advance for > the length/verbosity. Also, as a general disclaimer, I realize that you > are all experts; in many of my arguments, I occaisionally restate certain > concepts that I know

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

So how about a Java Language annotation (say, @RequiresExport) that we could place on IoC framework annotation definitions (say, @Entity, from JPA) that would tell the compiler that any type annotated with @Entity must be exported? That would solve the issue of making sure that users would

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

> On Jul 13, 2016, at 4:47 PM, mark.reinh...@oracle.com wrote: > > Jason -- thanks for your feedback on this topic. Hi Mark, Thanks for you reply! My thoughts are inline. I apologize in advance for the length/verbosity. Also, as a general disclaimer, I realize that you are all experts; in

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

Hi, I have a question about the following ... On 07/13/2016 11:47 PM, mark.reinh...@oracle.com wrote: To point (2), if some packages in a user module need to be exported for reflection at run time, and a container wishes to ensure that only select "trusted" framework modules can access the

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

Jason -- thanks for your feedback on this topic. To put what Alex wrote in a somewhat different way, I'd say that the tension here is between explicit configuration (as one finds today in, e.g., the Maven world) and implicit configuration (IoC). Both approaches are important. The former is

Re: A different feedback on proposal for #ReflectiveAccessToNonExportedTypes

Hi Peter, On 12/07/16 17:51, Peter Levart wrote: > I'll try to question the proposal for > #ReflectiveAccessToNonExportedTypes from a different angle. Thanks you for doing so. This is a very helpful summary of the issues at stake here and I find your proposal interesting although I don't think I

A different feedback on proposal for #ReflectiveAccessToNonExportedTypes

Hi, I'll try to question the proposal for #ReflectiveAccessToNonExportedTypes from a different angle. The proposal extends the language of module declaration with "exports dynamic" variant of export. Like classical plain "exports", the dynamic variant comes in unqualified and qualified

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

On 12/07/2016 10:28, Andrew Dinn wrote: : I think I need to ask you to clarify this as it doesn't seem to recognise the point I was making. Of course, that may well indicate that I have failed to understand the precise behaviour of exports dynamic. Let us assume Module M exports dynamic P,

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

On 11/07/16 12:02, Alan Bateman wrote: >> That option may well be the status quo as of JDK8 but with JDK9 it is >> the status quo in a changed world. Firstly, this so-called status quo >> significantly undermines the point and utility of Jigsaw since >> effectively it negates it's presence at

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

On 11/07/2016 10:41, Andrew Dinn wrote: : I don't think there is any confusion here other that that you have failed to note an important part of what is being asked for and, in consequence, recognise why that request was made. Jason, Paul and I all said we would like to see some sort of

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

On 09/07/16 22:22, Alan Bateman wrote: > Hence the `exports dynamic` proposal. There is a lot of confusion in > this thread and it might be useful if someone could try out a scenario > with an injectable constructor or method on a type in an otherwise > non-exported package. That might help get

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

Hi, in my opinion, the problem here is that there are two types of use cases that need a different "default" behavior with respect to exporting packages in runtime and if we decide to use the current behavior, the use cases that need to export everything by default in runtime can lead to

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

On 09/07/2016 12:22, Jochen Theodorou wrote: ok, let us assume I want to write a library that does what reflection can do today using bytecode generation. And let us assume I write a library, that will use this reflective module to call from private API to private API. How do we configure

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

Alan, but that is extra configuration in the module, as I have pointed out. The whole idea I have to opt someone into fuller reflection is taking control too far. I'm also advocating this is not the responsibility of the module to control reflection. What I have proposed using the Security Manager

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

On 09/07/2016 21:28, Paul Benedict wrote: The argument I'm making is not just someone really wants to do this, but that many people won't settle without it. Reflection has always been the tool to dynamically achieve what the Java language can't always express statically. IoC is built on the

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

Paul Benedict wrote: For those who are still supporters of preventing non-exported types from being reflected, I think a compromise can still be found, but it's not in this proposal. Here are two other alternatives I hope the EG will consider: 1) Introduce a new permission type to allow

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

The argument I'm making is not just someone really wants to do this, but that many people won't settle without it. Reflection has always been the tool to dynamically achieve what the Java language can't always express statically. IoC is built on the notion that language boundaries can and should

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

Alan Bateman wrote: On 09/07/2016 09:57, Simon Nash wrote: Is it really a good idea to encourage packages that currently use reflection to access non-exported private fields (an official part of the Java API) to change to using internal APIs? This seems like a step backwards to me. I

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

On 09.07.2016 09:50, Alan Bateman wrote: [...] As regards "enjoy special power" then the only module that is known to the VM and module system is "java.base". The java.base module, as you probably know, is the core of the system. The java.base modules has the VM, java.lang.**, the implementation

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

On 09/07/2016 09:57, Simon Nash wrote: Is it really a good idea to encourage packages that currently use reflection to access non-exported private fields (an official part of the Java API) to change to using internal APIs? This seems like a step backwards to me. I didn't suggest that. I

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

Alan Bateman wrote: On 09/07/2016 08:46, Simon Nash wrote: I think this a very important point. If someone wanted to reimplement Java serialization (java.io.ObjectOutputStream, etc.) as an external library (com.foo.ObjectOutputStream, etc.), the new restrictions on reflective access in JDK

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

On 09/07/2016 08:46, Simon Nash wrote: I think this a very important point. If someone wanted to reimplement Java serialization (java.io.ObjectOutputStream, etc.) as an external library (com.foo.ObjectOutputStream, etc.), the new restrictions on reflective access in JDK 9 would prevent this.

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

On 08/07/2016 22:42, Paul Benedict wrote: : 2) Allow layers to control if non-exported types can be reflected. Perhaps the JDK sets its own layers to "false", but Containers and what they deploy can be separately configured, each. A container or anything else doing dynamic configuration

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

Jason Greene wrote: There is also a disparity here that the JDK itself doesn’t require you to export packages (e.g. I don’t need it for Java serialization). Now I realize that there is an effort underway to de-privilege modules, but I suspect that a portion of the JDK will continue to enjoy

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

The practical matter is simply that all of this name visibility business is just entirely the wrong thing to be managing “modules” around. Instead, modules should be things that are more easily managed with tools that facilitate things that container systems will want to do. Modularity as a

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

For those who are still supporters of preventing non-exported types from being reflected, I think a compromise can still be found, but it's not in this proposal. Here are two other alternatives I hope the EG will consider: 1) Introduce a new permission type to allow non-exported types to be

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

> On Jul 7, 2016, at 5:31 PM, Paul Benedict wrote: > > If this restriction stays (and I am really hoping it doesn't), my next best > hope is for Containers like WildFly, Tomcat, SpringBoot etc. to enable me to > do this. If the Layer has a hook into amending the Module

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

> On Jul 7, 2016, at 5:10 PM, Alex Buckley wrote: > > Hi Jason, Hi Alex, Thank you for the thoughtful reply, I have included some debate below. > > On 7/7/2016 1:17 PM, Jason Greene wrote: >> I wanted to second Paul’s comments on jams-spec-comments[1], but with >>

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

On 08/07/2016 13:46, Andrew Dinn wrote: : Jason addressed some of this in his post -- the nub (but definitely not the total) of his points is in this paragraph "This brings us to the problem with the proposal. The expectation AFAICT appears to be that the user defining the enhanced code knows

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

On 08/07/16 10:16, Alan Bateman wrote: > > On 08/07/2016 09:39, Sander Mak wrote: >> That is, define your module-info's, possibly containing dynamic >> exports if your framework of choice does its magic through reflection. >> > Right and there is nothing in this proposal that is specific to core >

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

Hi, Putting my user's hat on, I'm interested in a solution which a) fulfils my desire to hide types internal to my implementation as much as possible (that's why I'm using a module system after all) and b) still is easy to use. Looking at the proposal, I feel adding *un-qualified* dynamic

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

On 08/07/2016 09:39, Sander Mak wrote: That is, define your module-info's, possibly containing dynamic exports if your framework of choice does its magic through reflection. Right and there is nothing in this proposal that is specific to core reflection either. The framework that I am using

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

On 07/07/2016 23:31, Paul Benedict wrote: : If this restriction stays (and I am really hoping it doesn't), my next best hope is for Containers like WildFly, Tomcat, SpringBoot etc. to enable me to do this. If the Layer has a hook into amending the Module Descriptor, then I am hoping each

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

> On 08 Jul 2016, at 10:04, Andrew Dinn wrote: > > Applying your > logic to the status quo ante and deriving JDK9 will break the most > significant body of code that is built on Java in a way that, as Jason > argues, is /in practice/ impossible to undo. How so? The classpath

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

On 07/07/16 23:31, Paul Benedict wrote: > It should be pointed out that the only reason IoC containers can succeed > with setAccessible() is because developers commonly run without the > Security Manager enabled. People who use IoC want to this circumvention on > purpose. It's not an oversight --

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

Hi Alex, Your rationale is very logical. The flaw I see in your argument is not that it makes invalid inferences, rather that it is based on wrong premises. Indeed, that flaw is visible in the result. Applying your logic to the status quo ante and deriving JDK9 will break the most significant

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

It should be pointed out that the only reason IoC containers can succeed with setAccessible() is because developers commonly run without the Security Manager enabled. People who use IoC want to this circumvention on purpose. It's not an oversight -- it's intended. As far as I am concerned, if

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

Hi Jason, On 7/7/2016 1:17 PM, Jason Greene wrote: I wanted to second Paul’s comments on jams-spec-comments[1], but with some additional thoughts. The proposal takes a step in the right direction by allowing a runtime path to bypass access control. However, the fundamental issue at play is

Feedback on proposal for #ReflectiveAccessToNonExportedTypes

I wanted to second Paul’s comments on jams-spec-comments[1], but with some additional thoughts. The proposal takes a step in the right direction by allowing a runtime path to bypass access control. However, the fundamental issue at play is that class visibility is being used as an access