Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "MoDisco/Components/Java/Documentation/0.9"
(→Java model to KDM model transformation) |
(→User manual) |
||
Line 199: | Line 199: | ||
To launch Java generation : | To launch Java generation : | ||
− | *Add ''org.eclipse.gmt.modisco.java.generation'' in your plugin dependencies and use the '' | + | *Add ''org.eclipse.gmt.modisco.java.generation'' in your plugin dependencies and use the ''GenerateJavaExtended'' main method with input model and target folder as parameters. The code should look like this : |
− | + | GenerateJavaExtended javaGenerator = new GenerateJavaExtended(URI.createFileURI("C:/.../my.javaxmi"), | |
new File("C:/.../myOutputFolder"), new ArrayList<Object>()); | new File("C:/.../myOutputFolder"), new ArrayList<Object>()); | ||
javaGenerator.doGenerate(null); | javaGenerator.doGenerate(null); | ||
Line 207: | Line 207: | ||
Or | Or | ||
− | *Checkout ''org.eclipse.gmt.modisco.java.generation'' into the workspace from Eclipse SVN repository, and then Create an Accelo launch configuration pointing to '' | + | *Checkout ''org.eclipse.gmt.modisco.java.generation'' into the workspace from Eclipse SVN repository, and then Create an Accelo launch configuration pointing to ''GenerateJavaExtended'' java class, and specify the input model and target folder. Use "Acceleo plugin Application" runner in launch configuration. If an error "could not load class GenerateJavaExtended" occurs, it may be caused by an already installed 'org.eclipsxe.gmt.modisco.java.generation' plugin, thus you may use "Java Application" runner (however, with this second runner, Java code formating step, launched at the end of the generation, will not work if the classpath is not completed with the required related java libraries. |
Or | Or |
Revision as of 14:22, 16 December 2010
MoDisco |
Website |
Download |
Community |
Mailing List • Forums |
Bugzilla |
Open |
Help Wanted |
Bug Day |
Contribute |
Browse Source • Project Set File |
Contents
- 1 Java Metamodel
- 1.1 Main metaclasses
- 1.1.1 ASTNode
- 1.1.2 Model, Package, AbstractTypeDeclaration
- 1.1.3 NamedElement & notion of Proxy
- 1.1.4 TypeAccess, PackageAccess, SingleVariableAccess, UnresolvedItemAccess
- 1.1.5 BodyDeclaration
- 1.1.6 Expressions
- 1.1.7 Statements
- 1.1.8 Zoom on comments
- 1.1.9 Zoom on annotations
- 1.1.10 Zoom on generics
- 1.2 Requirements
- 1.3 Source Repository
- 1.4 Associated Discoverers
- 1.1 Main metaclasses
- 2 Java Discoverer
- 3 Java Generation
- 4 Java model to KDM model transformation
Java Metamodel
The Java metamodel : it is the reflection of the Java language, as defined in version 3 of "Java Language Specification" from Sun Microsystems ("JLS3" corresponds to JDK 5).
The Java metamodel contains 126 metaclasses. To better understand it, this page will introduce its main features (metaclasses and links).
You could also browse the model definition, java.ecore available in sources (see source repository).
A good tip is also to see the javadoc associated to the metamodel implemented by the Eclipse team in the JDT (Java Development Tool) project. This metamodel and Java are very similar.
Main metaclasses
ASTNode
Every metaclass (apart from the Model metaclass) inherits from ASTNode. As its name indicates, ASTNode represents a graph node. ASTNode has a reference to the Comment metaclass because almost every java element can be associated to a comment (block or line comment and Javadoc). More details in the "Comment" section.
Model, Package, AbstractTypeDeclaration
The root element of each Java model is an instance of the "Model" metaclass. It is a translation of the concept of java application, so it contains package declarations (instances of the Package metaclass). And package declarations contain type declarations (instances compatible with the AbstractTypeDeclaration metaclass), and so on...
NamedElement & notion of Proxy
A lot of java elements are "named", and this name could be considered as an identifier : methods, packages, types, variables, fields, ... So all the corresponding metaclasses inherit from the NamedElement metaclass.
Another goal of this metaclass is to indicate whether an element is part of the current Java application or not (element from an external library of from the JDK). So, external elements are tagged as proxy through a dedicated attribute and can be easily filtered. For example, instruction "System.out.println" has been decomposed into three named elements (one class, one variable and one method) the definitions of which are not part of the current Java application. So attribute "proxy" of these elements has been initialized to true.
TypeAccess, PackageAccess, SingleVariableAccess, UnresolvedItemAccess
To represent links between Java elements, metaclasses TypeAccess, PackageAccess, SingleVariableAccess and UnresolvedItemAccess were introduced. Each allows to navigate directly to a NamedElement (proxy or not) in the graph.
A TypeAccess represents a reference on a type. A PackageAccess represents a reference on a package. A SingleVariableAccess represents a reference on a variable. On the contrary, references to methods are direct.BodyDeclaration
A type declaration has different kinds of contents : fields, methods, static block, initialization block or other type declarations. All of these elements are of type BodyDeclaration metaclass.
Expressions
Like in many languages, the concept of expression exists in Java : it is a portion of code, without declarations, and its evaluation returns a value, numerical or boolean or other ... For example,++i
Statements
An "instruction" in Java is represented by the Statement metaclass. A block of code (Block metaclass) contains a collection of statements, and a block of code may be contained by a method. Some examples of statements in java :if, while, for, do, ...
Zoom on comments
There are three kinds of comments : line comments (//), block comments (/* */) and javadoc comments (/** */). Every comment contains text fragments, but we can have more information on javadoc comments (Javadoc metaclass): they can also contain javadoc tags that are identified and collected through instances of the TagElement metaclass.
Zoom on annotations
Official usage of annotations has been introduced in version 5 of the JDK. To handle them, annotation declarations are managed as type declarations (AnnotationTypeDeclaration metaclass) with specific attributes (AnnotationTypeMemberDeclaration metaclass). And annotation usages are translated into instances of the Annotation metaclass, which reference corresponding annotation declarations. And parameters are translated into instances of the MemberValuePair metaclass. Some statements also have a list of annotations.
Zoom on generics
Version 5 of the JDK also introduced the concept of "generics". Generic types of method declarations are translated into instances of TypeDeclaration of AbstractMethodDeclaration metaclass with arguments as instances of the TypeParameter metaclass. Uses of these generics are translated into instances of the ParameterizedType metaclass which reference concrete elements (type and type arguments).
A specific case of type argument is the "wildcard" (for example "<? extends X>"). There is a specific metaclass to handle it : WildCardType.
Requirements
To use the plug-in you need:
- JDK 1.5 or above
- a version of Eclipse 3.3 or above with the following set of plug-ins installed
- EMF 2.3.0 or higher
Source Repository
All of the source code is stored in a public source repository, which you can access at:
Associated Discoverers
The main discoverer available for this metamodel : Java Discoverer
Java Discoverer
The goal of the Java Discoverer plug-in is to allow practical extractions of Java models from Java projects.
Description
This plug-in aims at analyzing Java source code compliant with version 3 of "Java Language Specification" from Sun Microsystems and providing a model describing the information found, conforming to the Java metamodel.
A Java model contains the full abstract syntax tree of the Java program: each statement such as attribute definition, method invocation or loop is described. In addition, links between elements are resolved (by resolved link we mean for instance a link between a method invocation and the declaration of this method, or between the usage of a variable and its declaration). The model can thus be seen as an abstract syntax graph (ASG).
Requirements
To use the plug-in you need:
- JDK 1.5 or above
- a version of Eclipse 3.3 or above with the following set of plug-ins installed
- EMF 2.3.0 or higher
- ATL 2.0.0 or higher
- Java metamodel
Source Repository
All of the source code is stored in a public source repository, which you can access at:
User manual
The plug-in provides the user with a contextual menu to easily create models.
By right-clicking on a Java Project in the Eclipse Package Explorer view, you can quickly create the Java model of your application (see next Figure).
A discovery parameter window proposes to
- indicate to extend the analysis to required Java projects and libraries
- indicate to limit the analysis to types/fields/methods declarations (no Java statements/expressions analysis)
- indicate a filter to exclude some Java packages from analysis
Once launched, a progress bar will appear at the bottom of the window as soon as the operation begins. Depending on the size of your application, the reverse engineering process might take some time to complete (see next Figure).
At the end of the process, the newly created model files are added to the root of your project and are automatically opened in the default editor (see next Figure).
.javaxmi files can be opened in the Sample Ecore Model Editor (see next Figure).
They can also be opened in the MoDisco model browser (see next Figure) which brings some graphical improvements.
Discoverer API
Each MoDisco discoverer responds to a normalized interface and can be called programmatically (see org.eclipse.gmt.modisco.infra.discoverymanager.Discoverer).
As an example, you may checkout the code from org.eclipse.gmt.modisco.java.discoverer.tests project.
Java Generation
The goal of the Java Generation plug-in is to allow Java code generation from a Java model. Such a generation will fulfill some of the requirements for Legacy refactoring & migration.
Description
This plug-in proposes Acceleo MTL modules for generating Java files conforming to Java models. Templates are contained in two modules :
- Structures modules : top level templates for generating classes/method/field declarations
- Statements modules
Java models are obtained with Java Discoverer component.
Considering a Java legacy, a minimal migration/refactoring chain will involve :
- A Java model discovery step
- A M2M transformation step
- A Java generation code step with the current component
User manual
A prerequisite is a Java model. Please refer to the Java Discoverer user manual.
To launch Java generation :
- Add org.eclipse.gmt.modisco.java.generation in your plugin dependencies and use the GenerateJavaExtended main method with input model and target folder as parameters. The code should look like this :
GenerateJavaExtended javaGenerator = new GenerateJavaExtended(URI.createFileURI("C:/.../my.javaxmi"), new File("C:/.../myOutputFolder"), new ArrayList<Object>()); javaGenerator.doGenerate(null);
Or
- Checkout org.eclipse.gmt.modisco.java.generation into the workspace from Eclipse SVN repository, and then Create an Accelo launch configuration pointing to GenerateJavaExtended java class, and specify the input model and target folder. Use "Acceleo plugin Application" runner in launch configuration. If an error "could not load class GenerateJavaExtended" occurs, it may be caused by an already installed 'org.eclipsxe.gmt.modisco.java.generation' plugin, thus you may use "Java Application" runner (however, with this second runner, Java code formating step, launched at the end of the generation, will not work if the classpath is not completed with the required related java libraries.
Or
- It is now possible to generate java code directly from a .javaxmi Java model. Just right click on a model, and select "Generate java code from Java model". The code will be generated next to your .javaxmi file
Java model to KDM model transformation
The goal of the "Java to KDM transformation" discoverer is to get a KDM model from a Java model. It is useful when the only available informations on a java source code is contained in a Java model. Even without the source code it is then possible to get a KDM representation.
User Manual
A prerequisite is a Java model. Please refer to the Java Discoverer user manual.
Once launched, a progress bar will appear at the bottom of the window as soon as the operation begins. Depending on the size of your java model, the transformation might take some time to complete (see next Figure).
At the end of the process, the newly created model files are added to the root of your project and are automatically opened in the default editor (see next Figure).