[jboss-as7-dev] Fwd: Late for the train

[Thomas Diesler]

Geoffrey,

 > unlike OSGi - the unit of reuse is the unit of release

in an ecosystem of distributed module providers, how can one provider 
reason about the requirements of another provider such that their 
requirements converge? Any complex system that has the notion of plugin 
would face this problem. For example, pluginA has a requirement on 
libraryX-1.0.0 and pluginB has a requirement on libraryX-1.1.0. How do 
you propose that libraryX is distributed in the target system?

Here some options:

#1 libraryX is available in both versions. pluginA/B bind to their 
respective versions
#2 libraryX is available in the highest compatible version (i.e. 
libraryX-1.1.0). pluginA/B bind to that

The problem with #1 is that it fails (is inconsistent) as soon as 
pluginA/B exchange a type from libraryX - you get a CCE
The problem with #2 is that you have to touch pluginA's wiring metadata 
- which contradicts "unit of reuse is the unit of release". pluginA must 
know that pluginB exists, which it cannot because A/B may be installed 
independently on user request.

Generally, in a complex modular system it must be possible to reason 
about A without having to think/know about B. Following this principal 
it not possible to make build time (release time) decisions that are 
guaranteed to be consistent at runtime. Instead you need to have an 
external authority that guarantees runtime consistency based on 
capabilities/requirements that can be defined at build time.

It's easy to see that a system based on human wiring decisions (may they 
be in manifest.mf, modules.xml or hard coded in DUPs) will fail as soon 
as complexity increases beyond a point where it cannot be managed any 
more by one team. It's in the nature of these complex systems that they 
are developed by distributed teams that don't even know about their 
respective existence.

In a nutshell: "unit of reuse is the unit of release" is too simplistic 
for complex modularity systems

cheers
-thomas


On 07/18/2012 09:07 AM, Geoffrey De Smet wrote:
> From what I 've read so far about Jigsaw, I like it.
> It would have consistent resolution (unlike OSGi - the unit of reuse 
> is the unit of release),
> it would be straightforward (unlike Maven -  there would be no "Maven 
> dependency puzzlers").
> And it would allow for runtime optimization.
> So basically, it would be JBoss modules ;)
>
> Anything particular why it would be a train wreck?
>
> With kind regards,
> Geoffrey De Smet
>
> Op 17-07-12 18:11, David M. Lloyd schreef:
>> This is actually great news for us... Jigsaw is a train wreck.  Maybe 
>> we'll have a chance to get in this game after all.
>>
>> -------- Original Message --------
>> Subject: Late for the train
>> Date: Tue, 17 Jul 2012 08:57:39 -0700
>> From: mark.reinhold at oracle.com
>> To: jigsaw-dev at openjdk.java.net
>>
>> As some of you are already aware, I've concluded with regret that 
>> Project
>> Jigsaw isn't going to make Java 8 as planned.  I've set out my reasoning
>> in a blog entry [1], and I've asked the Java SE 8 EG to consider 
>> dropping
>> the module system and modularization from the release [2].
>>
>> Slipping Jigsaw to Java 9 isn't an easy decision, but I think it's the
>> best of a set of unpleasant options.  We've made a lot of progress over
>> the past year, and I'm determined that we do our best to maintain our
>> momentum from here to Java 9.  I thank those who've contributed to this
>> effort so far, in ways both large and small, and I hope you'll all be
>> able to stay aboard for the rest of the journey.
>>
>> - Mark
>>
>>
>> [1] http://mreinhold.org/blog/late-for-the-train
>> [2] 
>> http://mail.openjdk.java.net/pipermail/java-se-8-spec-observers/2012-July/000001.html
>>
>
>

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx