The problem is that you then can't move to the latest module and thus
get access to the new APIs anywhere in your JVM unless/until you expunge
all usages of the old APIs from all of your own millions of lines of
code and all of the dozens of 3rd-party libraries you use.
This is a Python 3 schism. You wouldn't be able to move to the latest
of module X until your whole world was an ivory tower.
This would be a guaranteed recipe for all enterprise Java shops to stick
on whatever release was before this -- forever. You'd schism the
community each and every time you produced a new module version.
For similar reasons most any open source project with any brains keeps
all old methods and classes around once their APIs are initially stable
-- and moves to an entirely new package when they find they need to
violate this. That allows use of old and new APIs in parallel within
the same classloader without any OSGi fanciness. Breaking API
compatibility otherwise is nasty, user-vicious behavior. Moving to a
new package for Java classes is a non-starter in most cases -- better to
deal with cruft than to deal with java.lang.String and java.lang2.String
interoperability issues.
Note that even with something like OSGi juggling multiple versions of
one module within a JVM you still have java.lang.String and
java.lang2.String interoperability issues -- except they both have the
same class name (just different Class objects, different methods, etc)
to add to the confusion.
Oracle's not stupid -- such a move would be digging their own grave.
It's not the sort of language or platform evolution their customers can
tolerate.
On 7/19/2012 3:20 PM, Kevin Wright wrote:
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]
<mailto:[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.
--
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.
