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

Groups > comp.lang.java.programmer > #24568 > unrolled thread

Re: multiple inheritance in Java

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

Page 1 of 2  [1] 2  Next page →

#24568 — Re: multiple inheritance in Java

On 7/1/2013 8:31 PM, Stefan Ram wrote:
>    Assume you needed a class ColorPoint in Java:
>
> class ColorPoint extends Position, Color;
>
>    . Would it be so bad to implement this using public fields
>    instead of classical delegation? Public fields:
>
> class ColorPoint
> { public final Color color;
>    public final Position position; ... }
>
>    , usage:
>
> point.color.r = 72;
> point.color.b = 65;
> point.color.c = 41;
> point.position.x = 212;
> point.position.y = 117;
>
>    . Classical delegation style:
>
> point.setR( 72 );
> point.setB( 65 );
> point.setC( 41 );
> point.setX( 212 );
> point.setY( 117 );
>
>    . I only ask, because public fields usually are frowned upon
>    in OOP, but what would be the drawback here, especially when
>    those fields are final?

     Sorry, but I can't make head or tail of your question.  I haven't
been following the prognostications for future Java versions, and the
only versions I know forbid multiple inheritance.  Besides, I don't
see where M.I. comes into the picture: You seem to be asking about
public fields and final fields, not about how to merge multiple
implementations and resolve their potential conflicts.

     Also, what are Position and Color?  It doesn't seem to me that
javax.swing.text.Position or java.awt.Color are candidates.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [next] | [standalone]

#24572

On 7/1/2013 10:16 PM, Stefan Ram wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>> only versions I know forbid multiple inheritance.
>
>    Because they forbid this, my question asked for a kind
>    of emulation of multiple inheritance.
>
>> Besides, I don't see where M.I. comes into the picture: You
>> seem to be asking about public fields and final fields, not
>> about how to merge multiple implementations and resolve their
>> potential conflicts.
>
>    I deal with the special case, when there are no conflicts,
>    and one just wants to merge (not literally) two classes.
>
>>      Also, what are Position and Color?
>
>    Classes whose objects represent what is the English meaning
>    of position and color of a pixel, i.e., x and y, and r, g,
>    and b. I was hoping that this might become clear from the
>    examples given.

     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!)

     Still, I don't see the relevance of multiple inheritance to
your question, which seems to boil down to: "What are the trade-offs
in exposing fields vs. using accessors?"  I think we can debate (have
debated) that matter at length without involving M.I. -- so it seems
I'm still missing your intent.

     Could you explain how you feel the exposure-vs-accessor debate
would play out differently with multiple and single inheritance?

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24577

On 7/2/2013 6:02 AM, Stefan Ram wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>>      Still, I don't see the relevance of multiple inheritance to
>> your question, which seems to boil down to: "What are the trade-offs
>> in exposing fields vs. using accessors?"  I think we can debate (have
>> debated) that matter at length without involving M.I. -- so it seems
>> I'm still missing your intent.
>
>    When an object O exposes two public fields of two classes P and Q,
>    this has some of the benefits that mutiple inheritance from both
>    P and Q would have, while one does not tediously has to code
>    a lot of delegating methods in this object O.
>
>    (When I really implement this, P and Q actually are interfaces,
>    but the during the creation of O an implementation of those
>    interfaces is assigned to their corresponding fields in O.)

     I still don't see the relevance of M.I. to the question.
Thought experiment: How would anything change if you were to
remove Q from the scenario altogether?

>    This might also be called »poor man's multiple inheritance«.

     I'm not sure why anyone would use that term for "making a
field public."

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24635

On 7/2/2013 8:13 AM, Eric Sosman wrote:
> On 7/2/2013 6:02 AM, Stefan Ram wrote:
>> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>>>      Still, I don't see the relevance of multiple inheritance to
>>> your question, which seems to boil down to: "What are the trade-offs
>>> in exposing fields vs. using accessors?"  I think we can debate (have
>>> debated) that matter at length without involving M.I. -- so it seems
>>> I'm still missing your intent.
>>
>>    When an object O exposes two public fields of two classes P and Q,
>>    this has some of the benefits that mutiple inheritance from both
>>    P and Q would have, while one does not tediously has to code
>>    a lot of delegating methods in this object O.
>>
>>    (When I really implement this, P and Q actually are interfaces,
>>    but the during the creation of O an implementation of those
>>    interfaces is assigned to their corresponding fields in O.)
>
>      I still don't see the relevance of M.I. to the question.
> Thought experiment: How would anything change if you were to
> remove Q from the scenario altogether?
>
>>    This might also be called »poor man's multiple inheritance«.
>
>      I'm not sure why anyone would use that term for "making a
> field public."

I understand his »poor man's multiple inheritance«.

Instead of:

public class A {
     public void ma() { ... }
}

public class B {
     public void mb() { ... }
}

public class C extends A, B {
}

C o = new C();
o.ma();
o.mb();

which is not valid in Java he wants:

public class A {
     public void a() { ... }
}

public class B {
     public void b() { ... }
}

public class C {
     public final A a;
     public final B b;
     public C() {
         a = new A();
         b = new B();
     }
}

C o = new C();
o.a.ma();
o.b.mb();

But it still has nothing to do with public field vs accessor
as the above also be done as (and IMHO should be done as):

public class A {
     public void a() { ... }
}

public class B {
     public void b() { ... }
}

public class C {
     private A a;
     private B b;
     public C() {
         a = new A();
         b = new B();
     }
     public A getA() {
         return a;
     }
     public B getB() {
         return b;
     }
}

C o = new C();
o.getA().ma();
o.getB().mb();

Arne

[toc] | [prev] | [next] | [standalone]

#24644

