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
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
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
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
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
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
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
> 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.
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
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
.
-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
11 matches
Mail list logo