Traits, Mixins and Multiple Inheritance — Find the Bug¶

Ten snippets across Java, Scala, Python, Ruby and C++ where multiple inheritance, mixins, or linearization produce something surprising or wrong. For each: read the code, decide what's wrong (or what it actually prints), then reveal the diagnosis. The Java equivalent is shown wherever the bug is cross-language so you can see how Java's explicit model would have caught it.

1. The Java default conflict that "should just pick one"¶

interface Json { default String render() { return "{}"; } }
interface Xml  { default String render() { return "<x/>"; } }

class Document implements Json, Xml { }

String s = new Document().render();

What's wrong?

class Document implements Json, Xml {
    @Override public String render() { return Json.super.render(); }   // explicit choice
}

2. The Scala linearization that surprises¶

trait Base { def tag: String = "B" }
trait L extends Base { override def tag: String = "L-" + super.tag }
trait R extends Base { override def tag: String = "R-" + super.tag }

class C extends L with R
println(new C().tag)

What does it print — "L-R-B" or "R-L-B"?

3. The Python super() that skips to a sibling¶

class A:
    def who(self): return ["A"]
class B(A):
    def who(self): return ["B"] + super().who()
class C(A):
    def who(self): return ["C"] + super().who()
class D(B, C): pass

print(D().who())

["B", "A"]? Something else?

4. The C++ diamond that compiles but stores two values¶

struct Account { double balance = 0; };
struct Checking : Account { };
struct Savings  : Account { };
struct Combined : Checking, Savings { };

Combined c;
c.Checking::balance = 100;
double total = c.Savings::balance;   // what is total?

What is total?

struct Checking : virtual Account { };
struct Savings  : virtual Account { };   // now ONE shared Account

5. The Ruby module order bug¶

module Greet  def hi; "hi"; end end
module Shout  def hi; "HI"; end end

class Speaker
  include Shout
  include Greet
end

puts Speaker.new.hi

"HI" or "hi"?

6. The Java "interface-as-state" that's secretly global¶

interface Counted {
    AtomicInteger COUNT = new AtomicInteger();          // looks like per-instance state
    default int next() { return COUNT.incrementAndGet(); }
}
class A implements Counted { }
class B implements Counted { }

new A().next();   // 1
new B().next();   // ??

What does new B().next() return?

7. The Python C3 that won't even load¶

class A: pass
class B: pass
class X(A, B): pass
class Y(B, A): pass
class Z(X, Y): pass        # <-- here

What happens at the marked line?

8. The Java default that's silently dead code¶

interface Loggable {
    default String describe() { return "loggable"; }
}
class Entity {
    public String describe() { return "entity"; }
}
class User extends Entity implements Loggable { }

new User().describe();

Does this return "loggable"?

9. The Scala stackable-trait order regression¶

trait Validating extends Service { abstract override def run() = { validate(); super.run() } }
trait Logging    extends Service { abstract override def run() = { log(); super.run() } }

// v1
class S1 extends BaseService with Logging with Validating
// v2 — someone "tidied" the mixin order
class S2 extends BaseService with Validating with Logging

Why might S2 be a production incident?

10. The Java super that can't reach the grandparent¶

interface Vehicle { default String kind() { return "vehicle"; } }
interface Car extends Vehicle { }
class Sedan implements Car {
    @Override public String kind() {
        return Vehicle.super.kind() + "/sedan";   // <-- here
    }
}

Why won't this compile?

11. The mixin that breaks equals/hashCode expectations¶

interface Identified {
    String id();
    default boolean sameAs(Identified o) { return id().equals(o.id()); }
}
record User(String id, String name) implements Identified { }

Set<User> set = new HashSet<>();
set.add(new User("u1", "Ann"));
boolean dup = set.contains(new User("u1", "Bob"));   // ??

Is dup true?

Patterns across these bugs¶

• Implicit order is the recurring hazard (#2, #3, #5, #9): Scala linearization, Python MRO, Ruby ancestor chain all make super mean "next in a computed order", and reordering mixins silently changes behavior. Java's explicit X.super.m() (#1, #10) trades verbosity for the elimination of this entire class of bug.
• State on interfaces is always global (#6): §9.3 gives you static final, never per-instance — "stateful mixin" is a contradiction.
• Classes win, silently (#8): a default never beats a class method; defaults written to "provide" behavior can be dead code.
• The state diamond is real in C++ (#4) and impossible in Java — the single payoff of forbidding multiple state inheritance.
• Linearization can fail to exist (#7): an emergent, fragile-base-style failure Java structurally cannot produce.