From mark.reinhold at oracle.com Thu Jun 1 23:10:46 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 01 Jun 2017 16:10:46 -0700 Subject: Updated working-draft JPMS specification Message-ID: <20170601161046.442185613@eggemoggin.niobe.net> I've updated the working-draft specification to add a "future work" section, as promised in our final meeting last week [1]: http://cr.openjdk.java.net/~mr/jigsaw/spec/#Future-work At this point the working draft reflects, so far as I know, all of our recent decisions. If I've missed anything, or if you have any further comments or suggestions, please let me know by noon UTC next Tuesday, 6 June, so that I can prepare to submit the specification to the JCP PMO for the Public Review Reconsideration Ballot. If you say nothing between now and that time then I'll assume that you have no objections to submitting the specification in its current form. - Mark [1] http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-23#Ready-to-move-forward From mark.reinhold at oracle.com Wed Jun 7 18:07:41 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 07 Jun 2017 11:07:41 -0700 Subject: Updated working-draft JPMS specification In-Reply-To: <20170601161046.442185613@eggemoggin.niobe.net> References: <20170601161046.442185613@eggemoggin.niobe.net> Message-ID: <20170607110741.390898527@eggemoggin.niobe.net> 2017/6/1 16:10:46 -0700, mark.reinhold at oracle.com: > ... > > At this point the working draft reflects, so far as I know, all of our > recent decisions. If I've missed anything, or if you have any further > comments or suggestions, please let me know by noon UTC next Tuesday, > 6 June, so that I can prepare to submit the specification to the JCP > PMO for the Public Review Reconsideration Ballot. > > If you say nothing between now and that time then I'll assume that you > have no objections to submitting the specification in its current form. Hearing no objections, I've submitted this version to the JCP PMO after changing the subtitle to "Public-Review Reconsideration Specification": http://cr.openjdk.java.net/~mr/jigsaw/spec/ - Mark From peter.kriens at aqute.biz Wed Jun 14 12:59:58 2017 From: peter.kriens at aqute.biz (Peter Kriens) Date: Wed, 14 Jun 2017 14:59:58 +0200 Subject: JPMS Module Path question Message-ID: I am trying to formally specify JPMS using Alloy. One of the questions that is popping up is about the consistency of the Module Path. The Module Path is defined as a set of directories (and files?) containing modules. Duplicate names seem to be disallowed in one directory but allowed between directories (and files?), where the first one wins. (Though useful for overrides, it is a rather error prone solution as we learned from the linear search of the class path). However, I cannot seem to find consensus on the consistency of modules in this module path. Must the set of available modules on the module path be consistent or is there no relation between these modules. For example, can these modules contain the same package? That is, is the module path a giant repository and will a resolution pick out the needed modules and verify this subset for consistency, or is it supposed to be a subset optimised for an application? For example: dir-x: A { exports a, requires B } dir-x: B { exports b } dir-x: C { requires A,D } dir-y: D { contains a, b } dir-y: A { exports a, b } Loading A would be ok but loading C would fail. Is it intended that you can have potentially inconsistent modules? Some issues: * Since modules lack versions a repository seems infeasible * JPMS must read a module from disk, even if it does not use it, an inconsistent module path would require a different reader then a consistent module path. For a consistent module path each package can have one module but and inconsistent module path a package can have multiple providers I would highly appreciate an answer from this forum. Kind regards, Peter Kriens From alex.buckley at oracle.com Wed Jun 14 18:59:12 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 14 Jun 2017 11:59:12 -0700 Subject: JPMS Module Path question In-Reply-To: References: Message-ID: <59418780.5020508@oracle.com> On 6/14/2017 5:59 AM, Peter Kriens wrote: > I am trying to formally specify JPMS using Alloy. One of the questions that is popping up is about the consistency of the Module Path. > > The Module Path is defined as a set of directories (and files?) containing modules. Duplicate names seem to be disallowed in one directory but allowed between directories (and files?), where the first one wins. (Though useful for overrides, it is a rather error prone solution as we learned from the linear search of the class path). > > However, I cannot seem to find consensus on the consistency of modules in this module path. Must the set of available modules on the module path be consistent or is there no relation between these modules. For example, can these modules contain the same package? First, please review the latest updates to the java.lang.module API spec -- http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/module/package-summary.html. Then, it'll be clear that you should be defining two functions: one to compute the readability graph, and one to determine the observability of a module. These are Java SE concepts. The observability of a module is "implemented" by searching some paths, such as the upgrade module path and the application module path. These are not Java SE concepts but rather JDK concepts defined in JEP 261 and mentioned for color in the java.lang.module API spec. The path-oriented implementation of observability is unconcerned with the consistency of modules that are physically found on paths. Let's look at your example, assuming the modulepath = dir-x:dir-y. > That is, is the module path a giant repository and will a resolution pick out the needed modules and verify this subset for consistency, or is it supposed to be a subset optimised for an application? > > For example: > > dir-x: A { exports a, requires B } This module is observable. I note that this module 'exports a', which I am going to take to mean 'contains and exports a', because there is no "re-exporting" of other modules' APIs in the JPMS. > dir-x: B { exports b } This module is observable. I note that this module 'exports b', which I am going to take to mean 'contains and exports b'. > dir-x: C { requires A,D } This module is observable. > dir-y: D { contains a, b } This module is observable. > dir-y: A { exports a, b } This module is NOT observable. Informally speaking, it's shadowed by the A in dir-x. > Loading A would be ok but loading C would fail. Is it intended that you can have potentially inconsistent modules? The java.lang.module API spec never speaks of modules being loaded. Modules are resolved. Suppose the root module to be resolved is C. C is observable, and the recursive enumeration of required modules will succeed because A, B, and D are observable. To cut a long story short, resolution will succeed; a readability graph is produced; a java.lang.module.Configuration object is produced. There could be thousands of other modules observable in dir-x and dir-y, all containing packages called a and b, but no-one requires them so resolution does not enumerate them. Anyway, it remains to reify this readability graph into class loaders that can load the classes contained in the modules indicated by the graph. In other words, it remains to build a ModuleLayer object out of the Configuration object. Here are your options: - If you try to build a single-loader layer, you will get an exception because two modules in the readability graph (A and D) contain a package (a) with the same name. This is what happens for "java -m C". - If you try to build a multi-loader layer, you will succeed because each module C, A, B, and D will be mapped to its own loader. We are now a great distance beyond observability and paths. We've progressed to thinking about readability and, because of class loader creation, about visibility. The final step is of course accessibility, which brings it own challenges because of wanting to support run-time access (VM symbolic resolution of constant pool entries) distinct from reflective access (java.lang.reflect API). But I think you should have a better picture now of what modular JARs (and exploded directories) can be placed on a path for observation. Alex From alex.buckley at oracle.com Wed Jun 14 19:55:33 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 14 Jun 2017 12:55:33 -0700 Subject: JPMS Module Path question In-Reply-To: References: Message-ID: <594194B5.40404@oracle.com> On 6/14/2017 5:59 AM, Peter Kriens wrote: > I am trying to formally specify JPMS using Alloy. A quick note on http://aqute.biz/2017/06/14/jpms-the-sequel.html, which seems to have misunderstand a (now rather out of date) JLS draft. "PackageDeclaration in a module declaration seems topsy turvy and it does not compile. So ignoring this." Not sure what this means. PackageDeclaration is not "in" a module declaration. The JLS has never allowed a compilation unit that contains both PackageDeclaration and ModuleDeclaration. "The module name in the declaration uses a different production then the module name in the requires. They are identical but it is sloppy." One is a declaration of an entity (introduces a name for the entity by specifying identifiers) and one is a use of a previously declared entity (specifies a previously introduced name). It so happens that the syntactic forms are the same, but it is proper to distinguish declaration from use as has been done throughout the JLS since 1996. Alex From peter.kriens at aqute.biz Thu Jun 15 11:19:30 2017 From: peter.kriens at aqute.biz (Peter Kriens) Date: Thu, 15 Jun 2017 13:19:30 +0200 Subject: JPMS Module Path question In-Reply-To: <59418780.5020508@oracle.com> References: <59418780.5020508@oracle.com> Message-ID: Ok, thanks. That is a crystal clear answer, I see the module path is a searchable repository. Puzzled then. Though JPMS now solves the problem of split packages and shadowing of classes it now introduces the shadowing of modules? Isn?t this the exact problem they called DLL hell :-( Kind regards, Peter Kriens > On 14 Jun 2017, at 20:59, Alex Buckley wrote: > > On 6/14/2017 5:59 AM, Peter Kriens wrote: >> I am trying to formally specify JPMS using Alloy. One of the questions that is popping up is about the consistency of the Module Path. >> >> The Module Path is defined as a set of directories (and files?) containing modules. Duplicate names seem to be disallowed in one directory but allowed between directories (and files?), where the first one wins. (Though useful for overrides, it is a rather error prone solution as we learned from the linear search of the class path). >> >> However, I cannot seem to find consensus on the consistency of modules in this module path. Must the set of available modules on the module path be consistent or is there no relation between these modules. For example, can these modules contain the same package? > > First, please review the latest updates to the java.lang.module API spec -- > http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/module/package-summary.html. > > Then, it'll be clear that you should be defining two functions: one to compute the readability graph, and one to determine the observability of a module. These are Java SE concepts. > > The observability of a module is "implemented" by searching some paths, such as the upgrade module path and the application module path. These are not Java SE concepts but rather JDK concepts defined in JEP 261 and mentioned for color in the java.lang.module API spec. > > The path-oriented implementation of observability is unconcerned with the consistency of modules that are physically found on paths. Let's look at your example, assuming the modulepath = dir-x:dir-y. > >> That is, is the module path a giant repository and will a resolution pick out the needed modules and verify this subset for consistency, or is it supposed to be a subset optimised for an application? >> >> For example: >> >> dir-x: A { exports a, requires B } > This module is observable. I note that this module 'exports a', which I am going to take to mean 'contains and exports a', because there is no "re-exporting" of other modules' APIs in the JPMS. > >> dir-x: B { exports b } > This module is observable. I note that this module 'exports b', which I am going to take to mean 'contains and exports b'. > >> dir-x: C { requires A,D } > This module is observable. > >> dir-y: D { contains a, b } > This module is observable. > >> dir-y: A { exports a, b } > This module is NOT observable. Informally speaking, it's shadowed by the A in dir-x. > >> Loading A would be ok but loading C would fail. Is it intended that you can have potentially inconsistent modules? > > The java.lang.module API spec never speaks of modules being loaded. Modules are resolved. Suppose the root module to be resolved is C. C is observable, and the recursive enumeration of required modules will succeed because A, B, and D are observable. To cut a long story short, resolution will succeed; a readability graph is produced; a java.lang.module.Configuration object is produced. > > There could be thousands of other modules observable in dir-x and dir-y, all containing packages called a and b, but no-one requires them so resolution does not enumerate them. > > Anyway, it remains to reify this readability graph into class loaders that can load the classes contained in the modules indicated by the graph. In other words, it remains to build a ModuleLayer object out of the Configuration object. Here are your options: > > - If you try to build a single-loader layer, you will get an exception because two modules in the readability graph (A and D) contain a package (a) with the same name. This is what happens for "java -m C". > > - If you try to build a multi-loader layer, you will succeed because each module C, A, B, and D will be mapped to its own loader. > > We are now a great distance beyond observability and paths. We've progressed to thinking about readability and, because of class loader creation, about visibility. The final step is of course accessibility, which brings it own challenges because of wanting to support run-time access (VM symbolic resolution of constant pool entries) distinct from reflective access (java.lang.reflect API). But I think you should have a better picture now of what modular JARs (and exploded directories) can be placed on a path for observation. > > Alex From peter.kriens at aqute.biz Thu Jun 15 11:51:42 2017 From: peter.kriens at aqute.biz (Peter Kriens) Date: Thu, 15 Jun 2017 13:51:42 +0200 Subject: JPMS Module Path question In-Reply-To: <594194B5.40404@oracle.com> References: <594194B5.40404@oracle.com> Message-ID: Thanks, I?ve updated the document. Part of the problem is that I am not sure where I can find the set of documents that were inputed to the vote? Is there an official list of those documents? Kind regards, Peter Kriens > On 14 Jun 2017, at 21:55, Alex Buckley wrote: > > On 6/14/2017 5:59 AM, Peter Kriens wrote: >> I am trying to formally specify JPMS using Alloy. > > A quick note on http://aqute.biz/2017/06/14/jpms-the-sequel.html, which seems to have misunderstand a (now rather out of date) JLS draft. > > "PackageDeclaration in a module declaration seems topsy turvy and it does not compile. So ignoring this." > > Not sure what this means. PackageDeclaration is not "in" a module declaration. The JLS has never allowed a compilation unit that contains both PackageDeclaration and ModuleDeclaration. > > "The module name in the declaration uses a different production then the module name in the requires. They are identical but it is sloppy." > > One is a declaration of an entity (introduces a name for the entity by specifying identifiers) and one is a use of a previously declared entity (specifies a previously introduced name). It so happens that the syntactic forms are the same, but it is proper to distinguish declaration from use as has been done throughout the JLS since 1996. > > Alex From Alan.Bateman at oracle.com Thu Jun 15 12:13:40 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Jun 2017 13:13:40 +0100 Subject: JPMS Module Path question In-Reply-To: References: <594194B5.40404@oracle.com> Message-ID: <11d2695b-1150-8750-edee-2d65bc74c00c@oracle.com> On 15/06/2017 12:51, Peter Kriens wrote: > Thanks, I?ve updated the document. Part of the problem is that I am not sure where I can find the set of documents that were inputed to the vote? > > Is there an official list of those documents? > > Mark sent a link to this list (or rather jpms-spec-experts and auto forwarded to this list) last week: http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2017-June/000943.html -Alan From peter.kriens at aqute.biz Thu Jun 15 12:44:54 2017 From: peter.kriens at aqute.biz (Peter Kriens) Date: Thu, 15 Jun 2017 14:44:54 +0200 Subject: JPMS Module Path question In-Reply-To: <11d2695b-1150-8750-edee-2d65bc74c00c@oracle.com> References: <594194B5.40404@oracle.com> <11d2695b-1150-8750-edee-2d65bc74c00c@oracle.com> Message-ID: Thanks Alan. This link http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html seems very out of date when I compare it with the actual drafts. Might be an idea to update, remove or mark it as stale? Kind regards, Peter Kriens > On 15 Jun 2017, at 14:13, Alan Bateman wrote: > > On 15/06/2017 12:51, Peter Kriens wrote: >> Thanks, I?ve updated the document. Part of the problem is that I am not sure where I can find the set of documents that were inputed to the vote? >> >> Is there an official list of those documents? >> >> > Mark sent a link to this list (or rather jpms-spec-experts and auto forwarded to this list) last week: > http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2017-June/000943.html > > -Alan > From Alan.Bateman at oracle.com Thu Jun 15 14:18:08 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Jun 2017 15:18:08 +0100 Subject: JPMS Module Path question In-Reply-To: References: <594194B5.40404@oracle.com> <11d2695b-1150-8750-edee-2d65bc74c00c@oracle.com> Message-ID: <02d7131e-17c0-7b8d-57ef-708ac517faac@oracle.com> On 15/06/2017 13:44, Peter Kriens wrote: > Thanks Alan. > > This link http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html seems very out of date when I compare it with the actual drafts. Might be an idea to update, remove or mark it as stale? > That document is a summary of the changes for integrating modules into the JLS and JVMS. If you are looking for the actual changes to the JLS and JVMS then the drafts are linked from the next paragraph. The summary document has been really useful to document several aspects of the proposed changes in advance of the actual changes to the specs. It will be familiar to those that have been tracking the JSR and EA builds over the last 20 months or so. I've found it particularly useful as a document to point the maintainers of tools at when there are questions about the binary format of a module declaration. I can't speak for Alex but I believe that it will be hollowed out to be just the summary of the changes. -Alan From mark.reinhold at oracle.com Thu Jun 15 14:28:29 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 15 Jun 2017 07:28:29 -0700 Subject: Java Platform Module System (JSR 376) EG minutes: 2017/5/22 In-Reply-To: References: <20170525072340.469340015@eggemoggin.niobe.net> Message-ID: <20170615072829.413728718@eggemoggin.niobe.net> 2017/5/25 7:56:53 -0700, Michael Nascimento : > I can't understand from the minutes how #CyclicDependences was resolved as > LATER given only Oracle seemed to like this idea. Could you explain if you > are doing a voting to come to resolution or whether it's a top-down > decision from Oracle? The resolution was arrived at as described in the minutes. Brian summarized the sense of the meeting at the end of the discussion, and no one objected to it. There was no voting in those meetings; if there had been, then the votes would have been reported in the minutes. - Mark From peter.kriens at aqute.biz Thu Jun 15 14:51:10 2017 From: peter.kriens at aqute.biz (Peter Kriens) Date: Thu, 15 Jun 2017 16:51:10 +0200 Subject: JPMS Module Path question In-Reply-To: <02d7131e-17c0-7b8d-57ef-708ac517faac@oracle.com> References: <594194B5.40404@oracle.com> <11d2695b-1150-8750-edee-2d65bc74c00c@oracle.com> <02d7131e-17c0-7b8d-57ef-708ac517faac@oracle.com> Message-ID: I agree with you that it is a useful document but I think it is very confusing that certain sections are now just wrong. A warning might help prevent confusion. Kind regards, Peter Kriens > On 15 Jun 2017, at 16:18, Alan Bateman wrote: > > On 15/06/2017 13:44, Peter Kriens wrote: >> Thanks Alan. >> >> This link http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html seems very out of date when I compare it with the actual drafts. Might be an idea to update, remove or mark it as stale? >> > That document is a summary of the changes for integrating modules into the JLS and JVMS. If you are looking for the actual changes to the JLS and JVMS then the drafts are linked from the next paragraph. > > The summary document has been really useful to document several aspects of the proposed changes in advance of the actual changes to the specs. It will be familiar to those that have been tracking the JSR and EA builds over the last 20 months or so. I've found it particularly useful as a document to point the maintainers of tools at when there are questions about the binary format of a module declaration. I can't speak for Alex but I believe that it will be hollowed out to be just the summary of the changes. > > -Alan > From alex.buckley at oracle.com Thu Jun 15 18:49:09 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 15 Jun 2017 11:49:09 -0700 Subject: JPMS Module Path question In-Reply-To: References: <59418780.5020508@oracle.com> Message-ID: <5942D6A5.50308@oracle.com> On 6/15/2017 4:19 AM, Peter Kriens wrote: > Ok, thanks. That is a crystal clear answer, I see the module path is a searchable repository. > > Puzzled then. Though JPMS now solves the problem of split packages and shadowing of classes it now introduces the shadowing of modules? Isn?t this the exact problem they called DLL hell :-( It's true that modular JARs on the module path may not be observable due to "shadowing", but because they're not observable they cannot pollute the readability graph with their exports, so it's incomparable to anything involving JARs on the class path. In more detail: - [CLASS PATH] JAR Hell is what happens when multiple JARs that "export" a given package are "observed" and "read" by a given consumer. The identity of a JAR is immaterial, so each JAR on the class path is just as worthy of being "observed" and "read" as every other JAR on the class path. If there are 1000 JARs on the class path, then all will be "observed" and "read". Unhappy consequence: split packages. - [MODULE PATH] If JPMS resolution succeeds, then one modular JAR that exports a given package is read by a given consumer. The identity of a modular JAR is material, so the consumer specifies ('requires') a modular JAR on the module path that they wish to be observed and read. If there are 1000 modular JARs on the module path, then only one with the specified identity will be observed and read; that's in the definition of observability. Happy consequence: no split packages. Alex From alex.buckley at oracle.com Thu Jun 15 18:54:05 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 15 Jun 2017 11:54:05 -0700 Subject: JPMS Module Path question In-Reply-To: References: <594194B5.40404@oracle.com> <11d2695b-1150-8750-edee-2d65bc74c00c@oracle.com> <02d7131e-17c0-7b8d-57ef-708ac517faac@oracle.com> Message-ID: <5942D7CD.1030501@oracle.com> On 6/15/2017 7:51 AM, Peter Kriens wrote: > I agree with you that it is a useful document but I think it is very confusing that certain sections are now just wrong. Please identify a section that is "just wrong". Alex From alex.buckley at oracle.com Thu Jun 15 19:00:32 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 15 Jun 2017 12:00:32 -0700 Subject: JPMS Module Path question In-Reply-To: References: <594194B5.40404@oracle.com> Message-ID: <5942D950.3040606@oracle.com> On 6/15/2017 4:51 AM, Peter Kriens wrote: > Thanks, I?ve updated the document. I find it hard to understand why the document persists in saying that the grammar of a module declaration is "sloppy" when I have explained the technical reason for the different productions. Alex From peter.kriens at aqute.biz Fri Jun 16 06:55:22 2017 From: peter.kriens at aqute.biz (Peter Kriens) Date: Fri, 16 Jun 2017 08:55:22 +0200 Subject: JPMS Module Path question In-Reply-To: <5942D7CD.1030501@oracle.com> References: <594194B5.40404@oracle.com> <11d2695b-1150-8750-edee-2d65bc74c00c@oracle.com> <02d7131e-17c0-7b8d-57ef-708ac517faac@oracle.com> <5942D7CD.1030501@oracle.com> Message-ID: In the current summary in http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html (which I understand was pat of the input to the vote), the following things were wrong: * Grammar (package declaration allowed together with a module declaration), and * Several attribute descriptions were missing [] And of course the not so unimportant concepts like the UnnamedModule, AutomaticModule, enumerated, and read concepts are completely missing from the summary. Since I wrongly assumed the absence of these concepts in the summary was caused by them being runtime concepts and not JLS concepts I ignored them in the first article. However, the draft now shows they?ve become first class citizens, also for compiling. So I will create an update soon. Just citing in the summary that it is out of date would have helped me a lot. Kind regards, Peter Kriens > On 15 Jun 2017, at 20:54, Alex Buckley wrote: > > On 6/15/2017 7:51 AM, Peter Kriens wrote: >> I agree with you that it is a useful document but I think it is very confusing that certain sections are now just wrong. > > Please identify a section that is "just wrong". > > Alex From peter.kriens at aqute.biz Fri Jun 16 06:56:54 2017 From: peter.kriens at aqute.biz (Peter Kriens) Date: Fri, 16 Jun 2017 08:56:54 +0200 Subject: JPMS Module Path question In-Reply-To: <5942D950.3040606@oracle.com> References: <594194B5.40404@oracle.com> <5942D950.3040606@oracle.com> Message-ID: I removed it, it is a personal judgement/preference. Kind regards, Peter Kriens > On 15 Jun 2017, at 21:00, Alex Buckley wrote: > > On 6/15/2017 4:51 AM, Peter Kriens wrote: >> Thanks, I?ve updated the document. > > I find it hard to understand why the document persists in saying that the grammar of a module declaration is "sloppy" when I have explained the technical reason for the different productions. > > Alex From alex.buckley at oracle.com Fri Jun 16 20:02:22 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 16 Jun 2017 13:02:22 -0700 Subject: JPMS Module Path question In-Reply-To: References: <594194B5.40404@oracle.com> <11d2695b-1150-8750-edee-2d65bc74c00c@oracle.com> <02d7131e-17c0-7b8d-57ef-708ac517faac@oracle.com> <5942D7CD.1030501@oracle.com> Message-ID: <5944394E.60103@oracle.com> On 6/15/2017 11:55 PM, Peter Kriens wrote: > In the current summary in http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html (which I understand was pat of the input to the vote), the following things were wrong: > > * Grammar (package declaration allowed together with a module declaration), and As I said earlier in this thread, I don't understand this comment. Where is a package declaration allowed with a module declaration in: CompilationUnit: [PackageDeclaration] {ImportDeclaration} {TypeDeclaration} {ImportDeclaration} ModuleDeclaration ? The definition of CompilationUnit has been refactored since publication of this lang-vm.html file, but the language accepted by CompilationUnit has not changed. > * Several attribute descriptions were missing [] OK, I see that in the Module attribute, the exports_to_index, opens_to_index, and provides_with_index items should have [] suffixes, since they are tables. Alex From peter.kriens at aqute.biz Sat Jun 17 10:48:28 2017 From: peter.kriens at aqute.biz (Peter Kriens) Date: Sat, 17 Jun 2017 12:48:28 +0200 Subject: JPMS Module Path question In-Reply-To: <5944394E.60103@oracle.com> References: <594194B5.40404@oracle.com> <11d2695b-1150-8750-edee-2d65bc74c00c@oracle.com> <02d7131e-17c0-7b8d-57ef-708ac517faac@oracle.com> <5942D7CD.1030501@oracle.com> <5944394E.60103@oracle.com> Message-ID: > On 16 Jun 2017, at 22:02, Alex Buckley wrote: > On 6/15/2017 11:55 PM, Peter Kriens wrote: >> In the current summary in http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html (which I understand was pat of the input to the vote), the following things were wrong: >> * Grammar (package declaration allowed together with a module declaration), and > As I said earlier in this thread, I don't understand this comment. Where is a package declaration allowed with a module declaration in: > > CompilationUnit: > [PackageDeclaration] {ImportDeclaration} {TypeDeclaration} > {ImportDeclaration} ModuleDeclaration > ? The definition of CompilationUnit has been refactored since publication of this lang-vm.html file, but the language accepted by CompilationUnit has not changed. As you said, in the latest draft this is corrected but it is imho therefore still [wrong] in the current lang-vm.html file? I.e. in lang-vm it still allows: package foo; module foo {} In the draft this is invalid. Kind regards, Peter Kriens > >> * Several attribute descriptions were missing [] > > OK, I see that in the Module attribute, the exports_to_index, opens_to_index, and provides_with_index items should have [] suffixes, since they are tables. > > Alex From alex.buckley at oracle.com Mon Jun 19 19:22:33 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 19 Jun 2017 12:22:33 -0700 Subject: JPMS Module Path question In-Reply-To: References: <594194B5.40404@oracle.com> <11d2695b-1150-8750-edee-2d65bc74c00c@oracle.com> <02d7131e-17c0-7b8d-57ef-708ac517faac@oracle.com> <5942D7CD.1030501@oracle.com> <5944394E.60103@oracle.com> Message-ID: <59482479.6090803@oracle.com> On 6/17/2017 3:48 AM, Peter Kriens wrote: >> On 16 Jun 2017, at 22:02, Alex Buckley wrote: >> On 6/15/2017 11:55 PM, Peter Kriens wrote: >>> In the current summary in http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html (which I understand was pat of the input to the vote), the following things were wrong: >>> * Grammar (package declaration allowed together with a module declaration), and >> As I said earlier in this thread, I don't understand this comment. Where is a package declaration allowed with a module declaration in: >> >> CompilationUnit: >> [PackageDeclaration] {ImportDeclaration} {TypeDeclaration} >> {ImportDeclaration} ModuleDeclaration >> ? The definition of CompilationUnit has been refactored since publication of this lang-vm.html file, but the language accepted by CompilationUnit has not changed. > > As you said, in the latest draft this is corrected but it is imho therefore still [wrong] in the current lang-vm.html file? I.e. in lang-vm it still allows: > > package foo; > module foo {} lang-vm does not allow this and has never allowed it. The CompilationUnit production that is presented above has two alternatives. The first alternative accepts: package ... import ... class ... The second alternative accepts: import ... module ... Alex From peter.kriens at aqute.biz Wed Jun 21 08:10:52 2017 From: peter.kriens at aqute.biz (Peter Kriens) Date: Wed, 21 Jun 2017 10:10:52 +0200 Subject: JPMS Module Path question In-Reply-To: <59482479.6090803@oracle.com> References: <594194B5.40404@oracle.com> <11d2695b-1150-8750-edee-2d65bc74c00c@oracle.com> <02d7131e-17c0-7b8d-57ef-708ac517faac@oracle.com> <5942D7CD.1030501@oracle.com> <5944394E.60103@oracle.com> <59482479.6090803@oracle.com> Message-ID: > On 19 Jun 2017, at 21:22, Alex Buckley wrote: > On 6/17/2017 3:48 AM, Peter Kriens wrote: >>> On 16 Jun 2017, at 22:02, Alex Buckley wrote: >>> On 6/15/2017 11:55 PM, Peter Kriens wrote: >>>> In the current summary in http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html (which I understand was pat of the input to the vote), the following things were wrong: >>>> * Grammar (package declaration allowed together with a module declaration), and >>> As I said earlier in this thread, I don't understand this comment. Where is a package declaration allowed with a module declaration in: >>> >>> CompilationUnit: >>> [PackageDeclaration] {ImportDeclaration} {TypeDeclaration} >>> {ImportDeclaration} ModuleDeclaration >>> ? The definition of CompilationUnit has been refactored since publication of this lang-vm.html file, but the language accepted by CompilationUnit has not changed. >> >> As you said, in the latest draft this is corrected but it is imho therefore still [wrong] in the current lang-vm.html file? I.e. in lang-vm it still allows: >> >> package foo; >> module foo {} > > lang-vm does not allow this and has never allowed it. The CompilationUnit production that is presented above has two alternatives. The first alternative accepts: > > package ... > import ... > class ... > > The second alternative accepts: > > import ... > module ? Yes, I see I misinterpreted the formatting. The draft is much clearer in this OR CompilationUnit: OrdinaryCompilationUnit ModularCompilationUnit OrdinaryCompilationUnit: [PackageDeclaration] {ImportDeclaration} {TypeDeclaration} ModularCompilationUnit: {ImportDeclaration} ModuleDeclaration Thanks, kind regards, Peter Kriens > > Alex From alex.buckley at oracle.com Wed Jun 21 21:08:44 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 21 Jun 2017 14:08:44 -0700 Subject: JPMS Module Path question In-Reply-To: <594194B5.40404@oracle.com> References: <594194B5.40404@oracle.com> Message-ID: <594AE05C.4000203@oracle.com> On 6/14/2017 12:55 PM, Alex Buckley wrote: > On 6/14/2017 5:59 AM, Peter Kriens wrote: >> I am trying to formally specify JPMS using Alloy. > > A quick note on http://aqute.biz/2017/06/14/jpms-the-sequel.html Some comments on the three "interesting things" noted in the blog: - The modeling of 'static' dependences seems to cause nothing but trouble, since it leads to an inaccurate 'requires static java.base'. - The statement that "there is no rule in the JLS about [an overlap in packages between java.base and another module]" is incorrect. See the "association" of compilation units with modules in JLS9 7.3. The rule is specified as weakly as possible (that is, to apply to as few packages as possible) in order to maximize the freedom of compilers. - The statement "The java.base module has qualified exports to other modules." is puzzling because the model of the java.base module -- "one sig JavaBaseModule ..." -- does not indicate any exports. Alex From mark.reinhold at oracle.com Tue Jun 27 15:16:53 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 27 Jun 2017 17:16:53 +0200 (CEST) Subject: Updated working-draft JPMS specification Message-ID: <20170627151653.2C05076990@eggemoggin.niobe.net> Now that we're past the reconsideration ballot, I've updated the working-draft specification [1] as follows: - The draft of the JLS was updated to rely explicitly on the result of module resolution as specified by the `java.lang.module` package. This reliance occurs both when compiling ordinary compilation units associated with a module (??7.3) and when compiling modular compilation units that express dependences (??7.7.1). In addition, the draft gives a complete account of the compile-time rules for unnamed modules. - The draft of the JVMS was updated to incorporate all changes to the class-file chapter in support of module declarations. - The summary of changes (in the file `lang-vm.html`) to those two documents was simplified to remove text that has been merged into the drafts. The summary is no longer normative. - The specification of the `java.util.ServiceLoader` class was rewritten to align with the draft JLS, clarify the manner in which service providers are located, and give better guidance on how to define and use services. At this point I expect few changes between this draft and the Proposed Final Draft. - Mark [1] http://cr.openjdk.java.net/~mr/jigsaw/spec/