[fpc-devel] JVM: Question regarding converted Java code

[Jonas Maebe]

On 28 Dec 2011, at 23:28, Sven Barth wrote:

> 1) as it seems to be a rather usual practice in Java, would it be possible to disable the "Constructor should be public" warnings if the target cpu is the JVM?

Yes.

> 2) in the code I converted the classes often seem to "reintroduce" methods that are available in parent classes or implemented interfaces with different result types without declaring the original method though.
> 
> === Pascal source begin ===
> 
>  OBLocation = class external 'org.bukkit' name 'Location' (JLObject, JLCloneable)
>  public
>    ...
>    function clone(): OBLocation; overload; virtual;
>    ... // <= other functions between
>    function clone(): JLObject; overload; virtual;  // throws java.lang.CloneNotSupportedException
>  end;
> 
> === Pascal source end ===
> 
> Is this indeed correct? Does the compiler (or the JVM) indeed call the correct function in the end (in this case org.bukkit.Location.clone)?

The Java language does not support overloading based on result type, just like FPC. The JVM bytecode specs do allow it though, which enabled Sun to allow overriding an inherited method with a method that returns a child type of the original result type.

They do this by automatically also generating a method with the original return type, which simply calls the newly added method (since the child type can be implicitly converted to the original type, this is no problem). That way, regardless of which method is called, the correct code is always executed. This is required for correct operation because if, in your example, you would assign the OBLocation instance to a JLObject variable and then call its clone method (assuming for a moment that clone would be public in JLObject), javacc would generate code to call the clone-variant that returns JLObject rather than OBLocation (since JLObject does not declare clone with an OBLocation result type).

The warning in this case should probably be demoted to a hint in case of external classes, because for simplicity reasons javapp does not check for each method whether it is overriding method in a parent class or not. That is already done in most cases, but not for this particular case, apparently. It's strange that the clone():JLObject method apparently does not get a "synthetic" attribute in the class file (otherwise javapp would skip it), because that's normal for compiler-generated routines.


Jonas

PS: There's currently a bug in the JVM compiler in that it also allows you to override functions with ones that have a different return type, but it doesn't automatically generate overridden methods using the original return type to redirect them to the new one.