On 7/20/2012 2:42 PM, Kevin Wright wrote:
Nothing wrong with a half-baked solution. Something can have definite
value even if it's not "complete". But without the ability to evolve
the thing and change APIs under a different version number, it's too
risky to release in such a state.
No module system will give you what you want -- an ability to radically
and incompatibly change longstanding public APIs whenever and wherever
this is deemed more correct/pure/perfect, e.g. wherever you'd do it
differently if you could do it all over again.
That's a recipe for destroying the community -- irrespective of the
module system. OSGi wouldn't support that any better -- just imagine an
application using libraries which had 4 different versions of the
java.lang.String that they are trying to call one another with or having
to support 4 different flavors of your library (and maintenance bug
fixes to each) just to deal with the 4 different versions of
java.lang.String. Now imagine being faced with 4 different versions of
java.lang.String and 4 different independently varying versions of
java.util (what's the point in having modules if you can't increment
some versions indepedently)...
Modularity is important. Library versioning is important. Neither
allows you to redesign the core language APIs without either providing
backwards compatibility or fracturing the community -- those are your
choices.
--
You received this message because you are subscribed to the Google Groups "Java
Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
