SDA SE Wiki

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

User Tools

Site Tools


Java Types in JT 4.0

This file describes the changes in the type representation from JT 3 to JT 4.

Problems of JT 3 Representation

  1. The representation of types in JTransformer 3.0 was inconsistent:
    1. Class types (C) were represented uniquely, each class declaration by exactly one fact.
    2. Array types (C[]), parametrized types (Set<C>), and the type wildcard (*) where represented redundantly, with one fact per use of that type. E.g two different uses of C[] resulted in two different facts. In addition to the conceptual inconsistency, the redundant representation of array types, parameterized types and wildcards wasted storage.
  2. Type facts were referred to indirectly via a typeRefT fact. The related indirection wasted even more storage, complicated writing queries and slowed down their execution.
  3. Copmparing types1) required comparing the structure of several PEFs instead of comparing just a value (an ID).
  4. Copying types2) required copying the structure of several PEFs instead of copying just a value (an ID).
  5. Creating types3) required creating several facts and linking them properly with their parent (the declaration in which they occurred).

Benefits of JT 4 Representation

  1. Consistent handling of all types (simplifies learning JT and writing queries and transformations).
  2. No redundancy (saves memory and speeds up factbase creation).
  3. Easy comparison of types by comparing their IDs.
  4. Easy copying of type references by copying type IDs.
  5. No need to copy the (unique) type PEFs.

Change 1: Unique Type Facts

In JT 4.0, for each type there is a single fact that represents it. This applies not only to class types, but also to array types, parameterized types and wildcards. For example, there is a single fact that represents the type List<String> and a single one for the type C[].

Change 2: Removed parent references

As a result of change 1, in JT 4, array types, parameterized types an wildcards are now globally unique entities. Correspondingly, the facts that represent them do not have any parent reference anymore. They can be referenced from a number of other elements / facts and therefore it is not possible to define a unique parent:

JT 3 JT 4
arrayTypeT(#id, #parent, #type, 'dim') –> arrayTypeT(#id, #type, 'dim')
parameterizedTypeT(#id, #parent, #rawType, [#typeParam_1, …]) –> parameterizedTypeT(#id, #rawType, [#typeParam_1, ...])
wildCardT(#id, #parent, 'kind', bounds) –> wildcardT(#id, 'kind', bounds)

Change 3: Removed typeRefT

In JTransformer 4, each use of a type is represented by referencing the respective type fact directly, using its id. There are no more typeRefT indirections.

All PEFs that previously (JT 3) referred to a typeRefT/4 fact now (JT 4) directly refer to the PEF referenced by the typeRefT.

Example: Class Types and Basic Types

For example, two fields “C f1;” and “int f2;” are represented as follows:

JT 3 –> JT 4
IN EACH MEMBER DECLARATION
fieldT(F1, …, TR1, 'f1', …). fieldT(F1, …, IdOfC, 'f1', …).
typeRefT(TR1, F1, F1, IdOfC).
fieldT(F2, …, TR2, 'f2', …). fieldT(F2, …, IdOfint, 'f2', …).
typeRefT(TR2, F2, F2, IdOfint).
UNIQUE
classT(IdOfC, …, 'C', …). classT(IdOfC, …, 'C', …).
basicTypeT(IdOfint, int). basicTypeT(IdOfint, int).
Example: Array Types

For example, two fields “C[] f1;” and “C[] f2;” are represented as follows:

JT 3 –> JT 4
IN EACH MEMBER DECLARATION
fieldT(F1, …, AT1, 'f1', …). fieldT(F1, …, AT, 'f1', …).
arrayTypeT(AT1, F1, TR1, 1).
typeRefT(TR1, AT1, F1, IdOfC).
fieldT(F2, …, AT2, 'f2', …). fieldT(F2, …, AT, 'f2', …).
arrayTypeT(AT2, F2, TR2, 1).
typeRefT(TR2, AT2, F2, IdOfC).
UNIQUE
classT(IdOfC, …, 'C', …). classT(IdOfC, …, 'C', …).
arrayTypeT(AT, IdOfC, 1).
Example: Parameterized Types

For example, two fields “C<D> f1;” and “C<E> f2;” are represented as follows:

JT 3 –> JT 4
IN EACH MEMBER DECLARATION
fieldT(F1, …, AT1, 'f1', …). fieldT(F1, …, AT, 'f1', …).
arrayTypeT(AT1, F1, TR1, 1).
typeRefT(TR1, AT1, F1, IdOfC).
fieldT(F2, …, AT2, 'f2', …). fieldT(F2, …, AT, 'f2', …).
arrayTypeT(AT2, F2, TR2, 1).
typeRefT(TR2, AT2, F2, IdOfC).
UNIQUE
classT(IdOfC, …, 'C', …). classT(IdOfC, …, 'C', …).
arrayTypeT(AT, IdOfC, 1).

Change 4: New staticTypeRefT

In JT 4, static references to classes (which were also represented with the typeRefT in JT 3) are represented with staticTypeRefT facts.

Type-handling in CTs

Please make sure to adapt your CTs so that they

Except for the adaptations above, working with types in conditional transformations in JT 4.0 is much simpler than in JT 3.0:

  • No more copying of type trees: It is not necessary anymore to copy a type tree when using an existing type for a new element. It is sufficient to simply use the ID of the existing type for the new element.
  • Simplified generation of type facts: When using a specific type in a CT, the PEF representation of this type may or may not exist. The predicate ensure_type_exists/1 is used to ensure that the representation of a specific type exists.
ensure_type_exists(+TypeFacts) is det.
TypeFacts is a list of type PEFs, i.e. it may contain parameterizedTypeT/3, arrayTypeT/3, wildcardT/3 and outerTypeParamsT/3 facts.
The first argument of each PEF must be unbound, but the PEFs may contain references among each other. References to types not contained in TypeFacts must be bound.
The predicate will then bind the variables to the IDs of the type facts representing the given type. These type facts either already exist or will be created otherwise.
1) , 2) , 3)
array, parameterized, wildcards
research/jtransformer/api/java/typesinjt4.txt · Last modified: 2018/05/09 01:59 (external edit)

SEWiki, © 2019