call a procvar (includes virtual constructors and virtual class methods),
and raise its getCause() so that the original exception is propagated to
the caller
git-svn-id: branches/jvmbackend@19030 -
* fixed FpcBaseProcVarType.clone: create a new method field "pointer" and
set it (using the java.lang.reflect interface). Previously, the pointer
to the method record was copied via the inherited clone, which meant
that the original and new procvar shared it
git-svn-id: branches/jvmbackend@18816 -
* catch java.lang.NoSuchMethodException exceptions when resolving a procvar,
because java.lang.Class.getDeclaredMethod() only searches that particular
class itself and not its parents -> in case we get the address of a method
that's not overridden in the current class, also search the parent classes
git-svn-id: branches/jvmbackend@18730 -
on the caller side whether it's a normal or class method that we are
calling, add the self-class parameter inside the invoke method if
necessary (by simply counting the number of parameters and inserting
it if we're one short)
git-svn-id: branches/jvmbackend@18699 -
o every porocedural variable type is represented by a class with one
public "invoke" method whose signature matches the signature of the
procvar
o internally, dispatching happens via java.lang.reflect.Method.invoke().
WARNING: while this allows calling private/protected or other methods
that are normally not accessible from another context, a security
manger can override this. If such a security manager is installed,
most procvars will cause security exceptions
o such dispatching also requires that all arguments are wrapped, but
that's done in the compiler-generated body of the invoke method,
so that procvars can also be called conveniently from Java code
o typecasting between a procedure of object and tmethod is supported,
as well as Delphi-style replacing of only the method pointer via
@procvar1=@procvar2.
o nested procvars are not yet supported, but most of the basic
infrastructure for them is already present
* all units/programs now get an internal __FPC_JVM_Module_Class_Alias$
type when compiled for the JVM target, which is an "external" class
that maps to the unit name. This is required to look up the
JLRMethod instances for regular functions/procedures
+ new tabstractprocdef.copyas() method that allows to create a procvar
from a procdef and vice versa
git-svn-id: branches/jvmbackend@18690 -