Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #24606

Re: multiple inheritance in Java

Show all headers | View raw

On 07/02/2013 05:13 PM, Eric Sosman wrote:
> 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 ...
>
I'm thinking now that "compatibility layer" might be one of those
overloaded terms that will cause the scar tissue to itch and throb
for some. If that's the case I'm deeply sorry.
compatibilitylayercompatibilitylayercompatibilitylayercompatibilitylayer
So beside the @deprecated annotation there is no mechanism for out with 
the old and in with the new? Is it possible to come up with some such? 
Is it desirable? Is the Java ecosystem so large that no breaking changes 
will ever be tolerated.  Will some future version of the Java
Standard Library have an HTML API index that breaks the 1 gig barrier?

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: multiple inheritance in Java Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-01 21:52 -0400
  Re: multiple inheritance in Java Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-02 00:09 -0400
    Re: multiple inheritance in Java Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-02 08:13 -0400
      Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 17:33 -0400
        Re: multiple inheritance in Java Sebastian <news@seyweiler.dyndns.org> - 2013-07-05 08:04 +0200
    Re: multiple inheritance in Java Jeff Higgins <jeff@invalid.invalid> - 2013-07-02 13:17 -0400
      Re: multiple inheritance in Java Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-02 13:40 -0400
        Re: multiple inheritance in Java Jeff Higgins <jeff@invalid.invalid> - 2013-07-02 14:29 -0400
          Re: multiple inheritance in Java Jeff Higgins <jeff@invalid.invalid> - 2013-07-02 15:12 -0400
            Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 17:23 -0400
              Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 17:25 -0400
          Re: multiple inheritance in Java Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-02 15:44 -0400
            Re: multiple inheritance in Java Jeff Higgins <jeff@invalid.invalid> - 2013-07-02 16:28 -0400
              Re: multiple inheritance in Java Jeff Higgins <jeff@invalid.invalid> - 2013-07-02 16:44 -0400
              Re: multiple inheritance in Java Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-02 17:13 -0400
                Re: multiple inheritance in Java Jeff Higgins <jeff@invalid.invalid> - 2013-07-02 22:12 -0400
  Re: multiple inheritance in Java Lew <lewbloch@gmail.com> - 2013-07-02 11:53 -0700
    Re: multiple inheritance in Java Steven Simpson <ss@domain.invalid> - 2013-07-03 10:46 +0100
      Re: multiple inheritance in Java lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-07-03 13:01 +0100
        Re: multiple inheritance in Java Steven Simpson <ss@domain.invalid> - 2013-07-03 14:12 +0100
          Re: multiple inheritance in Java lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-07-03 14:49 +0100
        Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-06 22:19 -0400
  Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 17:36 -0400
    Re: multiple inheritance in Java Gene Wirchenko <genew@telus.net> - 2013-07-05 11:01 -0700

csiph-web