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
• Detailed description of the changes
  • projectT has been replaced by projectS
  • projectLocationT has been replaced by sourceFolderS
  • fileT has been replaced by fileS and compilationUnitT
  • classDefT now refers to a compilation unit
  • importT now refers to a compilation unit

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 (projectS ← sourceFolderS ← fileS) and a Java-sepcific one (packageT ← compilationUnitT ← classDefT ← …). 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.]

An Eclipse project is now represented by a projectS PEF with a unique ID.

projectT('projectName', 'localPath', 'outputProjectName', 'outputProjectLocalPath') ⇒
projectS(#id, 'projectName', 'localPath', 'outputProjectName', 'outputProjectLocalPath')

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')

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>

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 facts no longer reference a file as a parent but a compilationUnitT:

  compilationUnitT(#CompID,#Package,#File,[#Import],[#Types]).
  importT(#Import,#CompID,#X).