In a headless MPS build driven by Maven with the maven-antrun-plugin, several loggers inside MPS emit informational messages at WARNING level. They are using java.util.logging — commonly abbreviated JUL — the logging framework built into the JDK. Examples include jetbrains.mps.classloading.ModulesWatcher, jetbrains.mps.persistence.ModelSourceRootWalker, and jetbrains.mps.persistence.DefaultModelRoot. Here is an excerpt from an actual CI run:

These messages are not errors. The build succeeds. However, they appear in the Maven output prefixed with [ERROR], which visually mixes them with actual build failures and makes real errors harder to locate. On a large CI log, a dozen mislabelled warnings can hide a single genuine failure.

The messages are logged as WARNING by MPS via java.util.logging. JUL’s default ConsoleHandler writes WARNING records to System.err. Somewhere in the pipeline between stderr and the final Maven output, stderr content gets tagged as [ERROR]. That is likely why a WARNING written to stderr shows up as an error in CI.

The tag depends on the stream, not on the JUL severity: bytes on stderr get [ERROR], bytes on stdout get [INFO]. Whatever assigns the tag looks at where the bytes came from, not at what they say.

Two intervention points are available: stop the message at the source (filter), or change the stream it uses (redirect).

A JUL configuration file raises the log level of the affected loggers to SEVERE:

The configuration file is passed to the JVM via -Djava.util.logging.config.file=/path/to/logging.properties. Once loaded, JUL drops all WARNING records from the listed loggers before they reach any handler.

Consequences. The messages are gone from the log. If one of these loggers later emits a new WARNING that would have been informative, it is dropped as well. This solution treats output from the affected loggers as irrelevant noise.

A custom JUL handler writes to System.out instead of System.err, while preserving System.err for SEVERE records:

StreamHandler buffers its output, so the explicit flush() after each publish() call is necessary; without it, records may appear late or interleave unexpectedly with output from other handlers.

The JUL properties file routes the affected loggers through this handler and detaches them from the root handler chain:

handlers registers ConsoleHandler on the root logger. .level sets the root logger’s own level, which every logger in the tree without its own explicit level inherits  — including the three MPS loggers redirected below, which have no explicit level of their own. ConsoleHandler.level sets the handler’s own, independent level. A handler filters separately from the logger it’s attached to, regardless of which of the two is stricter. And ConsoleHandler.formatter sets the formatter explicitly, matching ConsoleHandler own default. These properties and their defaults are documented in the ConsoleHandler class documentation ^[2] and ^[3].

The JUL properties file also routes the affected loggers through this handler and detaches them from the root handler chain:

The useParentHandlers = false line is required. Without it, each record goes both to the custom handler and to the root ConsoleHandler, appearing twice: once on stdout, once on stderr.

The compiled handler must be available to the JVM early in startup, before the first log call. In principle, adding the JAR to the regular classpath (-cp) would work, since JUL loads handler classes through the system classloader. In this setup, however, we pass the logging configuration via JAVA_TOOL_OPTIONS (see below), which propagates to any downstream forked JVMs. Placing the handler JAR on the bootclasspath guarantees availability regardless of the classpath configuration each fork ends up with:

Consequences. The WARNING records are kept visible in the log, but appear with an [INFO] prefix (because Maven tags stdout as [INFO]). Real SEVERE records still route through stderr and appear as [ERROR], preserving the ability to see genuine errors from the same loggers.

The two solutions differ in what happens to future, unexpected messages from the affected loggers.

Solution A minimises the moving parts. It is one properties file. It fits situations where the loggers are known to produce only irrelevant noise, and preserving that assumption is acceptable.

Solution B costs a Java class, a compile step, and a bootclasspath entry. It fits situations where the loggers may occasionally produce information worth seeing, and only the [ERROR] labelling is the problem, not the content.

The JVM arguments described above (-Xbootclasspath/a:…​ and -Djava.util.logging.config.file=…​) can be passed via either MAVEN_OPTS or JAVA_TOOL_OPTIONS. The two behave differently:

If the build has any forked JVMs downstream of Maven (test runners, generator tasks, RCP builds), those forks need the same logging configuration. In that case, JAVA_TOOL_OPTIONS is required. MAVEN_OPTS alone leaves the forked JVMs on their default JUL configuration, and the warnings reappear from those processes.

When JAVA_TOOL_OPTIONS is set, the JVM emits a startup notification:

