On 29.12.2011 13:49, Jonas Maebe wrote:
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.
This would be nice :)
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).
Thank you for explaining this.
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.
According to
http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#80128
it should be rather easy to see whether a class file contains a
synthetic method, right? So a "cat classfile | grep -i synthetic" should
be sufficient? If so then there is indeed no such synthetic attribute
used in that class...
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.
Thank you for the warning.
Regards,
Sven
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
