JavaFactory provides generators for Java constructs.
Once Java constructs have been connected into
a complete class definition, the class can be generated
from them.
The generated class is created as a byte-code array that
can then be loaded by a class loader or, in our case,
the class utilities wrapper around our special class loader.
Each method shows the equivalent Java in the line starting
"Java:" in the header comment. Items in the java code that
begin with # refer to parameters used in constructing the
object. So, for example, newReturnStatement takes a parameter
named value; its Java code is:
Java: return #value;
This represents the fact that newReturnStatement returns a
object that represents a return statement that returns the
value represented by the parameter named value.
REVISIT: when StandardException is moved to BasicServices,
all of these want to support it so they can throw
real NotImplementedYet exceptions. It is expected that alot
of this interface can be not-implemented for engines that
do not need this complete treatment of the language.
Known Java constructs missing from this interface include:
- array initializers
- ,-lists of statements in for segments
- accessing a field of the current object or class without
including this or the class name
- declaring a list of variables against one type
- conversions/coercions/promotions of types
- empty statement
- labeled statement
- switch statement
- break, continue statements
- "super" expression (akin to the "this" expression).
- operations on multi-dimensional arrays
This interface also does not do real compilation -- there are no
checks for things like initialization before use of variables,
inclusion of catchs on throws, dead code, etc. Its purpose is to
let other parts of the system piece together what they know is valid
code and get bytecode out of doing that.
Also, implementations will require that the constructs be built
appropriately or they may fail to produce a valid class. For example,
newStaticMethodCall must be used to call static methods only,
not non-static local instance methods.
Implementations may be more, or less strict. You are best off assuming
you have to piece together each java construct and be as explicit as
possible. So, constructors must be created with newConstructor, not
newMethodBuilder; constructors must include the explicit call to
super(...) or this(...), as their first statement; all methods and
constructors must contain a final return statement at the end of
their code path(s). Method calls will derive the method to call
based on the type of the argument, so you must cast arguments as
the system will not search for a close method and coerce arguments
appropriately. This includes coercing them to be some superclass or
interface that they already are.
author: ames |