This message is emitted by HotSpot itself, written to stderr at every JVM start, and consequently appears as [ERROR] in the CI log. It is not an actual error.

The message cannot be disabled through JVM flags. An OpenJDK bug requesting a suppression option was filed in 2014 and closed with resolution Won’t Fix ^[7]. The rationale given in the bug comments is brief: "This will not be implemented, as it may introduce a vulnerability."

Practical option: accept the single cosmetic line per JVM start and document it.

After the redirect, SimpleFormatter writes each log entry across two lines by default. In the CI log, each line receives its own [INFO] prefix, and the first line ends with the method name of the log call (warning), which visually resembles a severity tag and can be mistaken for a duplicate:

The fix is a format string in the JUL properties file:

The format tokens are documented in the java.util.logging.SimpleFormatter API ^[8]. %1$tF %1$tT is ISO date and time, %4$s is the level, %3$s is the logger name, %5$s is the message, %6$s is the stack trace if present, and %n is one newline. The same log entry now appears as a single line:

One entry per line, one prefix per line.

With Solution B in place, the CI log shows the affected warnings prefixed as [INFO] instead of [ERROR]. Real SEVERE events from the same loggers continue to appear as [ERROR]. The build itself is unchanged; only the log presentation is corrected.

It’s 16:30 on a slow Wednesday, you’re finishing up your pull request for the day. You get a comment, requesting to change the name of a variable so it’s easier to understand. Sure, your commit takes 10 seconds to finalize. And now you have to wait 30 minutes for the build, staring through the window and waving the colleagues goodbye one by one.

GitHub Actions has a caching mechanism and MPS generated output is exactly the kind of "expensive to produce, cheap to store" artifact that benefits from caching.

A match made in heaven.

This post is a checklist for setting it up and a summary of the gotchas we hit along the way.

The project is the domain experts side, so it has no language modules, just solutions. It uses Maven, it has tens of solutions with hundreds of models. Lots of people work on separate branches, this means a lot of repeat building of mostly the same things.

On every push, we start a fresh runner, it pulls the dependencies, starts MPS and starts chugging through generators. This happens on a 1 line change, and on a 100 lines change.

Persist the generated output between runs and only regenerate what has actually changed.

GitHub Actions provides actions/cache for storing files in the GitHub Cache. However, as is with everything MPS, it’s not that simple. MPS generated output directories (source_gen, classes_gen, source_gen.caches, test_gen and test_gen.caches) sit in the same folder as the module file and model directories. So we have to pick which directories will be saved.

To solve this, we ended up with two composite actions:

Both are called from inside our build-mps composite action, so the caching logic stays out of the main pipeline file.

In optimal conditions — meaning a full cache hit on a branch with no model changes — the Build Phase dropped from 15 minutes to 5 minutes. Roughly a third of the original time, with most of what remained being the actual Java compilation and packaging.

Cache hits scale with how stable your models are between runs. Branches with lots of model changes will see less benefit because they invalidate the cache more often. But for the typical case of "domain expert changes a few models, the rest are untouched," the speedup is substantial.

Most of the difficulty here came not from the caching itself but from the layers of abstractions we had to peel back: composite actions inside composite actions, MPS generating output in 350 places, GitHub’s branch scoping, immutability rules, and the cache action’s quirks around path handling. Once each of those is understood, the actual code is fairly small.

If you find yourself optimising MPS pipelines and want to share something we missed, I’d love to hear about it, you can find my email below.

Method names tell code readers what the method does in its context. Context consists of both the elements in the method’s surroundings, and their level of abstraction.

Secondary, names make methods discoverable while writing more code.

It’s way more important to cater to readers than writers, because we write code once, but read it a lot more.

There are about 180 concepts in the pilot metamodel of SysML v2, not counting their properties and cross-references. With LionWeb, we transferred all these concepts, their properties and cross-references, from one language definition format (Ecore) to two other formats (MPS structure definition and Freon AST), automatically and without even bothering what these formats look like. Just imagine how much work would it take to recreate the SysML v2 metamodel in MPS or Freon from scratch!

Now as we have the SysML v2 language structure in MPS and Freon, we build the corresponding language infrastructure. This includes, among others, a default reflective editor for the SysML v2 language. Thus, we can instantiate a SysML v2 model using the default editor.

