Oops, copying list... ---
Who's being forced? You don't specify modules at all and you automatically get the latest version of the standard lib modules compatible with java 7 APIs. You specify LATEST, and you're exposed to changes in API's You specify exact version numbers, and you're certain that your code will compile and run, even against a newer version of java. People can move at their own pace, however slow that may be, but it may also be a fast pace - in which case you'll no longer be held back by the demands of backward compatibility all the way to java 1.0 On Jul 19, 2012 8:20 PM, "Jess Holle" <[email protected]> wrote: > On 7/19/2012 2:09 PM, Kevin Wright wrote: > > And how does simply hiding stuff deal with this "unfortunate" mess: > > http://docs.oracle.com/javase/7/docs/api/java/util/class-use/Enumeration.html > > No amount of {display: none} in the javadoc CSS will allow those methods > to return an iterator instead, not unless you deprecate them all and > implement new versions with subtly different names, and that's just one of > the more obvious examples! > > Just use a wrapper Iterator (with unsupported operation for remove()). > > Jigsaw is the *only* way we'll be able to bump up version numbers and > genuinely remove methods or change their signatures. As you said, this > stuff can be hidden in JavaDoc (hell, ScalaDoc already does something > similar by banishing them to the bottom of the page: > http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/index.html#scala.collection.Traversable > ) > > But... That then has to be reimplemented for each and every tool, in > each and every language running on the Java *platform*. And it *still* > doesn't allow you to change signatures in a backwardly-compatible fashion. > > Ah... So you're suggesting creating substantially different (gutted) APIs > for new versions of the core library modules, thereby forcing one to update > everything one would use in their whole JVM process to use the new APIs for > that module rather than old ones in order to use anything (including bug > fixes) from the new module version. That's a complete non-starter as I see > it -- that's back to Python 3.0 albeit on a more granular scale. That > would be chaos for anyone with millions of lines of code and many dozens of > 3rd-party libraries in their JVM, i.e. those with large enterprise > applications like many in Java's bread-and-butter space, including me. > > In reality Jigsaw is nothing more than a "move crufty *classes* into a > separate, optional module" solution here. Changes within a class still > require all the same API evolution considerations one had before. That's > life in the real world. > > -- > Jess Holle > > -- 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.
