multiple inheritance in Java

[Stefan Ram]

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?

 

[Eric Sosman]

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.

 

[Stefan Ram]

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.

 

[Eric Sosman]

Because they forbid this, my question asked for a kind
of emulation of multiple inheritance.


I deal with the special case, when there are no conflicts,
and one just wants to merge (not literally) two classes.


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?

 

[Stefan Ram]

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

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

 

[Eric Sosman]

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."

 

[Jeff Higgins]

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.

 

[Eric Sosman]

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.

 

[Jeff Higgins]

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.

 

[Lew]

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

 

[Jeff Higgins]

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.

 

[Eric Sosman]

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.

 

[Jeff Higgins]

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.

 

[Jeff Higgins]

I guess it's a "non-starter" because noone wants to pay the price
of bathing the CAFEBABE.

 

[Eric Sosman]

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

 

[Jeff Higgins]

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?

 

[Steven Simpson]

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?

 

[Arne Vajhøj]

I meant to say fail to compile here
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

 

[Arne Vajhøj]

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

 

[Arne Vajhøj]

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?


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