As a reference, I take this example SysML v2 model from the pilot implementation library, shown here both in the Xtext textual notation and as the underlying EMF tree:

In the MPS reflective editor, a model appears with the placeholders for all its properties and references. This is the default editor, automatically generated from the metamodel of the SysML v2 language. For the actual use, we need to create a custom editor for the SysML v2 language, in the same way as Xtext provides the custom textual notation for the ecore meta-model of SysML v2 in EMF.

In the Freon editor, the situation is the same: all the properties and features of the PictureTaking package are shown by default, as this editor is generated automatically from the meta-model. To make it usable, we need to define a custom editor.

What we have achieved so far, is transferring the abstract structure of a language from one tool to another. This is only the first step. Here are some further steps that we can take to leverage the benefits of our ecosystem of interoperable language engineering tools.

Freon’s framework includes five dedicated generators, each covering an essential part of language development:

Language Structure – Define the core concepts, properties, and relationships of your language. Editor – Customize how your language is represented and edited. Scoper – Manage references and name resolution. Typer – Ensure consistency by defining type rules. Validator – Set rules that enforce model correctness with real-time feedback.

Freon fully supports LionWeb, meaning there’s no tool lock-in. Any LionWeb-enabled tool can read and process your languages and models. (www.lionweb.io)

With this partnership, F1RE is reinforcing its commitment to making DSL development more accessible, flexible, and scalable for business. If you’re working or needing a DSLs and want to explore how Freon can fit into your workflow, get in touch — we’d love to help you get started!

At F1RE, we specialize in model-driven software engineering (MDE). For organizations using this in their daily operations, the benefits are clear. To those new to this field, model-driven engineering may seem like a specialized approach. But, MDE has demonstrated its value through successful implementations across industries, from automotive to aerospace. Consider how the ESA successfully moved from documents to models.

In this article, we share our perspective on why MDE becomes even more crucial in the age of AI - not as a competitor to AI, but as a foundation that can help organizations get the most value from AI while maintaining control and reliability.

Here’s the elephant in the room - Building specialized MDE tools would be a hard sell today considering the generative AI hype. "Why don’t you just dump the domain knowledge in the form of some documents and ask ChatGPT to create what you need" would not be a surprising rebuttal. Everyone’s rushing to "throw AI at it" these days for a fast result. At F1RE we don’t think this is smart. This creates more problems than it solves and you would lose control over what is being done with what.

Having worked at the intersection of model-driven engineering and AI across both industry and academia, I’ve seen how these two approaches interact in practice. In industry, I’ve worked with domain-specific languages for safety-critical systems and most recently led projects developing AI-enabled medical chatbots. Meanwhile, in academia, I co-authored a recent study published in ACL 2024 that looked at how these AI models actually understand code, and the findings were eye-opening. Despite their seemingly impressive outputs, these models don’t really grasp the meaningful connections in code - they just recognize patterns between similar-looking pieces. It’s like someone who can complete sentences in a conversation by pattern matching, without actually understanding how the different parts of the sentence relate to each other. Even more surprisingly, we found that making these AI models bigger (even up to billions of parameters) actually made them worse at capturing these important relationships, not better.

I saw these same limitations play out with the medical chatbots. Despite promising initial results, we struggled to make the system’s answers consistently reliable, even with sophisticated retrieval techniques. Our experience matches what we’re seeing across the industry - developers using AI assistants are seeing 40% more bugs, and Gartner’s survey of 5,728 customers revealed that "while customer service leaders are eager to adopt AI, 64% of customers remain concerned about such an adoption."

These concerns extend far beyond individual experiences. In safety-critical systems, even small inconsistencies in AI outputs can have serious implications. The challenge isn’t just about fixing bugs - it’s about guaranteeing reliable behavior in situations where mistakes could be costly (like affecting patient safety). This widespread experience across the industry shows why we need a more disciplined approach to AI integration, especially in domains where reliability matters.

The fundamental issue isn’t just about bugs or customer concerns - it’s about four critical properties that any business-critical system must have: determinism, reliability, verifiability, and explainability. In the following subsections, we’ll examine each of these properties in detail, comparing how traditional systems and generative AI solutions measure up against them. For each property, we’ll provide clear definitions and concrete examples that illustrate why simply 'adding AI' to existing processes often creates more problems than it solves:

