Re: Mutable modules

2016-05-18 Thread David M. Lloyd
I just raised this issue on the JPMS experts list, but I want to discuss the technical issues here. On 05/18/2016 08:23 AM, David M. Lloyd wrote: Related to #MutableConfigurations, in order to support dynamically changing deployments for containers (including, I believe, OSGi-compliant containe

Re: Mutable modules

2016-05-18 Thread Alan Bateman
On 18/05/2016 16:04, David M. Lloyd wrote: I just raised this issue on the JPMS experts list, but I want to discuss the technical issues here. On 05/18/2016 08:23 AM, David M. Lloyd wrote: Related to #MutableConfigurations, in order to support dynamically changing deployments for containers (i

Re: Mutable modules

2016-05-18 Thread David M. Lloyd
On 05/18/2016 10:35 AM, Alan Bateman wrote: On 18/05/2016 16:04, David M. Lloyd wrote: I just raised this issue on the JPMS experts list, but I want to discuss the technical issues here. On 05/18/2016 08:23 AM, David M. Lloyd wrote: Related to #MutableConfigurations, in order to support dynami

Re: Mutable modules

2016-05-18 Thread Alan Bateman
On 18/05/2016 17:13, David M. Lloyd wrote: At present, you can remove a module or a bundle even if existing dependent module classes are statically referring to their contents. It'll work fine as long as those classes haven't been loaded yet. So we'd basically be taking away this capability

Re: Mutable modules

2016-05-18 Thread Gregg Wonderly
The runtime environment needs to have a way that developers can impose version consistencies that make sense. In some cases it is just data consistencies which can be managed literally with data construction. But when code versions are mixed in with data versions, the runtime context needs to

Re: Mutable modules

2016-05-18 Thread David M. Lloyd
On 05/18/2016 12:36 PM, Alan Bateman wrote: On 18/05/2016 17:13, David M. Lloyd wrote: At present, you can remove a module or a bundle even if existing dependent module classes are statically referring to their contents. It'll work fine as long as those classes haven't been loaded yet. So we'd

Re: Mutable modules

2016-05-20 Thread Alan Bateman
On 18/05/2016 22:47, David M. Lloyd wrote: I mean in *our* current concept of a module, we can add/remove/modify the contents of a module (its "class path") at run time. It is up to the user to ensure that doing so makes sense. I don't think I can relate to the use case. As you probably know

Re: Mutable modules

2016-05-20 Thread Neil Bartlett
> On 20 May 2016, at 15:12, Alan Bateman wrote: > > On 18/05/2016 22:47, David M. Lloyd wrote: >> >> I mean in *our* current concept of a module, we can add/remove/modify the >> contents of a module (its "class path") at run time. It is up to the user >> to ensure that doing so makes sense.

Re: Mutable modules

2016-05-20 Thread David M. Lloyd
On 05/20/2016 09:12 AM, Alan Bateman wrote: On 18/05/2016 22:47, David M. Lloyd wrote: I mean in *our* current concept of a module, we can add/remove/modify the contents of a module (its "class path") at run time. It is up to the user to ensure that doing so makes sense. I don't think I can r

Re: Mutable modules

2016-05-20 Thread David M. Lloyd
I had one last follow-up thought, see below: On 05/20/2016 10:20 AM, David M. Lloyd wrote: You can't, on one hand, define a universal namespace and syntax for modules and their versions in the JDK or establish hard constraints on layer and module graph structure, and on the other hand expect oth

RE: Mutable modules

2016-05-20 Thread Stephen Felts
. -Original Message- From: Neil Bartlett [mailto:njbartl...@gmail.com] Sent: Friday, May 20, 2016 11:20 AM To: Alan Bateman Cc: jigsaw-dev Subject: Re: Mutable modules > On 20 May 2016, at 15:12, Alan Bateman wrote: > > On 18/05/2016 22:47, David M. Lloyd wrote: >> >> I