What the JSourceObjectizer is and what it does ...
In short, the JSourceObjectizer can be described as a Java® parser wrapper. Actually the JSourceObjectizer consists of the following three different parts and only one of these parts contains a parser:
- The JSOM (Java® Source Object Model) interface types
This part can be seen as the JSourceObjectizer's frontend. Once a Java® source has been parsed these interfaces provide all the methods to access the parser result and there's an interface type for most of the things that may occur within a Java® source code. Examples for such interface types are MethodDefinition, LocalVariableDeclaration, IfStatement, ThrowsClause, ModifierList, Annotation, AnnotationElementValue, BinaryOperatorExpression and so on. - The JSourceObjectizer's unmarshaller
The unmarshaller part contains not only a real Java® parser but also the implementations of the JSOM interface types. These implementations resolve the parser results and transform them into the appropriate JSOM types. The only type from the unmarshaller needed to be used by JSourceObjectizer users directly is the class Unmarshaller. All other classes within this part can be ignored for most cases - they just do their work. - The JSourceObjectizer's marshaller
Currently, this is just a placeholder for future versions of the JSourceObjectizer.
... and for what at all
A very good example of for what the JSourceObjectizer can be used is a tool written for one of the major Munich software companies. This tool is based on the JSourceObjectizer and its job is to check the compliance with internal programming guidelines from the semantical point of view.
Of course, a lot of such checks could also be done within a grammer definition, i.e. just in time when a Java® source gets parsed and resolved, for instance a check condition like 'System.exit() calls are not allowed' . However, semantical programming guidelines can have the nature to sound simple at first but become very complex if the compliance should be monitored automatically. This is the case for mostly all checks that need resolving type dependencies and/or managing symbol scope stacks. At a certain point of complexity it makes sense to have access to the parsed Java® code with the help of a collection of interfaces that represent the content of a Java® code in a more programmer-friendly way.