The MPS 2024.1 EAP Has Started
We’ve been working hard on MPS 2024.1, and we’ve packaged a lot of the new functionality into its first EAP build. You can now download it and take it for a test drive.
Here’s what you’ll find.
Enhanced platform support for MPS Kotlin
Kotlin in MPS was initially designed to support only common code. However, the only supported use case in MPS was compilation to the JVM, and the distinction between common code and JVM code was unclear.
In this release, we’re introducing platform source set configuration for Kotlin nodes in MPS. This allows you to identify which target platforms a piece of code supports and hide declarations from incompatible code.
Source sets
In a regular Kotlin project, you can use source sets to separate code from 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.
Loading and compilation for stubs
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 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 (both artifacts contain all necessary declarations), a new mechanism for filtering duplication was introduced 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.
Test runtime improvements
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/EditorTestCase). For large test models, this could have a noticeable impact on performance, not to mention how it resulted in a rather odd setup with duplicated test nodes. In MPS 2024.1, a model with tests will no longer be copied; only the test nodes (the TestNode children of NodeTestCase or EditorTestCase) will be, along with their respective environment nodes (the targets of their references).
Complete overhaul of module classloading
In our endeavor to separate classloading from model access and the depreciation of ReloadableSModule, we’ve changed how classloading works for modules. Although we worked hard to avoid making any noticeable changes for end users, the updates may lead to classloading 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 “snapshot” method fails.
These changes are part of an ongoing effort to improve Java module facets and module facets in general.
Placeholder cells
We’ve introduced placeholder cells that can stand in for concrete cells. For example, a %lt;no default constructor> placeholder cell can be displayed where a real constructor would be shown. The style fixes the cursor position at 0 and disables editing.
Reimplementation of the Logical View pane
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. Details can be found in the ProjectPane implementation on top of ProjectViewTree knowledge base article.
This new implementation has resulted in a few notable changes:
- Error and warning indicators are no longer available.
- Errors and warnings found in the hierarchy are underlined in red.
- Show Descriptor Models affects all descriptor models.
- Some drag-and-drop operations work differently.
- The settings in the Logical View pane have been reorganized slightly.
Other
A hexadecimal long literal has been introduced into BaseLanguage.
Numerous bug fixes
Our mission is to keep the quality of the MPS codebase high, and we’ve fixed a great number of problems as part of our work on this build. You can find a full list of all the issues we’ve fixed here.
This is only the first EAP release. We will keep adding features to MPS 2024.1, so stay tuned!
Your JetBrains MPS team
Subscribe to MPS Blog updates
