About
We built the engine we wanted years ago.
In earlier ventures we ran into the same wall. Past a certain size, changing the structure of a codebase safely stops being a question of effort and becomes a question of tooling — and the tooling was not there.
Why it exists
Technical debt: easy to measure, hard to remove.
Plenty of tools will tell you that a class is too large, that a package depends on one it should not, that a method is never called. Far fewer can do anything about it. The gap between knowing and changing is where the work actually is, and it is where large codebases quietly stall.
Closing that gap needs depth. To change structure safely you have to know which types can stand in for which, what is reachable from where, how data moves between fields and methods, and what else has to change when you change one thing. That is a model of what the code means rather than how it is written, and building one is a long job. What CodeLaser brings to the market is what that model makes possible: changing the structure of a large codebase safely.
A short company timeline.
The analyzer started as a research project into immutability and modification in Java. It was the foundation: to say anything trustworthy about a change, you first need a model that knows what the code means.
Founded in Belgium to build the engine on top of that analyzer and to use it on other people’s codebases.
e2immu renamed. The same analyzer, covering Java and through a shared syntax tree Kotlin as well. It is open source and stays that way, so what is built on it does not depend on us.