Having seen how bolt-on approaches fail to address the fundamental challenges of AI integration, we propose a different path forward: Instead of teaching AI rules through prompts or documents, we encode constraints into the system’s structure itself using our three layer vision. Let’s examine this approach:

Software languages are meant for communicating instructions to machines by people. For this, a software language constitutes a system of notation for writing programs. Such a system is usually defined in the form of the language syntax and semantics. Syntax defines the form that programs can have. Semantics defines the meaning of the programs.

For example, there exist many programming languages that are widely used in developing software:

While general-purpose programming languages can in principle be used for developing any type of application (from web-based SaaS to embedded software), each domain-specific language is specialized in a particular application domain.

For example, the following DSLs are good for expressing machine tasks in their particular domains, but hardly can be used for building an arbitrary software application. MATLAB is useful for describing matrix calculations, but we hardly would use it for programming a web application. SQL is meant for querying databases, but we will not use it for programming a microcontroller.

The power of DSLs is in that they capture the essence of a particular domain in a concise, efficient manner. They focus on a specific domain and this makes them understandable to domain experts without requiring deep programming knowledge. As a result, we achieve two important benefits of using DSLs.

Thus, the software development process becomes more efficient, faster-to-market and bug-free.

The same as for software languages, a DSL consists of syntax and semantics. However, as DSLs are meant to be usable and useful for domain experts with different technical background, DSLs can have multiple notations (concrete syntax) and multiple meanings (semantics). For example, we might want to have both a textual notation (for the ease of editing and exchanging programs) and graphical notation (for the better overview and comprehension). As for the semantics, we might want to generate executable source code, documentation, and test scenarios — all from the same DSL program.

To implement such an approach, we follow model-driven engineering (MDE) and put a model of the DSL in the center:

The domain model defines the structure of the DSL, its concepts and relationships between them. Parsers, and editors offer various notations (visual and textual) and tools to create and edit models (DSL programs). Translators and interpreters define semantics of the DSL by mapping its models to the executable code or other machine artifacts.

For example, here is a screenshot of the state machine DSL implemented in JetBrains MPS:

Here on the left we see two representations of a state machine model: a textual and a graphical. Both these representations are used to edit the actual (abstract) model behind. And on the right is the Gherkin test scenario generated from the state machine model. The following video demonstrates this example in action:

DSLs are more than just specialized languages. They are transformative tools that capture, express, and automate domain knowledge. With DSLs, we can model and transform domain knowledge in ways that are scalable, reusable, and aligned with specific industry needs. As the demand for efficient, specialized software grows, DSLs offer a powerful solution to bridge the gap between domain expertise and technology.

Do you think a DSL can be useful in your context? We recommend to take these four considerations into account.

As mentioned before, enumerations can be implemented using the built-in Enumeration, Accessory models, and Abstract concepts. In this section we show you how the enumeration can be implemented using each technique. For each technique, we create a language.

Now, the question is: Why should we use different implementation techniques in the first place? We can just use the built-in enumeration and be done, right?

Well, that’s where this section is for. To evaluate the different implementation techniques, we go over the following criteria:

In this post, we have looked at three different implementation techniques: The built-in enumerations, enumerations using the abstract concept, and enumerations using the accessory model. Now the question is: which technique should you use?

As most things in this world: It depends. This all depends on your use case.

Using the built-in enumeration is very easy, but very often bites in the long run — languages tend to evolve and split up, then enums get messy. Also, built-in enums are hard to migrate. Accessories are a good compromise between additional effort and flexibility. Abstract has the most flexibility, but also takes the most effort.

Our advice: Outside corner cases, don’t use built-in. Choose between accessories and abstract according to your needs, these two are also easier to migrate between.

Additionally, to help you figure out which technique you should use, we highlight the advantages and disadvantages in the following table.

Thanks for reading this post and have fun implementing!

𝗣𝗿𝗲𝗰𝗶𝘀𝗶𝗼𝗻: Tailored to specific domains, ensuring accuracy in tasks.

𝗘𝗳𝗳𝗶𝗰𝗶𝗲𝗻𝗰𝘆: Streamlines processes, reducing time spent on complex analyses.

𝗔𝗰𝗰𝗲𝘀𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆: Makes complex regulations understandable, enhancing decision-making.

The adoption of DSLs in specialized fields is not just an innovation; it’s a necessity. For professionals and visionary teams alike, it can be a game-changer, transforming challenges into opportunities.