On 20 July 2012 20:54, Jess Holle <je...@ptc.com> wrote: > 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. > > Radically change - yes Whenever and wherever - no
I'm only concerned with two classes of issue here: 1. The big, infrequent changes: removing Corba, breaking swing out into a separate module, a one-off replacement of all methods using enumeration to use iterable. The sort of legacy stuff that you often hear people wishing could be changed with each new release, but which is tied to backwards compatibility. 2. Very new stuff that's still evolving. Instead of hiding JavaFX 2 from the public for so long, it could have been released as a versioned module. Frequent changes here wouldn't be a problem in the same way as for more established functionality, because nobody's yet had time to build up any legacy code around them. The extreme way that I works because it happens in a very lean environment, where the developers are all co-located, the "application" is made up of numerous modules all communicating via JSON, and where almost all our services are for in-house consumption by our own client app. I can't imagine that approach working in the Java libs for a second. > 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 javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
