Java 8 introduces default methods. In the current HotSpot implementation this makes adding a private method to a non-final class a binary breaking change (contrary to what the JLS says about this).
Here's an example. Suppose you have two separate code bases Lib and App, shipped by different parties. App depends on Lib.
Lib defines a class B:
public class B {}
App defines an interface I and a class D:
public interface I { default void m() { System.out.println("I.m"); }}
public class D extends B implements I { public static void main(String[] args) { D d = new D(); d.m(); }}
All is well in the world. Now Lib ships a new version that includes a new version of class B:
public class B { private void m() { }}
Now when you run D the output is:
Exception in thread "main" java.lang.IllegalAccessError: tried to access method B.m()V from class D at D.main(D.java:4)
You could argue that this is "just" an implementation bug, but I posted it as part of this series because it is symptomatic of the mess that is Java's method dispatch story.
Remember Me
I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.
Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)
Powered by: newtelligence dasBlog 2.3.12105.0
© Copyright 2021, Jeroen Frijters
E-mail