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