On 7/2/2013 3:12 PM, Jeff Higgins wrote:
On 07/02/2013 02:29 PM, Jeff Higgins wrote:
On 07/02/2013 01:40 PM, Eric Sosman wrote:
On 7/2/2013 1:17 PM, Jeff Higgins wrote:
On 07/02/2013 12:09 AM, Eric Sosman wrote:
Okay. It might have been clearer if you'd chosen names that
weren't already taken -- although, one must admit, that's not easy
to do with Java's ever-growing namespace bloat. (Factoid: The HTML
*index* for the 7.0 API occupies eighteen meg!)
Java never throws anything away. I wonder about a compatibility layer.
rt.jar would contain all of the current stuff, rtc.jar the old.
Not sure what the separation would accomplish. All the
package names would remain unchanged, all the class and method
and field names would remain unchanged, the JavaDoc would still
have to describe them all, and the JVM would need to open one
more file than it already does.
If someone wanted to expend the effort to do the pruning
the following would compile with the compatibility switch on
otherwise throw ClassNotFoundException.
I meant to say fail to compile here
Vector<String> v;
JList<String> l = new JList<String>(v);
I could download JDK9 or JDK9C, I guess only JDK9C compiler
would include the -compatibility switch.
So now each new release has a compatibility distribution in addition
to the version release distribution. A JSR would be attached to each
new version to determine the prunings and of course the physical
pruning must be done. If we want to maintain the status quo of
backward compatibility for evermore along with introduction of new
features then we will also want to accept the bloat.
Interesting concept.
But I don't think it will work in practice.
A big part of Java code is code intended to run in
Java EE context (web or full).
And it is very common to include a lot of external
libraries.
The chance that one of them will require the C version
is high.
So as a result then everybody will get the C version.
And this big change which would have required a huge
effort will have achieved nothing.