Every modeling course I have taught starts the same way: the first two weeks go into installing things. Eclipse, the right EMF version, the plugin that stopped working with the last Java update, the laptop that refuses to run any of it. By the time students draw their first metamodel, a good part of the semester’s goodwill is gone. Research prototypes have the same problem at a different scale: they are written as Eclipse plugins, they work for the paper, and they die when the platform moves on. Kermeta and xMOF were serious pieces of work, and almost nobody can run them today.
Jjodel started from the decision to remove that layer entirely. It is a metamodeling platform with nothing to install: you open a browser, define a language, draw its notation, edit models, transform them. Version 3.0, out on September 15, is the first release where all the pieces are in place and the interface has been rebuilt around them. This post says what the tool is for, how it works, how it compares with the tools you already know, and where we are taking it.
What need it solves
Jjodel is a language workbench for the browser. You define a metamodel, one or more concrete syntaxes for it, and transformations between languages. The goals are the ones you would expect from a research group that also teaches: zero setup, so that a lab session can start in the first ten minutes; one artefact that students, researchers and external users share by sending a link; and a single environment that covers the whole pipeline, from abstract syntax to model-to-model transformation, without a second tool for each step.
The last point matters more than it sounds. In the Eclipse world the pipeline is real but assembled: EMF for the metamodel, Sirius or GMF for the notation, ATL or Epsilon for transformations, each with its own project layout and its own learning curve. In Jjodel the same pipeline is one project, with one tree on the left and one canvas in the middle. That is not a claim of superiority over the Eclipse stack; the ecosystem there is twenty years deep and ours is not. It is a claim about the entry cost.
How it works, in five steps
The documentation follows a single running example through five tutorials, and it is the fastest way to see how the pieces fit. The example is an entity-relationship language.
1. Metamodel
The metamodel editor is a class diagram editor with a palette on the left and properties on the right. In Basic mode it shows classes, attributes, references and enumerations and nothing else; Advanced mode adds abstract classes, operations, literals, multiplicities, and the rest. The ER metamodel in the tutorial has five classes and takes a few minutes.
The ER metamodel in the metamodel editor, Basic mode.
2. Notation
A viewpoint assigns a view to each class. A view is a symbol (rectangle, ellipse, diamond, and forty-odd other presets grouped in families such as UML, BPMN, flowchart and ER) plus structure (where the name goes, how compartments are laid out) plus style rules. A Chen-style notation for the ER language is three views: a rounded box for entities, a pill for attributes, a diamond for relationships, each with a fill and a label; keys get a deeper fill through a conditional rule on the attribute’s isKey flag. The same metamodel can carry as many viewpoints as you like; switching notation is a click.
The same model rendered with a Chen-style viewpoint
The symbol editor: preset families, fill, border and labels for a view.
3. Data, not only diagrams
Not every model wants to be drawn. The Data Manager turns any metamodel into tables and forms: one table per class, one form per instance, layout derived from the metamodel. You can create, edit and delete instances there, and the canvas updates. In practice this is where a lot of the editing happens once a model has more than a handful of objects.
The Data Manager: tables and forms generated from the metamodel.
4. Jjodie, the assistant
Jjodie is a chat panel that writes JjScript, a small scripting language for manipulating metamodels and models. You describe a library metamodel in a sentence, Jjodie answers with a script, you read it and run it, and the classes appear on the canvas. It also explains a diagram you select and drafts the documentation of a language, with sections you mark as protected so that regeneration leaves them alone. Jjodie runs on the provider you configure in the settings: OpenAI, Anthropic or a local Ollama. We do not resell API access; you bring your own key. That is a choice forced by the size of the project, and it has a side effect I like: the tool has no opinion about which model you use.
Jjodie writing a JjScript for a library metamodel.
5. Transformation
JjTL is a rule-based model-to-model transformation language: source metamodel on the left, target on the right, rules in the middle, with mappings between metaclasses drawn as arrows on top of the text. The ER-to-relational transformation is three rules. Execution produces a target model and a trace model: every generated element knows which source elements it came from, and the trace view lets you walk it in both directions. The trace is the thing students ask for first when a transformation does something unexpected, and it is the thing most textbook transformation tools leave for later.
The JjTL editor with the ER-to-relational transformation.
The execution trace: each target element linked to its source.
What is new in 3.0
The visible change is the interface, redesigned from scratch with progressive disclosure as the organising principle. Every panel has a Basic and an Advanced mode; the first shows what you need in the first hour, the second shows everything. A first-year student and someone building a real DSL see the same tool at different depths. Under the interface, three things are new: JjTL with the trace model, the Data Manager with metamodel-driven forms, and Jjodie with the four uses above (generation, explanation, documentation, and a chat that answers questions about MDE and about the tool). Ecore import works from the interface, so an existing EMF metamodel is a drag away.
How it compares
Against EMF, Sirius and the Eclipse stack, Jjodel trades ecosystem for entry cost. If you need OCL, Xtext, a mature code generator or an industrial tool that already speaks Ecore, Eclipse is the right answer and will be for years. If you need thirty students modeling in the first ten minutes of a lab, or a prototype that a reviewer can open from the paper, the browser wins.
Against Sirius Web, the closest relative in the Eclipse family, the difference is one of shape rather than of ambition. Sirius Web brings the Sirius approach to the browser: Ecore on a Java server, studios to define notations, a React front end, and a solid industrial record with Obeo behind it and projects such as SysON built on top. It is a framework you deploy and configure; someone has to run the server, and the language engineering still happens largely in Eclipse-side artefacts. Jjodel is an application you open: metamodel, notation, data and transformations are all defined in the same browser tab, with no server of your own. If you are building a modeling product for an organisation, Sirius Web is the more mature base; if you are a course, a research group or a single language designer who wants to be modeling in ten minutes, that is the case Jjodel was built for.
Against WebGME, the other relative in spirit, Jjodel is younger and less battle-tested at scale, and it puts more weight on concrete syntax (multiple viewpoints, symbol families) and on transformations as a first-class language.
Against BESSER, which readers of this blog know well: the two projects overlap on the web editor and diverge on purpose. BESSER is a low-code platform, with B-UML as the fixed modeling language and code generation as the main output. Jjodel is a language workbench: the modeling language is the thing you define. If your goal is generating an application from a UML-like model, BESSER is the better fit; if your goal is defining a language and its notation, Jjodel is. I would be happy to see the two talk to each other, and Ecore import is one place where they already could.
Where it is going
Two directions. The first is simulation: a language defined in Jjodel should be executable in Jjodel, with the semantics written in JjEL (the expression language used for guards and actions) rather than in a second language bolted on the side. A parked simulation panel exists and will return. The second, and the one that interests me most as research, is dynamic classification as a core construct of the meta-metamodel. A state in a state machine is Active or Inactive; today you model that with a flag, which is a surrogate for what you mean. If the meta-metamodel can say that an instance’s type depends on the model’s marking, on its relations, or on its history, then the sequence of reclassifications is the operational semantics, and the transformation from state machines to Petri nets that we teach becomes unnecessary because the marking is already there. That is the 4.0 story, and it is why the platform had to be web-native: an idea about the meta-metamodel is useless if nobody can run the tool that has it.
Try it
Open app.jjodel.io and create a project; the tutorials take you from an empty project to the ER-to-relational transformation in five short steps, each with a two-minute video. The source is on GitHub. If you teach modeling this semester and want to run one lab session with it, write to me; I will help you set up the exercise, and I want to hear what breaks. We will be at MODELS 2026 with a demo of Jjodie in the Tools and Demonstrations track.
Recent Comments