Am 04.07.2013 23:33, schrieb Arne Vajhøj:
[snip]
> I understand his »poor man's multiple inheritance«.
[snip]
>
> But it still has nothing to do with public field vs accessor
> as the above also be done as (and IMHO should be done as):
>
> public class A {
> public void a() { ... }
> }
>
> public class B {
> public void b() { ... }
> }
>
> public class C {
> private A a;
> private B b;
> public C() {
> a = new A();
> b = new B();
> }
> public A getA() {
> return a;
> }
> public B getB() {
> return b;
> }
> }
>
> C o = new C();
> o.getA().ma();
> o.getB().mb();
>
> Arne
Or even better, if you really want inheritance, use inner classes:

public class C {
     private CA a;
     private CB b;

     private class CA extends A {
         @Override
         public void a() { ... }
     }

     private class CB extends B {
         ...
     }

     public C() {
         a = new CA();
         b = new CB();
     }

     public A asA() {
         return a;
     }

     public B asB() {
         return b;
     }
}

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#24590

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.

On the plus side, I can now do this:
public class Scratch {
   public static void main(String[] args) {
     int mySSNumber = 000_00_0000;
     System.out.println(mySSNumber); // :-( }}

Progress.

[toc] | [prev] | [next] | [standalone]

#24592

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.

> On the plus side, I can now do this:
> public class Scratch {
>    public static void main(String[] args) {
>      int mySSNumber = 000_00_0000;
>      System.out.println(mySSNumber); // :-( }}
>
> Progress.

     A number like 089_89_8989 would be even more progressive.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24593

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.

[toc] | [prev] | [next] | [standalone]

#24595

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.

[toc] | [prev] | [next] | [standalone]

#24633

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.

Arne

[toc] | [prev] | [next] | [standalone]

#24634

On 7/4/2013 5:23 PM, Arne Vajhøj wrote:
> 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.

We need to live with the fact that the library has, is
and will continue to grow.

Arne

[toc] | [prev] | [next] | [standalone]

#24599

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. :)

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24600

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.

[toc] | [prev] | [next] | [standalone]

#24601

On 07/02/2013 04:28 PM, Jeff Higgins wrote:
> I guess it's a "non-starter" because noone wants to pay the price
> of bathing the CAFEBABE.
>

[toc] | [prev] | [next] | [standalone]

#24602

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

[toc] | [prev] | [next] | [standalone]

#24606

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?

[toc] | [prev] | [next] | [standalone]

#24594

WIth Java 8 don't we get default methods? You can multiply-inherit interfaces.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#24609

On 02/07/13 19:53, Lew wrote:
> WIth Java 8 don't we get default methods? You can multiply-inherit interfaces.

I don't see how default methods help here.  You might define Position as 
an interface:

   interface Position {
     int getX();
     int getY();
     void setX(int x);
     void setY(int y);
   }

...but what default implementations can you give any of these methods 
without adding some state to Position?


-- 
ss at comp dot lancs dot ac dot uk

[toc] | [prev] | [next] | [standalone]

#24610

On 03/07/13 10:46, Steven Simpson wrote:
> On 02/07/13 19:53, Lew wrote:
>> WIth Java 8 don't we get default methods? You can multiply-inherit
>> interfaces.
>
> I don't see how default methods help here.  You might define Position as
> an interface:
>
>    interface Position {
>      int getX();
>      int getY();
>      void setX(int x);
>      void setY(int y);
>    }
>
> ...but what default implementations can you give any of these methods
> without adding some state to Position?

This is an interesting question
It is possible to add state to an interface so that it is *almost* a class

The following compiles and runs on 64 bit Ubuntu Linux with

java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b96)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b38, mixed mode)

javac 1.8.0-ea

I haven't figured out all the mechanics or ramifications of this yet but 
it certainly looks like it is effectively possible to implement a form 
of multiple inheritance in Java. Not exactly an edifying prospect.

=============================================================

/* public instance variables for brevity */
class State{
     public Integer a = 0;
     public Integer b = 0;
}

interface Foo{

    /* explicitly static and final */
    Integer i = 0;
    State state = new State(); /* final reference, mutable instance */

    default public void doFoo(Integer x){
        //i = 10; /* illegal */
        Integer y = x + i;
        state.a = y + y;
        System.out.println("doingFoo, i + x is " + y);
        System.out.println("doingFoo, accessing state state.a is " + 
state.a);
    }
}

interface Bar{

    Integer i = 0;
    State state = new State();

    default public void doBar(Integer x){
        Integer y = x + i;
        state.a = y + y;
        System.out.println("doingBar, i + x is " + y);
        System.out.println("doingBar, accessing state state.a is " + 
state.a);
    }
}

/* who owns the state? */
class FooBarImpl implements Foo, Bar{
}

public class Test{
     public static void main(String[] args){
         FooBarImpl fbi = new FooBarImpl();
         fbi.doFoo(5);
	fbi.doBar(10);
     }
}

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#24611

On 03/07/13 13:01, lipska the kat wrote:
> It is possible to add state to an interface so that it is *almost* a 
> class [...]
>
> interface Foo{
>
>    /* explicitly static and final */
>    Integer i = 0;
>    State state = new State(); /* final reference, mutable instance */
>
>    default public void doFoo(Integer x){
>        //i = 10; /* illegal */
>        Integer y = x + i;
>        state.a = y + y;
>        System.out.println("doingFoo, i + x is " + y);
>        System.out.println("doingFoo, accessing state state.a is " + 
> state.a);
>    }
> }

Foo.state is effectively class state, rather than instance state, isn't 
it?  Some possibilities were discussed here:

<http://mail.openjdk.java.net/pipermail/lambda-dev/2012-July/005165.html>


-- 
ss at comp dot lancs dot ac dot uk

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web