In a regular Kotlin project, you can use source sets to separate code targeting different platforms. In MPS, we introduced this at the root level, with the option to specify the set of supported platforms for each Kotlin root node. These source sets can be configured at the root node level with the help of an intention action.

In practice, this means that:

• Code under a given source set can only access declarations with compatible platforms. For example, code specific to the JVM may access only JVM-specific code and common code that targets the JVM.
• Generated sources are structured under source-set-specific directories. If a directory is unspecified, it uses the default source set, which corresponds to the module’s default.
• Expected and actual declarations are now supported.

By default, Kotlin code without an explicit platform uses the JVM, maintaining backward compatibility.

Stubs have been improved to support new multiplatform use cases. In the past, MPS offered separate options for Kotlin and Kotlin/JVM stubs, which loaded common and JVM stubs, respectively.

These two options have now been unified under the one for Kotlin stubs, which now automatically determines whether a provided artifact exposes common code, JVM code, or code for other platforms.

As declarations between common and platform-specific libraries are redundant (as both artifacts contain all necessary declarations), we’ve introduced a new mechanism for filtering duplication to keep stubs tidy. When platform-specific libraries are declared under the same module, they can access common declarations, so you don’t have to declare them again.

Dependency configuration is the same as before:

• Both common and platform-specific libraries can be used as stubs.
• JVM libraries are required to compile common code to the JVM, and they should be declared in the Java facet.

For instance, writing common code requires you to use a common library for stubs, using the common source set, but you also have to declare the Java artifact in the Java facet.

Kotlin code in MPS used to raise a lot of typesystem and scope errors when the Kotlin Typesystem plugin, based on CodeRules, was not available. In order to improve readability and testability, these checks and errors are now muted when the CodeRules-based typesystem plugin is not available.

In such cases, all scopes in Kotlin languages are replaced with a default scope including all nodes of compatible concepts. This removes any false-positive errors, as all valid nodes are in the scope.

The guidelines for dealing with Kotlin code remain the same as before:

• Writing and checking Kotlin code should be done with CodeRules enabled and the Kotlin Typesystem plugin installed.
• Reading Kotlin and generating it can be safely performed without them.

The Logical View pane is now based on an asynchronous architecture, which helps keep the UI responsive and contributes to the overall performance of the IDE. The new implementation also allows for easier extensions and modifications. For more details, refer to our article in the knowledge base entitled ProjectPane implementation on top of ProjectViewTree.

This new implementation has resulted in a few notable changes:

• Error and warning indicators are no longer available.
• Both errors and warnings found in the hierarchy are underlined in red.
• The Show Descriptor Models option affects all descriptor models.
• Some drag-and-drop operations work differently.
• The settings in the Logical View pane have been reorganized slightly.

We’ve introduced a new style into BaseLanguage that allows constant cells to serve as placeholders if there’s a missing value (a child node or a reference). For example, when no constructor is present in a class, a <no default constructor> placeholder cell can be displayed instead. The style causes constant cells to exhibit the behavior you would expect from such placeholder cells. The cursor can only be placed on the first position, and it is not possible to edit the value. Only modifications provided by attached transformation menus are permitted.

The Boolean doNotCompile option of modules in the build language has been replaced with a Java enum to better distinguish the cases when:

• The module contains no code at all.
• The module contains code, but the code is compiled by tools other than MPS.

Both of these cases used to be represented by the value true.

The new Java enum has three possible values:

• compile in MPS
• compile externally
• no code

When migrating to 2024.1, the original false value of doNotCompile will be migrated to compile in MPS, while the true value of doNotCompile will be migrated to compile externally.

A small experimental new feature enables you to add a fork for a generation plan without actually modifying the original plan that is being forked. A generation plan can be marked as a fork of another generation plan. The marked plan will be treated as if it were referred to explicitly with the standard fork statement inserted at the very beginning of the forked generation plan.

Additionally, when defining a fork, you can use a string modifier that will serve as a trigger. The fork will only happen if the model being generated is owned by a module that has a generation target facet with a facet ID matching the string trigger.

JUnit tests in MPS can now generate test reports not only in the Vintage and Jupiter formats, but also in the Open Test Reporting format. A new option is available in the build language’s test options to control whether the Open Test report is included in the generated reports. If the option is set to true, report files named junit-platform-events*-$BUILD_NAME$.xml are created in the project directory.

If the option is set to false, the legacy reports for Vintage and Jupiter engines are created.

MPS test reports now respect the JUnit @DisplayName annotation and propagate the name to reports shown in the test report tool window.

When running a node or editor test, MPS used to copy the whole test model into transient models and make additional copies of every test case node (starting from the root NodeTestCase or EditorTestCase). For large test models, this tended to have a noticeable impact on performance. It also resulted in a rather odd setup with duplicated test nodes. In MPS 2024.1, models with tests will no longer be copied; only the TestNode children of NodeTestCase or EditorTestCase will be, along with their respective environment nodes (the targets of their references).

TestInfo declarations are no longer required for tests that need an MPS project to be open. This applies to all approaches to executing the JUnit tests:

• If the test is run from the IDE, either in-process or out-of-process, the project currently open will be used.
• If the test is run with the <launchtests> task, the project path can be specified as an additional project path option of the task. If left unspecified, ${basedir} is used, which corresponds to the home directory of the current project.
• For special cases where neither of the above approaches can be used, you can specify the project location via the -Dmps.test.project.path system property.

Existing TestInfo declarations are still supported and can be kept.

In our endeavor to separate class loading from model access and the deprecation of ReloadableSModule, we’ve changed how class loading works for modules. Although we worked hard to avoid making any noticeable changes for end users, the updates may lead to class loading issues that previously did not exist.

As part of this overhaul, MPS now sticks to dependencies declared in module.xml for deployed modules without trying to calculate them on startup based on information scattered in module files. During the design phase, dependencies are derived from information collected during the model transformation phase, and they are not re-calculated here either. The old logic that analyzes module dependencies from .mpl or .msd files is still in place as a fallback in case the new method fails.

These changes are part of an ongoing effort to improve Java module facets and module facets in general.

When relying on the default scope calculation, commented-out potential target nodes are now automatically excluded from the scope.