SDA SE Wiki

Software Engineering for Smart Data Analytics & Smart Data Analytics for Software Engineering

User Tools

Site Tools


Migration to AST Version 2.6.0

JTransformer Release 2.6.0 incorporates some new and redesigned PEFs. In order to migrate from a pre-2.6.0 Version the changes described on this page must be taken into consideration.

Changes Overview

The language specific PEFs projectT,projectLocationT and fileT have been modified/replaced to represent language independent information.

The suffix S of projectS, sourceFolderS and fileS indicates that these elements belong to the language independent representation of source information (S = Source), not to an Abstract Syntax Tree (which has the suffix T – for Tree). compilationUnitT is the link from the Java AST to the source representation.

Now there are two containment hierarchies, a language-independent one (projectSsourceFolderSfileS) and a Java-sepcific one (packageTcompilationUnitTclassDefT ← …). They are linked by the reference from compilationUnitT to fileS.

[Just for historical completeness (superseded by the following “Detailed description of changes”: Upgrade from 2.5.0 to 2.6.0.]

Detailed description of the changes

projectT has been replaced by projectS

projectLocationT has been replaced by sourceFolderS

The projectLocationT element has been removed from the AST specification. It has been replaced by a sourceFolderS element representing a source folder in an Eclipse project represented by a projectS element.

projectLocationT(#file, 'ProjectName', 'SourceFolder')
sourceFolderS(#id, #ProjectID, 'SourceFolder')

fileT has been replaced by fileS and compilationUnitT

Up until version 2.6.0 fileT facts had been used to represent java source files. fileT has been replaced by

  • by fileS facts representing any kind of source file in some Eclipse source folder.
  • by compilationUnitT facts representing a Java compilation unit.

Migrating to the new representation requires replacing any <code Prolog>

fileT(Id, Package, Filename, Definitions) 

</Code> by <code Prolog>

separate_imports_from_types(Definitions, Imports, Types),
compilationUnitT(Id, Package, FileId, Imports, Types),
fileS(FileId, SourceFolder, Filename).

</Code>

classDefT now refers to a compilation unit

In addition, classDefT now does not reference a package as a parent but refers instead to a compilation unit. So any <code Prolog>

classDefT(Id, Package, Classname, Definitions) 

</Code> must be checked manually. In cases where the existing code does not use the package reference (that is, the package reference is an anonymous or singleton variable) one does not need to change anything, except singleton variable names: <code Prolog>

classDefT(Id, __CompilationUnit, Classname, Definitions)

</Code> If the package reference is relevant, one must write <code Prolog>

classDefT(Id, CompilationUnit, Classname, Definitions)
compilationUnitT(CompilationUnit, Package, _, _, _)

</Code>

Byte-code classes refer to a dummy compilation unit that refers to a dummy file with the ID 'dummyFile', the correct package, an empty list of imports and a type definition list that only contains the respective byte-code class. For each class #C for which “externT(#C)” is true, we have the following representation:

<code Prolog>

externT(#C).
classDefT(#C, #CompilationUnit, Classname, Definitions).
compilationUnitT(#CompilationUnit, #Package, 'dummyFile', [], [#C]).

</Code>

importT now refers to a compilation unit

importT facts no longer reference a file as a parent but a compilationUnitT:

  compilationUnitT(#CompID,#Package,#File,[#Import],[#Types]).
  importT(#Import,#CompID,#X).
research/jtransformer/api/java/migration/2.6.txt · Last modified: 2018/05/09 01:59 (external edit)

SEWiki, © 2019