Java has special markers on methods called synthetic and bridge.
JLS 13.1.7, "Any constructs introduced by a Java compiler that do not have a corresponding construct in the source code must be marked as synthetic ..."
So synthetic methods are anything generated by the compiler and not represented in the source code, and although it's not mentioned in that specification PDF very well, bridge methods are used to typecheck generics. (E.g. Animal.interactWith(Creature c) gets a bridge method interactWith(Object c), which casts to Creature and calls the other method.)
We have this API called Bukkit, which provides stable access to change how a Minecraft server works. One facet of the underlying implementation of the API (aka vanilla Minecraft), which we have little control over, was recently forced in version 1.6.1 to change from integer values to float values. And in the interest of avoiding the difficulty of another change, we chose to change all our API methods to doubles.
So, for example:
public int getHealth();
public void setHealth(int health);
// Must now be
public double getHealth();
public void setHealth(double health);
However, as always, we would like plugins compiled with the previous version, 1.5.2, to still work as much as possible - that's the whole point of the API.
The setHealth is a solved problem, just introduce an overload.
And currently, we have a method named _INVALID_getHealth(V)I which is being renamed at implementation compile (not API compile) to getHealth(V)I, and this lets the old plugins continue to run.
However, when someone tries to extend our implementation of these renamed methods, they get compile errors from the doubly-named methods and overriding.
Is there a way to provide both the int and double returns using a manually / tool-inserted synthetic or bridge method, that won't cause compilation errors for those who try to change parts of our API implementation?
