From pbenedict at apache.org Thu Nov 12 14:57:09 2015 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 12 Nov 2015 08:57:09 -0600 Subject: Anything going on with the EG? Message-ID: I haven't seen any posts from the EG in more than 2 weeks. Are there behind the scene discussions? I am just curious about the inactivity. Cheers, Paul From david.lloyd at redhat.com Wed Nov 18 16:10:30 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 18 Nov 2015 10:10:30 -0600 Subject: My position on module security/access control Message-ID: <564CA2F6.10406@redhat.com> I wanted to summarize my position on module security and access control, so that all my thoughts are in one place instead of scattered across various threads. The first point I want to make is that I think that the idea of having public classes that are not public is a red flag. If a class and member is public, it should always be accessible to everyone regardless of who imports what module. There should only be one access control mechanism in the language. Users already seem keen to find ways to break out of the Jigsaw export-based restrictions and I think this is an indicator that, while expedient, the Jigsaw approach is far from ideal. In addition I think this is an essential step towards the ultimate goal of removing the dreaded setAccessible() method; if frameworks cannot even access public members then they will never be able break away from using reflection as a back door. The concept being established here is the ability to have a public class which is not exported but is still accessible to anyone. The second point is around module privacy. It is clear that (language-wise) we need an access level that is module-private. Given the relative uselessness of package-private accessibility in the module world, I propose that any reference to a default-access-level member in a Java 9 class should be considered to be a module-private access, not a package-private access, in both javac and the JVM. The protected access level should be similarly widened. This avoids the need for changing the class file format or introducing new modifiers to the language or reflection APIs, and ensures that the language continues to have only one central access control mechanism, instead of two interacting mechanisms, and completely eliminates all the "SharedSecret"-like cases found throughout the JDK and elsewhere. In the very long term, if/when support for Java 8-and-earlier class files is removed, only module access will remain, which results in a somewhat cleaner and more useful set of access controls. The third point is around "friend" modules. It seems clear that we have a requirement (which can be extrapolated easily from the document) that some modules need the ability to provide selective access to nonpublic members to other modules. This requirement seems perfectly reasonable, and the access level change described previously should be amenable to this mechanism. The mechanism could work on a package-by-package basis or at a module level; I think that the distinction between the two is relatively small in terms of implementation and is purely a user requirements question. The compiler and JVM should take this information into account when checking access to a peer module's class. The compiler will need to know, as part of compilation, what peer modules (or packages within peer modules) are expected to be accessible to the currently-compiling module at run time; the means of accomplishing this is a question of how the module metadata is represented and stored and is not directly relevant to the issue at hand, though I feel that a simple argument to javac/JavaCompiler is sufficient (i.e. let the build tool, which understands how the module is to be assembled and may have access to a variety of forms of metadata, discover the information and pass it to the compiler). The fourth point relates to ServiceLoader. If ServiceLoader has a unique and special blessing to bypass the access mechanism, then we've failed to design an adequately flexible (and secure) access control mechanism. By implementing the three points above, ServiceLoader no longer needs to be a special citizen, because all service implementation classes are public (as they are today, and as they should be). A user could implement ServiceLoader in unprivileged code and it would work with no special trapdoors. My intuition is that tying exporting with accessibility hides some potentially serious and maybe unsolvable land mines, and recent discussion on the Jigsaw list seems to imply that there are more practical problems as well. Keeping the concepts separate and building on the established accessibility mechanism seems like a much safer course to me (if not as expedient), and I hope I can convince the rest of the experts of the same. -- - DML From pbenedict at apache.org Tue Nov 24 21:26:16 2015 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 24 Nov 2015 15:26:16 -0600 Subject: Requires and exports Message-ID: Mark, are you still refining syntax? If so, I would like you to consider adding "module" and "package" to "requires" and "exports", respectively. module java.sql { requires module java.logging; requires module java.xml; exports package java.sql; exports package javax.sql; exports package javax.transaction.xa; } I find the explicitness to be much more instantly readable. WDYT? Cheers, Paul From mark.reinhold at oracle.com Tue Nov 24 21:33:34 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 24 Nov 2015 13:33:34 -0800 Subject: Requires and exports In-Reply-To: References: Message-ID: <20151124133334.855410@eggemoggin.niobe.net> 2015/11/24 1:26 -0800, Paul Benedict : > Mark, are you still refining syntax? ... If you want the EG to consider a specific suggestion then please send it to the jpms-spec-comments list rather than to this list, or to me directly. The EG is not obligated to read the observers list. - Mark From stef at epardaud.fr Fri Nov 27 11:06:02 2015 From: stef at epardaud.fr (Stephane Epardaud) Date: Fri, 27 Nov 2015 12:06:02 +0100 Subject: Did javax.annotation.Generated get removed? Message-ID: <5658391A.8060301@epardaud.fr> Hi, I'm testing Ceylon on Java 9 preview and besides the boot classpath removal with jimage files, I'm progressing in making it work. But I'm looking for the javax.annotation.Generated annotation, and I can't seem to find it. It was originally slated to end up in the javax.annotation module back when Jigsaw was targetted at Java 7, but now I can't find it in the lib .jimages. Did it get removed? Or is it hiding somewhere else? For the curious, Ceylon depends on a fork of Java 7 javac, which it includes. Adapting it to use the NIO FileSystem for jimage was relatively easy, and there's javac 9's code I can use to back port too. Other question: on https://jdk9.java.net/ I see "JDK9 Early Access Now Available!" and "JDK 9 Early Access with Project Jigsaw", both of these seem to differ. It's not very clear to me how, since the first does use ".jimage" files already. Is the second ("with Project Jigsaw") about the addition of user modules, or are they really the same thing? Thanks, cheers. From stef at epardaud.fr Fri Nov 27 11:10:12 2015 From: stef at epardaud.fr (Stephane Epardaud) Date: Fri, 27 Nov 2015 12:10:12 +0100 Subject: Did javax.annotation.Generated get removed? In-Reply-To: <5658391A.8060301@epardaud.fr> References: <5658391A.8060301@epardaud.fr> Message-ID: <56583A14.2030405@epardaud.fr> And also, why is the JDK9 EA With Jigsaw about 500 megs when the latest JDK9 EA is normal sized? From Alan.Bateman at oracle.com Fri Nov 27 11:27:18 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 Nov 2015 11:27:18 +0000 Subject: Did javax.annotation.Generated get removed? In-Reply-To: <5658391A.8060301@epardaud.fr> References: <5658391A.8060301@epardaud.fr> Message-ID: <56583E16.5050004@oracle.com> On 27/11/2015 11:06, Stephane Epardaud wrote: > Hi, > > I'm testing Ceylon on Java 9 preview and besides the boot classpath > removal with jimage files, I'm progressing in making it work. But I'm > looking for the javax.annotation.Generated annotation, and I can't seem > to find it. It was originally slated to end up in the javax.annotation > module back when Jigsaw was targetted at Java 7, but now I can't find it > in the lib .jimages. Did it get removed? Or is it hiding somewhere else? > > For the curious, Ceylon depends on a fork of Java 7 javac, which it > includes. Adapting it to use the NIO FileSystem for jimage was > relatively easy, and there's javac 9's code I can use to back port too. > > Other question: on https://jdk9.java.net/ I see "JDK9 Early Access Now > Available!" and "JDK 9 Early Access with Project Jigsaw", both of these > seem to differ. It's not very clear to me how, since the first does use > ".jimage" files already. Is the second ("with Project Jigsaw") about the > addition of user modules, or are they really the same thing? > At things currently stand then module java.annotations.common exports javax.annotation so this is where you'll find @Generated. I can't tell which build you are using or whether you are using the /modules or /packages tree but we've had issues with sym links in the jrt file system and maybe you are running into issues there. It's best to follow-up on jigsaw-dev with questions in this area as it's implementation rather than JSR 376. Same thing for the question on why the EA downloads include the jmod files with debug information. -Alan From Tim_Ellison at uk.ibm.com Fri Nov 27 12:21:34 2015 From: Tim_Ellison at uk.ibm.com (Tim Ellison) Date: Fri, 27 Nov 2015 12:21:34 +0000 Subject: My position on module security/access control In-Reply-To: <564CA2F6.10406@redhat.com> References: <564CA2F6.10406@redhat.com> Message-ID: <201511271221.tARCLfQi018044@d06av01.portsmouth.uk.ibm.com> David, You raise a number of deep and interesting points here. Rather than get into the details of each suggestion, I will say that I agree with the premise that the current modularity design is addressing visibility, while trying to live within the existing (and arguably sub-optimal) Java language access control model. I have argued that the Java security model should be brought up to date, but I understand that requires a far reaching redesign that is beyond the remit of the modularity EG. That means that modularity should 'do no harm', while avoiding those land mines you refer to below. Regards, Tim "David M. Lloyd" wrote on 18/11/2015 16:10:30: > I wanted to summarize my position on module security and access control, > so that all my thoughts are in one place instead of scattered across > various threads. > > The first point I want to make is that I think that the idea of having > public classes that are not public is a red flag. If a class and member > is public, it should always be accessible to everyone regardless of who > imports what module. There should only be one access control mechanism > in the language. Users already seem keen to find ways to break out of > the Jigsaw export-based restrictions and I think this is an indicator > that, while expedient, the Jigsaw approach is far from ideal. In > addition I think this is an essential step towards the ultimate goal of > removing the dreaded setAccessible() method; if frameworks cannot even > access public members then they will never be able break away from using > reflection as a back door. The concept being established here is the > ability to have a public class which is not exported but is still > accessible to anyone. > > The second point is around module privacy. It is clear that > (language-wise) we need an access level that is module-private. Given > the relative uselessness of package-private accessibility in the module > world, I propose that any reference to a default-access-level member in > a Java 9 class should be considered to be a module-private access, not a > package-private access, in both javac and the JVM. The protected access > level should be similarly widened. This avoids the need for changing > the class file format or introducing new modifiers to the language or > reflection APIs, and ensures that the language continues to have only > one central access control mechanism, instead of two interacting > mechanisms, and completely eliminates all the "SharedSecret"-like cases > found throughout the JDK and elsewhere. In the very long term, if/when > support for Java 8-and-earlier class files is removed, only module > access will remain, which results in a somewhat cleaner and more useful > set of access controls. > > The third point is around "friend" modules. It seems clear that we have > a requirement (which can be extrapolated easily from the document) that > some modules need the ability to provide selective access to nonpublic > members to other modules. This requirement seems perfectly reasonable, > and the access level change described previously should be amenable to > this mechanism. The mechanism could work on a package-by-package basis > or at a module level; I think that the distinction between the two is > relatively small in terms of implementation and is purely a user > requirements question. The compiler and JVM should take this > information into account when checking access to a peer module's class. > The compiler will need to know, as part of compilation, what peer > modules (or packages within peer modules) are expected to be accessible > to the currently-compiling module at run time; the means of > accomplishing this is a question of how the module metadata is > represented and stored and is not directly relevant to the issue at > hand, though I feel that a simple argument to javac/JavaCompiler is > sufficient (i.e. let the build tool, which understands how the module is > to be assembled and may have access to a variety of forms of metadata, > discover the information and pass it to the compiler). > > The fourth point relates to ServiceLoader. If ServiceLoader has a > unique and special blessing to bypass the access mechanism, then we've > failed to design an adequately flexible (and secure) access control > mechanism. By implementing the three points above, ServiceLoader no > longer needs to be a special citizen, because all service implementation > classes are public (as they are today, and as they should be). A user > could implement ServiceLoader in unprivileged code and it would work > with no special trapdoors. > > My intuition is that tying exporting with accessibility hides some > potentially serious and maybe unsolvable land mines, and recent > discussion on the Jigsaw list seems to imply that there are more > practical problems as well. Keeping the concepts separate and building > on the established accessibility mechanism seems like a much safer > course to me (if not as expedient), and I hope I can convince the rest > of the experts of the same. > > -- > - DML > From stef at epardaud.fr Fri Nov 27 13:19:06 2015 From: stef at epardaud.fr (Stephane Epardaud) Date: Fri, 27 Nov 2015 14:19:06 +0100 Subject: Did javax.annotation.Generated get removed? In-Reply-To: <56583E16.5050004@oracle.com> References: <5658391A.8060301@epardaud.fr> <56583E16.5050004@oracle.com> Message-ID: <5658584A.3010505@epardaud.fr> Thanks, I'll subscribe there and post my new questions there. On 27/11/15 12:27, Alan Bateman wrote: > At things currently stand then module java.annotations.common exports > javax.annotation so this is where you'll find @Generated. I can't tell > which build you are using or whether you are using the /modules or > /packages tree but we've had issues with sym links in the jrt file > system and maybe you are running into issues there. > > It's best to follow-up on jigsaw-dev with questions in this area as > it's implementation rather than JSR 376. Same thing for the question > on why the EA downloads include the jmod files with debug information. > > -Alan