JaGra 2005 (Antwerpen, March 6-8 2005)


The workshop aims at working out a concrete graph transformation semantics for Java (referred to as "the model"). This document describes the planned setup of the JaGra workshop: its general form, the key issues to be considered and a preliminary program. We also identify a number of issues that we should preferably agree upon before the actual meeting: in this way we hope to save time and  be able to concentrate on the core questions. The document ends with brief list of tasks that we ask all participants to carry out in preparation to the workshop.

This is a first proposal, and we are open to suggestions, including changes of the overall setup or of the more detailed program below. We would like to see the workshop as a cooperative effort in which we try to achieve a precise goal, rather than as a presentation of past work.


University of Antwerp - Department of Mathematics and Computer Science
Middelheimlaan 1, 2020 Antwerpen (Berchem), Belgium
Building G
Room to be announced.

A route description for car and train travelers can be found on the faculty website.


The workshop mainly consists of a number of plenary sessions and smaller working group (WG) sessions, of 2-3 persons each. In a first plenary session we will set up a work plan and discuss the reactions from the participants to the preparatory tasks. The working groups concentrate on modelling the statics and dynamics of particular isolated language features; the plenary sessions are there to integrate the results into a single meta-model and set of rules. In a final plenary session we will discuss the form of the documents or reports that should result from the meeting, as well as the possible continuation of the work initiated. 

We have identified a list of language features (LFs) that are candidates for modelling in a working group session - see below. In the initial plenary session we will discuss and probably complete this list, assign priorities to the LFs and identify those that are actually going to be addressed, in each of two rounds. Each of these rounds consists of a WG session  and a plenary session. Selected Java program fragments will serve as test cases for evaluating the quality of the model resulting from this process, possibly leading to a further fine-tuning.

Graphs, transformations and meta-models

We see it as imperative that, for the purpose of this workshop, we agree on a graph and transformation formalism, in terms of which we discuss and present our results. The formalism should be chosen such that it can be mapped (more or less) easily to the personal favourites of everyone present. Moreover, we do not want to lose too much time in choosing this "reference formalism" during the workshop; instead, we would like to establish it as much as possible in preparation to the workshop, and spend just a brief time the initial plenary session to complete it and present it to the participants.  We intend to use the papers [1] and [2] as a starting point for the discussions.

Choices to be made

Furthermore, for the purpose of conciseness and clarity, it could be useful to enrich the type graph with multiplicities and inheritance, turning it into a meta-model in the MDA sense. The original type graph would correspond to the flattened meta-model with multiplicities removed.

Language features

Here is our proposed list of language features. The idea behind this list is that, combined, these LFs encompass *all* of the Java language, also those parts that we do not intend to model in this workshop. The decision which LFs to address is part of the prioritization; see below.
  1. Primitive types and operations
  2. Simple classes, including the treatment of null and void
  3. Inheritance
  4. Packages and visibility
  5. Inner and anonymous classes
  6. Interfaces
  7. Arrays
  8. Type generics (Java 5)
  9. Enum types (Java 5)
  10. Class loading, linking and initialization
  11. Object creation and initialization
  12. Method call, lookup and return (virtual, super and static)
  13. Normal control flow, including conditionals and loops
  14. Exception handling
  15. Multi-threading, including synchronization & scheduling
  16. Reflection
  17. I/O
  18. GUI's
  19. Serialization
  20. Memory management and garbage collection
Since it is not possible to cover all of these in the workshop, we propose to distinguish between three categories of LFs:
  1. Core features. These are such that, if we do not address them, we cannot say that we have covered a realistic fragment of Java.
  2. Optional features. These are features, outside the core, that could in principle be covered by our approach, but which we ignore for the time being.
  3. Out-of-scope features. These are features that do not lend themselves easily (or at all) to a semantic definition using our approach.
First we should agree on a completed list of LFs, and then we should agree upon a classification along these lines. We should aim at addressing all class A features during the workshop.

Common vocabulary and framework

To get off to a quick start, it is necessary to establish the beginnings of a commonly agreed-upon framework before the workshop. Issues at hand are:
  1. Interpretation versus compilation approaches:

    By compilation we mean creating program-specific rules; each rule corresponds to a fragment of the program. Interpretation, on the other hand, means representing a large part or all of the static program structure in the state graphs, and having a fixed number of rules that model the semantics of each language construct. In the compilation approach, more rules are needed (but possibly with a lot of similarity between them); in the interpretation approach one has to deal with larger state graphs (but with a lot of overlap).

    There are at least three ways to handle the issue of compilation versus interpretation:
    1. Complete compilation; there is essentially a rule per statement/expression in the program. In other words, the rules themselves are close to the bytecode level.
    2. Complete interpretation; there is essentially a rule per kind of statement/expression. This requires (an abstraction of) the entire program to be part of the state graphs.
    3. A hybrid approach, for instance with one rule for each method and possibly each looping construct. This is essentially the approach of [1].
  2. The global structure of the state graphs. Obviously this is tied to the first issue.

    Based on the kind of information represented by the various elements of a state graph, one may distinguish the following subgraphs:
    1. Program graph. This is the graphical representation of the static program structure. Depending on the mixture of compilation and interpretation, the program graph may be large, small or possibly even absent.
    2. Value graph. This represents (mostly) the heap. It contains the objects and their attributes, but possibly also the formal parameters, local variables and primitive values
    3. Frame graph. This represents (mostly) the program stack. It contains representations of the running methods. Local variables may also belong here, rather than in the value graph.

Proposed program

Sunday, March 6
Monday, March 7
Tuesday, March 8
  • Workplan
  • Discussion of preparatory work
  • General formalism
Planning (15 min.)
  • Structure of the resulting document
  • Further use(s) of the model

  Working Groups
Session 2b

Coffee Break
Coffee Break Coffee Break
  • Global structure of the graphs
  • Language features
  • Assignment of priorities
  • Report on WGs
  • Discussion on Round 2
  • Integration of Round 1 and Round 2
  • Metamodel, version 2

  • Summary of results per LF
  • Which LFs to tackle next
  • Interface with tools for GTS
  • End of workshop

  Working Groups
Session 1

Lunch Lunch

  Working Groups
Session 1


  Working Groups
Session 3: Program examples for Round 1

  • Report on WGs
  • Discussion on Round 1
  • Version 1
  • Report on WGs
  • Integration in Metamodel, version 2
Coffee Break Coffee Break


  Working Groups
Session 2


  Working Groups
Session 4: Program examples for round 2

  • Report on WGs
  • Integration in Metamodel, version 2

19:00 - 20:00
Finetuning the model (?)

Clearly this is only a proposal, the program can be adapted to your suggestions and
to the progress we make. We intend to develop the model through a number of iterations,
developing consecutive versions of the model, but  it is obviously not possible to predict how far each iteration will bring us. In a very optimistic scenario, we can agree on a proposal by monday evening, and reserve a session on tuesday for looking into broader issues, such as the perceived long-term advantages of having a graph transformation semantics for OO languages, new lines of research, interesting related work, etc. In any case, the following issues have to be discussed in the final plenary sessions:


In preparation for the workshop, we ask all participants to do the following:


[1] Andrea Corradini, Fernando Luís Dotti, Luciana Foss and Leila Ribeiro.  Translating Java Code to Graph Transformation Systems.  In Graph Transformations: Second International Conference, ICGT 2004, Rome, Italy, September 28–October 1, 2004.

[2] Arend Rensink et al.

Contact webmaster.