About java Runtime self-written public API compatibility

Question

I just encounter a real problem about changed API. And i want to know more about this topic. Using the following example as a demo.

There are 4 simple classes, Child class extends Parent. PubAPI is the class which provides public method for cient use. Client class invokes PubAPI's public methods.

public class Parent
{
}

public class Child extends Parent
{
}


public class PubAPI
{
public Parent getChild(){
    return new Child();
}
}


public class Client
{
public static void main(String[] args)
{
    System.out.println(new PubAPI().getChild());
}
}

The first 3 class is provided by an API maker, let's say the above version is version 1.

in Version 2, the PubAPI class is changed to return child type :

public class PubAPI
{
public Child getChild(){
    return new Child();
}
}

the 3 API provider class is in versoin 2 now, while if we don't recompile the "Client" class and use its version 1 generated class file. IT will fail in java runtime with error can not find the version 1 method (because the return type changes).

I don't know this before, and i want to know if anyone know more about this topic , for example, if the public API add a throw, or addd a synchronize or the class become final, etc. In these situation, how will it hehave.

IN all, what is the public API/class bytecode level compabability rule for API classes used by others.

thanks.

Answer 1

EDIT: You asked almost the exact same question two weeks back and accepted an answer. I am wondering what prompted you to ask again, you didn't think the rules would have changed in two weeks, did you?

You are on the right track with the keyword bytecode level compatibility. It is called binary compatibility which you can look up on the net. For example, here

The rules are not always easy to understand at first but usually make sense when you get an error and think about them. Best thing is to try the individual cases you have listed and when you get an error confirm in JLS that is an incompatibility and then try and rationalize for yourself why it is so.

This question on so seems to discuss the exact same issue. The document at eclipse it sites is an easier read than JLS.