Re: multiple inheritance in Java
On 7/2/2013 4:28 PM, Jeff Higgins wrote:
On 07/02/2013 03:44 PM, Eric Sosman wrote:
On 7/2/2013 2: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.
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.
Oh, now I get it. I hadn't realized that you meant the
"compatibility layer" to be unavailable unless specifically
requested. But I think that's a non-starter: Look at all the
"current" classes that still use "old" stuff. Vector, to take
your example, is required by the Swing classes ButtonGroup,
DefaultComboBoxModel, JComboBox, JList, JTable, and JTree,
and perhaps others. (Wisecracks about moving all of Swing to
"old" will be punished with great severity. :)
Known uses of Vector:
<http://docs.oracle.com/javase/7/docs/api/java/util/class-use/Vector.html>
I don't mean to suggest throwing the baby out with the bath water.
We could have a new 'old' API sans the grime, but
I guess it's a "non-starter" because noone wants to pay the price
for a cleaner Java Standard Library.
Yah. Keep in mind that it's not only Snoracle's price to pay,
but also the developers and maintainers of all the Java code in
the world. Seems to me they'd face a choice between
1) Ripping all the "old" stuff out of their existing Java code,
and out of their test code, and out of the tools that write
Java code for them, and fixing the inevitable bugs.
2) Modifying all their build procedures to add "-compatibility",
and fixing the breakage from the inevitable silly typos and/or
version skew.
3) Sticking with the pre-split Java version indefinitely, and
trying to pressure Snoracle into dual-releasing all new
features (not to mention security fixes).
A development manager's first choice would probably be (3) until
and unless Larry finally balks. At that point the fallback would be
(2), as it looks like less work (remember, whatever work is required
just regains the status quo ante without improving the end product;
development managers hate spending their budgets on unproductive work).
I cannot imagine anyone undertaking (1) on a significant body of code,
although they might mandate following it for new code. "Write once,
rewrite often."
The upshot is that the division into rt.jar and rtc.jar would
actually go into effect for only a tiny fraction of Java code -- I
don't think "It'll be cleaner" will motivate Larry to rewrite Fusion
or Ginni to overhaul WebSphere -- so the division would actually
accomplish almost nothing ...
... which matches up pretty well with the posited benefits ...
--
Eric Sosman
esosman@comcast-dot-net.invalid