Use-cases for version ranges?

Brian Pontarelli brian at pontarelli.com
Mon Nov 21 13:50:49 PST 2011 

That's an entirely different topic, by my quick opinion is that meta-data should be outside to increase performance. I shouldn't have to download every version of every module in my dependency graph to build/traverse/prune it.

-bp


On Nov 21, 2011, at 12:57 PM, David Bosschaert wrote:

> I think that the fact that in JBoss Modules the metadata is *outside*
> of the module (in a separate file that sits alongside the module) and
> in OSGi the metadata is *inside* the module (embedded in the Jar) is a
> significant difference.
> 
> If you have the metadata outside of the module you have additional
> flexibility. You can change the metadata without changing the module
> itself, so if there is an issue with the metadata you can easily fix
> it up (e.g. if you need to depend on another version of your
> dependency). Also there are obviously impacts of changing the module
> metadata if its inside the module and you are working with signed
> jars. On the other side, having the metadata inside the module has the
> benefit that you only need to worry about a single artifact: the
> module itself.
> 
> I'm not advocating one over the other here; I think both have
> benefits, but I think that using version ranges makes more sense in
> the case the metadata is embedded in the module.
> 
> If I'm not mistaken, the model that Jigsaw is going for is currently
> also the model where the metadata is inside the module.
> 
> David
> 
> On 21 November 2011 16:33, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> On 11/21/2011 10:11 AM, Neil Bartlett wrote:
>>> 
>>> David,
>>> I'm likewise tired of hearing these defeatist straw-man arguments.
>>> First, nobody is suggesting that you be forced to use version ranges.
>>> Second, nobody is suggesting that you be forced to design software by
>>> separating interfaces from implementation. Finally, nobody is
>>> suggesting that unmodified legacy code can be trivially modularised in
>>> *any* module system.
>> 
>> Trivial?  Depends on how you define it.  Most artifacts should be able to be
>> modularized as-is however, with minimal changes if any.  We adopted an
>> external descriptor strategy for the sole purpose of being able to use
>> modules as is, and we were able to package our 200+ modules just that way,
>> no repackaging needed.  So far the only problems we have really run into
>> seem to be legitimate bugs, and one or two libraries which assume a flat
>> classpath.
>> 
>> I just glanced at the quick stats for Maven Central.  There are 267,924
>> indexed artifacts at the time of this writing - 31,847 unique artifacts.
>>  This is a major reason why people even use Java in the first place. Ideally
>> we would be able to start with at least the possibility of having a somewhat
>> pre-populated repository.
>> 
>>> The module system must support both existing software and new
>>> software, of course. You seem suggest that I believe existing software
>>> is unimportant; nothing could be further from the truth. But I also
>>> believe that new software is important and that practices like
>>> interface/implementation separation and semantic versioning will help
>>> make the new software better than the old software.
>>> Therefore I believe that these features must be supported (though not
>>> mandated) in any new module system. You appear to be suggesting that
>>> these features are worthless because they cannot be applied to
>>> existing software, and/or will not be used by all Java developers.
>>> Well so what??
>> 
>> Not worthless, but a question of personal choice.  I believe that interface
>> and implementation separation has not been objectively shown to be a
>> superior way to write frameworks.  In my experience, sometimes it is and
>> sometimes it is not.
>> 
>> I believe that "semantic versioning" isn't going to work because most people
>> who develop Java software will not understand it or not get it right, due in
>> no small part to being a complex idea with a lot of subtlety.  In think that
>> empirical testing is the only way to ensure compatibility which will scale.
>> 
>>> Regards,Neil
>>> On Mon, Nov 21, 2011 at 3:15 PM, David M. Lloyd<david.lloyd at redhat.com>
>>>  wrote:
>>>> 
>>>> I'm tired of hearing pie-in-the sky, "intro to OOP" wishful crap like
>>>> this.
>>>>  Mission one should be supporting *existing* code.  The fact is that
>>>> people
>>>> do *not* always split their API from their implementation, and APIs
>>>> almost
>>>> *never* consist solely of interfaces.  There are many ways of designing
>>>> an
>>>> API which people consider "right" and I don't see anyone on this list
>>>> having
>>>> any special insight that would enable them to select the "one true"
>>>> approach
>>>> to API design.
>>>> 
>>>> The fact is that any version scheme or module resolution engine which
>>>> only
>>>> works for new code which is designed "properly" for it is *going* to
>>>> fail.
>>>>  And there's no reason for such constraints anyway.  Version ranges are
>>>> barely useful at all in practice.  The only ones who can assert
>>>> compatibility between two libraries of arbitrary version are the ones who
>>>> have tested the two together (along with anything else that uses a
>>>> combination of the two).
>>>> 
>>>> The best one can do establish *minimum* compatibility based on available
>>>> features, and test test test.  When a module is added to a repository, if
>>>> it
>>>> is tested by running both its internal unit tests and all available tests
>>>> of
>>>> all its dependents, then that should be adequate to establish
>>>> compatibility
>>>> *within a repository*.  There are too many factors to establish
>>>> compatibility beyond it.
>>>> 
>>>> On 11/20/2011 07:45 AM, Neil Bartlett wrote:
>>>>> 
>>>>> Stephen,
>>>>> 
>>>>> You again seem to be talking about dependencies on implementation
>>>>> packages. If we depend on APIs consisting primarily of interfaces,
>>>>> then versions and version ranges are reliable and can be completely
>>>>> automated.
>>>>> 
>>>>> Regards,
>>>>> Neil
>>>>> 
>>>>> 
>>>>> On Sun, Nov 20, 2011 at 12:25 PM, Stephen McConnell<mcconnell at dpml.net>
>>>>>  wrote:
>>>>>> 
>>>>>> I could say that the question is academic - but here is the thing - its
>>>>>> not
>>>>>> even academic.
>>>>>> 
>>>>>> We talk about versions and yet the platform has no computational
>>>>>> mechanisms
>>>>>> to flag version violation. At least an academic discussion would bring
>>>>>> in
>>>>>> grounded metrics.  In reality - the discussion here about V1 versus V2
>>>>>> and
>>>>>> that warm fuzzy feeling when your are just a n.m from an n+1 and it's a
>>>>>> waste of breath (and that comment goes to all sides of the debate).
>>>>>> 
>>>>>> Give me an endorsed tool that shows me that module [name]-[build] is
>>>>>> computationally backward compatible to a different [name]-[build] and
>>>>>> then,
>>>>>> only them will this discussion have reasonable grounds to assert any
>>>>>> authority on the subject of version compatibility (past or future).
>>>>>> Without
>>>>>> that tool - versioning is a unqualified statement of trust. And the
>>>>>> evidence
>>>>>> suggests that the threshold of trust delivery on actual computational
>>>>>> compliance is really really thin.
>>>>>> 
>>>>>> Cheers, Steve.
>>>>>> 
>>>>>> 
>>>>>> -----Original Message----- From: cowwoc
>>>>>> Sent: Sunday, November 20, 2011 1:39 PM
>>>>>> To: jigsaw-dev at openjdk.java.net
>>>>>> Subject: Re: Use-cases for version ranges?
>>>>>> 
>>>>>> 
>>>>>>    I'd like to propose another possibility: the author of the
>>>>>> dependency should tell *us* about version compatibility, not the other
>>>>>> way around. For example:
>>>>>> 
>>>>>> 1. The author of module A declares a dependency on module B version 1.2
>>>>>> (specific version).
>>>>>> 2. The author of module B publishes version 1.3. He declares that
>>>>>> version 1.3 is compatible with 1.2 (meaning, the runtime system is
>>>>>> allows to substitute version 1.3 for 1.2).
>>>>>> 
>>>>>>    The upside of this approach is that the author of B is in a better
>>>>>> position to declare compatibility than the author of A. The author of A
>>>>>> still only needs to test a single version. What do you think?
>>>>>> 
>>>>>> Gili
>>>>>> 
>>>>>> On 19/11/2011 1:59 AM, Neil Bartlett wrote:
>>>>>>> 
>>>>>>> Gili,
>>>>>>> 
>>>>>>> I didn't say anything about guarantees, and in this industry I have
>>>>>>> never heard of anybody providing a guarantees about the performance of
>>>>>>> their software, especially in the presence of external dependencies.
>>>>>>> 
>>>>>>> Version ranges are a means of communicating expectations, and we
>>>>>>> provide both a lower and an upper bound because this is useful
>>>>>>> information. I expect my module will work with 1.2.14, and I expect it
>>>>>>> will not work with 2.0. If I were a provider of the API rather than a
>>>>>>> consumer then I would have a much narrower expectation,  e.g.
>>>>>>> [1.2,1.3), and this would also be useful information to convey.
>>>>>>> 
>>>>>>> Regards
>>>>>>> Neil
>>>>>>> 
>>>>>>> On Sat, Nov 19, 2011 at 4:27 AM, cowwoc<cowwoc at bbs.darktech.org>
>>>>>>>  wrote:
>>>>>>>> 
>>>>>>>> Neil,
>>>>>>>> 
>>>>>>>>    I guess I don't understand why Jigsaw should work differently from
>>>>>>>> Maven
>>>>>>>> on this point. I am expecting developers to specify specific versions
>>>>>>>> that
>>>>>>>> they tested (point versions, not ranges) and end-users may override
>>>>>>>> these
>>>>>>>> "recommendations" as they see fit.
>>>>>>>> 
>>>>>>>>    Where you see version range [1.2.14, 2.0) as a way of
>>>>>>>> communicating
>>>>>>>> "the
>>>>>>>> developer guarantees 1.2.14 but you may use newer versions up to 2.0
>>>>>>>> at
>>>>>>>> your
>>>>>>>> own risk" I'd expect the developer to simply specify 1.2.14 and there
>>>>>>>> should
>>>>>>>> be no limit on what version end-users may use if they so wish.
>>>>>>>> 
>>>>>>>> Gili
>>>>>>>> 
>>>>>>>> On 18/11/2011 2:23 AM, Neil Bartlett wrote:
>>>>>>>>> 
>>>>>>>>> I noticed that I failed to address your point about Maven using
>>>>>>>>> point
>>>>>>>>> versions.
>>>>>>>>> 
>>>>>>>>> Maven is a build tool. At build time we need to compile against a
>>>>>>>>> single specific version so that we have repeatable builds. In
>>>>>>>>> general
>>>>>>>>> we should build each module against the lowest version of the
>>>>>>>>> library
>>>>>>>>> that it can possibly use, and there are no major negative
>>>>>>>>> consequences
>>>>>>>>> of having several versions of a library at build time (except that
>>>>>>>>> Maven has to download a lot!). At runtime however we need to have
>>>>>>>>> the
>>>>>>>>> flexibility to substitute a single compatible version.
>>>>>>>>> 
>>>>>>>>> Neil
>>>>>>>>> 
>>>>>>>>> On Fri, Nov 18, 2011 at 7:10 AM, Neil Bartlett<njbartlett at gmail.com>
>>>>>>>>>  wrote:
>>>>>>>>>> 
>>>>>>>>>> Suppose as the developer of module A, I declare a dependency on
>>>>>>>>>> log4j,
>>>>>>>>>> exactly version 1.0.0 because I have not tested against log4j
>>>>>>>>>> 1.0.1,
>>>>>>>>>> 1.0.2, 1.3, 999.999 etc. I effectively prevent my module *ever*
>>>>>>>>>> being
>>>>>>>>>> used with log4j version 1.0.1 even if this combinations is later
>>>>>>>>>> tested and proven to work by somebody else. In other words, testing
>>>>>>>>>> is
>>>>>>>>>> important but it doesn't necessarily have to always be done by the
>>>>>>>>>> original developer of each module.
>>>>>>>>>> 
>>>>>>>>>> On the other hand let's say I state my dependency using the
>>>>>>>>>> following
>>>>>>>>>> range: [1.2.14, 2.0). This is OSGi syntax and I believe Jigsaw is
>>>>>>>>>> following it, and it simply means I accept version 1.2.14 up to but
>>>>>>>>>> not including 2.0. Anybody can see that I compiled and tested
>>>>>>>>>> against
>>>>>>>>>> 1.2.14, but has the option of using 1.2.15, 1.2.16, 1.3, 1.9 etc.
>>>>>>>>>> It
>>>>>>>>>> does not mean that I *guarantee* my module will work with log4j 1.3
>>>>>>>>>> because that obviously depends on whether the log4j authors accept
>>>>>>>>>> and
>>>>>>>>>> follow the common semantics of indicating backwards-incompatible
>>>>>>>>>> changes with a bump to the first version segment.
>>>>>>>>>> 
>>>>>>>>>> The consequence of trying to lock down imports to a narrow range or
>>>>>>>>>> even a point version is that assembling an application becomes very
>>>>>>>>>> difficult, and we are forced to deploy many versions of common
>>>>>>>>>> libraries concurrently. This is non-optimal, though we can handle
>>>>>>>>>> it
>>>>>>>>>> to some degree via per-module classloaders as in OSGi.
>>>>>>>>>> 
>>>>>>>>>> Regards,
>>>>>>>>>> Neil
>>>>>>>>>> 
>>>>>>>>>> On Thu, Nov 17, 2011 at 11:52 PM, cowwoc<cowwoc at bbs.darktech.org>
>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Can someone please explain why modules need to be able to specify
>>>>>>>>>>> version
>>>>>>>>>>> ranges for dependencies? I believe OSGI allows the specification
>>>>>>>>>>> of
>>>>>>>>>>> version
>>>>>>>>>>> ranges while Maven allows the specification of individual
>>>>>>>>>>> versions.
>>>>>>>>>>> 
>>>>>>>>>>> The only thing that comes to mind is when module C depends on A
>>>>>>>>>>> and
>>>>>>>>>>> B,
>>>>>>>>>>> A
>>>>>>>>>>> depends on log4j 1.0, and B depends on log4j 1.1. What does C do?
>>>>>>>>>>> Is
>>>>>>>>>>> this
>>>>>>>>>>> the main use-case for version ranges?
>>>>>>>>>>> 
>>>>>>>>>>> By the sound of it, this is a trust model where developers are
>>>>>>>>>>> told
>>>>>>>>>>> that
>>>>>>>>>>> log4j 1.x won't break compatibility so they depend on that range
>>>>>>>>>>> without
>>>>>>>>>>> actually testing against each version (newer versions may be
>>>>>>>>>>> released
>>>>>>>>>>> after
>>>>>>>>>>> their own software). I question whether such a mechanism is better
>>>>>>>>>>> or
>>>>>>>>>>> worse
>>>>>>>>>>> than depending on individual versions which may be overridden at a
>>>>>>>>>>> later
>>>>>>>>>>> time (a la Maven). On the one hand, you don't need to release a
>>>>>>>>>>> new
>>>>>>>>>>> version
>>>>>>>>>>> of the application each time a dependency is updated. On the other
>>>>>>>>>>> hand,
>>>>>>>>>>> no
>>>>>>>>>>> one is actually running tests to ensure that the versions are
>>>>>>>>>>> really
>>>>>>>>>>> compatible.
>>>>>>>>>>> 
>>>>>>>>>>> Is there a way to get module A to see log4j 1.0 and module B to
>>>>>>>>>>> see
>>>>>>>>>>> log4j
>>>>>>>>>>> 1.1 (using separate ClassLoaders)?
>>>>>>>>>>> 
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Gili
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> View this message in context:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> http://jigsaw-dev.1059479.n5.nabble.com/Use-cases-for-version-ranges-tp5002801p5002801.html
>>>>>>>>>>> Sent from the jigsaw-dev mailing list archive at Nabble.com.
>>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> --
>>>> - DML
>>>> 
>> 
>> 
>> --
>> - DML
>>

More information about the jigsaw-dev mailing list