From mark.reinhold at oracle.com Tue Mar 1 17:41:05 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 1 Mar 2016 09:41:05 -0800 (PST) Subject: Preparing for EDR: Issue summary Message-ID: <20160301174105.07B8A9C6A3@eggemoggin.niobe.net> Last September I proposed an initial design as the starting point for the specification to be produced for this JSR [1]. Feedback on that design from Java developers and from library and tool maintainers, via e-mail and in person at three major conferences (JavaOne 2015, Devoxx BE 2015, and Jfokus 2016), has been generally positive yet, as expected, some important issues have been raised. Here in the EG we've discussed some specific aspects of the proposed design. We've also discussed, at a high level, some completely different approaches, but none of the latter has gained traction. At this point I'd like to move forward with the proposed design, with an aim to publish an Early Draft Review fairly soon. As a first step toward that milestone I've prepared a list of open issues in this design [2] gathered from the JSR 376 e-mail lists (EG, comments, and observers) and the OpenJDK jigsaw-dev list. We need not resolve all, or even any, of these issues for the EDR, but we should do our best to make sure that the issue list is complete. If you think any important issues are missing, or if any of the existing issue summaries could be improved, then please suggest specific additions or revisions. The issue list is meant to be a living document, updated regularly as work progresses. Each issue is assigned a unique hash tag for use in the e-mail messages and other textual media in which the issues will be discussed so that such discussions can be discovered, tracked, and summarized. To that end, if you wish to open a thread on an issue then please make sure to include its hash tag in the subject line of your message. - Mark [1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2015-September/000092.html [2] http://openjdk.java.net/projects/jigsaw/spec/issues/ From mark.reinhold at oracle.com Tue Mar 1 17:42:05 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 1 Mar 2016 09:42:05 -0800 (PST) Subject: Issue #ReflectionWithoutReadability: Proposal Message-ID: <20160301174205.136449C6AA@eggemoggin.niobe.net> Issue summary [1]: Having to add read edges dynamically just to enable reflection is painful, and could slow migration and adoption. Consider relaxing the access model so that reflection does not require, or perhaps simply assumes, readability. Proposal: Adopt the second alternative suggested in the summary. Revise the core reflection APIs (java.lang.reflect) to assume that any module that contains code that invokes a reflective operation can read the module that defines the types that are the subject of that operation. As a consequence, most code that uses reflection will not have to take the trouble to add readability edges manually. Code of this form that was previously added to the prototype implementation will be removed. This proposal does weaken the fidelity story a tiny bit, in the sense that you'll be able to do more at run time than you can in earlier phases, but that seems a worthwhile tradeoff in order to ease migration. - Mark [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#ReflectionWithoutReadability From david.lloyd at redhat.com Tue Mar 1 21:04:01 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 1 Mar 2016 15:04:01 -0600 Subject: SO files in module images and SELinux Message-ID: <56D603C1.3050008@redhat.com> Is it well-understood how the mechanism which allows .so files to be inside of module images is going to interact with OS security infrastructures like SELinux which may require shared object libraries to be pre-authorized before they may be linked/executed? -- - DML From david.lloyd at redhat.com Tue Mar 1 23:56:00 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 1 Mar 2016 17:56:00 -0600 Subject: Coupling modules and class loaders In-Reply-To: <5672FCE6.20501@redhat.com> References: <56276E91.5060605@redhat.com> <20151210012745.EFD0F849EA@eggemoggin.niobe.net> <56699CB0.6020704@redhat.com> <20151214194413.C698A85311@eggemoggin.niobe.net> <567052EB.4080403@redhat.com> <20151217162614.4CA4185A7C@eggemoggin.niobe.net> <5672FCE6.20501@redhat.com> Message-ID: <56D62C10.30205@redhat.com> Still awaiting a reply on the following. I still maintain that the module API and class loader decoupling is a design issue. On 12/17/2015 12:20 PM, David M. Lloyd wrote: > On 12/17/2015 10:26 AM, mark.reinhold at oracle.com wrote: >> 2015/12/15 9:50 -0800, david.lloyd at redhat.com: >>> On 12/14/2015 01:44 PM, mark.reinhold at oracle.com wrote: >>>> ... >>>> >>>> What I'm thinking of is an existing application with its own >>>> non-trivial >>>> class-loader architecture which, due to compatibility constraints, >>>> cannot >>>> be changed. If at least one of its class loaders loads classes from >>>> logically-distinct components that are later converted into >>>> corresponding >>>> modules then upgrading the application to load those components as >>>> modules would, under your approach, require replacing that one class >>>> loader with many class loaders, which would break compatibility. >>>> >>>> Imagine, e.g., a Java EE application server that loads >>>> implementations of >>>> all the standard EE components using one class loader. Imagine further >>>> that existing users (for good or for ill) depend upon that. If a >>>> future >>>> version of Java EE defines those components as modules then the only >>>> way >>>> to arrange for this app server to load them as such would be to change >>>> its class-loader architecture in a way that would break existing uses. >>>> >>>> (This is, roughly, the situation with Oracle's WebLogic app server, as >>>> I've mentioned previously.) >>> >>> With a multi-class-loader arrangement, it should be possible to emulate >>> any single-class-loader arrangement, in two ways and with one caveat >>> that I know of: >>> >>> * You can create modules which provide "cut down" views of another >>> module, such that the module appears as multiple modules but with one >>> /defining/ class loader for all classes actually loaded from them; >> >> I think you mean one defining loader, not one initiating loader. If >> loader M actually loads a module, and loaders X and Y define "cut down" >> views of M by delegating to M, then all three loaders can be initiating >> loaders of classes in M but only M will be the defining loader of such >> classes. > > You're right, I used the wrong term, I don't know what I was thinking > about. Sorry about that, I've fixed the text to hopefully reduce > confusion... > >>> * You can create a module which aggregates multiple modules into one, as >>> long as no code relies on the the specific relationship between the >>> /defining/ class loaders of classes within the module (as the /defining/ >>> class loader will reflect the module in which the class was defined; >>> this is the caveat I was referring to above). >> >> Again, I think you mean defining loader. If loaders M1 and M2 load >> modules, and loader X aggregates those into a single apparent module, >> then M1 and M2 will be defining loaders and X will be an initiating >> loader. > > Fixed... > >> >>> In the JDK itself, there's the special case of the null return of >>> Class.getClassLoader() being used for legacy security checks, for code >>> that depends on this, though there are multiple ways that I know of in >>> which this could potentially be mitigated, if this is a problem that you >>> are thinking of and you want to discuss it. >>> >>> What do you think about these options in terms of WebLogic? Are there >>> additional cases that cannot be covered by fixes in these two areas? >>> Are there other compatibility cases beyond these that you have in mind >>> where using multiple class loaders for either platform components or for >>> Java EE specification modules could break existing behaviors, or does >>> the combination of the change of /defining/ class loader and behavior of >>> Class.getClassLoader() summarize the potential issues that you see? >> >> To make an approach along these lines work for the JDK, for WebLogic, >> and for any other application with a non-trivial, non-loader-per-module >> class-loader architecture, I think you're going to have to fundamentally >> redefine the meaning of the Class::getClassLoader method. > > ...because WebLogic depends on the defining class loader being something > in particular? Looking at the WebLogic class loading documentation, it > seems like it is less important what the defining loader is, and more > important what each (EE) module can "see". In fact there are a number > of restrictions which actually seem to play in favor of per-classloader > modules: limited nesting depth, a clear delegation pattern (because > traditional classloader hierarchy trees are just a subclass of the > overall directed-graph relationship of modularity), restriction of > customization to web and EJB modules, call-by-value in certain > situations, etc. > > It would appear to me (just from reading the documentation) that > WebLogic should already be well-positioned to adopt a > classloader-oriented modularity strategy for Java EE, unless there is > some problem that stems directly from having differing defining class > loaders. > >> It would no >> longer return the defining loader of a class but, rather, an initiating, >> aggregating loader as you describe above. Given the roles of class >> loaders in both VM-level access checking and SecurityManager-level >> permission checking, this is far from being a simple change. >> >> To take just one case, suppose a class C is loaded and defined by a >> module class loader M1, which itself is aggregated together with some >> other module class loader M2 by an aggregating loader X, so if I have >> C's Class object then its getClassLoader method will return X. Suppose >> further that X is an instance of an end-user-supplied subclass of a >> ClassLoader subclass provided by the application, long ago, as part of >> its supported API. When one of the defineClass methods of X is invoked >> to define some new class D, what will be the defining loader of D? >> >> If the defining loader is not X, then X must somehow delegate class >> definition to either M1 or M2, but which one? If D's package is already >> defined to just one of those loaders then maybe defining it with that >> loader would (often) be the right thing. What would X do if D's package >> is split across M1 and M2, or would you disallow that? What would X do >> if D's package is not yet defined in either M1 or M2, just define D with >> X? That might work in some cases but not if some code later on depends >> upon D having been defined by M1 specifically. >> >> If the defining loader is X, rather than M1 or M2, then D would have a >> different defining loader relative to classes now in M1 or M2 than it did >> when run on pre-9 releases. If D is meant to have package-private access >> to some class E in the same package, whose defining loader was X but is >> now M1 due to modularization, then it will fail, since D's run-time >> package will be different from that of E, since its defining loader is >> different. >> >> (You could consider an even deeper change and say that X is the defining >> loader, not just an initiating loader, of all classes in both M1 and >> M2. >> Module-private types in those modules would then, however, no longer be >> strongly encapsulated.) >> >> So, that's just one case of one family of methods, defineClass, in the >> existing ClassLoader API. To change the meaning of Class::getClassLoader >> would require a deep analysis of all the methods in ClassLoader, not just >> this one. Maybe there's some super-clever way to make them all work in a >> manner that's both sensible and compatible, but I don't know what that is >> and I can't believe it'd be straightforward. This kind of complexity is >> exactly why we abandoned the module-per-loader approach implemented in >> the first Jigsaw prototype. > > Yeah I didn't mean to imply that we should make a fundamental shift in > what getClassLoader means; however, I would definitely consider the idea > of making small changes to it to be reasonable, if it were just for > compatibility with things that use e.g. ClassLoader.getSystemResources() > or Class.forName(x, y, null) for example, or which use getClassLoader() > == null for security checks; this kind of behavior could optionally be > deprecated & removed in the long term. > > The thrust of my question was intended to be regarding platform and > application class loaders. As a hopefully better approach, I'll break > it into a few (more specific) hypothetical situations which are centered > around 1:1 modules/classloaders. Some seem reasonable, some seem more > unlikely but might still be worth exploring for the purposes of thought > experimentation. > > 1. Premise: The Java EE 9 specification establishes a rule wherein each > Java EE API is required to be available statically to applications by a > module name which corresponds to the API in use. Existing application > servers currently present all these APIs as one large unit. Question: > is it a problem to present each API as a "cut down"/filtered view of one > module which consists the of all those APIs in the same large unit? > > 2. Premise: Same as #1, except the Java EE 9 specification also requires > that each API be actually encapsulated in a separate module. Question: > is it a problem that the defining class loader of these classes has > changed to be per-API rather than a single one? > > 3. Premise: Java EE 9 requires that each deployment item presently > defined in the EE platform spec as a "module" be established as a > module, while otherwise maintaining the existing neutrality about the > "types and arrangements" of class loaders (meaning for example that it > is the app vendor's choice as to whether each transitive Class-Path > dependency becomes a (potentially shared) module, or whether those > classes are folded in to the EE module, or some other strategy). > Question: does this present a compatibility problem that you can foresee? > > 4. Premise: Same as #3, however it also introduces a means to determine > whether other JARs in a deployment should be established as a module, as > well as a means to establish dependencies to and from such modules. > Question: does this mitigate or exacerbate any problems from #3? > > 5. Premise: Java EE 9 requires that every single archive within every > application or module be established as a module. Question: how big a > disaster would this be, and why? > -- - DML From david.lloyd at redhat.com Wed Mar 2 23:56:12 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 2 Mar 2016 17:56:12 -0600 Subject: Expounding on #ModuleNameSyntax Message-ID: <56D77D9C.1060401@redhat.com> It seems to me that the syntax requirements presently established for Jigsaw in particular are really specific to the module layer(s) handled by the JDK. It is easy to imagine containers and other such systems that are provided in their own layers might have different, pre-existing syntax requirement (we have such a situation with our existing module environment, allowing (in some layers) names with hypens, slashes, etc.). Shouldn't syntax checking of names be a policy decision of the module layer, rather than a global policy? -- - DML From david.lloyd at redhat.com Thu Mar 3 00:07:06 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 2 Mar 2016 18:07:06 -0600 Subject: New issue: Layers are strictly hierarchical Message-ID: <56D7802A.9070305@redhat.com> If there is any expectation of moving existing systems over to Jigsaw, I think that the strict hierarchical layer system should be abandoned in favor of a graph-oriented system. This allows containers to maintain separate module graphs with separate namespaces which nevertheless interconnect. I believe that this is a necessary requirement if (in particular) there is an expectation that Java EE 9 (or another Java EE specification) would be reframed in terms of Jigsaw-style modules, since Java EE module names have many fewer restrictions, and it is possible for (for example) more than one application to contain modules of the same name. If on the other hand there is an expectation that Java EE is not going to be retrofitted in a way which maps EE applications and modules to Jigsaw modules, then this should be clearly declared. -- - DML From david.lloyd at redhat.com Thu Mar 3 00:12:29 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 2 Mar 2016 18:12:29 -0600 Subject: New issue: ModuleClassLoader is final Message-ID: <56D7816D.5050406@redhat.com> If ModuleClassLoader is final, then it is impossible to have (for example) an OSGi implementation where OSGi bundles map to modules, because the class loader of OSGi bundles must implement an OSGi interface. Other containers may also wish to use ModuleClassLoader subclasses to store assocations in similar ways with deployment modules or bundles; the prevalence of the TCCL to mark the currently active application's class loader makes this a particularly useful technique. -- - DML From david.lloyd at redhat.com Thu Mar 3 00:15:10 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 2 Mar 2016 18:15:10 -0600 Subject: New Issue: Module interconnects between layers Message-ID: <56D7820E.9030106@redhat.com> In a container which uses module layers to provide isolated module namespaces, it is nevertheless sometimes necessary to provide dependency interconnects between modules in different layers. If there is not an expectation to support the use of Jigsaw modules in containers, this should be stated explicitly. -- - DML From david.lloyd at redhat.com Thu Mar 3 00:22:42 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 2 Mar 2016 18:22:42 -0600 Subject: #AvoidConcealedPackageConflicts (and others) supplement Message-ID: <56D783D2.2000302@redhat.com> It should be noted that enforcing a 1:1 relationship between class loaders and modules easily and conveniently solves #AvoidConcealedPackageConflicts, #MultipleModuleVersions, and (less obviously) #ResourceEncapsulation (by way of the existing class loader access restriction mechanism). -- - DML From david.lloyd at redhat.com Thu Mar 3 02:11:34 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 2 Mar 2016 20:11:34 -0600 Subject: New issue: Configurations are not mutable Message-ID: <56D79D56.7040801@redhat.com> It appears from what I can see in the Jigsaw code, that once a Configuration is calculated, it cannot be changed in any way, which makes them unsuitable for use in containers which add and remove modules at run time. It is not clear how such containers are expected to function. If there is a deliberate intention that the Jigsaw system will not support dynamic modification of layers/configurations (including the dynamic addition and removal of modules at run time), then that should be explicitly stated. -- - DML From david.lloyd at redhat.com Thu Mar 3 03:08:21 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 2 Mar 2016 21:08:21 -0600 Subject: New issue: ModuleClassLoader is final In-Reply-To: <56D7816D.5050406@redhat.com> References: <56D7816D.5050406@redhat.com> Message-ID: <56D7AAA5.7030605@redhat.com> On 03/02/2016 06:12 PM, David M. Lloyd wrote: > If ModuleClassLoader is final, then it is impossible to have (for > example) an OSGi implementation where OSGi bundles map to modules, > because the class loader of OSGi bundles must implement an OSGi > interface. Other containers may also wish to use ModuleClassLoader > subclasses to store assocations in similar ways with deployment modules > or bundles; the prevalence of the TCCL to mark the currently active > application's class loader makes this a particularly useful technique. After updating my checkout I see that this class is actually completely gone now. Am I correct in understanding that in the current implementation, a Layer can establish any ClassLoader for a module (via Layer.ClassLoaderFinder)? -- - DML From david.lloyd at redhat.com Thu Mar 3 03:09:27 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 2 Mar 2016 21:09:27 -0600 Subject: #AvoidConcealedPackageConflicts (and others) supplement In-Reply-To: <56D783D2.2000302@redhat.com> References: <56D783D2.2000302@redhat.com> Message-ID: <56D7AAE7.8030801@redhat.com> On 03/02/2016 06:22 PM, David M. Lloyd wrote: > It should be noted that enforcing a 1:1 relationship between class > loaders and modules easily and conveniently solves > #AvoidConcealedPackageConflicts, #MultipleModuleVersions, and (less > obviously) #ResourceEncapsulation (by way of the existing class loader > access restriction mechanism). This last bit is incomplete: the various resource-get methods on Class have always been unrestricted, so to change that behavior, there must be a change in spec no matter what. -- - DML From david.lloyd at redhat.com Thu Mar 3 03:16:50 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 2 Mar 2016 21:16:50 -0600 Subject: New issue: ModuleClassLoader is final In-Reply-To: <56D7AAA5.7030605@redhat.com> References: <56D7816D.5050406@redhat.com> <56D7AAA5.7030605@redhat.com> Message-ID: <56D7ACA2.3070101@redhat.com> On 03/02/2016 09:08 PM, David M. Lloyd wrote: > On 03/02/2016 06:12 PM, David M. Lloyd wrote: >> If ModuleClassLoader is final, then it is impossible to have (for >> example) an OSGi implementation where OSGi bundles map to modules, >> because the class loader of OSGi bundles must implement an OSGi >> interface. Other containers may also wish to use ModuleClassLoader >> subclasses to store assocations in similar ways with deployment modules >> or bundles; the prevalence of the TCCL to mark the currently active >> application's class loader makes this a particularly useful technique. > > After updating my checkout I see that this class is actually completely > gone now. Am I correct in understanding that in the current > implementation, a Layer can establish any ClassLoader for a module (via > Layer.ClassLoaderFinder)? Now Function, which was going to be my next question... -- - DML From david.lloyd at redhat.com Thu Mar 3 03:22:49 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 2 Mar 2016 21:22:49 -0600 Subject: New issue: run time eager module loading Message-ID: <56D7AE09.1030003@redhat.com> It looks as though the instantiation of a Layer causes a complete load of all the modules in the layer. Apart from the consequent lack of dynamicism, I think this is very likely to cause problems for large applications, particularly if such an application might have many operation modes, some of which do not require *all* of the bundled modules to be loaded every single time. Can there not instead be an incremental resolution algorithm, akin to how classes are lazily loaded? -- - DML From david.lloyd at redhat.com Thu Mar 3 03:42:05 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 2 Mar 2016 21:42:05 -0600 Subject: Bikeshed-ish issue: Optional Message-ID: <56D7B28D.30807@redhat.com> I notice that Jigsaw is making arguably excessive use of Optional. Reinier Zwitzerloot [1] quoted Brian Goetz about this topic; the full quote [2] is as follows: "Of course, people will do what they want. But we did have a clear intention when adding this feature, and it was not to be a general purpose Maybe or Some type, as much as many people would have liked us to do so. Our intention was to provide a limited mechanism for library method return types where there needed to be a clear way to represent "no result", and using null for such was overwhelmingly likely to cause errors. "For example, you probably should never use it for something that returns an array of results, or a list of results; instead return an empty array or list. You should almost never use it as a field of something or a method parameter. "I think routinely using it as a return value for getters would definitely be over-use. "There's nothing wrong with Optional that it should be avoided, it's just not what many people wish it were, and accordingly we were fairly concerned about the risk of zealous over-use." Incidentally [1] is also the go-to reference when people have questions about Optional<> in the ##java IRC channel on irc.freenode.net. [1] https://www.voxxed.com/blog/2015/01/embracing-void-6-refined-tricks-dealing-nulls-java/ [2] https://stackoverflow.com/questions/26327957/should-java-8-getters-return-optional-type/26328555#26328555 -- - DML From david.lloyd at redhat.com Thu Mar 3 15:42:47 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 3 Mar 2016 09:42:47 -0600 Subject: Issue: Modules can only open resources as streams Message-ID: <56D85B77.4040607@redhat.com> Module.getResourceAsStream() is the only way a resource can be loaded from a module. This makes it impossible to do either of the following: ? Determine the size of a resource in advance of loading it ? Determine the existence of a resource without opening it Loading resources as java.net.URLs allowed these things to be done (among other things), however it is also disadvantageous due to the heavyweight nature of that class. I had earlier come up with a simple patch [1], initially as a way to address JDK-6865375 [2], which introduced the idea of a Resource class that is associated with a ClassLoader, with a name, URL, size, and stream factory method, which would also be a clean solution here (though with the addition of a Module property as well since in Jigsaw they're separate). The idea is to put resources on a similar footing to classes, whereby you can (if suitably permitted) acquire their class loaders just like Class.getClassLoader() allows you to do for classes. This also allows things like ServiceLoader to load classes directly from the module which contained the corresponding service descriptor. [1] https://github.com/dmlloyd/openjdk-modules/commit/d9ab5a4b51f63d71d0ff5bdb0625ea3fa149f90c [2] https://bugs.openjdk.java.net/browse/JDK-6865375 -- - DML From david.lloyd at redhat.com Fri Mar 4 22:31:51 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 4 Mar 2016 16:31:51 -0600 Subject: Jigsaw and other module systems Message-ID: <56DA0CD7.3040900@redhat.com> I've raised several issues but the thrust of them really boils down to the ability to retrofit existing module systems on to Jigsaw. OSGi is certainly one of these, and of course our own module system into which we're reasonably invested is another. Ultimately our needs can, I think, be met by either solving (somehow) the aforementioned issues, or failing that, rather by eliminating any disadvantage afforded to non-Jigsaw-loaded code by providing alternative hooks (for example, allowing class loaders to assign a name and version to the "unnamed" module would allow non-Jigsaw code to have stack traces which take advantage of the new information, or perhaps by allowing ClassLoaders to define their own kinds of Module that perhaps obey different rules or constraints than the JDK-supplied ones). In this current situation, it is looking pretty grim for our users, who may want to take some sort of advantage of JDK-supplied modularity while still retaining compatibility with the existing module system as well as the extra capabilities that our existing module system has. So just be aware that I am not intending to be inflexible about the issues I've raised as long as we can meet our needs some other way. I am willing to engage in any discussion about these issues (in this or other media), also including contributing code, as this is one of my top priority items at the moment. My main intention is to not leave our users "high and dry". -- - DML From david.lloyd at redhat.com Fri Mar 4 23:06:46 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 4 Mar 2016 17:06:46 -0600 Subject: Issue: The JAXP+modules story is still a bit of a mess Message-ID: <56DA1506.2010008@redhat.com> I'm not sure if this is just something that has not yet been gotten 'round to, but the way JAXP loading works has become somewhat less convenient. If you are a container author, and you need to supply your own global default JAXP implementation classes, your options are highly limited: you can rely on TCCL being set on every call to Xxxx.newFactory() (never going to happen 100% of the time in reality), or you can set the appropriate system properties and make your implementation visible from every class loader (something of the opposite of the kind of encapsulation that we have modules for). Today we do the latter, along with some "redirect" implementations of all the major JAXP classes which allow the global default factory to be established or changed by suitably privileged code. However, this solution is untenable when the JDK implementation classes cannot be accessed: the global default which is established by the JDK is now extremely difficult to reach through any other means! The system property approach - really any approach to locating anything which involves a class name without some kind of context for locating that class (be it a module name or whatever) - is pretty outdated; it seems like it could be a good idea at this time to add methods to allow setting (maybe even on a one-time-only basis) a global Supplier for each JAXP type. Is there any way this could be accomplished? -- - DML From mark.reinhold at oracle.com Tue Mar 8 15:59:53 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 08 Mar 2016 07:59:53 -0800 Subject: Issue #ReflectionWithoutReadability: Proposal In-Reply-To: <20160301174205.136449C6AA@eggemoggin.niobe.net> References: <20160301174205.136449C6AA@eggemoggin.niobe.net> Message-ID: <20160308075953.11754050eggemoggin.niobe.net> 2016/3/1 9:42 -0800, mark.reinhold at oracle.com: > Issue summary [1]: > > Having to add read edges dynamically just to enable reflection is > painful, and could slow migration and adoption. Consider relaxing the > access model so that reflection does not require, or perhaps simply > assumes, readability. > > Proposal: Adopt the second alternative suggested in the summary. Revise > the core reflection APIs (java.lang.reflect) to assume that any module > that contains code that invokes a reflective operation can read the > module that defines the types that are the subject of that operation. > > As a consequence, most code that uses reflection will not have to take > the trouble to add readability edges manually. Code of this form that > was previously added to the prototype implementation will be removed. > > This proposal does weaken the fidelity story a tiny bit, in the sense > that you'll be able to do more at run time than you can in earlier > phases, but that seems a worthwhile tradeoff in order to ease migration. Hearing no objections, I'll mark this issue as resolved. The relevant changes have already been made in the prototype. - Mark [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#ReflectionWithoutReadability From mark.reinhold at oracle.com Tue Mar 8 16:46:39 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 8 Mar 2016 08:46:39 -0800 (PST) Subject: The State of the Module System: Automatic Edition Message-ID: <20160308164639.055639DEA1@eggemoggin.niobe.net> I've posted an update to the State of the Module System document [1]. The main change in this edition is the introduction of material on compatibility and migration, including automatic modules [2]. This update also revises the description of reflective readability [3], reorders the text to improve the flow of the narrative, and is organized into a two-level hierarchy of sections and subsections for easier navigation. - Mark [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/ [2] http://openjdk.java.net/projects/jigsaw/spec/sotms/#compatibility--migration [3] http://openjdk.java.net/projects/jigsaw/spec/sotms/#reflective-readability From mark.reinhold at oracle.com Fri Mar 11 17:42:51 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 11 Mar 2016 09:42:51 -0800 (PST) Subject: Expounding on #ModuleNameSyntax In-Reply-To: <56D77D9C.1060401@redhat.com> References: <56D77D9C.1060401@redhat.com> Message-ID: <20160311174251.4B3FF9E877@eggemoggin.niobe.net> 2016/3/2 15:56 -0800, david.lloyd at redhat.com: > It seems to me that the syntax requirements presently established for > Jigsaw in particular are really specific to the module layer(s) handled > by the JDK. It is easy to imagine containers and other such systems > that are provided in their own layers might have different, pre-existing > syntax requirement (we have such a situation with our existing module > environment, allowing (in some layers) names with hypens, slashes, > etc.). Shouldn't syntax checking of names be a policy decision of the > module layer, rather than a global policy? New issue: http://openjdk.java.net/projects/jigsaw/spec/issues/#ModuleNameCharacters - Mark From mark.reinhold at oracle.com Fri Mar 11 17:43:51 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 11 Mar 2016 09:43:51 -0800 (PST) Subject: New issue: Layers are strictly hierarchical In-Reply-To: <56D7802A.9070305@redhat.com> References: <56D7802A.9070305@redhat.com> Message-ID: <20160311174351.4CA159E87C@eggemoggin.niobe.net> 2016/3/2 16:07 -0800, david.lloyd at redhat.com: > If there is any expectation of moving existing systems over to Jigsaw, I > think that the strict hierarchical layer system should be abandoned in > favor of a graph-oriented system. This allows containers to maintain > separate module graphs with separate namespaces which nevertheless > interconnect. > > I believe that this is a necessary requirement if (in particular) there > is an expectation that Java EE 9 (or another Java EE specification) > would be reframed in terms of Jigsaw-style modules, since Java EE module > names have many fewer restrictions, and it is possible for (for example) > more than one application to contain modules of the same name. New issue: http://openjdk.java.net/projects/jigsaw/spec/issues/#NonHierarchicalLayers > If on the other hand there is an expectation that Java EE is not going > to be retrofitted in a way which maps EE applications and modules to > Jigsaw modules, then this should be clearly declared. Of course we have that expectation -- that's why the requirements include an entire section on dynamic configuration. - Mark From mark.reinhold at oracle.com Fri Mar 11 17:44:51 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 11 Mar 2016 09:44:51 -0800 (PST) Subject: New issue: Configurations are not mutable In-Reply-To: <56D79D56.7040801@redhat.com> References: <56D79D56.7040801@redhat.com> Message-ID: <20160311174451.4E3659E881@eggemoggin.niobe.net> 2016/3/2 18:11 -0800, david.lloyd at redhat.com: > It appears from what I can see in the Jigsaw code, that once a > Configuration is calculated, it cannot be changed in any way, which > makes them unsuitable for use in containers which add and remove modules > at run time. It is not clear how such containers are expected to > function. If there is a deliberate intention that the Jigsaw system > will not support dynamic modification of layers/configurations > (including the dynamic addition and removal of modules at run time), > then that should be explicitly stated. New issue: http://openjdk.java.net/projects/jigsaw/spec/issues/#MutableConfigurations - Mark From mark.reinhold at oracle.com Fri Mar 11 17:45:51 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 11 Mar 2016 09:45:51 -0800 (PST) Subject: #AvoidConcealedPackageConflicts (and others) supplement In-Reply-To: <56D783D2.2000302@redhat.com> References: <56D783D2.2000302@redhat.com> Message-ID: <20160311174551.5004E9E886@eggemoggin.niobe.net> 2016/3/2 16:22 -0800, david.lloyd at redhat.com: > It should be noted that enforcing a 1:1 relationship between class > loaders and modules easily and conveniently solves > #AvoidConcealedPackageConflicts, #MultipleModuleVersions, and (less > obviously) #ResourceEncapsulation (by way of the existing class loader > access restriction mechanism). Over the last few months you've argued for the 1:1 loader-per-module approach, I've pointed out some fundamental difficulties with it, and no one else in the EG has supported your position. I therefore don't see a need to record this as an open issue, nor as a possible solution to any other open issue. - Mark From mark.reinhold at oracle.com Fri Mar 11 17:46:51 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 11 Mar 2016 09:46:51 -0800 (PST) Subject: New issue: ModuleClassLoader is final In-Reply-To: <56D7816D.5050406@redhat.com> References: <56D7816D.5050406@redhat.com> Message-ID: <20160311174651.51C769E88B@eggemoggin.niobe.net> 2016/3/2 19:08 -0800, david.lloyd at redhat.com: > After updating my checkout I see that this class is actually completely > gone now. Am I correct in understanding that in the current > implementation, a Layer can establish any ClassLoader for a module (via > Layer.ClassLoaderFinder)? Yes. - Mark From mark.reinhold at oracle.com Fri Mar 11 17:47:51 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 11 Mar 2016 09:47:51 -0800 (PST) Subject: New issue: run time eager module loading In-Reply-To: <56D7AE09.1030003@redhat.com> References: <56D7AE09.1030003@redhat.com> Message-ID: <20160311174751.5399C9E891@eggemoggin.niobe.net> 2016/3/2 19:22 -0800, david.lloyd at redhat.com: > It looks as though the instantiation of a Layer causes a complete load > of all the modules in the layer. What do you mean by "complete load"? Loading all the classes? > Apart from the consequent lack of > dynamicism, I think this is very likely to cause problems for large > applications, particularly if such an application might have many > operation modes, some of which do not require *all* of the bundled > modules to be loaded every single time. > > Can there not instead be an incremental resolution algorithm, akin to > how classes are lazily loaded? Configuring a set of modules and instantiating that configuration as a layer requires no more than reading the modules' descriptors. Nothing else from any module definition will be read until it's actually needed. If you really want to avoid configuring all modules in certain operation modes, do layers not provide sufficient flexibility? Load the core of your application into the boot layer, figure out which modules you need for the requested operation mode, and then create an additional layer to load those modules. - Mark From mark.reinhold at oracle.com Fri Mar 11 17:48:51 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 11 Mar 2016 09:48:51 -0800 (PST) Subject: Bikeshed-ish issue: Optional In-Reply-To: <56D7B28D.30807@redhat.com> References: <56D7B28D.30807@redhat.com> Message-ID: <20160311174851.559D69E896@eggemoggin.niobe.net> 2016/3/2 19:42 -0800, david.lloyd at redhat.com: > I notice that Jigsaw is making arguably excessive use of Optional. > Reinier Zwitzerloot [1] quoted Brian Goetz about this topic; the full > quote [2] is as follows: > > ... We recently removed the most confusing use, in the return type of ModuleDescriptor.Exports::targets, which now returns a simple Set of package names rather than an Optional>. What other specific uses would you suggest to remove? - Mark From mark.reinhold at oracle.com Fri Mar 11 17:49:51 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 11 Mar 2016 09:49:51 -0800 (PST) Subject: Issue: Modules can only open resources as streams In-Reply-To: <56D85B77.4040607@redhat.com> References: <56D85B77.4040607@redhat.com> Message-ID: <20160311174951.575F29E89B@eggemoggin.niobe.net> 2016/3/3 7:42 -0800, david.lloyd at redhat.com: > Module.getResourceAsStream() is the only way a resource can be loaded > from a module. This makes it impossible to do either of the following: > > - Determine the size of a resource in advance of loading it > - Determine the existence of a resource without opening it > > Loading resources as java.net.URLs allowed these things to be done > (among other things), however it is also disadvantageous due to the > heavyweight nature of that class. > > I had earlier come up with a simple patch [1], initially as a way to > address JDK-6865375 [2], which introduced the idea of a Resource class > that is associated with a ClassLoader, with a name, URL, size, and > stream factory method, which would also be a clean solution here (though > with the addition of a Module property as well since in Jigsaw they're > separate). > > The idea is to put resources on a similar footing to classes, whereby > you can (if suitably permitted) acquire their class loaders just like > Class.getClassLoader() allows you to do for classes. This also allows > things like ServiceLoader to load classes directly from the module which > contained the corresponding service descriptor. New issue: http://openjdk.java.net/projects/jigsaw/spec/issues/#ResourceExistenceAndSize - Mark From mark.reinhold at oracle.com Fri Mar 11 17:50:51 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 11 Mar 2016 09:50:51 -0800 (PST) Subject: Issue: The JAXP+modules story is still a bit of a mess In-Reply-To: <56DA1506.2010008@redhat.com> References: <56DA1506.2010008@redhat.com> Message-ID: <20160311175051.593F39E89F@eggemoggin.niobe.net> 2016/3/4 15:06 -0800, david.lloyd at redhat.com: > I'm not sure if this is just something that has not yet been gotten > 'round to, but the way JAXP loading works has become somewhat less > convenient. > > If you are a container author, and you need to supply your own global > default JAXP implementation classes, your options are highly limited: > you can rely on TCCL being set on every call to Xxxx.newFactory() (never > going to happen 100% of the time in reality), or you can set the > appropriate system properties and make your implementation visible from > every class loader (something of the opposite of the kind of > encapsulation that we have modules for). > > Today we do the latter, along with some "redirect" implementations of > all the major JAXP classes which allow the global default factory to be > established or changed by suitably privileged code. However, this > solution is untenable when the JDK implementation classes cannot be > accessed: the global default which is established by the JDK is now > extremely difficult to reach through any other means! > > The system property approach - really any approach to locating anything > which involves a class name without some kind of context for locating > that class (be it a module name or whatever) - is pretty outdated; it > seems like it could be a good idea at this time to add methods to allow > setting (maybe even on a one-time-only basis) a global > Supplier for each JAXP type. Is there any way this could be > accomplished? This is an issue for Java SE 9, and its forthcoming Umbrella JSR, rather than for the module system itself. - Mark From mark.reinhold at oracle.com Fri Mar 11 17:51:51 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 11 Mar 2016 09:51:51 -0800 (PST) Subject: Coupling modules and class loaders In-Reply-To: <5672FCE6.20501@redhat.com> References: <56276E91.5060605@redhat.com> <20151210012745.EFD0F849EA@eggemoggin.niobe.net> <56699CB0.6020704@redhat.com> <20151214194413.C698A85311@eggemoggin.niobe.net> <567052EB.4080403@redhat.com> <20151217162614.4CA4185A7C@eggemoggin.niobe.net> <5672FCE6.20501@redhat.com> Message-ID: <20160311175151.5B10E9E8A4@eggemoggin.niobe.net> 2015/12/17 10:20 -0800, david.lloyd at redhat.com: > ... > > The thrust of my question was intended to be regarding platform and > application class loaders. As a hopefully better approach, I'll break > it into a few (more specific) hypothetical situations which are centered > around 1:1 modules/classloaders. Some seem reasonable, some seem more > unlikely but might still be worth exploring for the purposes of thought > experimentation. > > 1. Premise: ... At this stage of the game I don't think that further rumination on such abstract scenarios is a productive use of time. We have an initial design and we are moving forward with it. If you see specific issues in the design that would prevent adoption by a future version of Java EE, or its implementations, then please (continue to) identify them. - Mark From david.lloyd at redhat.com Fri Mar 11 21:16:17 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 11 Mar 2016 15:16:17 -0600 Subject: Bikeshed-ish issue: Optional In-Reply-To: <20160311174851.559D69E896@eggemoggin.niobe.net> References: <56D7B28D.30807@redhat.com> <20160311174851.559D69E896@eggemoggin.niobe.net> Message-ID: <56E335A1.8030705@redhat.com> On 03/11/2016 11:48 AM, mark.reinhold at oracle.com wrote: > 2016/3/2 19:42 -0800, david.lloyd at redhat.com: >> I notice that Jigsaw is making arguably excessive use of Optional. >> Reinier Zwitzerloot [1] quoted Brian Goetz about this topic; the full >> quote [2] is as follows: >> >> ... > > We recently removed the most confusing use, in the return type of > ModuleDescriptor.Exports::targets, which now returns a simple Set > of package names rather than an Optional>. > > What other specific uses would you suggest to remove? I think that all of the getter-style usages are definitely not in line with the original intent of the class. This would include: ? java.lang.module.Configuration#parent() ? java.lang.module.ModuleDescriptor#mainClass() ? java.lang.module.ModuleDescriptor#osName() ? java.lang.module.ModuleDescriptor#osArch() ? java.lang.module.ModuleDescriptor#osVersion() ? java.lang.module.ModuleReference#location() The following usages also seem excessive to me, though they aren't strictly getters. There's no stream-related use for these methods that I can think of and I can't imagine a case where Optional provides a real benefit, and in some cases there's a precedent for similar methods to return null: ? java.lang.module.Configuration#findDescriptor() ? java.lang.module.Configuration#findModule() ? java.lang.module.ModuleFinder#find() ? java.lang.module.ModuleReader#find() ? java.lang.module.ModuleReader#open() ? java.lang.module.ModuleReader#read() By my count there are now more usages of Optional in java.lang.module than in all of the rest of java.base combined. It feels like what Brian was referring to as "zealous over-use" to me. -- - DML From david.lloyd at redhat.com Fri Mar 11 21:55:56 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 11 Mar 2016 15:55:56 -0600 Subject: New issue: run time eager module loading In-Reply-To: <20160311174751.5399C9E891@eggemoggin.niobe.net> References: <56D7AE09.1030003@redhat.com> <20160311174751.5399C9E891@eggemoggin.niobe.net> Message-ID: <56E33EEC.20706@redhat.com> On 03/11/2016 11:47 AM, mark.reinhold at oracle.com wrote: > 2016/3/2 19:22 -0800, david.lloyd at redhat.com: >> It looks as though the instantiation of a Layer causes a complete load >> of all the modules in the layer. > > What do you mean by "complete load"? Loading all the classes? No I mean locating and loading all of the descriptors and building all the wiring information for every module. >> Apart from the consequent lack of >> dynamicism, I think this is very likely to cause problems for large >> applications, particularly if such an application might have many >> operation modes, some of which do not require *all* of the bundled >> modules to be loaded every single time. >> >> Can there not instead be an incremental resolution algorithm, akin to >> how classes are lazily loaded? > > Configuring a set of modules and instantiating that configuration as a > layer requires no more than reading the modules' descriptors. Nothing > else from any module definition will be read until it's actually needed. But it does require that all the module descriptors from a given layer be available, and that the load time for the first load of a module in a layer will always be bounded by the size of the layer, rather than just by the dependency subgraph of the module being loaded. Based on application server deployments that I know about, I think the far upper bound for a realistic number of modules in a layer will probably lie in the thousands to ten thousands range (though there is always the outlier case where someone has to push it to see how far it goes...), which might translate into a substantial startup overhead. Another potential issue is requiring that all modules be present, though this is more closely related to #MutableConfigurations now I think; I suspect this issue could be mitigated with an acceptable solution to that issue. > If you really want to avoid configuring all modules in certain operation > modes, do layers not provide sufficient flexibility? Load the core of > your application into the boot layer, figure out which modules you need > for the requested operation mode, and then create an additional layer to > load those modules. That can work in some cases, but only if things are loaded one additional time (rather than on-demand as configuration changes, for example) or in such a way that you could just keep adding layers. But in the event of one large intermeshed layer, this won't work without #MutableConfigurations and/or #NonHierarchicalLayers and something to coordinate the load. -- - DML From david.lloyd at redhat.com Fri Mar 11 22:13:03 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 11 Mar 2016 16:13:03 -0600 Subject: Missing issue: Version string format Message-ID: <56E342EF.80303@redhat.com> The current java.lang.module.ModuleDescriptor.Version class contains the comment: "Vaguely Debian-like version strings, for now. "This will, eventually, change." At some point the syntax and semantics of version designators has to be worked out and agreed upon. Ideally the scheme would be compatible with as many existing widely deployed schemes as possible in terms of allowed syntax, and as much as possible, collation order (at least within the context of other modules from the same versioning scheme). -- - DML From forax at univ-mlv.fr Tue Mar 15 17:54:22 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 15 Mar 2016 18:54:22 +0100 (CET) Subject: New Issue: How to deprecate a module ? In-Reply-To: <711804582.1781038.1458064355622.JavaMail.zimbra@u-pem.fr> Message-ID: <1944740085.1781960.1458064462482.JavaMail.zimbra@u-pem.fr> A module declaration (in module-info) doesn't accept annotation, so it seems not possible to deprecate a module ? I think that module declaration should allow annotation (at least compile-time annotation). R?mi From pbenedict at apache.org Tue Mar 15 19:55:24 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 15 Mar 2016 14:55:24 -0500 Subject: New Issue: How to deprecate a module ? In-Reply-To: <1944740085.1781960.1458064462482.JavaMail.zimbra@u-pem.fr> References: <711804582.1781038.1458064355622.JavaMail.zimbra@u-pem.fr> <1944740085.1781960.1458064462482.JavaMail.zimbra@u-pem.fr> Message-ID: Remi's issue could also possibly tie into #StandardModuleAttributes. If the module was deprecated because it merely migrated to a new name, would it be valuable at compile-time to know what that is? If such standard module attributes come to be, please consider how deprecation relates. It might not all be that dissimilar from the Maven Repository's ability to contain relocation metadata. Cheers, Paul On Tue, Mar 15, 2016 at 12:54 PM, Remi Forax wrote: > A module declaration (in module-info) doesn't accept annotation, > so it seems not possible to deprecate a module ? > > I think that module declaration should allow annotation (at least > compile-time annotation). > > R?mi > From david.lloyd at redhat.com Mon Mar 21 13:49:22 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 21 Mar 2016 08:49:22 -0500 Subject: Missing issue: Version string format In-Reply-To: <56E342EF.80303@redhat.com> References: <56E342EF.80303@redhat.com> Message-ID: <56EFFBE2.4010609@redhat.com> On 03/11/2016 04:13 PM, David M. Lloyd wrote: > The current java.lang.module.ModuleDescriptor.Version class contains the > comment: > > "Vaguely Debian-like version strings, for now. > "This will, eventually, change." > > At some point the syntax and semantics of version designators has to be > worked out and agreed upon. Ideally the scheme would be compatible with > as many existing widely deployed schemes as possible in terms of allowed > syntax, and as much as possible, collation order (at least within the > context of other modules from the same versioning scheme). Judging from the lack of response, I assume that nobody has done any work on this, so I have a proposal. *** PLEASE review this in detail and post responses and criticisms ASAP. I am interpreting silence as agreement/approval! *** In particular, the syntax and collation rules could use some discussion! ?Version Requirements? Versions must abide by a consistent, easily describable syntax. Versions must support as many widely-used versioning schemes as possible, in a manner which is as interoperable as possible. Versions must collate in a manner consistent with expectations in terms of existing systems, to the maximum extent possible. ?Version Syntax? I propose that a version conform to the following EBNF syntax: alpha = ? all Unicode letters (open for discussion) ? number = ? all Unicode digits (open for discussion) ? separator = "-" | "+" | "_" | "." | ? alpha-to-number transition ? | ? number-to-alpha transition ? part = number* | alpha* version = part { separator part } The special transitions mean that strings such as "8u12" will count as a three-part version "8" (sep) "u" (sep) "12" and would collate as such. ?Unicode considerations? All version components would be normalized in NFKC form, in order to ensure consistent collation. ?Collation? Versions shall abide by the following collation rules. Each part and separator in the version contributes to collation order. Since a version is comprised of strictly alternating parts and separators, there is no sensible or defined collation order between parts and separators. Number parts shall sort before alpha parts. The sort order for separators should be as follows: ? transitions sort highest (first) ? underscores "_" sort next ? pluses "+" sort next ? hyphens "-" sort next ? dots "." sort lowest (last) ?Compatibility? OpenJDK and Oracle JDK versions follow a few different mildly complex schemes but can be more simply characterized by a few examples which are valid in different contexts: ? 1.3.0 ? 1.3.1-beta ? 1.3.1_05-ea ? 1.8.0_66-b17 ? 8u66 ? 9-ea All of these examples will parse and collate in a manner that seems consistent with expectations. OSGi versions are in the form: number "." number "." number [ "." ? any string ? ]. Due to the arbitrary nature of the optional final (qualifier) segment, there exist a set of OSGi versions which are not strictly compatible with this scheme, and a set of OSGi versions which are compatible but whose collation order might be affected by this scheme. Maven versions are highly under-specified, but using the org.sonatype.aether.util.version.GenericVersion class as a reference indicates that Maven is employing a similar scheme, including empty "transition" separators, with the exception that all separators appear to be considered equal. This may cause certain projects to collate differently, for example in the event that the separator was switched from "-" to "." along a branch's development lifecycle. In addition, certain strings such as "alpha", "beta" etc. are specially detected and ordered. However, other than the "ga" or "final" string, these strings already collate naturally, and it is a fairly common practice to rely on natural collation regardless, which may mitigate interoperability issues. Debian versions allow ":" and "~" characters, and also allow parts to be empty, both of which are extensions that could be applied to this scheme if desired, as long as collation rules could be worked out for them. ?Implementation? Two implementation approaches seem obvious. The first approach uses an internal linked list comprised of alternating segments of parts and separators. Parts and separators have collation methods which consider the current part or separator, then fall back to the next link (if any). This approach is simple and elegant, however has substantial memory overhead due to the number of objects required (for example, the string "1.8.0_66-b17" requires six parts and five separators for a total of 11 objects, which seems excessive). The second approach simply stores the content as a string, and uses an internal tokenizer to parse, validate, and collate. This approach may be slightly more verbose in implementation but should be far more memory-efficient, generally requiring one or two temporary object allocations per parse/collate operation, and otherwise only requiring the memory necessary to hold the String object of the version plus the memory requirements of the Version object itself. The existing Version class is designed more for simplicity than efficiency, using Lists of boxed objects internally and so forth. While this is adequate for prototyping, I think the latter String/tokenizer based design is a better long-term solution and that is what I will pursue unless there is a strong argument otherwise. Looking forward to discussion, -- - DML From david.lloyd at redhat.com Mon Mar 21 14:14:15 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 21 Mar 2016 09:14:15 -0500 Subject: Issue: Modules can only open resources as streams In-Reply-To: <56D85B77.4040607@redhat.com> References: <56D85B77.4040607@redhat.com> Message-ID: <56F001B7.6030006@redhat.com> On 03/03/2016 09:42 AM, David M. Lloyd wrote: > Module.getResourceAsStream() is the only way a resource can be loaded > from a module. This makes it impossible to do either of the following: > > ? Determine the size of a resource in advance of loading it > ? Determine the existence of a resource without opening it > > Loading resources as java.net.URLs allowed these things to be done > (among other things), however it is also disadvantageous due to the > heavyweight nature of that class. > > I had earlier come up with a simple patch [1], initially as a way to > address JDK-6865375 [2], which introduced the idea of a Resource class > that is associated with a ClassLoader, with a name, URL, size, and > stream factory method, which would also be a clean solution here (though > with the addition of a Module property as well since in Jigsaw they're > separate). > > The idea is to put resources on a similar footing to classes, whereby > you can (if suitably permitted) acquire their class loaders just like > Class.getClassLoader() allows you to do for classes. This also allows > things like ServiceLoader to load classes directly from the module which > contained the corresponding service descriptor. > > [1] > https://github.com/dmlloyd/openjdk-modules/commit/d9ab5a4b51f63d71d0ff5bdb0625ea3fa149f90c > > [2] https://bugs.openjdk.java.net/browse/JDK-6865375 Without any further discussion I'm going to assume complete agreement with the definition and acceptance of the problem and (at least the general gist of) the proposed solution. If any of you disagree with this issue on any basis, PLEASE speak up ASAP otherwise I will assume that the group is in agreement! -- - DML From david.lloyd at redhat.com Mon Mar 21 14:18:11 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 21 Mar 2016 09:18:11 -0500 Subject: #MutableConfigurations (Re: New issue: Configurations are not mutable) In-Reply-To: <20160311174451.4E3659E881@eggemoggin.niobe.net> References: <56D79D56.7040801@redhat.com> <20160311174451.4E3659E881@eggemoggin.niobe.net> Message-ID: <56F002A3.3050707@redhat.com> On 03/11/2016 11:44 AM, mark.reinhold at oracle.com wrote: > 2016/3/2 18:11 -0800, david.lloyd at redhat.com: >> It appears from what I can see in the Jigsaw code, that once a >> Configuration is calculated, it cannot be changed in any way, which >> makes them unsuitable for use in containers which add and remove modules >> at run time. It is not clear how such containers are expected to >> function. If there is a deliberate intention that the Jigsaw system >> will not support dynamic modification of layers/configurations >> (including the dynamic addition and removal of modules at run time), >> then that should be explicitly stated. > > New issue: http://openjdk.java.net/projects/jigsaw/spec/issues/#MutableConfigurations In the absence of further discussion, I am going to assume that the expert group is in agreement that working mutable Configurations are part of the acceptance criteria for this JSR. If you disagree please speak up ASAP - even if your objection is presently nonspecific - I am taking silence to mean assent of the entire group! -- - DML From david.lloyd at redhat.com Mon Mar 21 14:25:13 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 21 Mar 2016 09:25:13 -0500 Subject: Expounding on #ModuleNameSyntax In-Reply-To: <20160311174251.4B3FF9E877@eggemoggin.niobe.net> References: <56D77D9C.1060401@redhat.com> <20160311174251.4B3FF9E877@eggemoggin.niobe.net> Message-ID: <56F00449.5050707@redhat.com> On 03/11/2016 11:42 AM, mark.reinhold at oracle.com wrote: > 2016/3/2 15:56 -0800, david.lloyd at redhat.com: >> It seems to me that the syntax requirements presently established for >> Jigsaw in particular are really specific to the module layer(s) handled >> by the JDK. It is easy to imagine containers and other such systems >> that are provided in their own layers might have different, pre-existing >> syntax requirement (we have such a situation with our existing module >> environment, allowing (in some layers) names with hypens, slashes, >> etc.). Shouldn't syntax checking of names be a policy decision of the >> module layer, rather than a global policy? > > New issue: http://openjdk.java.net/projects/jigsaw/spec/issues/#ModuleNameCharacters In the absence of expert group discussion I am assuming that everyone is in agreement that each layer should have complete autonomy in terms of module name validation. If you disagree or have other discussion points to raise, please respond ASAP, as silence will be interpreted as agreement of the group! -- - DML From david.lloyd at redhat.com Mon Mar 21 15:43:52 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 21 Mar 2016 10:43:52 -0500 Subject: Missing issue: Version string format In-Reply-To: <56EFFBE2.4010609@redhat.com> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> Message-ID: <56F016B8.5060505@redhat.com> On 03/21/2016 08:49 AM, David M. Lloyd wrote: > On 03/11/2016 04:13 PM, David M. Lloyd wrote: >> The current java.lang.module.ModuleDescriptor.Version class contains the >> comment: >> >> "Vaguely Debian-like version strings, for now. >> "This will, eventually, change." >> >> At some point the syntax and semantics of version designators has to be >> worked out and agreed upon. Ideally the scheme would be compatible with >> as many existing widely deployed schemes as possible in terms of allowed >> syntax, and as much as possible, collation order (at least within the >> context of other modules from the same versioning scheme). > > Judging from the lack of response, I assume that nobody has done any > work on this, so I have a proposal. I just updated to the latest code and it looks like last week the scheme was updated. I would reframe this discussion into a proposal a few changes from the existing code. ? Addition of a few more separator characters: the new code supports "+", "-", and ".", and also the transition types. It does not support "_" which I believe to be in fairly wide use. I would propose that this character be added as a valid separator. ? The current code uses multiple "classes" of separators, which also depend on their location within the version string. I suggest that if possible, a version sequence be agnostic to scheme, or else make versions layer-specific (similar to the #ModuleNameCharacters issue); I think the scheme I outlined would support all of the currently supported schemes with little or no adjustment. ? The implementation is probably considerably heavier than it needs to be in terms of objects. A zero-object representation is possible, as is a one- or zero-object tokenizer/validator. Unless someone has an early strong disagreement, I will prepare a prototype to illustrate the changes. > > *** PLEASE review this in detail and post responses and criticisms ASAP. > I am interpreting silence as agreement/approval! *** > > In particular, the syntax and collation rules could use some discussion! > > ?Version Requirements? > > Versions must abide by a consistent, easily describable syntax. > > Versions must support as many widely-used versioning schemes as > possible, in a manner which is as interoperable as possible. > > Versions must collate in a manner consistent with expectations in terms > of existing systems, to the maximum extent possible. > > ?Version Syntax? > > I propose that a version conform to the following EBNF syntax: > > alpha = ? all Unicode letters (open for discussion) ? > number = ? all Unicode digits (open for discussion) ? > separator = "-" | "+" | "_" | "." | ? alpha-to-number transition ? | > ? number-to-alpha transition ? > part = number* | alpha* > version = part { separator part } > > The special transitions mean that strings such as "8u12" will count as a > three-part version "8" (sep) "u" (sep) "12" and would collate as such. > > ?Unicode considerations? > > All version components would be normalized in NFKC form, in order to > ensure consistent collation. > > ?Collation? > > Versions shall abide by the following collation rules. > > Each part and separator in the version contributes to collation order. > Since a version is comprised of strictly alternating parts and > separators, there is no sensible or defined collation order between > parts and separators. > > Number parts shall sort before alpha parts. > > The sort order for separators should be as follows: > ? transitions sort highest (first) > ? underscores "_" sort next > ? pluses "+" sort next > ? hyphens "-" sort next > ? dots "." sort lowest (last) > > ?Compatibility? > > OpenJDK and Oracle JDK versions follow a few different mildly complex > schemes but can be more simply characterized by a few examples which are > valid in different contexts: > ? 1.3.0 > ? 1.3.1-beta > ? 1.3.1_05-ea > ? 1.8.0_66-b17 > ? 8u66 > ? 9-ea > > All of these examples will parse and collate in a manner that seems > consistent with expectations. > > OSGi versions are in the form: number "." number "." number [ "." ? any > string ? ]. Due to the arbitrary nature of the optional final > (qualifier) segment, there exist a set of OSGi versions which are not > strictly compatible with this scheme, and a set of OSGi versions which > are compatible but whose collation order might be affected by this scheme. > > Maven versions are highly under-specified, but using the > org.sonatype.aether.util.version.GenericVersion class as a reference > indicates that Maven is employing a similar scheme, including empty > "transition" separators, with the exception that all separators appear > to be considered equal. This may cause certain projects to collate > differently, for example in the event that the separator was switched > from "-" to "." along a branch's development lifecycle. In addition, > certain strings such as "alpha", "beta" etc. are specially detected and > ordered. However, other than the "ga" or "final" string, these strings > already collate naturally, and it is a fairly common practice to rely on > natural collation regardless, which may mitigate interoperability issues. > > Debian versions allow ":" and "~" characters, and also allow parts to be > empty, both of which are extensions that could be applied to this scheme > if desired, as long as collation rules could be worked out for them. > > ?Implementation? > > Two implementation approaches seem obvious. > > The first approach uses an internal linked list comprised of alternating > segments of parts and separators. Parts and separators have collation > methods which consider the current part or separator, then fall back to > the next link (if any). This approach is simple and elegant, however > has substantial memory overhead due to the number of objects required > (for example, the string "1.8.0_66-b17" requires six parts and five > separators for a total of 11 objects, which seems excessive). > > The second approach simply stores the content as a string, and uses an > internal tokenizer to parse, validate, and collate. This approach may > be slightly more verbose in implementation but should be far more > memory-efficient, generally requiring one or two temporary object > allocations per parse/collate operation, and otherwise only requiring > the memory necessary to hold the String object of the version plus the > memory requirements of the Version object itself. > > The existing Version class is designed more for simplicity than > efficiency, using Lists of boxed objects internally and so forth. While > this is adequate for prototyping, I think the latter String/tokenizer > based design is a better long-term solution and that is what I will > pursue unless there is a strong argument otherwise. > > Looking forward to discussion, -- - DML From forax at univ-mlv.fr Mon Mar 21 16:07:31 2016 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 21 Mar 2016 16:07:31 +0000 Subject: Expounding on #ModuleNameSyntax In-Reply-To: <56F00449.5050707@redhat.com> References: <56D77D9C.1060401@redhat.com> <20160311174251.4B3FF9E877@eggemoggin.niobe.net> <56F00449.5050707@redhat.com> Message-ID: I agree. R?mi Le 21 mars 2016 15:25:13 CET, "David M. Lloyd" a ?crit : >On 03/11/2016 11:42 AM, mark.reinhold at oracle.com wrote: >> 2016/3/2 15:56 -0800, david.lloyd at redhat.com: >>> It seems to me that the syntax requirements presently established >for >>> Jigsaw in particular are really specific to the module layer(s) >handled >>> by the JDK. It is easy to imagine containers and other such systems >>> that are provided in their own layers might have different, >pre-existing >>> syntax requirement (we have such a situation with our existing >module >>> environment, allowing (in some layers) names with hypens, slashes, >>> etc.). Shouldn't syntax checking of names be a policy decision of >the >>> module layer, rather than a global policy? >> >> New issue: >http://openjdk.java.net/projects/jigsaw/spec/issues/#ModuleNameCharacters > >In the absence of expert group discussion I am assuming that everyone >is >in agreement that each layer should have complete autonomy in terms of >module name validation. If you disagree or have other discussion >points >to raise, please respond ASAP, as silence will be interpreted as >agreement of the group! From david.lloyd at redhat.com Mon Mar 21 19:44:35 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 21 Mar 2016 14:44:35 -0500 Subject: Missing issue: Version string format In-Reply-To: <56F016B8.5060505@redhat.com> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> Message-ID: <56F04F23.5070904@redhat.com> On 03/21/2016 10:43 AM, David M. Lloyd wrote: > On 03/21/2016 08:49 AM, David M. Lloyd wrote: >> On 03/11/2016 04:13 PM, David M. Lloyd wrote: >>> The current java.lang.module.ModuleDescriptor.Version class contains the >>> comment: >>> >>> "Vaguely Debian-like version strings, for now. >>> "This will, eventually, change." >>> >>> At some point the syntax and semantics of version designators has to be >>> worked out and agreed upon. Ideally the scheme would be compatible with >>> as many existing widely deployed schemes as possible in terms of allowed >>> syntax, and as much as possible, collation order (at least within the >>> context of other modules from the same versioning scheme). >> >> Judging from the lack of response, I assume that nobody has done any >> work on this, so I have a proposal. > > I just updated to the latest code and it looks like last week the scheme > was updated. > > I would reframe this discussion into a proposal a few changes from the > existing code. > > ? Addition of a few more separator characters: the new code supports > "+", "-", and ".", and also the transition types. It does not support > "_" which I believe to be in fairly wide use. I would propose that this > character be added as a valid separator. > ? The current code uses multiple "classes" of separators, which also > depend on their location within the version string. I suggest that if > possible, a version sequence be agnostic to scheme, or else make > versions layer-specific (similar to the #ModuleNameCharacters issue); I > think the scheme I outlined would support all of the currently supported > schemes with little or no adjustment. > ? The implementation is probably considerably heavier than it needs to > be in terms of objects. A zero-object representation is possible, as is > a one- or zero-object tokenizer/validator. > > Unless someone has an early strong disagreement, I will prepare a > prototype to illustrate the changes. I want to expand on this just a little more. I think it is worth dividing the concept of a version scheme from the concept of syntax of a version string. The former should be specific to a layer, and the latter should be (if possible) global. This allows layers to enforce policy that makes sense to that layer, while also allowing predictable (if not intuitive) interoperability between version schemes. My change will create a general parsing scheme for versions as previously described, and move the specific validation rules to the existent layers to which they are relevant, as necessary to pass tests. -- - DML From forax at univ-mlv.fr Tue Mar 22 00:30:59 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 22 Mar 2016 01:30:59 +0100 (CET) Subject: Missing issue: Version string format In-Reply-To: <56F04F23.5070904@redhat.com> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> Message-ID: <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> Hi David, maybe a stupid question but given that there is no need for a version of a module in the JDK, why do you want the JDK to reify the version value as a specific object with weird rules, why not considering that it can be any string (like in the JVM classfile format) ? regards, R?mi ----- Mail original ----- > De: "David M. Lloyd" > ?: jpms-spec-experts at openjdk.java.net > Envoy?: Lundi 21 Mars 2016 20:44:35 > Objet: Re: Missing issue: Version string format > > On 03/21/2016 10:43 AM, David M. Lloyd wrote: > > On 03/21/2016 08:49 AM, David M. Lloyd wrote: > >> On 03/11/2016 04:13 PM, David M. Lloyd wrote: > >>> The current java.lang.module.ModuleDescriptor.Version class contains the > >>> comment: > >>> > >>> "Vaguely Debian-like version strings, for now. > >>> "This will, eventually, change." > >>> > >>> At some point the syntax and semantics of version designators has to be > >>> worked out and agreed upon. Ideally the scheme would be compatible with > >>> as many existing widely deployed schemes as possible in terms of allowed > >>> syntax, and as much as possible, collation order (at least within the > >>> context of other modules from the same versioning scheme). > >> > >> Judging from the lack of response, I assume that nobody has done any > >> work on this, so I have a proposal. > > > > I just updated to the latest code and it looks like last week the scheme > > was updated. > > > > I would reframe this discussion into a proposal a few changes from the > > existing code. > > > > ? Addition of a few more separator characters: the new code supports > > "+", "-", and ".", and also the transition types. It does not support > > "_" which I believe to be in fairly wide use. I would propose that this > > character be added as a valid separator. > > ? The current code uses multiple "classes" of separators, which also > > depend on their location within the version string. I suggest that if > > possible, a version sequence be agnostic to scheme, or else make > > versions layer-specific (similar to the #ModuleNameCharacters issue); I > > think the scheme I outlined would support all of the currently supported > > schemes with little or no adjustment. > > ? The implementation is probably considerably heavier than it needs to > > be in terms of objects. A zero-object representation is possible, as is > > a one- or zero-object tokenizer/validator. > > > > Unless someone has an early strong disagreement, I will prepare a > > prototype to illustrate the changes. > > I want to expand on this just a little more. I think it is worth > dividing the concept of a version scheme from the concept of syntax of a > version string. The former should be specific to a layer, and the > latter should be (if possible) global. This allows layers to enforce > policy that makes sense to that layer, while also allowing predictable > (if not intuitive) interoperability between version schemes. > > My change will create a general parsing scheme for versions as > previously described, and move the specific validation rules to the > existent layers to which they are relevant, as necessary to pass tests. > -- > - DML > From forax at univ-mlv.fr Tue Mar 22 00:39:28 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 22 Mar 2016 01:39:28 +0100 (CET) Subject: Issue: Modules can only open resources as streams In-Reply-To: <56F001B7.6030006@redhat.com> References: <56D85B77.4040607@redhat.com> <56F001B7.6030006@redhat.com> Message-ID: <500316063.1088451.1458607168931.JavaMail.zimbra@u-pem.fr> Hi David, usually, instead of using an URL, you can use an URI and if you want the info then create an URL from the URI. Does adding a new method getResourceAsURI() is not enough ? R?mi ----- Mail original ----- > De: "David M. Lloyd" > ?: jpms-spec-experts at openjdk.java.net > Envoy?: Lundi 21 Mars 2016 15:14:15 > Objet: Re: Issue: Modules can only open resources as streams > > On 03/03/2016 09:42 AM, David M. Lloyd wrote: > > Module.getResourceAsStream() is the only way a resource can be loaded > > from a module. This makes it impossible to do either of the following: > > > > ? Determine the size of a resource in advance of loading it > > ? Determine the existence of a resource without opening it > > > > Loading resources as java.net.URLs allowed these things to be done > > (among other things), however it is also disadvantageous due to the > > heavyweight nature of that class. > > > > I had earlier come up with a simple patch [1], initially as a way to > > address JDK-6865375 [2], which introduced the idea of a Resource class > > that is associated with a ClassLoader, with a name, URL, size, and > > stream factory method, which would also be a clean solution here (though > > with the addition of a Module property as well since in Jigsaw they're > > separate). > > > > The idea is to put resources on a similar footing to classes, whereby > > you can (if suitably permitted) acquire their class loaders just like > > Class.getClassLoader() allows you to do for classes. This also allows > > things like ServiceLoader to load classes directly from the module which > > contained the corresponding service descriptor. > > > > [1] > > https://github.com/dmlloyd/openjdk-modules/commit/d9ab5a4b51f63d71d0ff5bdb0625ea3fa149f90c > > > > [2] https://bugs.openjdk.java.net/browse/JDK-6865375 > > Without any further discussion I'm going to assume complete agreement > with the definition and acceptance of the problem and (at least the > general gist of) the proposed solution. If any of you disagree with > this issue on any basis, PLEASE speak up ASAP otherwise I will assume > that the group is in agreement! > > -- > - DML > From david.lloyd at redhat.com Tue Mar 22 00:56:46 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 21 Mar 2016 19:56:46 -0500 Subject: Missing issue: Version string format In-Reply-To: <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> Message-ID: <56F0984E.1010900@redhat.com> I'd be okay with that personally. It would certainly be less code. :) Having a general version syntax and collation system is generally useful but it's a bit more of an abstract sort of usefulness. On 03/21/2016 07:30 PM, Remi Forax wrote: > Hi David, > maybe a stupid question but > given that there is no need for a version of a module in the JDK, > why do you want the JDK to reify the version value as a specific object with weird rules, > why not considering that it can be any string (like in the JVM classfile format) ? > > regards, > R?mi > > ----- Mail original ----- >> De: "David M. Lloyd" >> ?: jpms-spec-experts at openjdk.java.net >> Envoy?: Lundi 21 Mars 2016 20:44:35 >> Objet: Re: Missing issue: Version string format >> >> On 03/21/2016 10:43 AM, David M. Lloyd wrote: >>> On 03/21/2016 08:49 AM, David M. Lloyd wrote: >>>> On 03/11/2016 04:13 PM, David M. Lloyd wrote: >>>>> The current java.lang.module.ModuleDescriptor.Version class contains the >>>>> comment: >>>>> >>>>> "Vaguely Debian-like version strings, for now. >>>>> "This will, eventually, change." >>>>> >>>>> At some point the syntax and semantics of version designators has to be >>>>> worked out and agreed upon. Ideally the scheme would be compatible with >>>>> as many existing widely deployed schemes as possible in terms of allowed >>>>> syntax, and as much as possible, collation order (at least within the >>>>> context of other modules from the same versioning scheme). >>>> >>>> Judging from the lack of response, I assume that nobody has done any >>>> work on this, so I have a proposal. >>> >>> I just updated to the latest code and it looks like last week the scheme >>> was updated. >>> >>> I would reframe this discussion into a proposal a few changes from the >>> existing code. >>> >>> ? Addition of a few more separator characters: the new code supports >>> "+", "-", and ".", and also the transition types. It does not support >>> "_" which I believe to be in fairly wide use. I would propose that this >>> character be added as a valid separator. >>> ? The current code uses multiple "classes" of separators, which also >>> depend on their location within the version string. I suggest that if >>> possible, a version sequence be agnostic to scheme, or else make >>> versions layer-specific (similar to the #ModuleNameCharacters issue); I >>> think the scheme I outlined would support all of the currently supported >>> schemes with little or no adjustment. >>> ? The implementation is probably considerably heavier than it needs to >>> be in terms of objects. A zero-object representation is possible, as is >>> a one- or zero-object tokenizer/validator. >>> >>> Unless someone has an early strong disagreement, I will prepare a >>> prototype to illustrate the changes. >> >> I want to expand on this just a little more. I think it is worth >> dividing the concept of a version scheme from the concept of syntax of a >> version string. The former should be specific to a layer, and the >> latter should be (if possible) global. This allows layers to enforce >> policy that makes sense to that layer, while also allowing predictable >> (if not intuitive) interoperability between version schemes. >> >> My change will create a general parsing scheme for versions as >> previously described, and move the specific validation rules to the >> existent layers to which they are relevant, as necessary to pass tests. >> -- >> - DML >> -- - DML From david.lloyd at redhat.com Tue Mar 22 13:02:54 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 22 Mar 2016 08:02:54 -0500 Subject: Issue: Modules can only open resources as streams In-Reply-To: <500316063.1088451.1458607168931.JavaMail.zimbra@u-pem.fr> References: <56D85B77.4040607@redhat.com> <56F001B7.6030006@redhat.com> <500316063.1088451.1458607168931.JavaMail.zimbra@u-pem.fr> Message-ID: <56F1427E.1060102@redhat.com> URI is definitely better than URL. However it doesn't really solve the points I listed below. It would really be useful for a resource to be a handle with size, stream, and origin class loader/module fields. On 03/21/2016 07:39 PM, Remi Forax wrote: > Hi David, > usually, instead of using an URL, you can use an URI and if you want the info then create an URL from the URI. > > Does adding a new method getResourceAsURI() is not enough ? > > R?mi > > ----- Mail original ----- >> De: "David M. Lloyd" >> ?: jpms-spec-experts at openjdk.java.net >> Envoy?: Lundi 21 Mars 2016 15:14:15 >> Objet: Re: Issue: Modules can only open resources as streams >> >> On 03/03/2016 09:42 AM, David M. Lloyd wrote: >>> Module.getResourceAsStream() is the only way a resource can be loaded >>> from a module. This makes it impossible to do either of the following: >>> >>> ? Determine the size of a resource in advance of loading it >>> ? Determine the existence of a resource without opening it >>> >>> Loading resources as java.net.URLs allowed these things to be done >>> (among other things), however it is also disadvantageous due to the >>> heavyweight nature of that class. >>> >>> I had earlier come up with a simple patch [1], initially as a way to >>> address JDK-6865375 [2], which introduced the idea of a Resource class >>> that is associated with a ClassLoader, with a name, URL, size, and >>> stream factory method, which would also be a clean solution here (though >>> with the addition of a Module property as well since in Jigsaw they're >>> separate). >>> >>> The idea is to put resources on a similar footing to classes, whereby >>> you can (if suitably permitted) acquire their class loaders just like >>> Class.getClassLoader() allows you to do for classes. This also allows >>> things like ServiceLoader to load classes directly from the module which >>> contained the corresponding service descriptor. >>> >>> [1] >>> https://github.com/dmlloyd/openjdk-modules/commit/d9ab5a4b51f63d71d0ff5bdb0625ea3fa149f90c >>> >>> [2] https://bugs.openjdk.java.net/browse/JDK-6865375 >> >> Without any further discussion I'm going to assume complete agreement >> with the definition and acceptance of the problem and (at least the >> general gist of) the proposed solution. If any of you disagree with >> this issue on any basis, PLEASE speak up ASAP otherwise I will assume >> that the group is in agreement! >> >> -- >> - DML >> -- - DML From forax at univ-mlv.fr Tue Mar 22 17:13:31 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 22 Mar 2016 18:13:31 +0100 (CET) Subject: Issue: Modules can only open resources as streams In-Reply-To: <56F1427E.1060102@redhat.com> References: <56D85B77.4040607@redhat.com> <56F001B7.6030006@redhat.com> <500316063.1088451.1458607168931.JavaMail.zimbra@u-pem.fr> <56F1427E.1060102@redhat.com> Message-ID: <1007712673.1899774.1458666811381.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "David M. Lloyd" > ?: "Remi Forax" > Cc: jpms-spec-experts at openjdk.java.net > Envoy?: Mardi 22 Mars 2016 14:02:54 > Objet: Re: Issue: Modules can only open resources as streams > > URI is definitely better than URL. However it doesn't really solve the > points I listed below. It would really be useful for a resource to be a > handle with size, stream, and origin class loader/module fields. from an URI, you can call toURL() and get access to the size, the stream etc. thinking a little more on this, you can already have access to the URI of a resource of a module by using the ModuleReader, from the ModuleReference, from the Configuration, from the Layer ... try(ModuleReader reader = module.getLayer().configuration().findModule(module.getName()).get().reference().open()) { Optional uri = reader.find(resourseName); ... } obviously, directly exposing the ModuleReader might be a good idea :) R?mi > > On 03/21/2016 07:39 PM, Remi Forax wrote: > > Hi David, > > usually, instead of using an URL, you can use an URI and if you want the > > info then create an URL from the URI. > > > > Does adding a new method getResourceAsURI() is not enough ? > > > > R?mi > > > > ----- Mail original ----- > >> De: "David M. Lloyd" > >> ?: jpms-spec-experts at openjdk.java.net > >> Envoy?: Lundi 21 Mars 2016 15:14:15 > >> Objet: Re: Issue: Modules can only open resources as streams > >> > >> On 03/03/2016 09:42 AM, David M. Lloyd wrote: > >>> Module.getResourceAsStream() is the only way a resource can be loaded > >>> from a module. This makes it impossible to do either of the following: > >>> > >>> ? Determine the size of a resource in advance of loading it > >>> ? Determine the existence of a resource without opening it > >>> > >>> Loading resources as java.net.URLs allowed these things to be done > >>> (among other things), however it is also disadvantageous due to the > >>> heavyweight nature of that class. > >>> > >>> I had earlier come up with a simple patch [1], initially as a way to > >>> address JDK-6865375 [2], which introduced the idea of a Resource class > >>> that is associated with a ClassLoader, with a name, URL, size, and > >>> stream factory method, which would also be a clean solution here (though > >>> with the addition of a Module property as well since in Jigsaw they're > >>> separate). > >>> > >>> The idea is to put resources on a similar footing to classes, whereby > >>> you can (if suitably permitted) acquire their class loaders just like > >>> Class.getClassLoader() allows you to do for classes. This also allows > >>> things like ServiceLoader to load classes directly from the module which > >>> contained the corresponding service descriptor. > >>> > >>> [1] > >>> https://github.com/dmlloyd/openjdk-modules/commit/d9ab5a4b51f63d71d0ff5bdb0625ea3fa149f90c > >>> > >>> [2] https://bugs.openjdk.java.net/browse/JDK-6865375 > >> > >> Without any further discussion I'm going to assume complete agreement > >> with the definition and acceptance of the problem and (at least the > >> general gist of) the proposed solution. If any of you disagree with > >> this issue on any basis, PLEASE speak up ASAP otherwise I will assume > >> that the group is in agreement! > >> > >> -- > >> - DML > >> > > -- > - DML > From david.lloyd at redhat.com Tue Mar 22 21:02:38 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 22 Mar 2016 16:02:38 -0500 Subject: Issue: Modules can only open resources as streams In-Reply-To: <1007712673.1899774.1458666811381.JavaMail.zimbra@u-pem.fr> References: <56D85B77.4040607@redhat.com> <56F001B7.6030006@redhat.com> <500316063.1088451.1458607168931.JavaMail.zimbra@u-pem.fr> <56F1427E.1060102@redhat.com> <1007712673.1899774.1458666811381.JavaMail.zimbra@u-pem.fr> Message-ID: <56F1B2EE.2010509@redhat.com> On 03/22/2016 12:13 PM, forax at univ-mlv.fr wrote: > ----- Mail original ----- >> De: "David M. Lloyd" >> ?: "Remi Forax" >> Cc: jpms-spec-experts at openjdk.java.net >> Envoy?: Mardi 22 Mars 2016 14:02:54 >> Objet: Re: Issue: Modules can only open resources as streams >> >> URI is definitely better than URL. However it doesn't really solve the >> points I listed below. It would really be useful for a resource to be a >> handle with size, stream, and origin class loader/module fields. > > from an URI, you can call toURL() and get access to the size, the stream etc. > > thinking a little more on this, you can already have access to the URI of a resource of a module by using the ModuleReader, from the ModuleReference, from the Configuration, from the Layer ... > > try(ModuleReader reader = module.getLayer().configuration().findModule(module.getName()).get().reference().open()) { > Optional uri = reader.find(resourseName); > ... > } > > obviously, directly exposing the ModuleReader might be a good idea :) Knowing which module your resource came from is definitely a key requirement. I'm not sure what URI actually will benefit in this case though. Not only do you have to switch it to URL to actually use it to load anything, but by returning URI, modules lose the ability to send back URLs with custom behaviors. Also it means that every resource needs an absolute location, which is an unnecessary constraint as far as I can see. -- - DML From forax at univ-mlv.fr Tue Mar 22 21:40:24 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 22 Mar 2016 22:40:24 +0100 (CET) Subject: Issue: Modules can only open resources as streams In-Reply-To: <56F1B2EE.2010509@redhat.com> References: <56D85B77.4040607@redhat.com> <56F001B7.6030006@redhat.com> <500316063.1088451.1458607168931.JavaMail.zimbra@u-pem.fr> <56F1427E.1060102@redhat.com> <1007712673.1899774.1458666811381.JavaMail.zimbra@u-pem.fr> <56F1B2EE.2010509@redhat.com> Message-ID: <1859089609.1958479.1458682824742.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "David M. Lloyd" > ?: forax at univ-mlv.fr > Cc: jpms-spec-experts at openjdk.java.net > Envoy?: Mardi 22 Mars 2016 22:02:38 > Objet: Re: Issue: Modules can only open resources as streams > > On 03/22/2016 12:13 PM, forax at univ-mlv.fr wrote: > > ----- Mail original ----- > >> De: "David M. Lloyd" > >> ?: "Remi Forax" > >> Cc: jpms-spec-experts at openjdk.java.net > >> Envoy?: Mardi 22 Mars 2016 14:02:54 > >> Objet: Re: Issue: Modules can only open resources as streams > >> > >> URI is definitely better than URL. However it doesn't really solve the > >> points I listed below. It would really be useful for a resource to be a > >> handle with size, stream, and origin class loader/module fields. > > > > from an URI, you can call toURL() and get access to the size, the stream > > etc. > > > > thinking a little more on this, you can already have access to the URI of a > > resource of a module by using the ModuleReader, from the ModuleReference, > > from the Configuration, from the Layer ... > > > > try(ModuleReader reader = > > module.getLayer().configuration().findModule(module.getName()).get().reference().open()) > > { > > Optional uri = reader.find(resourseName); > > ... > > } > > > > obviously, directly exposing the ModuleReader might be a good idea :) > > Knowing which module your resource came from is definitely a key > requirement. I'm not sure what URI actually will benefit in this case > though. Not only do you have to switch it to URL to actually use it to > load anything, but by returning URI, modules lose the ability to send > back URLs with custom behaviors. Also it means that every resource > needs an absolute location, which is an unnecessary constraint as far as > I can see. not an absolute location per se, like an URI of a resource inside a jar, the URI is composed of the name of the module and the name of the resource. > > -- > - DML > R?mi From david.lloyd at redhat.com Tue Mar 22 22:27:07 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 22 Mar 2016 17:27:07 -0500 Subject: Issue: Modules can only open resources as streams In-Reply-To: <1859089609.1958479.1458682824742.JavaMail.zimbra@u-pem.fr> References: <56D85B77.4040607@redhat.com> <56F001B7.6030006@redhat.com> <500316063.1088451.1458607168931.JavaMail.zimbra@u-pem.fr> <56F1427E.1060102@redhat.com> <1007712673.1899774.1458666811381.JavaMail.zimbra@u-pem.fr> <56F1B2EE.2010509@redhat.com> <1859089609.1958479.1458682824742.JavaMail.zimbra@u-pem.fr> Message-ID: <56F1C6BB.4030203@redhat.com> On 03/22/2016 04:40 PM, forax at univ-mlv.fr wrote: > > > ----- Mail original ----- >> De: "David M. Lloyd" >> ?: forax at univ-mlv.fr >> Cc: jpms-spec-experts at openjdk.java.net >> Envoy?: Mardi 22 Mars 2016 22:02:38 >> Objet: Re: Issue: Modules can only open resources as streams >> >> On 03/22/2016 12:13 PM, forax at univ-mlv.fr wrote: >>> ----- Mail original ----- >>>> De: "David M. Lloyd" >>>> ?: "Remi Forax" >>>> Cc: jpms-spec-experts at openjdk.java.net >>>> Envoy?: Mardi 22 Mars 2016 14:02:54 >>>> Objet: Re: Issue: Modules can only open resources as streams >>>> >>>> URI is definitely better than URL. However it doesn't really solve the >>>> points I listed below. It would really be useful for a resource to be a >>>> handle with size, stream, and origin class loader/module fields. >>> >>> from an URI, you can call toURL() and get access to the size, the stream >>> etc. >>> >>> thinking a little more on this, you can already have access to the URI of a >>> resource of a module by using the ModuleReader, from the ModuleReference, >>> from the Configuration, from the Layer ... >>> >>> try(ModuleReader reader = >>> module.getLayer().configuration().findModule(module.getName()).get().reference().open()) >>> { >>> Optional uri = reader.find(resourseName); >>> ... >>> } >>> >>> obviously, directly exposing the ModuleReader might be a good idea :) >> >> Knowing which module your resource came from is definitely a key >> requirement. I'm not sure what URI actually will benefit in this case >> though. Not only do you have to switch it to URL to actually use it to >> load anything, but by returning URI, modules lose the ability to send >> back URLs with custom behaviors. Also it means that every resource >> needs an absolute location, which is an unnecessary constraint as far as >> I can see. > > not an absolute location per se, like an URI of a resource inside a jar, > the URI is composed of the name of the module and the name of the resource. An absolute module name is only useful in the context of the default layer. To support multiple layers, especially if we move to a non-hierarchical model, every layer would need its own URI scheme (and probably a corresponding registered URL protocol handler) or else some kind of global registration, which might or might not make sense and might be unnecessarily complex (especially if your resource is just coming from, say, a JAR file, and would be served just as well using a classical jar: URL). To support module-specific naming schemes, the URI might end up having to be awkwardly encoded. Better to keep the module name out of the URL altogether. -- - DML From david.lloyd at redhat.com Wed Mar 23 14:20:26 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 23 Mar 2016 09:20:26 -0500 Subject: Alternative Version implementation In-Reply-To: <56F0984E.1010900@redhat.com> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> Message-ID: <56F2A62A.1040808@redhat.com> I've gone ahead and written a new Version implementation that implements the rules I've described. It seems to work OK though I am having a hard time running all tests locally due to some environmental problem that I'm still working on, so I don't have a webrev yet. But I do have a diff that can be examined (and commented upon) at [1]. The features of this implementation are: * Defines a single, unified version syntax and collation order without defining a versioning policy * Internally only contains one field, a String, which should provide a minimal memory footprint compared to the multiple List approach * Can be iterated piece-wise using a public Version.Iterator class (also lightweight), which allows user-defined validation via e.g. Predicate to be easily implemented * Internal validation and collation logic uses a simple objectless iteration (tokenizer-based) system by way of "cookie" values that represent iteration state, which are reused by the aforementioned Iterator class * A bit more Unicode-friendly, as iteration operates on a code point basis rather than on a character basis The unresolved issues of this implementation are: * It was my intention to apply Unicode normalization to the input String, however the Version class is required to be used at an earlier stage than Normalizer can be used so there's a bootstrap-related NPE if that code is enabled * There is no hook to provide a layer-specific validation policy; Configuration seems to be the logical place for this but it's not clear how it can be hooked in to the resolution process because of the tight coupling between Configurations and resolution... resolving #ModuleNameCharacters will probably provide an answer to this as well * Needs additional dedicated tests (all testing thus far has been manual) * Need to review/examine/discuss the collation rules (particularly around separators), which I mainly just pulled out of my hat, to determine what makes the most sense from a first-use perspective as well as a compatibility perspective (OSGi, Maven, packaging systems etc.) I will follow up with a webrev at some point in the future unless anyone wants to discuss or possibly reject this approach. R?mi has already pointed out that a plain version String is possibly the simplest/best approach; I think part of this discussion must revolve around whether unifying on a version system is desirable. My position is that there is value to be gained by unification (particularly around a common collation scheme), but the compatibility path may be a tricky one. [1] https://github.com/dmlloyd/openjdk-modules/compare/jigsaw/jake...version -- - DML From david.lloyd at redhat.com Wed Mar 23 14:38:03 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 23 Mar 2016 09:38:03 -0500 Subject: Alternative Version implementation In-Reply-To: <56F2A62A.1040808@redhat.com> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> <56F2A62A.1040808@redhat.com> Message-ID: <56F2AA4B.2020409@redhat.com> On 03/23/2016 09:20 AM, David M. Lloyd wrote: > I've gone ahead and written a new Version implementation that implements > the rules I've described. It seems to work OK though I am having a hard > time running all tests locally due to some environmental problem that > I'm still working on, so I don't have a webrev yet. But I do have a > diff that can be examined (and commented upon) at [1]. > > The features of this implementation are: > > * Defines a single, unified version syntax and collation order without > defining a versioning policy > * Internally only contains one field, a String, which should provide a > minimal memory footprint compared to the multiple List approach > * Can be iterated piece-wise using a public Version.Iterator class (also > lightweight), which allows user-defined validation via e.g. > Predicate to be easily implemented > * Internal validation and collation logic uses a simple objectless > iteration (tokenizer-based) system by way of "cookie" values that > represent iteration state, which are reused by the aforementioned > Iterator class > * A bit more Unicode-friendly, as iteration operates on a code point > basis rather than on a character basis > > The unresolved issues of this implementation are: > > * It was my intention to apply Unicode normalization to the input > String, however the Version class is required to be used at an earlier > stage than Normalizer can be used so there's a bootstrap-related NPE if > that code is enabled > * There is no hook to provide a layer-specific validation policy; > Configuration seems to be the logical place for this but it's not clear > how it can be hooked in to the resolution process because of the tight > coupling between Configurations and resolution... resolving > #ModuleNameCharacters will probably provide an answer to this as well > * Needs additional dedicated tests (all testing thus far has been manual) > * Need to review/examine/discuss the collation rules (particularly > around separators), which I mainly just pulled out of my hat, to > determine what makes the most sense from a first-use perspective as well > as a compatibility perspective (OSGi, Maven, packaging systems etc.) > > I will follow up with a webrev at some point in the future unless anyone > wants to discuss or possibly reject this approach. R?mi has already > pointed out that a plain version String is possibly the simplest/best > approach; I think part of this discussion must revolve around whether > unifying on a version system is desirable. My position is that there is > value to be gained by unification (particularly around a common > collation scheme), but the compatibility path may be a tricky one. > > [1] > https://github.com/dmlloyd/openjdk-modules/compare/jigsaw/jake...version It was pointed out by Reinier Zwitserloot that the ordering I had proposed for numeric versus textual parts was backwards. I've updated the code accordingly, but you can still see the previous version at this [2] link. [2] https://github.com/dmlloyd/openjdk-modules/commit/2fe57f574483814eee6b72f82111dc2b44952c2d -- - DML From david.lloyd at redhat.com Wed Mar 23 17:13:50 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 23 Mar 2016 12:13:50 -0500 Subject: Alternative Version implementation In-Reply-To: <56F2AA4B.2020409@redhat.com> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> <56F2A62A.1040808@redhat.com> <56F2AA4B.2020409@redhat.com> Message-ID: <56F2CECE.9040204@redhat.com> On 03/23/2016 09:38 AM, David M. Lloyd wrote: > On 03/23/2016 09:20 AM, David M. Lloyd wrote: >> I've gone ahead and written a new Version implementation that implements >> the rules I've described. It seems to work OK though I am having a hard >> time running all tests locally due to some environmental problem that >> I'm still working on, so I don't have a webrev yet. But I do have a >> diff that can be examined (and commented upon) at [1]. >> >> The features of this implementation are: >> >> * Defines a single, unified version syntax and collation order without >> defining a versioning policy >> * Internally only contains one field, a String, which should provide a >> minimal memory footprint compared to the multiple List approach >> * Can be iterated piece-wise using a public Version.Iterator class (also >> lightweight), which allows user-defined validation via e.g. >> Predicate to be easily implemented >> * Internal validation and collation logic uses a simple objectless >> iteration (tokenizer-based) system by way of "cookie" values that >> represent iteration state, which are reused by the aforementioned >> Iterator class >> * A bit more Unicode-friendly, as iteration operates on a code point >> basis rather than on a character basis >> >> The unresolved issues of this implementation are: >> >> * It was my intention to apply Unicode normalization to the input >> String, however the Version class is required to be used at an earlier >> stage than Normalizer can be used so there's a bootstrap-related NPE if >> that code is enabled >> * There is no hook to provide a layer-specific validation policy; >> Configuration seems to be the logical place for this but it's not clear >> how it can be hooked in to the resolution process because of the tight >> coupling between Configurations and resolution... resolving >> #ModuleNameCharacters will probably provide an answer to this as well >> * Needs additional dedicated tests (all testing thus far has been manual) >> * Need to review/examine/discuss the collation rules (particularly >> around separators), which I mainly just pulled out of my hat, to >> determine what makes the most sense from a first-use perspective as well >> as a compatibility perspective (OSGi, Maven, packaging systems etc.) >> >> I will follow up with a webrev at some point in the future unless anyone >> wants to discuss or possibly reject this approach. R?mi has already >> pointed out that a plain version String is possibly the simplest/best >> approach; I think part of this discussion must revolve around whether >> unifying on a version system is desirable. My position is that there is >> value to be gained by unification (particularly around a common >> collation scheme), but the compatibility path may be a tricky one. >> >> [1] >> https://github.com/dmlloyd/openjdk-modules/compare/jigsaw/jake...version > > It was pointed out by Reinier Zwitserloot that the ordering I had > proposed for numeric versus textual parts was backwards. I've updated > the code accordingly, but you can still see the previous version at this > [2] link. > > [2] > https://github.com/dmlloyd/openjdk-modules/commit/2fe57f574483814eee6b72f82111dc2b44952c2d Later in this same discussion, Reinier argues that version pairs whose collation is conventionally ambiguous (e.g. 1.0 vs 1.0.0) should not be compared or collated at all. I argued that a stable sort relationship is worth more in this case than undefined behavior, and that a stable sort is in fact an acceptable result when the expectation is that the result is undefined. He followed up arguing that this kind of behavior *should* be defined, but as an error rather than a particular sort result. The roles and behaviors of multiple types of separators was not brought up in this discussion but is probably relevant since it complicates the concept of conventional ambiguity. I still favor a consistent, well-defined behavior which matches existing schemes to the maximum extent possible. -- - DML From david.lloyd at redhat.com Wed Mar 23 18:46:01 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 23 Mar 2016 13:46:01 -0500 Subject: Alternative Version implementation In-Reply-To: <56F2A62A.1040808@redhat.com> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> <56F2A62A.1040808@redhat.com> Message-ID: <56F2E469.1050207@redhat.com> On 03/23/2016 09:20 AM, David M. Lloyd wrote: > I've gone ahead and written a new Version implementation that implements > the rules I've described. It seems to work OK though I am having a hard > time running all tests locally due to some environmental problem that > I'm still working on, so I don't have a webrev yet. But I do have a > diff that can be examined (and commented upon) at [1]. One oddity that springs up relating to numeric versions when not normalizing the version string in any way is that version segments leading zeros parse and sort strangely. After fiddling around with various approaches, currently I've settled on this order: 1 1.0 1.1 1.00 1.01 1.10 1.11 1.000 1.001 1.010 1.011 1.100 1.101 1.110 1.111 Wherein versions are sorted for length first, then for value. However that might be counter-intuitive if your expectation is that (for example) 1.0 is equal to 1.00 or at least sorts immediately before or after it. A good case could be made that versions should be normalized to strip leading zeros, and I believe the previous implementation did this (either intentionally or unintentionally) as an implementation side-effect. The downside of normalization is the extra work and extra String being produced as a result. A third option would be to reject version segments with leading zeros, which prevents the problem from coming up and also avoids the extra copy work, making the "number" production look like: number = ? Unicode decimal digit with values 1-9 ? { ? Unicode decimal digit ? } Any thoughts on this would be appreciated. -- - DML From pbenedict at apache.org Wed Mar 23 18:53:01 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 23 Mar 2016 13:53:01 -0500 Subject: Alternative Version implementation In-Reply-To: <56F2E469.1050207@redhat.com> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> <56F2A62A.1040808@redhat.com> <56F2E469.1050207@redhat.com> Message-ID: For any of the EG members observing this list, I find David's collating order acceptable and expected. I am not privy to Reiner's particular discussion, but it is my opinion that 1.0 should precede 1.0.0. Although both are numerically equal, one is more precise -- ambiguity should be first, precision last. I don't find this to be any different than the alphanumerical nature of a phone book where A would precede AA. That's not a perfect analogy but it gets my point across. Cheers, Paul On Wed, Mar 23, 2016 at 1:46 PM, David M. Lloyd wrote: > On 03/23/2016 09:20 AM, David M. Lloyd wrote: > >> I've gone ahead and written a new Version implementation that implements >> the rules I've described. It seems to work OK though I am having a hard >> time running all tests locally due to some environmental problem that >> I'm still working on, so I don't have a webrev yet. But I do have a >> diff that can be examined (and commented upon) at [1]. >> > > One oddity that springs up relating to numeric versions when not > normalizing the version string in any way is that version segments leading > zeros parse and sort strangely. After fiddling around with various > approaches, currently I've settled on this order: > > 1 > 1.0 > 1.1 > 1.00 > 1.01 > 1.10 > 1.11 > 1.000 > 1.001 > 1.010 > 1.011 > 1.100 > 1.101 > 1.110 > 1.111 > > Wherein versions are sorted for length first, then for value. However > that might be counter-intuitive if your expectation is that (for example) > 1.0 is equal to 1.00 or at least sorts immediately before or after it. A > good case could be made that versions should be normalized to strip leading > zeros, and I believe the previous implementation did this (either > intentionally or unintentionally) as an implementation side-effect. The > downside of normalization is the extra work and extra String being produced > as a result. > > A third option would be to reject version segments with leading zeros, > which prevents the problem from coming up and also avoids the extra copy > work, making the "number" production look like: > > number = ? Unicode decimal digit with values 1-9 ? { ? Unicode decimal > digit ? } > > Any thoughts on this would be appreciated. > -- > - DML > From neil.bartlett at paremus.com Wed Mar 23 20:01:05 2016 From: neil.bartlett at paremus.com (Neil Bartlett (Paremus)) Date: Wed, 23 Mar 2016 20:01:05 +0000 Subject: Alternative Version implementation In-Reply-To: References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> <56F2A62A.1040808@redhat.com> <56F2E469.1050207@redhat.com> Message-ID: Hi Paul and David, You may consider this collation order intuitive, but it?s clearly incompatible with existing version systems; in particular I?m thinking of those used in OSGi and Maven. I really don?t know to what extent this matters, as it was my understanding that JSR 376 would not define versioning of modules and that this are would be left to the discretion of external tools such as build systems. David can you explain the work you are doing in this context? Regards, Neil > On 23 Mar 2016, at 18:53, Paul Benedict wrote: > > For any of the EG members observing this list, > > I find David's collating order acceptable and expected. I am not privy to > Reiner's particular discussion, but it is my opinion that 1.0 should > precede 1.0.0. Although both are numerically equal, one is more precise -- > ambiguity should be first, precision last. I don't find this to be any > different than the alphanumerical nature of a phone book where A would > precede AA. That's not a perfect analogy but it gets my point across. > > Cheers, > Paul > > On Wed, Mar 23, 2016 at 1:46 PM, David M. Lloyd > wrote: > >> On 03/23/2016 09:20 AM, David M. Lloyd wrote: >> >>> I've gone ahead and written a new Version implementation that implements >>> the rules I've described. It seems to work OK though I am having a hard >>> time running all tests locally due to some environmental problem that >>> I'm still working on, so I don't have a webrev yet. But I do have a >>> diff that can be examined (and commented upon) at [1]. >>> >> >> One oddity that springs up relating to numeric versions when not >> normalizing the version string in any way is that version segments leading >> zeros parse and sort strangely. After fiddling around with various >> approaches, currently I've settled on this order: >> >> 1 >> 1.0 >> 1.1 >> 1.00 >> 1.01 >> 1.10 >> 1.11 >> 1.000 >> 1.001 >> 1.010 >> 1.011 >> 1.100 >> 1.101 >> 1.110 >> 1.111 >> >> Wherein versions are sorted for length first, then for value. However >> that might be counter-intuitive if your expectation is that (for example) >> 1.0 is equal to 1.00 or at least sorts immediately before or after it. A >> good case could be made that versions should be normalized to strip leading >> zeros, and I believe the previous implementation did this (either >> intentionally or unintentionally) as an implementation side-effect. The >> downside of normalization is the extra work and extra String being produced >> as a result. >> >> A third option would be to reject version segments with leading zeros, >> which prevents the problem from coming up and also avoids the extra copy >> work, making the "number" production look like: >> >> number = ? Unicode decimal digit with values 1-9 ? { ? Unicode decimal >> digit ? } >> >> Any thoughts on this would be appreciated. >> -- >> - DML >> From pbenedict at apache.org Wed Mar 23 20:10:39 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 23 Mar 2016 15:10:39 -0500 Subject: Alternative Version implementation In-Reply-To: References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> <56F2A62A.1040808@redhat.com> <56F2E469.1050207@redhat.com> Message-ID: Neil, I believe you're right regarding how JSR 376 will not define versions. David can speak for himself, but I didn't get the impression he is proposing a "de facto" way of what a version scheme is. His class just encompasses the many versioning schemes out in the wild so they can be parsed and inspected by a single class. I don't see any incompatibility with OSGi and Maven here, per se, since their schemes is just one of many. David's code does give a universal way to collate with these schemes, which I find appealing. Cheers, Paul On Wed, Mar 23, 2016 at 3:01 PM, Neil Bartlett (Paremus) < neil.bartlett at paremus.com> wrote: > Hi Paul and David, > > You may consider this collation order intuitive, but it?s clearly > incompatible with existing version systems; in particular I?m thinking of > those used in OSGi and Maven. > > I really don?t know to what extent this matters, as it was my > understanding that JSR 376 would not define versioning of modules and that > this are would be left to the discretion of external tools such as build > systems. David can you explain the work you are doing in this context? > > Regards, > Neil > > > > On 23 Mar 2016, at 18:53, Paul Benedict wrote: > > > > For any of the EG members observing this list, > > > > I find David's collating order acceptable and expected. I am not privy to > > Reiner's particular discussion, but it is my opinion that 1.0 should > > precede 1.0.0. Although both are numerically equal, one is more precise > -- > > ambiguity should be first, precision last. I don't find this to be any > > different than the alphanumerical nature of a phone book where A would > > precede AA. That's not a perfect analogy but it gets my point across. > > > > Cheers, > > Paul > > > > On Wed, Mar 23, 2016 at 1:46 PM, David M. Lloyd > > wrote: > > > >> On 03/23/2016 09:20 AM, David M. Lloyd wrote: > >> > >>> I've gone ahead and written a new Version implementation that > implements > >>> the rules I've described. It seems to work OK though I am having a > hard > >>> time running all tests locally due to some environmental problem that > >>> I'm still working on, so I don't have a webrev yet. But I do have a > >>> diff that can be examined (and commented upon) at [1]. > >>> > >> > >> One oddity that springs up relating to numeric versions when not > >> normalizing the version string in any way is that version segments > leading > >> zeros parse and sort strangely. After fiddling around with various > >> approaches, currently I've settled on this order: > >> > >> 1 > >> 1.0 > >> 1.1 > >> 1.00 > >> 1.01 > >> 1.10 > >> 1.11 > >> 1.000 > >> 1.001 > >> 1.010 > >> 1.011 > >> 1.100 > >> 1.101 > >> 1.110 > >> 1.111 > >> > >> Wherein versions are sorted for length first, then for value. However > >> that might be counter-intuitive if your expectation is that (for > example) > >> 1.0 is equal to 1.00 or at least sorts immediately before or after it. > A > >> good case could be made that versions should be normalized to strip > leading > >> zeros, and I believe the previous implementation did this (either > >> intentionally or unintentionally) as an implementation side-effect. The > >> downside of normalization is the extra work and extra String being > produced > >> as a result. > >> > >> A third option would be to reject version segments with leading zeros, > >> which prevents the problem from coming up and also avoids the extra copy > >> work, making the "number" production look like: > >> > >> number = ? Unicode decimal digit with values 1-9 ? { ? Unicode decimal > >> digit ? } > >> > >> Any thoughts on this would be appreciated. > >> -- > >> - DML > >> > > From david.lloyd at redhat.com Wed Mar 23 20:23:01 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 23 Mar 2016 15:23:01 -0500 Subject: Alternative Version implementation In-Reply-To: References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> <56F2A62A.1040808@redhat.com> <56F2E469.1050207@redhat.com> Message-ID: <56F2FB25.9020402@redhat.com> The OSGi specification allows (from what I can tell) arbitrary strings for the last segment and that is definitely incompatible with the notion of these more general version rules... this is the only difference I can find though, and many practical examples of OSGi versions should continue to work, which at least yields the possibility of moving forward. Are there additional scenarios you can identify? Maven on the other hand does not really have a specification, so I just referred to of existing examples and they seem to function as expected. The work I'm doing is intended as something of a bridge between what is in place now (a structure which is designed for use in the JDK and which implies a strict syntactical and semantic format which is incompatible with a very large number of existing schemes and version numbers) and a way to allow each layer to impose its own policy. But I think what you are implying is that you share my interpretation of R?mi Forax's opinion that a plain string is a better version identifier, with no sorting/comparison or validation logic, putting 100% of the responsibility for interpretation and validation of the version string to the layer which defines the module. Is my understanding of your position correct? On 03/23/2016 03:01 PM, Neil Bartlett (Paremus) wrote: > Hi Paul and David, > > You may consider this collation order intuitive, but it?s clearly incompatible with existing version systems; in particular I?m thinking of those used in OSGi and Maven. > > I really don?t know to what extent this matters, as it was my understanding that JSR 376 would not define versioning of modules and that this are would be left to the discretion of external tools such as build systems. David can you explain the work you are doing in this context? > > Regards, > Neil > > >> On 23 Mar 2016, at 18:53, Paul Benedict wrote: >> >> For any of the EG members observing this list, >> >> I find David's collating order acceptable and expected. I am not privy to >> Reiner's particular discussion, but it is my opinion that 1.0 should >> precede 1.0.0. Although both are numerically equal, one is more precise -- >> ambiguity should be first, precision last. I don't find this to be any >> different than the alphanumerical nature of a phone book where A would >> precede AA. That's not a perfect analogy but it gets my point across. >> >> Cheers, >> Paul >> >> On Wed, Mar 23, 2016 at 1:46 PM, David M. Lloyd >> wrote: >> >>> On 03/23/2016 09:20 AM, David M. Lloyd wrote: >>> >>>> I've gone ahead and written a new Version implementation that implements >>>> the rules I've described. It seems to work OK though I am having a hard >>>> time running all tests locally due to some environmental problem that >>>> I'm still working on, so I don't have a webrev yet. But I do have a >>>> diff that can be examined (and commented upon) at [1]. >>>> >>> >>> One oddity that springs up relating to numeric versions when not >>> normalizing the version string in any way is that version segments leading >>> zeros parse and sort strangely. After fiddling around with various >>> approaches, currently I've settled on this order: >>> >>> 1 >>> 1.0 >>> 1.1 >>> 1.00 >>> 1.01 >>> 1.10 >>> 1.11 >>> 1.000 >>> 1.001 >>> 1.010 >>> 1.011 >>> 1.100 >>> 1.101 >>> 1.110 >>> 1.111 >>> >>> Wherein versions are sorted for length first, then for value. However >>> that might be counter-intuitive if your expectation is that (for example) >>> 1.0 is equal to 1.00 or at least sorts immediately before or after it. A >>> good case could be made that versions should be normalized to strip leading >>> zeros, and I believe the previous implementation did this (either >>> intentionally or unintentionally) as an implementation side-effect. The >>> downside of normalization is the extra work and extra String being produced >>> as a result. >>> >>> A third option would be to reject version segments with leading zeros, >>> which prevents the problem from coming up and also avoids the extra copy >>> work, making the "number" production look like: >>> >>> number = ? Unicode decimal digit with values 1-9 ? { ? Unicode decimal >>> digit ? } >>> >>> Any thoughts on this would be appreciated. >>> -- >>> - DML >>> > -- - DML From neil.bartlett at paremus.com Wed Mar 23 20:23:08 2016 From: neil.bartlett at paremus.com (Neil Bartlett (Paremus)) Date: Wed, 23 Mar 2016 20:23:08 +0000 Subject: Alternative Version implementation In-Reply-To: References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> <56F2A62A.1040808@redhat.com> <56F2E469.1050207@redhat.com> Message-ID: <09883AAF-D90C-4672-9F76-EE57430C2FB4@paremus.com> The incompatibility with OSGi is easy enough to illustrate ? Maven less so because, as David says, Maven versions are chronically underspecified. In OSGi, version 1 and 1.0 and 1.0.0 are strictly identical, with the former two being nothing more than abbreviations for the latter. Also David?s scheme for implicit separators when transitioning between numeric and alphabet characters does not work with OSGi?s qualifier segment, which is a single alphanumeric (plus hyphen and underscore) string that is collated with String.compare(). Again, I?m struggling to see the motivation. I believe that a universal scheme is impossible ? it?s a circle that can?t be squared, especially when you try to encompass the versions used by Java releases like ?8u66?. So if it?s not universal and it?s not to be adopted by JSR 376, what is the intended purpose? Neil > On 23 Mar 2016, at 20:10, Paul Benedict wrote: > > Neil, I believe you're right regarding how JSR 376 will not define versions. David can speak for himself, but I didn't get the impression he is proposing a "de facto" way of what a version scheme is. His class just encompasses the many versioning schemes out in the wild so they can be parsed and inspected by a single class. I don't see any incompatibility with OSGi and Maven here, per se, since their schemes is just one of many. David's code does give a universal way to collate with these schemes, which I find appealing. > > Cheers, > Paul > > On Wed, Mar 23, 2016 at 3:01 PM, Neil Bartlett (Paremus) > wrote: > Hi Paul and David, > > You may consider this collation order intuitive, but it?s clearly incompatible with existing version systems; in particular I?m thinking of those used in OSGi and Maven. > > I really don?t know to what extent this matters, as it was my understanding that JSR 376 would not define versioning of modules and that this are would be left to the discretion of external tools such as build systems. David can you explain the work you are doing in this context? > > Regards, > Neil > > > > On 23 Mar 2016, at 18:53, Paul Benedict > wrote: > > > > For any of the EG members observing this list, > > > > I find David's collating order acceptable and expected. I am not privy to > > Reiner's particular discussion, but it is my opinion that 1.0 should > > precede 1.0.0. Although both are numerically equal, one is more precise -- > > ambiguity should be first, precision last. I don't find this to be any > > different than the alphanumerical nature of a phone book where A would > > precede AA. That's not a perfect analogy but it gets my point across. > > > > Cheers, > > Paul > > > > On Wed, Mar 23, 2016 at 1:46 PM, David M. Lloyd > > > wrote: > > > >> On 03/23/2016 09:20 AM, David M. Lloyd wrote: > >> > >>> I've gone ahead and written a new Version implementation that implements > >>> the rules I've described. It seems to work OK though I am having a hard > >>> time running all tests locally due to some environmental problem that > >>> I'm still working on, so I don't have a webrev yet. But I do have a > >>> diff that can be examined (and commented upon) at [1]. > >>> > >> > >> One oddity that springs up relating to numeric versions when not > >> normalizing the version string in any way is that version segments leading > >> zeros parse and sort strangely. After fiddling around with various > >> approaches, currently I've settled on this order: > >> > >> 1 > >> 1.0 > >> 1.1 > >> 1.00 > >> 1.01 > >> 1.10 > >> 1.11 > >> 1.000 > >> 1.001 > >> 1.010 > >> 1.011 > >> 1.100 > >> 1.101 > >> 1.110 > >> 1.111 > >> > >> Wherein versions are sorted for length first, then for value. However > >> that might be counter-intuitive if your expectation is that (for example) > >> 1.0 is equal to 1.00 or at least sorts immediately before or after it. A > >> good case could be made that versions should be normalized to strip leading > >> zeros, and I believe the previous implementation did this (either > >> intentionally or unintentionally) as an implementation side-effect. The > >> downside of normalization is the extra work and extra String being produced > >> as a result. > >> > >> A third option would be to reject version segments with leading zeros, > >> which prevents the problem from coming up and also avoids the extra copy > >> work, making the "number" production look like: > >> > >> number = ? Unicode decimal digit with values 1-9 ? { ? Unicode decimal > >> digit ? } > >> > >> Any thoughts on this would be appreciated. > >> -- > >> - DML > >> > > From pbenedict at apache.org Wed Mar 23 20:34:10 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 23 Mar 2016 15:34:10 -0500 Subject: Alternative Version implementation In-Reply-To: <09883AAF-D90C-4672-9F76-EE57430C2FB4@paremus.com> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> <56F2A62A.1040808@redhat.com> <56F2E469.1050207@redhat.com> <09883AAF-D90C-4672-9F76-EE57430C2FB4@paremus.com> Message-ID: Neil, when you say "In OSGi, version 1 and 1.0 and 1.0.0 are strictly identical", I don't disagree. You can be numerically equivalent but collated different. You can either leave the collation undefined or define some sort of ordering. David chose the latter. Are we maybe talking pass each other on equivalency vs. collation? Cheers, Paul On Wed, Mar 23, 2016 at 3:23 PM, Neil Bartlett (Paremus) < neil.bartlett at paremus.com> wrote: > The incompatibility with OSGi is easy enough to illustrate ? Maven less so > because, as David says, Maven versions are chronically underspecified. In > OSGi, version 1 and 1.0 and 1.0.0 are strictly identical, with the former > two being nothing more than abbreviations for the latter. Also David?s > scheme for implicit separators when transitioning between numeric and > alphabet characters does not work with OSGi?s qualifier segment, which is a > single alphanumeric (plus hyphen and underscore) string that is collated > with String.compare(). > > Again, I?m struggling to see the motivation. I believe that a universal > scheme is impossible ? it?s a circle that can?t be squared, especially when > you try to encompass the versions used by Java releases like ?8u66?. So if > it?s not universal and it?s not to be adopted by JSR 376, what is the > intended purpose? > > Neil > > On 23 Mar 2016, at 20:10, Paul Benedict wrote: > > Neil, I believe you're right regarding how JSR 376 will not define > versions. David can speak for himself, but I didn't get the impression he > is proposing a "de facto" way of what a version scheme is. His class just > encompasses the many versioning schemes out in the wild so they can be > parsed and inspected by a single class. I don't see any incompatibility > with OSGi and Maven here, per se, since their schemes is just one of many. > David's code does give a universal way to collate with these schemes, which > I find appealing. > > Cheers, > Paul > > On Wed, Mar 23, 2016 at 3:01 PM, Neil Bartlett (Paremus) < > neil.bartlett at paremus.com> wrote: > >> Hi Paul and David, >> >> You may consider this collation order intuitive, but it?s clearly >> incompatible with existing version systems; in particular I?m thinking of >> those used in OSGi and Maven. >> >> I really don?t know to what extent this matters, as it was my >> understanding that JSR 376 would not define versioning of modules and that >> this are would be left to the discretion of external tools such as build >> systems. David can you explain the work you are doing in this context? >> >> Regards, >> Neil >> >> >> > On 23 Mar 2016, at 18:53, Paul Benedict wrote: >> > >> > For any of the EG members observing this list, >> > >> > I find David's collating order acceptable and expected. I am not privy >> to >> > Reiner's particular discussion, but it is my opinion that 1.0 should >> > precede 1.0.0. Although both are numerically equal, one is more precise >> -- >> > ambiguity should be first, precision last. I don't find this to be any >> > different than the alphanumerical nature of a phone book where A would >> > precede AA. That's not a perfect analogy but it gets my point across. >> > >> > Cheers, >> > Paul >> > >> > On Wed, Mar 23, 2016 at 1:46 PM, David M. Lloyd > > >> > wrote: >> > >> >> On 03/23/2016 09:20 AM, David M. Lloyd wrote: >> >> >> >>> I've gone ahead and written a new Version implementation that >> implements >> >>> the rules I've described. It seems to work OK though I am having a >> hard >> >>> time running all tests locally due to some environmental problem that >> >>> I'm still working on, so I don't have a webrev yet. But I do have a >> >>> diff that can be examined (and commented upon) at [1]. >> >>> >> >> >> >> One oddity that springs up relating to numeric versions when not >> >> normalizing the version string in any way is that version segments >> leading >> >> zeros parse and sort strangely. After fiddling around with various >> >> approaches, currently I've settled on this order: >> >> >> >> 1 >> >> 1.0 >> >> 1.1 >> >> 1.00 >> >> 1.01 >> >> 1.10 >> >> 1.11 >> >> 1.000 >> >> 1.001 >> >> 1.010 >> >> 1.011 >> >> 1.100 >> >> 1.101 >> >> 1.110 >> >> 1.111 >> >> >> >> Wherein versions are sorted for length first, then for value. However >> >> that might be counter-intuitive if your expectation is that (for >> example) >> >> 1.0 is equal to 1.00 or at least sorts immediately before or after >> it. A >> >> good case could be made that versions should be normalized to strip >> leading >> >> zeros, and I believe the previous implementation did this (either >> >> intentionally or unintentionally) as an implementation side-effect. >> The >> >> downside of normalization is the extra work and extra String being >> produced >> >> as a result. >> >> >> >> A third option would be to reject version segments with leading zeros, >> >> which prevents the problem from coming up and also avoids the extra >> copy >> >> work, making the "number" production look like: >> >> >> >> number = ? Unicode decimal digit with values 1-9 ? { ? Unicode >> decimal >> >> digit ? } >> >> >> >> Any thoughts on this would be appreciated. >> >> -- >> >> - DML >> >> >> >> > > From neil.bartlett at paremus.com Wed Mar 23 20:44:14 2016 From: neil.bartlett at paremus.com (Neil Bartlett (Paremus)) Date: Wed, 23 Mar 2016 20:44:14 +0000 Subject: Alternative Version implementation In-Reply-To: <56F2FB25.9020402@redhat.com> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> <56F2A62A.1040808@redhat.com> <56F2E469.1050207@redhat.com> <56F2FB25.9020402@redhat.com> Message-ID: Thanks David, I should have awaited your reply before responding to Paul. See that email for more specifics on OSGi versions. I wasn?t implying anything about agreement with Remi Forax or anybody else. In this case, my question was really just a question. However I am skeptical about the practical feasibility of creating a version scheme that can bring together all the existing practices. I am also very concerned with your the suggested collation order in which 1.1 sorts before 1.00. This is subjective of course, but I find it highly counter-intuitive. If the segment looks like a number then it should act like a number, unless all segments are explicitly defined as strings with alphanumeric sorting. Neil > On 23 Mar 2016, at 20:23, David M. Lloyd wrote: > > The OSGi specification allows (from what I can tell) arbitrary strings for the last segment and that is definitely incompatible with the notion of these more general version rules... this is the only difference I can find though, and many practical examples of OSGi versions should continue to work, which at least yields the possibility of moving forward. Are there additional scenarios you can identify? > > Maven on the other hand does not really have a specification, so I just referred to of existing examples and they seem to function as expected. > > The work I'm doing is intended as something of a bridge between what is in place now (a structure which is designed for use in the JDK and which implies a strict syntactical and semantic format which is incompatible with a very large number of existing schemes and version numbers) and a way to allow each layer to impose its own policy. But I think what you are implying is that you share my interpretation of R?mi Forax's opinion that a plain string is a better version identifier, with no sorting/comparison or validation logic, putting 100% of the responsibility for interpretation and validation of the version string to the layer which defines the module. Is my understanding of your position correct? > > On 03/23/2016 03:01 PM, Neil Bartlett (Paremus) wrote: >> Hi Paul and David, >> >> You may consider this collation order intuitive, but it?s clearly incompatible with existing version systems; in particular I?m thinking of those used in OSGi and Maven. >> >> I really don?t know to what extent this matters, as it was my understanding that JSR 376 would not define versioning of modules and that this are would be left to the discretion of external tools such as build systems. David can you explain the work you are doing in this context? >> >> Regards, >> Neil >> >> >>> On 23 Mar 2016, at 18:53, Paul Benedict wrote: >>> >>> For any of the EG members observing this list, >>> >>> I find David's collating order acceptable and expected. I am not privy to >>> Reiner's particular discussion, but it is my opinion that 1.0 should >>> precede 1.0.0. Although both are numerically equal, one is more precise -- >>> ambiguity should be first, precision last. I don't find this to be any >>> different than the alphanumerical nature of a phone book where A would >>> precede AA. That's not a perfect analogy but it gets my point across. >>> >>> Cheers, >>> Paul >>> >>> On Wed, Mar 23, 2016 at 1:46 PM, David M. Lloyd >>> wrote: >>> >>>> On 03/23/2016 09:20 AM, David M. Lloyd wrote: >>>> >>>>> I've gone ahead and written a new Version implementation that implements >>>>> the rules I've described. It seems to work OK though I am having a hard >>>>> time running all tests locally due to some environmental problem that >>>>> I'm still working on, so I don't have a webrev yet. But I do have a >>>>> diff that can be examined (and commented upon) at [1]. >>>>> >>>> >>>> One oddity that springs up relating to numeric versions when not >>>> normalizing the version string in any way is that version segments leading >>>> zeros parse and sort strangely. After fiddling around with various >>>> approaches, currently I've settled on this order: >>>> >>>> 1 >>>> 1.0 >>>> 1.1 >>>> 1.00 >>>> 1.01 >>>> 1.10 >>>> 1.11 >>>> 1.000 >>>> 1.001 >>>> 1.010 >>>> 1.011 >>>> 1.100 >>>> 1.101 >>>> 1.110 >>>> 1.111 >>>> >>>> Wherein versions are sorted for length first, then for value. However >>>> that might be counter-intuitive if your expectation is that (for example) >>>> 1.0 is equal to 1.00 or at least sorts immediately before or after it. A >>>> good case could be made that versions should be normalized to strip leading >>>> zeros, and I believe the previous implementation did this (either >>>> intentionally or unintentionally) as an implementation side-effect. The >>>> downside of normalization is the extra work and extra String being produced >>>> as a result. >>>> >>>> A third option would be to reject version segments with leading zeros, >>>> which prevents the problem from coming up and also avoids the extra copy >>>> work, making the "number" production look like: >>>> >>>> number = ? Unicode decimal digit with values 1-9 ? { ? Unicode decimal >>>> digit ? } >>>> >>>> Any thoughts on this would be appreciated. >>>> -- >>>> - DML >>>> >> > > -- > - DML From pbenedict at apache.org Wed Mar 23 20:57:47 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 23 Mar 2016 15:57:47 -0500 Subject: Alternative Version implementation In-Reply-To: References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> <56F2A62A.1040808@redhat.com> <56F2E469.1050207@redhat.com> <56F2FB25.9020402@redhat.com> Message-ID: David, I accidentally missed something first time around. I am happy Neil pointed it out (thank you). This is actually the order I was expecting. I am treating numbers as numbers, with more precision being greater in the collation. 1 1.0 1.00 1.000 1.01 1.001 1.010 1.011 1.100 1.101 1.110 1.111 1.1 1.10 1.11 Cheers, Paul On Wed, Mar 23, 2016 at 3:44 PM, Neil Bartlett (Paremus) < neil.bartlett at paremus.com> wrote: > Thanks David, I should have awaited your reply before responding to Paul. > See that email for more specifics on OSGi versions. > > I wasn?t implying anything about agreement with Remi Forax or anybody > else. In this case, my question was really just a question. However I am > skeptical about the practical feasibility of creating a version scheme that > can bring together all the existing practices. > > I am also very concerned with your the suggested collation order in which > 1.1 sorts before 1.00. This is subjective of course, but I find it highly > counter-intuitive. If the segment looks like a number then it should act > like a number, unless all segments are explicitly defined as strings with > alphanumeric sorting. > > > Neil > > > > On 23 Mar 2016, at 20:23, David M. Lloyd wrote: > > > > The OSGi specification allows (from what I can tell) arbitrary strings > for the last segment and that is definitely incompatible with the notion of > these more general version rules... this is the only difference I can find > though, and many practical examples of OSGi versions should continue to > work, which at least yields the possibility of moving forward. Are there > additional scenarios you can identify? > > > > Maven on the other hand does not really have a specification, so I just > referred to of existing examples and they seem to function as expected. > > > > The work I'm doing is intended as something of a bridge between what is > in place now (a structure which is designed for use in the JDK and which > implies a strict syntactical and semantic format which is incompatible with > a very large number of existing schemes and version numbers) and a way to > allow each layer to impose its own policy. But I think what you are > implying is that you share my interpretation of R?mi Forax's opinion that a > plain string is a better version identifier, with no sorting/comparison or > validation logic, putting 100% of the responsibility for interpretation and > validation of the version string to the layer which defines the module. Is > my understanding of your position correct? > > > > On 03/23/2016 03:01 PM, Neil Bartlett (Paremus) wrote: > >> Hi Paul and David, > >> > >> You may consider this collation order intuitive, but it?s clearly > incompatible with existing version systems; in particular I?m thinking of > those used in OSGi and Maven. > >> > >> I really don?t know to what extent this matters, as it was my > understanding that JSR 376 would not define versioning of modules and that > this are would be left to the discretion of external tools such as build > systems. David can you explain the work you are doing in this context? > >> > >> Regards, > >> Neil > >> > >> > >>> On 23 Mar 2016, at 18:53, Paul Benedict wrote: > >>> > >>> For any of the EG members observing this list, > >>> > >>> I find David's collating order acceptable and expected. I am not privy > to > >>> Reiner's particular discussion, but it is my opinion that 1.0 should > >>> precede 1.0.0. Although both are numerically equal, one is more > precise -- > >>> ambiguity should be first, precision last. I don't find this to be any > >>> different than the alphanumerical nature of a phone book where A would > >>> precede AA. That's not a perfect analogy but it gets my point across. > >>> > >>> Cheers, > >>> Paul > >>> > >>> On Wed, Mar 23, 2016 at 1:46 PM, David M. Lloyd < > david.lloyd at redhat.com> > >>> wrote: > >>> > >>>> On 03/23/2016 09:20 AM, David M. Lloyd wrote: > >>>> > >>>>> I've gone ahead and written a new Version implementation that > implements > >>>>> the rules I've described. It seems to work OK though I am having a > hard > >>>>> time running all tests locally due to some environmental problem that > >>>>> I'm still working on, so I don't have a webrev yet. But I do have a > >>>>> diff that can be examined (and commented upon) at [1]. > >>>>> > >>>> > >>>> One oddity that springs up relating to numeric versions when not > >>>> normalizing the version string in any way is that version segments > leading > >>>> zeros parse and sort strangely. After fiddling around with various > >>>> approaches, currently I've settled on this order: > >>>> > >>>> 1 > >>>> 1.0 > >>>> 1.1 > >>>> 1.00 > >>>> 1.01 > >>>> 1.10 > >>>> 1.11 > >>>> 1.000 > >>>> 1.001 > >>>> 1.010 > >>>> 1.011 > >>>> 1.100 > >>>> 1.101 > >>>> 1.110 > >>>> 1.111 > >>>> > >>>> Wherein versions are sorted for length first, then for value. However > >>>> that might be counter-intuitive if your expectation is that (for > example) > >>>> 1.0 is equal to 1.00 or at least sorts immediately before or after > it. A > >>>> good case could be made that versions should be normalized to strip > leading > >>>> zeros, and I believe the previous implementation did this (either > >>>> intentionally or unintentionally) as an implementation side-effect. > The > >>>> downside of normalization is the extra work and extra String being > produced > >>>> as a result. > >>>> > >>>> A third option would be to reject version segments with leading zeros, > >>>> which prevents the problem from coming up and also avoids the extra > copy > >>>> work, making the "number" production look like: > >>>> > >>>> number = ? Unicode decimal digit with values 1-9 ? { ? Unicode > decimal > >>>> digit ? } > >>>> > >>>> Any thoughts on this would be appreciated. > >>>> -- > >>>> - DML > >>>> > >> > > > > -- > > - DML > > From david.lloyd at redhat.com Wed Mar 23 21:02:28 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 23 Mar 2016 16:02:28 -0500 Subject: Alternative Version implementation In-Reply-To: References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> <56F2A62A.1040808@redhat.com> <56F2E469.1050207@redhat.com> <56F2FB25.9020402@redhat.com> Message-ID: <56F30464.5000508@redhat.com> Understood, thanks for the feedback. Yes it does seem like it would be impossible to fully reconcile the two problems of OSGi version abbreviations and that open-ended final segment. As for the collation order - I agree that it is not great. I just finished (locally) a tree which simply forbids leading zeros; this is also appealing for its simplicity but I'm afraid might interfere with a lot more common practice version schemes (just google "version 1.001" to see what I mean). I'll follow up on that on Paul's thread. On 03/23/2016 03:44 PM, Neil Bartlett (Paremus) wrote: > Thanks David, I should have awaited your reply before responding to Paul. See that email for more specifics on OSGi versions. > > I wasn?t implying anything about agreement with Remi Forax or anybody else. In this case, my question was really just a question. However I am skeptical about the practical feasibility of creating a version scheme that can bring together all the existing practices. > > I am also very concerned with your the suggested collation order in which 1.1 sorts before 1.00. This is subjective of course, but I find it highly counter-intuitive. If the segment looks like a number then it should act like a number, unless all segments are explicitly defined as strings with alphanumeric sorting. > > > Neil > > >> On 23 Mar 2016, at 20:23, David M. Lloyd wrote: >> >> The OSGi specification allows (from what I can tell) arbitrary strings for the last segment and that is definitely incompatible with the notion of these more general version rules... this is the only difference I can find though, and many practical examples of OSGi versions should continue to work, which at least yields the possibility of moving forward. Are there additional scenarios you can identify? >> >> Maven on the other hand does not really have a specification, so I just referred to of existing examples and they seem to function as expected. >> >> The work I'm doing is intended as something of a bridge between what is in place now (a structure which is designed for use in the JDK and which implies a strict syntactical and semantic format which is incompatible with a very large number of existing schemes and version numbers) and a way to allow each layer to impose its own policy. But I think what you are implying is that you share my interpretation of R?mi Forax's opinion that a plain string is a better version identifier, with no sorting/comparison or validation logic, putting 100% of the responsibility for interpretation and validation of the version string to the layer which defines the module. Is my understanding of your position correct? >> >> On 03/23/2016 03:01 PM, Neil Bartlett (Paremus) wrote: >>> Hi Paul and David, >>> >>> You may consider this collation order intuitive, but it?s clearly incompatible with existing version systems; in particular I?m thinking of those used in OSGi and Maven. >>> >>> I really don?t know to what extent this matters, as it was my understanding that JSR 376 would not define versioning of modules and that this are would be left to the discretion of external tools such as build systems. David can you explain the work you are doing in this context? >>> >>> Regards, >>> Neil >>> >>> >>>> On 23 Mar 2016, at 18:53, Paul Benedict wrote: >>>> >>>> For any of the EG members observing this list, >>>> >>>> I find David's collating order acceptable and expected. I am not privy to >>>> Reiner's particular discussion, but it is my opinion that 1.0 should >>>> precede 1.0.0. Although both are numerically equal, one is more precise -- >>>> ambiguity should be first, precision last. I don't find this to be any >>>> different than the alphanumerical nature of a phone book where A would >>>> precede AA. That's not a perfect analogy but it gets my point across. >>>> >>>> Cheers, >>>> Paul >>>> >>>> On Wed, Mar 23, 2016 at 1:46 PM, David M. Lloyd >>>> wrote: >>>> >>>>> On 03/23/2016 09:20 AM, David M. Lloyd wrote: >>>>> >>>>>> I've gone ahead and written a new Version implementation that implements >>>>>> the rules I've described. It seems to work OK though I am having a hard >>>>>> time running all tests locally due to some environmental problem that >>>>>> I'm still working on, so I don't have a webrev yet. But I do have a >>>>>> diff that can be examined (and commented upon) at [1]. >>>>>> >>>>> >>>>> One oddity that springs up relating to numeric versions when not >>>>> normalizing the version string in any way is that version segments leading >>>>> zeros parse and sort strangely. After fiddling around with various >>>>> approaches, currently I've settled on this order: >>>>> >>>>> 1 >>>>> 1.0 >>>>> 1.1 >>>>> 1.00 >>>>> 1.01 >>>>> 1.10 >>>>> 1.11 >>>>> 1.000 >>>>> 1.001 >>>>> 1.010 >>>>> 1.011 >>>>> 1.100 >>>>> 1.101 >>>>> 1.110 >>>>> 1.111 >>>>> >>>>> Wherein versions are sorted for length first, then for value. However >>>>> that might be counter-intuitive if your expectation is that (for example) >>>>> 1.0 is equal to 1.00 or at least sorts immediately before or after it. A >>>>> good case could be made that versions should be normalized to strip leading >>>>> zeros, and I believe the previous implementation did this (either >>>>> intentionally or unintentionally) as an implementation side-effect. The >>>>> downside of normalization is the extra work and extra String being produced >>>>> as a result. >>>>> >>>>> A third option would be to reject version segments with leading zeros, >>>>> which prevents the problem from coming up and also avoids the extra copy >>>>> work, making the "number" production look like: >>>>> >>>>> number = ? Unicode decimal digit with values 1-9 ? { ? Unicode decimal >>>>> digit ? } >>>>> >>>>> Any thoughts on this would be appreciated. >>>>> -- >>>>> - DML >>>>> >>> >> >> -- >> - DML > -- - DML From david.lloyd at redhat.com Wed Mar 23 21:04:08 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 23 Mar 2016 16:04:08 -0500 Subject: Alternative Version implementation In-Reply-To: References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> <56F2A62A.1040808@redhat.com> <56F2E469.1050207@redhat.com> <56F2FB25.9020402@redhat.com> Message-ID: <56F304C8.9010004@redhat.com> I guess you mean more like this: 1 1.0 1.00 1.000 1.1 1.01 1.001 1.10 1.010 1.11 1.011 1.100 1.101 1.110 1.111 where the numeric value is most significant and otherwise the sort is by length ascending? On 03/23/2016 03:57 PM, Paul Benedict wrote: > David, I accidentally missed something first time around. I am happy > Neil pointed it out (thank you). This is actually the order I was > expecting. I am treating numbers as numbers, with more precision being > greater in the collation. > > 1 > 1.0 > 1.00 > 1.000 > 1.01 > 1.001 > 1.010 > 1.011 > 1.100 > 1.101 > 1.110 > 1.111 > 1.1 > 1.10 > 1.11 > > > Cheers, > Paul > > On Wed, Mar 23, 2016 at 3:44 PM, Neil Bartlett (Paremus) > > wrote: > > Thanks David, I should have awaited your reply before responding to > Paul. See that email for more specifics on OSGi versions. > > I wasn?t implying anything about agreement with Remi Forax or > anybody else. In this case, my question was really just a question. > However I am skeptical about the practical feasibility of creating a > version scheme that can bring together all the existing practices. > > I am also very concerned with your the suggested collation order in > which 1.1 sorts before 1.00. This is subjective of course, but I > find it highly counter-intuitive. If the segment looks like a number > then it should act like a number, unless all segments are explicitly > defined as strings with alphanumeric sorting. > > > Neil > > > > On 23 Mar 2016, at 20:23, David M. Lloyd > wrote: > > > > The OSGi specification allows (from what I can tell) arbitrary strings for the last segment and that is definitely incompatible with the notion of these more general version rules... this is the only difference I can find though, and many practical examples of OSGi versions should continue to work, which at least yields the possibility of moving forward. Are there additional scenarios you can identify? > > > > Maven on the other hand does not really have a specification, so I just referred to of existing examples and they seem to function as expected. > > > > The work I'm doing is intended as something of a bridge between what is in place now (a structure which is designed for use in the JDK and which implies a strict syntactical and semantic format which is incompatible with a very large number of existing schemes and version numbers) and a way to allow each layer to impose its own policy. But I think what you are implying is that you share my interpretation of R?mi Forax's opinion that a plain string is a better version identifier, with no sorting/comparison or validation logic, putting 100% of the responsibility for interpretation and validation of the version string to the layer which defines the module. Is my understanding of your position correct? > > > > On 03/23/2016 03:01 PM, Neil Bartlett (Paremus) wrote: > >> Hi Paul and David, > >> > >> You may consider this collation order intuitive, but it?s clearly incompatible with existing version systems; in particular I?m thinking of those used in OSGi and Maven. > >> > >> I really don?t know to what extent this matters, as it was my understanding that JSR 376 would not define versioning of modules and that this are would be left to the discretion of external tools such as build systems. David can you explain the work you are doing in this context? > >> > >> Regards, > >> Neil > >> > >> > >>> On 23 Mar 2016, at 18:53, Paul Benedict > wrote: > >>> > >>> For any of the EG members observing this list, > >>> > >>> I find David's collating order acceptable and expected. I am not privy to > >>> Reiner's particular discussion, but it is my opinion that 1.0 should > >>> precede 1.0.0. Although both are numerically equal, one is more precise -- > >>> ambiguity should be first, precision last. I don't find this to be any > >>> different than the alphanumerical nature of a phone book where A would > >>> precede AA. That's not a perfect analogy but it gets my point across. > >>> > >>> Cheers, > >>> Paul > >>> > >>> On Wed, Mar 23, 2016 at 1:46 PM, David M. Lloyd > > >>> wrote: > >>> > >>>> On 03/23/2016 09:20 AM, David M. Lloyd wrote: > >>>> > >>>>> I've gone ahead and written a new Version implementation that implements > >>>>> the rules I've described. It seems to work OK though I am having a hard > >>>>> time running all tests locally due to some environmental problem that > >>>>> I'm still working on, so I don't have a webrev yet. But I do have a > >>>>> diff that can be examined (and commented upon) at [1]. > >>>>> > >>>> > >>>> One oddity that springs up relating to numeric versions when not > >>>> normalizing the version string in any way is that version segments leading > >>>> zeros parse and sort strangely. After fiddling around with various > >>>> approaches, currently I've settled on this order: > >>>> > >>>> 1 > >>>> 1.0 > >>>> 1.1 > >>>> 1.00 > >>>> 1.01 > >>>> 1.10 > >>>> 1.11 > >>>> 1.000 > >>>> 1.001 > >>>> 1.010 > >>>> 1.011 > >>>> 1.100 > >>>> 1.101 > >>>> 1.110 > >>>> 1.111 > >>>> > >>>> Wherein versions are sorted for length first, then for value. However > >>>> that might be counter-intuitive if your expectation is that (for example) > >>>> 1.0 is equal to 1.00 or at least sorts immediately before or after it. A > >>>> good case could be made that versions should be normalized to strip leading > >>>> zeros, and I believe the previous implementation did this (either > >>>> intentionally or unintentionally) as an implementation side-effect. The > >>>> downside of normalization is the extra work and extra String being produced > >>>> as a result. > >>>> > >>>> A third option would be to reject version segments with leading zeros, > >>>> which prevents the problem from coming up and also avoids the extra copy > >>>> work, making the "number" production look like: > >>>> > >>>> number = ? Unicode decimal digit with values 1-9 ? { ? Unicode decimal > >>>> digit ? } > >>>> > >>>> Any thoughts on this would be appreciated. > >>>> -- > >>>> - DML > >>>> > >> > > > > -- > > - DML > > -- - DML From pbenedict at apache.org Wed Mar 23 21:11:17 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 23 Mar 2016 16:11:17 -0500 Subject: Alternative Version implementation In-Reply-To: <56F304C8.9010004@redhat.com> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> <56F2A62A.1040808@redhat.com> <56F2E469.1050207@redhat.com> <56F2FB25.9020402@redhat.com> <56F304C8.9010004@redhat.com> Message-ID: Yes. :-) Cheers, Paul On Wed, Mar 23, 2016 at 4:04 PM, David M. Lloyd wrote: > I guess you mean more like this: > > 1 > 1.0 > 1.00 > 1.000 > 1.1 > 1.01 > 1.001 > 1.10 > 1.010 > 1.11 > 1.011 > 1.100 > 1.101 > 1.110 > 1.111 > > where the numeric value is most significant and otherwise the sort is by > length ascending? > > On 03/23/2016 03:57 PM, Paul Benedict wrote: > >> David, I accidentally missed something first time around. I am happy >> Neil pointed it out (thank you). This is actually the order I was >> expecting. I am treating numbers as numbers, with more precision being >> greater in the collation. >> >> 1 >> 1.0 >> 1.00 >> 1.000 >> 1.01 >> 1.001 >> 1.010 >> 1.011 >> 1.100 >> 1.101 >> 1.110 >> 1.111 >> 1.1 >> 1.10 >> 1.11 >> >> >> Cheers, >> Paul >> >> On Wed, Mar 23, 2016 at 3:44 PM, Neil Bartlett (Paremus) >> > wrote: >> >> Thanks David, I should have awaited your reply before responding to >> Paul. See that email for more specifics on OSGi versions. >> >> I wasn?t implying anything about agreement with Remi Forax or >> anybody else. In this case, my question was really just a question. >> However I am skeptical about the practical feasibility of creating a >> version scheme that can bring together all the existing practices. >> >> I am also very concerned with your the suggested collation order in >> which 1.1 sorts before 1.00. This is subjective of course, but I >> find it highly counter-intuitive. If the segment looks like a number >> then it should act like a number, unless all segments are explicitly >> defined as strings with alphanumeric sorting. >> >> >> Neil >> >> >> > On 23 Mar 2016, at 20:23, David M. Lloyd > > wrote: >> > >> > The OSGi specification allows (from what I can tell) arbitrary >> strings for the last segment and that is definitely incompatible with the >> notion of these more general version rules... this is the only difference I >> can find though, and many practical examples of OSGi versions should >> continue to work, which at least yields the possibility of moving forward. >> Are there additional scenarios you can identify? >> > >> > Maven on the other hand does not really have a specification, so I >> just referred to of existing examples and they seem to function as expected. >> > >> > The work I'm doing is intended as something of a bridge between >> what is in place now (a structure which is designed for use in the JDK and >> which implies a strict syntactical and semantic format which is >> incompatible with a very large number of existing schemes and version >> numbers) and a way to allow each layer to impose its own policy. But I >> think what you are implying is that you share my interpretation of R?mi >> Forax's opinion that a plain string is a better version identifier, with no >> sorting/comparison or validation logic, putting 100% of the responsibility >> for interpretation and validation of the version string to the layer which >> defines the module. Is my understanding of your position correct? >> > >> > On 03/23/2016 03:01 PM, Neil Bartlett (Paremus) wrote: >> >> Hi Paul and David, >> >> >> >> You may consider this collation order intuitive, but it?s clearly >> incompatible with existing version systems; in particular I?m thinking of >> those used in OSGi and Maven. >> >> >> >> I really don?t know to what extent this matters, as it was my >> understanding that JSR 376 would not define versioning of modules and that >> this are would be left to the discretion of external tools such as build >> systems. David can you explain the work you are doing in this context? >> >> >> >> Regards, >> >> Neil >> >> >> >> >> >>> On 23 Mar 2016, at 18:53, Paul Benedict > > wrote: >> >>> >> >>> For any of the EG members observing this list, >> >>> >> >>> I find David's collating order acceptable and expected. I am not >> privy to >> >>> Reiner's particular discussion, but it is my opinion that 1.0 >> should >> >>> precede 1.0.0. Although both are numerically equal, one is more >> precise -- >> >>> ambiguity should be first, precision last. I don't find this to >> be any >> >>> different than the alphanumerical nature of a phone book where A >> would >> >>> precede AA. That's not a perfect analogy but it gets my point >> across. >> >>> >> >>> Cheers, >> >>> Paul >> >>> >> >>> On Wed, Mar 23, 2016 at 1:46 PM, David M. Lloyd < >> david.lloyd at redhat.com > >> >>> wrote: >> >>> >> >>>> On 03/23/2016 09:20 AM, David M. Lloyd wrote: >> >>>> >> >>>>> I've gone ahead and written a new Version implementation that >> implements >> >>>>> the rules I've described. It seems to work OK though I am >> having a hard >> >>>>> time running all tests locally due to some environmental >> problem that >> >>>>> I'm still working on, so I don't have a webrev yet. But I do >> have a >> >>>>> diff that can be examined (and commented upon) at [1]. >> >>>>> >> >>>> >> >>>> One oddity that springs up relating to numeric versions when not >> >>>> normalizing the version string in any way is that version >> segments leading >> >>>> zeros parse and sort strangely. After fiddling around with >> various >> >>>> approaches, currently I've settled on this order: >> >>>> >> >>>> 1 >> >>>> 1.0 >> >>>> 1.1 >> >>>> 1.00 >> >>>> 1.01 >> >>>> 1.10 >> >>>> 1.11 >> >>>> 1.000 >> >>>> 1.001 >> >>>> 1.010 >> >>>> 1.011 >> >>>> 1.100 >> >>>> 1.101 >> >>>> 1.110 >> >>>> 1.111 >> >>>> >> >>>> Wherein versions are sorted for length first, then for value. >> However >> >>>> that might be counter-intuitive if your expectation is that (for >> example) >> >>>> 1.0 is equal to 1.00 or at least sorts immediately before or >> after it. A >> >>>> good case could be made that versions should be normalized to >> strip leading >> >>>> zeros, and I believe the previous implementation did this (either >> >>>> intentionally or unintentionally) as an implementation >> side-effect. The >> >>>> downside of normalization is the extra work and extra String >> being produced >> >>>> as a result. >> >>>> >> >>>> A third option would be to reject version segments with leading >> zeros, >> >>>> which prevents the problem from coming up and also avoids the >> extra copy >> >>>> work, making the "number" production look like: >> >>>> >> >>>> number = ? Unicode decimal digit with values 1-9 ? { ? Unicode >> decimal >> >>>> digit ? } >> >>>> >> >>>> Any thoughts on this would be appreciated. >> >>>> -- >> >>>> - DML >> >>>> >> >> >> > >> > -- >> > - DML >> >> >> > -- > - DML > From david.lloyd at redhat.com Wed Mar 23 22:29:48 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 23 Mar 2016 17:29:48 -0500 Subject: Alternative Version implementation In-Reply-To: <56F2E469.1050207@redhat.com> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> <56F2A62A.1040808@redhat.com> <56F2E469.1050207@redhat.com> Message-ID: <56F318DC.8020509@redhat.com> On 03/23/2016 01:46 PM, David M. Lloyd wrote: > On 03/23/2016 09:20 AM, David M. Lloyd wrote: >> I've gone ahead and written a new Version implementation that implements >> the rules I've described. It seems to work OK though I am having a hard >> time running all tests locally due to some environmental problem that >> I'm still working on, so I don't have a webrev yet. But I do have a >> diff that can be examined (and commented upon) at [1]. > > One oddity that springs up relating to numeric versions when not > normalizing the version string in any way is that version segments > leading zeros parse and sort strangely. After fiddling around with > various approaches, currently I've settled on this order: After some discussion with Paul Benedict and Neil Bartlett, I've updated the comparator code to sort as follows: 1 1.0 1.00 1.000 1.1 1.01 1.001 1.10 1.010 1.11 1.011 1.100 1.101 1.110 1.111 The numeric value is most significant, and the length (shortest to longest) is least significant. -- - DML From david.lloyd at redhat.com Wed Mar 23 22:37:51 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 23 Mar 2016 17:37:51 -0500 Subject: Missing issue: Version string format In-Reply-To: <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> Message-ID: <56F31ABF.3050706@redhat.com> Neil Bartlett also is expressing skepticism that one general syntax can be suitable for all or even most module systems, pointing out that a general scheme like this not only breaks the "final freeform field" aspect of OSGi versions but also the fact that under OSGi, a version of e.g. "1.0" is exactly equal to "1.0.0", which *may* be possible to achieve in a general system but probably not in combination with multiple, sortable separators. It's feeling more to me like maybe R?mi is right and module versions should just be Strings, and furthermore that version validation (via Predicate?) and sorting (via Comparator) should be implemented by the module layer, with a general scheme (perhaps like this one) being available for ease of implementation and a specific scheme (like this one plus semantic rules) for the default module layer. Note (as an aside) that this also eliminates the need for the hacky static Version cache that is used as a simple deduplication mechanism in jdk.internal.module.Builder#cachedVersion, so it already "feels" better in at least one other way. Any thoughts on this? On 03/21/2016 07:30 PM, Remi Forax wrote: > Hi David, > maybe a stupid question but > given that there is no need for a version of a module in the JDK, > why do you want the JDK to reify the version value as a specific object with weird rules, > why not considering that it can be any string (like in the JVM classfile format) ? > > regards, > R?mi > > ----- Mail original ----- >> De: "David M. Lloyd" >> ?: jpms-spec-experts at openjdk.java.net >> Envoy?: Lundi 21 Mars 2016 20:44:35 >> Objet: Re: Missing issue: Version string format >> >> On 03/21/2016 10:43 AM, David M. Lloyd wrote: >>> On 03/21/2016 08:49 AM, David M. Lloyd wrote: >>>> On 03/11/2016 04:13 PM, David M. Lloyd wrote: >>>>> The current java.lang.module.ModuleDescriptor.Version class contains the >>>>> comment: >>>>> >>>>> "Vaguely Debian-like version strings, for now. >>>>> "This will, eventually, change." >>>>> >>>>> At some point the syntax and semantics of version designators has to be >>>>> worked out and agreed upon. Ideally the scheme would be compatible with >>>>> as many existing widely deployed schemes as possible in terms of allowed >>>>> syntax, and as much as possible, collation order (at least within the >>>>> context of other modules from the same versioning scheme). >>>> >>>> Judging from the lack of response, I assume that nobody has done any >>>> work on this, so I have a proposal. >>> >>> I just updated to the latest code and it looks like last week the scheme >>> was updated. >>> >>> I would reframe this discussion into a proposal a few changes from the >>> existing code. >>> >>> ? Addition of a few more separator characters: the new code supports >>> "+", "-", and ".", and also the transition types. It does not support >>> "_" which I believe to be in fairly wide use. I would propose that this >>> character be added as a valid separator. >>> ? The current code uses multiple "classes" of separators, which also >>> depend on their location within the version string. I suggest that if >>> possible, a version sequence be agnostic to scheme, or else make >>> versions layer-specific (similar to the #ModuleNameCharacters issue); I >>> think the scheme I outlined would support all of the currently supported >>> schemes with little or no adjustment. >>> ? The implementation is probably considerably heavier than it needs to >>> be in terms of objects. A zero-object representation is possible, as is >>> a one- or zero-object tokenizer/validator. >>> >>> Unless someone has an early strong disagreement, I will prepare a >>> prototype to illustrate the changes. >> >> I want to expand on this just a little more. I think it is worth >> dividing the concept of a version scheme from the concept of syntax of a >> version string. The former should be specific to a layer, and the >> latter should be (if possible) global. This allows layers to enforce >> policy that makes sense to that layer, while also allowing predictable >> (if not intuitive) interoperability between version schemes. >> >> My change will create a general parsing scheme for versions as >> previously described, and move the specific validation rules to the >> existent layers to which they are relevant, as necessary to pass tests. >> -- >> - DML >> -- - DML From mark.reinhold at oracle.com Wed Mar 23 23:30:06 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 23 Mar 2016 16:30:06 -0700 (PDT) Subject: Bikeshed-ish issue: Optional In-Reply-To: <56E335A1.8030705@redhat.com> References: <56D7B28D.30807@redhat.com> <20160311174851.559D69E896@eggemoggin.niobe.net> <56E335A1.8030705@redhat.com> Message-ID: <20160323233006.C9FFDA1C13@eggemoggin.niobe.net> 2016/3/11 13:16:17 -0800, david.lloyd at redhat.com: > On 03/11/2016 11:48 AM, mark.reinhold at oracle.com wrote: >> ... >> >> We recently removed the most confusing use, in the return type of >> ModuleDescriptor.Exports::targets, which now returns a simple Set >> of package names rather than an Optional>. >> >> What other specific uses would you suggest to remove? > > I think that all of the getter-style usages are definitely not in line > with the original intent of the class. This would include: > > ??? java.lang.module.Configuration#parent() > ??? java.lang.module.ModuleDescriptor#mainClass() > ??? java.lang.module.ModuleDescriptor#osName() > ??? java.lang.module.ModuleDescriptor#osArch() > ??? java.lang.module.ModuleDescriptor#osVersion() > ??? java.lang.module.ModuleReference#location() > > The following usages also seem excessive to me, though they aren't > strictly getters. There's no stream-related use for these methods that > I can think of and I can't imagine a case where Optional provides a real > benefit, and in some cases there's a precedent for similar methods to > return null: > > ??? java.lang.module.Configuration#findDescriptor() > ??? java.lang.module.Configuration#findModule() > ??? java.lang.module.ModuleFinder#find() > ??? java.lang.module.ModuleReader#find() > ??? java.lang.module.ModuleReader#open() > ??? java.lang.module.ModuleReader#read() > > By my count there are now more usages of Optional in java.lang.module > than in all of the rest of java.base combined. Well of course not, since Optional was only introduced in Java 8. That fact, of itself, is not an argument against using Optional in java.base. > It feels like what Brian > was referring to as "zealous over-use" to me. I asked Brian to review the uses of java.util.Optional in the draft API. He concluded that they were "entirely reasonable." In response to your comment about getters he further remarked (quoted with permission): This is taking my quote out of context. By "getter", I didn't mean "any non-void method". The question was in the context of JavaBean style classes, whose many getters are simply (usually trivially) mediating access to the Bean's state. Routinely using optional for Bean getters (and state) would be overuse. This is not that. I see no need for further changes here. - Mark From mark.reinhold at oracle.com Wed Mar 23 23:31:06 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 23 Mar 2016 16:31:06 -0700 (PDT) Subject: New issue: run time eager module loading In-Reply-To: <56E33EEC.20706@redhat.com> References: <56D7AE09.1030003@redhat.com> <20160311174751.5399C9E891@eggemoggin.niobe.net> <56E33EEC.20706@redhat.com> Message-ID: <20160323233106.CDD34A1C18@eggemoggin.niobe.net> 2016/3/11 13:55:56 -0800, david.lloyd at redhat.com: > On 03/11/2016 11:47 AM, mark.reinhold at oracle.com wrote: >> 2016/3/2 19:22 -0800, david.lloyd at redhat.com: >>> ... >>> >>> Can there not instead be an incremental resolution algorithm, akin to >>> how classes are lazily loaded? >> >> Configuring a set of modules and instantiating that configuration as a >> layer requires no more than reading the modules' descriptors. Nothing >> else from any module definition will be read until it's actually needed. > > But it does require that all the module descriptors from a given layer > be available, and that the load time for the first load of a module in a > layer will always be bounded by the size of the layer, rather than just > by the dependency subgraph of the module being loaded. Based on > application server deployments that I know about, I think the far upper > bound for a realistic number of modules in a layer will probably lie in > the thousands to ten thousands range (though there is always the outlier > case where someone has to push it to see how far it goes...), which > might translate into a substantial startup overhead. New issue: http://openjdk.java.net/projects/jigsaw/spec/issues/#LazyConfigurationAndInstantiation - Mark From mark.reinhold at oracle.com Wed Mar 23 23:32:06 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 23 Mar 2016 16:32:06 -0700 (PDT) Subject: New Issue: How to deprecate a module ? In-Reply-To: <1944740085.1781960.1458064462482.JavaMail.zimbra@u-pem.fr> References: <711804582.1781038.1458064355622.JavaMail.zimbra@u-pem.fr> <1944740085.1781960.1458064462482.JavaMail.zimbra@u-pem.fr> Message-ID: <20160323233206.D25D9A1C1B@eggemoggin.niobe.net> 2016/3/15 10:54:22 -0700, forax at univ-mlv.fr: > A module declaration (in module-info) doesn't accept annotation, > so it seems not possible to deprecate a module ? Correct, at present module declarations do not admit annotations (#ModuleAnnotations). > I think that module declaration should allow annotation (at least > compile-time annotation). New issue: http://openjdk.java.net/projects/jigsaw/spec/issues/#ModuleDeprecation - Mark From mark.reinhold at oracle.com Wed Mar 23 23:33:06 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 23 Mar 2016 16:33:06 -0700 (PDT) Subject: Issue: Modules can only open resources as streams In-Reply-To: <56F001B7.6030006@redhat.com> References: <56D85B77.4040607@redhat.com> <56F001B7.6030006@redhat.com> Message-ID: <20160323233306.D4AAAA1C20@eggemoggin.niobe.net> 2016/3/21 7:14:15 -0700, david.lloyd at redhat.com: > ... > > Without any further discussion I'm going to assume complete agreement > with the definition and acceptance of the problem and (at least the > general gist of) the proposed solution. If any of you disagree with > this issue on any basis, PLEASE speak up ASAP otherwise I will assume > that the group is in agreement! You may assume what you like, but just to be clear: As the Spec Lead for this JSR I'm not going to consider the discussion of any particular topic closed until I've had time to think about it, and until I'm convinced that others have also. - Mark From mark.reinhold at oracle.com Wed Mar 23 23:34:06 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 23 Mar 2016 16:34:06 -0700 (PDT) Subject: #MutableConfigurations (Re: New issue: Configurations are not mutable) In-Reply-To: <56F002A3.3050707@redhat.com> References: <56D79D56.7040801@redhat.com> <20160311174451.4E3659E881@eggemoggin.niobe.net> <56F002A3.3050707@redhat.com> Message-ID: <20160323233406.D83C3A1C26@eggemoggin.niobe.net> 2016/3/21 7:18:11 -0700, david.lloyd at redhat.com: > ... > > In the absence of further discussion, I am going to assume that the > expert group is in agreement that working mutable Configurations are > part of the acceptance criteria for this JSR. If you disagree please > speak up ASAP - even if your objection is presently nonspecific - I am > taking silence to mean assent of the entire group! Again: You may assume what you like, but as the Spec Lead for this JSR I'm not going to consider the discussion of any particular topic closed until I've had time to think about it, and until I'm convinced that others have also. - Mark From mark.reinhold at oracle.com Wed Mar 23 23:35:06 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 23 Mar 2016 16:35:06 -0700 (PDT) Subject: Expounding on #ModuleNameSyntax In-Reply-To: <56F00449.5050707@redhat.com> References: <56D77D9C.1060401@redhat.com> <20160311174251.4B3FF9E877@eggemoggin.niobe.net> <56F00449.5050707@redhat.com> Message-ID: <20160323233506.DBBDEA1C2D@eggemoggin.niobe.net> 2016/3/21 7:25:13 -0700, david.lloyd at redhat.com: > ... > > In the absence of expert group discussion I am assuming that everyone is > in agreement that each layer should have complete autonomy in terms of > module name validation. If you disagree or have other discussion points > to raise, please respond ASAP, as silence will be interpreted as > agreement of the group! Again: You may assume what you like, but as the Spec Lead for this JSR I'm not going to consider the discussion of any particular topic closed until I've had time to think about it, and until I'm convinced that others have also. - Mark From bryan.atsatt at oracle.com Wed Mar 23 23:36:00 2016 From: bryan.atsatt at oracle.com (Bryan Atsatt) Date: Wed, 23 Mar 2016 16:36:00 -0700 Subject: Alternative Version implementation In-Reply-To: <56F304C8.9010004@redhat.com> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> <56F2A62A.1040808@redhat.com> <56F2E469.1050207@redhat.com> <56F2FB25.9020402@redhat.com> <56F304C8.9010004@redhat.com> Message-ID: <56F32860.4000906@oracle.com> FWIW: I wrote the attached Version type some time back for a previous module system effort. It assumes module system specific parsing, into a canonical internal form, and supports string conversions using a canonical format. Ordering is well defined. // Bryan On 3/23/16 2:04 PM, David M. Lloyd wrote: > I guess you mean more like this: > > 1 > 1.0 > 1.00 > 1.000 > 1.1 > 1.01 > 1.001 > 1.10 > 1.010 > 1.11 > 1.011 > 1.100 > 1.101 > 1.110 > 1.111 > > where the numeric value is most significant and otherwise the sort is > by length ascending? > > On 03/23/2016 03:57 PM, Paul Benedict wrote: >> David, I accidentally missed something first time around. I am happy >> Neil pointed it out (thank you). This is actually the order I was >> expecting. I am treating numbers as numbers, with more precision being >> greater in the collation. >> >> 1 >> 1.0 >> 1.00 >> 1.000 >> 1.01 >> 1.001 >> 1.010 >> 1.011 >> 1.100 >> 1.101 >> 1.110 >> 1.111 >> 1.1 >> 1.10 >> 1.11 >> >> >> Cheers, >> Paul >> >> On Wed, Mar 23, 2016 at 3:44 PM, Neil Bartlett (Paremus) >> > wrote: >> >> Thanks David, I should have awaited your reply before responding to >> Paul. See that email for more specifics on OSGi versions. >> >> I wasn?t implying anything about agreement with Remi Forax or >> anybody else. In this case, my question was really just a question. >> However I am skeptical about the practical feasibility of creating a >> version scheme that can bring together all the existing practices. >> >> I am also very concerned with your the suggested collation order in >> which 1.1 sorts before 1.00. This is subjective of course, but I >> find it highly counter-intuitive. If the segment looks like a number >> then it should act like a number, unless all segments are explicitly >> defined as strings with alphanumeric sorting. >> >> >> Neil >> >> >> > On 23 Mar 2016, at 20:23, David M. Lloyd >> > wrote: >> > >> > The OSGi specification allows (from what I can tell) arbitrary >> strings for the last segment and that is definitely incompatible with >> the notion of these more general version rules... this is the only >> difference I can find though, and many practical examples of OSGi >> versions should continue to work, which at least yields the >> possibility of moving forward. Are there additional scenarios you >> can identify? >> > >> > Maven on the other hand does not really have a specification, >> so I just referred to of existing examples and they seem to function >> as expected. >> > >> > The work I'm doing is intended as something of a bridge between >> what is in place now (a structure which is designed for use in the >> JDK and which implies a strict syntactical and semantic format which >> is incompatible with a very large number of existing schemes and >> version numbers) and a way to allow each layer to impose its own >> policy. But I think what you are implying is that you share my >> interpretation of R?mi Forax's opinion that a plain string is a >> better version identifier, with no sorting/comparison or validation >> logic, putting 100% of the responsibility for interpretation and >> validation of the version string to the layer which defines the >> module. Is my understanding of your position correct? >> > >> > On 03/23/2016 03:01 PM, Neil Bartlett (Paremus) wrote: >> >> Hi Paul and David, >> >> >> >> You may consider this collation order intuitive, but it?s >> clearly incompatible with existing version systems; in particular I?m >> thinking of those used in OSGi and Maven. >> >> >> >> I really don?t know to what extent this matters, as it was my >> understanding that JSR 376 would not define versioning of modules and >> that this are would be left to the discretion of external tools such >> as build systems. David can you explain the work you are doing in >> this context? >> >> >> >> Regards, >> >> Neil >> >> >> >> >> >>> On 23 Mar 2016, at 18:53, Paul Benedict > > wrote: >> >>> >> >>> For any of the EG members observing this list, >> >>> >> >>> I find David's collating order acceptable and expected. I am >> not privy to >> >>> Reiner's particular discussion, but it is my opinion that 1.0 >> should >> >>> precede 1.0.0. Although both are numerically equal, one is >> more precise -- >> >>> ambiguity should be first, precision last. I don't find this >> to be any >> >>> different than the alphanumerical nature of a phone book >> where A would >> >>> precede AA. That's not a perfect analogy but it gets my point >> across. >> >>> >> >>> Cheers, >> >>> Paul >> >>> >> >>> On Wed, Mar 23, 2016 at 1:46 PM, David M. Lloyd >> > >> >>> wrote: >> >>> >> >>>> On 03/23/2016 09:20 AM, David M. Lloyd wrote: >> >>>> >> >>>>> I've gone ahead and written a new Version implementation >> that implements >> >>>>> the rules I've described. It seems to work OK though I am >> having a hard >> >>>>> time running all tests locally due to some environmental >> problem that >> >>>>> I'm still working on, so I don't have a webrev yet. But I >> do have a >> >>>>> diff that can be examined (and commented upon) at [1]. >> >>>>> >> >>>> >> >>>> One oddity that springs up relating to numeric versions when >> not >> >>>> normalizing the version string in any way is that version >> segments leading >> >>>> zeros parse and sort strangely. After fiddling around with >> various >> >>>> approaches, currently I've settled on this order: >> >>>> >> >>>> 1 >> >>>> 1.0 >> >>>> 1.1 >> >>>> 1.00 >> >>>> 1.01 >> >>>> 1.10 >> >>>> 1.11 >> >>>> 1.000 >> >>>> 1.001 >> >>>> 1.010 >> >>>> 1.011 >> >>>> 1.100 >> >>>> 1.101 >> >>>> 1.110 >> >>>> 1.111 >> >>>> >> >>>> Wherein versions are sorted for length first, then for >> value. However >> >>>> that might be counter-intuitive if your expectation is that >> (for example) >> >>>> 1.0 is equal to 1.00 or at least sorts immediately before or >> after it. A >> >>>> good case could be made that versions should be normalized >> to strip leading >> >>>> zeros, and I believe the previous implementation did this >> (either >> >>>> intentionally or unintentionally) as an implementation >> side-effect. The >> >>>> downside of normalization is the extra work and extra String >> being produced >> >>>> as a result. >> >>>> >> >>>> A third option would be to reject version segments with >> leading zeros, >> >>>> which prevents the problem from coming up and also avoids >> the extra copy >> >>>> work, making the "number" production look like: >> >>>> >> >>>> number = ? Unicode decimal digit with values 1-9 ? { ? >> Unicode decimal >> >>>> digit ? } >> >>>> >> >>>> Any thoughts on this would be appreciated. >> >>>> -- >> >>>> - DML >> >>>> >> >> >> > >> > -- >> > - DML >> >> > -------------- next part -------------- /* * Copyright 2009 Oracle Corporation * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package java.lang.module; import java.util.regex.Pattern; /** * A canonical, syntax agnostic version number type that supports ordered comparison. *

* Instances may contain any number of positive numeric components and an optional * 'preview' or 'update' string qualifier. An unqualified instance is considered a * 'release' version. Qualifier strings may contain any of the posix visible characters * (i.e. '\u0021' through '\u006E'). *

* During comparison: *

    *
  • Numeric components of differing lengths are normalized by zero padding.
    • *
  • Types are compared only if numeric components are equal: PREVIEW < RELEASE < UPDATE.
    • *
  • Qualifiers are compared, * * lexicographically, only if types and all numeric components are equal.
    • *
* Lexicographic qualifier comparison can result in unexpected ordering (e.g. "100" < "20"); * therefore, version schemes should be mapped to use additional numeric components where * possible. * * @author Bryan Atsatt * @since Dec 10, 2008 */ public class Version implements Matcher, Comparable { private static final Pattern DOT_SEP = Pattern.compile("\\."); public enum Type { /** * A PREVIEW version may have a qualifier and is less than a RELEASE * or UPDATE version with equal components. */ PREVIEW, /** * A RELEASE version has no qualifier and is greater than a PREVIEW * version with equal components and less than an UPDATE version with * equal components. */ RELEASE, /** * An UPDATE version may have a qualifier and is greater than a RELEASE * version with equal components. */ UPDATE, } /** * An instance of the minimum value. */ public static final Version MIN_VALUE = new Version(true) { public int compareTo(Version other) { return other == this ? 0 : -1; } public String toString() { return "min"; } }; /** * An instance of the maximum value. */ public static final Version MAX_VALUE = new Version(false) { public int compareTo(Version other) { return other == this ? 0 : 1; } public String toString() { return "max"; } }; /** * An instance of the release version zero. */ public static Version ZERO = newReleaseVersion(0); private static final Pattern visibleCharacters = Pattern.compile("([\\p{Graph}])+"); private Type type; private int[] components; private String qualifier; /** * Create a new PREVIEW version. * * @param components The components. * @param qualifier The qualifier. * @return The new instance. */ public static Version newPreviewVersion(int[] components, String qualifier) { return new Version(Type.PREVIEW, components, qualifier); } /** * Create a new RELEASE version. * * @param components The components. * @return The new instance. */ public static Version newReleaseVersion(int... components) { return new Version(Type.RELEASE, components, null); } /** * Create a new UPDATE version. * * @param components The components. * @param qualifier The qualifier. * @return The new instance. */ public static Version newUpdateVersion(int[] components, String qualifier) { return new Version(Type.UPDATE, components, qualifier); } /** * Create a new version. * * @param type The type. * @param components The components. * @param qualifier The qualifier. Must be null if type == RELEASE, otherwise * must be non-zero length. * @return The new instance. */ public static Version newVersion(Type type, int[] components, String qualifier) { return new Version(type, components, qualifier); } /** * Returns the type of this instance. * * @return The type. */ public Type getType() { return type; } /** * Returns the number of components in this instance. * * @return The count. */ public int getComponentCount() { return components.length; } /** * Return the component at the specified index. * * @param index The index. * @return The component. * @throws IndexOutOfBoundsException if index is out of bounds. */ public int getComponentAt(int index) { return components[index]; } /** * Returns the qualifier, if any. * * @return The qualifier if type is PREVIEW or UPDATE, null if RELEASE; */ public String getQualifier() { return qualifier; } /** * Compare two {@code Version} objects. * * @param version the {@code Version} to be compared. * @return the value 0 if the this {@code Version} is equal to the * {@code Version} argument; a value less than 0 if this * {@code Version} is less than the {@code Version} argument; and a * value greater than 0 if this {@code Version} is greater than the * {@code Version} argument. */ public int compareTo(Version version) { int result = 0; if (this != version) { if (version == MAX_VALUE) { result = -1; } else if (version == MIN_VALUE) { result = 1; } else { // Are the components equal? result = compare(components, version.components); if (result == 0) { // Yes. Are the types equal? result = type.ordinal() - version.type.ordinal(); if (result == 0 && type != Type.RELEASE) { // Yes, and there is a qualifier, so the result depends // solely on comparing them... result = qualifier.compareTo(version.qualifier); } } } } return result; } /** * Compare two {@code Version} objects for equality. The result is * {@code true} if and only if the argument is not {@code null} and is a * {@code Version} object for which compareTo() returns 0. * * @param obj the object to compare with. * @return whether or not two {@code Version} objects are equal. */ @Override public boolean equals(Object obj) { return this == obj || (obj instanceof Version && (compareTo((Version) obj) == 0)); } /** * Returns a hash code for this {@code Version}. * * @return a hash code value for this {@code Version}. */ @Override public int hashCode() { int result = 17 * (type.ordinal() + 1); for (int n : components) { result = 37 * result + n; } result = 37 * result + (qualifier == null ? 0 : qualifier.hashCode()); return result; } /** * Returns a {@code String} object representing this {@code Version}'s * value. * * @return a string representation of the value of this {@code Version}. */ @Override public String toString() { return toString(" preview '", " update '", "'"); } /** * Returns a {@code String} object representing this {@code Version}'s * value, in canonical form: * 
     *     digit[.digit]... [ -<previewQualifier> | _<updateQualifier> ]
     *
* * @return a string representation of the value of this {@code Version}, in * canonical form. */ public String toCanonicalForm() { if (this == MIN_VALUE) return "min"; if (this == MAX_VALUE) return "max"; return toString("-", "_", null); } /** * Returns a {@code Version} object from the specified canonical * version string. * * @param version The canonical version string. * @return The {@code Version}. * @see #toCanonicalForm() */ public static Version fromCanonicalForm(String version) { if (version.equals("min")) return MIN_VALUE; if (version.equals("max")) return MAX_VALUE; int pi = version.indexOf("-"); int ui = version.indexOf("_"); if (pi > 0 && ui > 0) { if (pi < ui) { ui = -1; } else { pi = -1; } } if (pi > 0) { int[] components = toComponents(version.substring(0, pi)); return newPreviewVersion(components, version.substring(pi + 1)); } else if (ui > 0) { int[] components = toComponents(version.substring(0, ui)); return newUpdateVersion(components, version.substring(ui + 1)); } return newReleaseVersion(toComponents(version)); } /** * Tests if the specified version is equal to this instance. * * @param version The target version. * @return {@code true} if the specified version is equal to this instance; * {@code false} otherwise. */ public boolean matches(Version version) { return equals(version); } private String toString(String preview, String update, String trailing) { StringBuilder buf = new StringBuilder(); int length = components.length; for (int i = 0; i < length; i++) { if (i > 0) { buf.append('.'); } buf.append(components[i]); } if (length == 1) { buf.append(".0"); } if (type != Type.RELEASE) { if (type == Type.PREVIEW) { buf.append(preview); } else { buf.append(update); } buf.append(qualifier); if (trailing != null) { buf.append(trailing); } } return buf.toString(); } private Version(Type type, int[] components, String qualifier) { assert (type != null); this.type = type; this.components = components; this.qualifier = qualifier; validateComponents(); validateQualifier(); } private Version(boolean minValue) { // Special MIN/MAX value ctor. if (minValue) { type = Type.PREVIEW; components = new int[]{0}; qualifier = "!"; } else { type = Type.UPDATE; components = new int[]{Integer.MAX_VALUE}; qualifier = "~"; } } private static int compare(int[] right, int[] left) { int rLen = right.length; int lLen = left.length; int len = Math.max(rLen, lLen); for (int i = 0; i < len; i++) { int rValue = i < rLen ? right[i] : 0; int lValue = i < lLen ? left[i] : 0; int result = rValue - lValue; if (result != 0) { return result; } } return 0; } private void validateComponents() { if (components == null) { throw new IllegalArgumentException("Version components must not be null."); } if (components.length == 0) { throw new IllegalArgumentException("Version components must not be empty."); } for (int c : components) { if (c < 0) { throw new IllegalArgumentException("Version components must not be negative: " + this); } } } private void validateQualifier() { if (type == Type.RELEASE) { if (qualifier != null) { throw new IllegalArgumentException("Version qualifier must be null."); } } else { if (qualifier == null) { throw new IllegalArgumentException("Version qualifier must not be null."); } if (qualifier.length() == 0) { throw new IllegalArgumentException("Version qualifier must not be empty: " + this); } if (!visibleCharacters.matcher(qualifier).matches()) { throw new IllegalArgumentException( "Version qualifier must contain only posix visible characters: " + this); } } } private static int[] toComponents(String componentStr) { String[] componentStrings = DOT_SEP.split(componentStr); int[] components = new int[componentStrings.length]; for (int i = 0; i < components.length; i++) { components[i] = Integer.parseInt(componentStrings[i].trim()); } return components; } } From mark.reinhold at oracle.com Wed Mar 23 23:36:06 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 23 Mar 2016 16:36:06 -0700 (PDT) Subject: Missing issue: Version string format In-Reply-To: <56F016B8.5060505@redhat.com> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> Message-ID: <20160323233606.DF42AA1C32@eggemoggin.niobe.net> 2016/3/21 8:43:52 -0700, david.lloyd at redhat.com: > On 03/21/2016 08:49 AM, David M. Lloyd wrote: >> On 03/11/2016 04:13 PM, David M. Lloyd wrote: >>> The current java.lang.module.ModuleDescriptor.Version class contains the >>> comment: >>> >>> "Vaguely Debian-like version strings, for now. >>> "This will, eventually, change." >>> >>> At some point the syntax and semantics of version designators has to be >>> worked out and agreed upon. Ideally the scheme would be compatible with >>> as many existing widely deployed schemes as possible in terms of allowed >>> syntax, and as much as possible, collation order (at least within the >>> context of other modules from the same versioning scheme). >> >> Judging from the lack of response, I assume that nobody has done any >> work on this, so I have a proposal. > > I just updated to the latest code and it looks like last week the scheme > was updated. Yes; among other things there's now an actual (initial) specification, as you've seen [1]. > I would reframe this discussion into a proposal a few changes from the > existing code. > > ... I'll reply to your proposal in due course, but for now to track it I've created http://openjdk.java.net/projects/jigsaw/spec/issues/#VersionSyntax . - Mark [1] http://download.java.net/java/jigsaw/docs/api/java/lang/module/ModuleDescriptor.Version.html From mark.reinhold at oracle.com Wed Mar 23 23:37:06 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 23 Mar 2016 16:37:06 -0700 (PDT) Subject: Alternative Version implementation In-Reply-To: <56F2A62A.1040808@redhat.com> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> <56F2A62A.1040808@redhat.com> Message-ID: <20160323233706.E2BFBA1C38@eggemoggin.niobe.net> 2016/3/23 7:20:26 -0700, david.lloyd at redhat.com: > I've gone ahead and written a new Version implementation that implements > the rules I've described. It seems to work OK though I am having a hard > time running all tests locally due to some environmental problem that > I'm still working on, so I don't have a webrev yet. But I do have a > diff that can be examined (and commented upon) at [1]. Process point: This list, and the associated jpms-spec-{observers,comments} lists, are for discussion of the JSR 376 specification only. As such we can certainly discuss the present specification of the ModuleDescriptor.Version class, and how it might be improved, but if you wish to discuss actual code then please do that on jigsaw-dev at openjdk.java.net. - Mark From mark.reinhold at oracle.com Wed Mar 23 23:45:39 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 23 Mar 2016 16:45:39 -0700 Subject: Nomination to the JSR 376 EG: Neil Bartlett Message-ID: <20160323164539.511779244eggemoggin.niobe.net> FYI, Neil Bartlett of Paremus has applied to join this EG. I have declined his nomination since we already have one representative of the OSGi community, namely Peter Kriens, and I think it's important to keep a reasonable balance of interests across the group. - Mark From forax at univ-mlv.fr Thu Mar 24 00:24:33 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 24 Mar 2016 01:24:33 +0100 (CET) Subject: New Issue: let the module version be free In-Reply-To: <1917323716.2520522.1458778281653.JavaMail.zimbra@u-pem.fr> Message-ID: <1775152958.2522760.1458779073877.JavaMail.zimbra@u-pem.fr> Currently the module version does not appear in module-info.java is stored as a string in the module-info.class when a modular jar is created. So the version doesn't appear in the Java source code and is provided by the build tool we love using any format we ask. At runtime, when the module-info.class is read, the version is parsed using the class ModuleDescriptor.Version that verifies a very specific format [1]. Given that the format will never be the right one, i.e. never support every possible module version formats that exist in the universe, i propose to not try to parse the version string and to exposes it only as a string at runtime and let the module systems that are built on top of jigsaw to parse the version as they want. R?mi [1] http://download.java.net/java/jigsaw/docs/api/java/lang/module/ModuleDescriptor.Version.html From stef at epardaud.fr Thu Mar 24 10:23:18 2016 From: stef at epardaud.fr (Stephane Epardaud) Date: Thu, 24 Mar 2016 11:23:18 +0100 Subject: Alternative Version implementation In-Reply-To: <56F2FB25.9020402@redhat.com> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <56F04F23.5070904@redhat.com> <1886997541.1087276.1458606659119.JavaMail.zimbra@u-pem.fr> <56F0984E.1010900@redhat.com> <56F2A62A.1040808@redhat.com> <56F2E469.1050207@redhat.com> <56F2FB25.9020402@redhat.com> Message-ID: <56F3C016.3050208@epardaud.fr> On 23/03/16 21:23, David M. Lloyd wrote: > Maven on the other hand does not really have a specification, so I > just referred to of existing examples and they seem to function as > expected. Actually, having had to recently switch our internal version comparator to be compatible with Maven, we did find a "spec": https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning Note that it is a bit important to be compatible with this version ordering as this is what defined how Maven resolves which version is newer in case of conflict and users "expect" us to figure out that "1.GA" is newer than "1.RC" despite the alphabetical ordering pointing the other way. For better or worse, this is what people expect now :( From neil.bartlett at paremus.com Thu Mar 24 13:20:12 2016 From: neil.bartlett at paremus.com (Neil Bartlett (Paremus)) Date: Thu, 24 Mar 2016 13:20:12 +0000 Subject: Nomination to the JSR 376 EG: Neil Bartlett In-Reply-To: <56f32ab8.5247620a.99842.1ec6SMTPIN_ADDED_BROKEN@mx.google.com> References: <56f32ab8.5247620a.99842.1ec6SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: <89DC79D9-9C1A-4A85-BF99-4873936800ED@paremus.com> Mark, Thank you for your mail, I accept your decision. For the interest of the Experts and observers who might be puzzled at the apparent timing of my application, I would like to make it known that I applied to join the EG over 10 months ago and have chased up on many occasions. It is not clear what organisational hiccup within the JCP has led to my application being ignored for so long but its clearly very disappointing. I also note that other members have joined the Expert Group within this window so it is odd that my application specifically got lost. As additional clarification, my intended purpose in joining the JSR was to represent Paremus Ltd, who are Board Members of the OSGi Alliance and active in the OSGi community. We are concerned about compatibility for OSGi with Java 9 and wish to work on interoperability between the two module systems. We believe that there are significant shortcomings and oversimplifications in this JSR with respect to application modularity and that these may have a detrimental effect on Java modularity in general. As you can see from my blog post dated 13 Nov 2015 (https://blogs.paremus.com/2015/11/osgi-and-java-9-modules-working-together/) the objective of breaking the monolithic Java runtime into smaller modules is in our opinion very worthwhile and fully working and interoperable with OSGi already, so good job on that. Finally I note that if a balance of interests is sought, this is not well served by those EG members who have not participated at all in the discussions. Several members have not interacted beyond their first introductory mail, and one member did not even send that introduction! I do not blame you as the Spec Lead for their failings, rather I would encourage them to get involved more in what is a very important JSR for the future of Java. I would be grateful if you could forward this message to the EG since for obvious reasons I cannot respond directly there myself. Kind regards, Neil > On 23 Mar 2016, at 23:45, mark.reinhold at oracle.com wrote: > > FYI, Neil Bartlett of Paremus has applied to join this EG. > > I have declined his nomination since we already have one representative > of the OSGi community, namely Peter Kriens, and I think it's important > to keep a reasonable balance of interests across the group. > > - Mark From volker.berlin at goebel-clan.de Thu Mar 24 20:23:05 2016 From: volker.berlin at goebel-clan.de (Volker Berlin) Date: Thu, 24 Mar 2016 21:23:05 +0100 Subject: Missing issue: Version string format In-Reply-To: <20160323233606.DF42AA1C32@eggemoggin.niobe.net> References: <56E342EF.80303@redhat.com> <56EFFBE2.4010609@redhat.com> <56F016B8.5060505@redhat.com> <20160323233606.DF42AA1C32@eggemoggin.niobe.net> Message-ID: <56F44CA9.3060403@goebel-clan.de> Why you does not create a standard class (for example java.util.Version)? There are also other spec that need it. http://openjdk.java.net/jeps/223 Volker Berlin Am 24.03.2016 um 00:36 schrieb mark.reinhold at oracle.com: > 2016/3/21 8:43:52 -0700, david.lloyd at redhat.com: >> On 03/21/2016 08:49 AM, David M. Lloyd wrote: >>> On 03/11/2016 04:13 PM, David M. Lloyd wrote: >>>> The current java.lang.module.ModuleDescriptor.Version class contains the >>>> comment: >>>> >>>> "Vaguely Debian-like version strings, for now. >>>> "This will, eventually, change." >>>> >>>> At some point the syntax and semantics of version designators has to be >>>> worked out and agreed upon. Ideally the scheme would be compatible with >>>> as many existing widely deployed schemes as possible in terms of allowed >>>> syntax, and as much as possible, collation order (at least within the >>>> context of other modules from the same versioning scheme). >>> Judging from the lack of response, I assume that nobody has done any >>> work on this, so I have a proposal. >> I just updated to the latest code and it looks like last week the scheme >> was updated. > Yes; among other things there's now an actual (initial) specification, as > you've seen [1]. > >> I would reframe this discussion into a proposal a few changes from the >> existing code. >> >> ... > I'll reply to your proposal in due course, but for now to track it I've > created http://openjdk.java.net/projects/jigsaw/spec/issues/#VersionSyntax . > > - Mark > > > [1] http://download.java.net/java/jigsaw/docs/api/java/lang/module/ModuleDescriptor.Version.html > From mark.reinhold at oracle.com Thu Mar 31 15:48:58 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 31 Mar 2016 08:48:58 -0700 Subject: Issue: The JAXP+modules story is still a bit of a mess In-Reply-To: <20160311175051.593F39E89F@eggemoggin.niobe.net> References: <56DA1506.2010008@redhat.com> <20160311175051.593F39E89F@eggemoggin.niobe.net> Message-ID: <20160331084858.698503150eggemoggin.niobe.net> 2016/3/11 9:50:51 -0800, mark.reinhold at oracle.com: > 2016/3/4 15:06 -0800, david.lloyd at redhat.com: >> I'm not sure if this is just something that has not yet been gotten >> 'round to, but the way JAXP loading works has become somewhat less >> convenient. >> >> If you are a container author, and you need to supply your own global >> default JAXP implementation classes, your options are highly limited: >> you can rely on TCCL being set on every call to Xxxx.newFactory() (never >> going to happen 100% of the time in reality), or you can set the >> appropriate system properties and make your implementation visible from >> every class loader (something of the opposite of the kind of >> encapsulation that we have modules for). >> >> ... > > This is an issue for Java SE 9, and its forthcoming Umbrella JSR, rather > than for the module system itself. Further discussion on the OpenJDK core-libs-dev list [1] made me realize that this is, in fact, a problem that should be solved by a module-system requirement we previously recorded but have not yet addressed [2]. Since this is already an open requirement, there's no need to create a specific open issue for it. - Mark [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-March/039569.html [2] http://openjdk.java.net/projects/jigsaw/spec/reqs/#selective-binding From david.lloyd at redhat.com Thu Mar 31 16:01:10 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 31 Mar 2016 11:01:10 -0500 Subject: Issue: The JAXP+modules story is still a bit of a mess In-Reply-To: <20160331084858.698503150eggemoggin.niobe.net> References: <56DA1506.2010008@redhat.com> <20160311175051.593F39E89F@eggemoggin.niobe.net> <20160331084858.698503150eggemoggin.niobe.net> Message-ID: <56FD49C6.1070705@redhat.com> On 03/31/2016 10:48 AM, mark.reinhold at oracle.com wrote: > 2016/3/11 9:50:51 -0800, mark.reinhold at oracle.com: >> 2016/3/4 15:06 -0800, david.lloyd at redhat.com: >>> I'm not sure if this is just something that has not yet been gotten >>> 'round to, but the way JAXP loading works has become somewhat less >>> convenient. >>> >>> If you are a container author, and you need to supply your own global >>> default JAXP implementation classes, your options are highly limited: >>> you can rely on TCCL being set on every call to Xxxx.newFactory() (never >>> going to happen 100% of the time in reality), or you can set the >>> appropriate system properties and make your implementation visible from >>> every class loader (something of the opposite of the kind of >>> encapsulation that we have modules for). >>> >>> ... >> >> This is an issue for Java SE 9, and its forthcoming Umbrella JSR, rather >> than for the module system itself. > > Further discussion on the OpenJDK core-libs-dev list [1] made me > realize that this is, in fact, a problem that should be solved by a > module-system requirement we previously recorded but have not yet > addressed [2]. Since this is already an open requirement, there's > no need to create a specific open issue for it. Works for me. -- - DML