Description Georg Lenz 2005-05-31 07:11:08 EDT

SQLJ Blocks in Java Classes 

1.Extensibility of the internal Java parser to SQLJ blocks so that Java
operations like "Organize Imports", Code Completion, Refactoring, QuickFix can
be carried out correctly. 

2.Possibility to carry out Java operations (like the above mentioned ones) on
file extensions other than .java, in particular .sqlj 

3.Extensibility of CompilationUnitEditor by sqlj blocks


Remarks:
To point one and three: There is no way to protect certain blocks of a Java
class that contains SQLJ statements from the Java parser. It simply reports an
error an stops. As a consequence of this the same is true for the
CompilationUnitEditor. To enable code completion and context menus for the SQLJ
blocks “dirty hacks” on internal classes are necessary.
To point two: The CompilationUnitEditor has at some places hard wired calls
against the “.java” file extension that enforces “ditry” workarounds like a temp
“.java” file.

Current problems: 

The internal java parser reports an error and stops. The above mentioned
operations cannot be carried out correctly. Results are incorrect outlines,
missing Java operations 

Again, we have to use internal classes, e.g. CompilationUnitEditor