Migration Guide

Java Module Facet settings

A dedicated project migration saves Java Module Facet settings in the module descriptors as explicit values rather than unrelated values scattered around the descriptor (e.g. compileInMps and pluginKind were attributes of a module, and external classloading was managed by an additional module facet).

Extract gnu.trove and org.jdom libraries

A project migration extracts gnu.trove and org.jdom libraries out of MPS.Core. There are 2 new stub modules for these libraries. The migration redirects references to their stub classes that used to go through MPS.Core right to the new modules. These modules can be used independently of MPS.Core, if necessary.

Make facets, TextGen and Generate moved

Make facets, TextGen and Generate, used to reside in a plugin aspect of the j.m.lang.core language and now got moved out into a dedicated module, j.m.make.facetsi>. You may notice updated Make Target names in your generated sources if you reference these facets. Although unlikely, you may need to adjust model imports in the model with your custom Make Facet in case you reference TextGen/Generate as a dependency.

JNA library update

The generic distribution of MPS now contains two versions of the native jna library, each held in a separate subfolder of the /lib/jna/ folder:

• amd64 - for the Intel-based Mac computers

• aarch64 - for the Apple hardware Mac computers

The build script wizard that creates build scripts for standalone MPS IDEs, already provides an additional MPS-macos-aarch64.zip layout that utilizes the aarch64 variant of the jna library, while the other three, previously existing, layouts have been updated to correctly include their corresponding jna libraries from the new location.
Existing build scripts shall be updated manually to accommodate for the change in location of the jna library as well as to adjust the set of binary files according to the new platform.

Stop supporting the old format for enumeration values

Although the structure language's enumerations and their persistence format had changed many releases ago, the old format was still supported for compatibility reasons. This supports ended with MPS 2022.2, which only supports the new format. This may cause problems reading models in MPS 2022.2, if the models have not been migrated properly in the previouos versions of MPS. To fix this, re-run the migration "Update enumeration properties" that has been introduced intoo the structure language in MPS 2019.1. You have to run the migration in an older MPS before opening the project in MPS 2022.2.

MPS Kotlin language updates

Automatic migrations have been provided to reflect the recent improvements in the MPS Kotlin language:

• Statement support has been made generic in the IStatementHolder interface; other concepts using statements on their own have been migrated to use this concept.

• String literal and multiline literal have been merged into a single string literal concept.

• Inheritance modifier (final, abstract, etc.) on function declarations is now mandatory because of the usage of the Inheritable interface; declarations will be migrated accordingly.

• Support for deconstructing variables has been grouped under the IDeconstructingDeclarations interface; for statement and lambda multi-parameter are migrated to use it.

• Concepts with receiver types no longer use the ReceiverType concept (which is an expression referring to a type) and hold the type directly.

• Unsigned, Long and Integer literal concepts have been grouped under the IntegerLiteral concept (which uses boolean flags). Moreover, negative number literals are no longer supported and must be created using the unary minus concept.

Using JDK 17

MPS 2022.2 has been developed and tested with JDK 17, so it is recommended to use JDK 17 for running MPS as well as for running standalone IDEs built with MPS. There may potentially be some problems with the visibility of different classes that your code may be accessing using Java reflection API. You can solve the issues in the same way we solved it for the JDK classes when running MPS. Use the --add-opens JVM argument to add the respective packages:

Changes in logging configuration

Due to abandoned log4j, bin/log.xml configuration is no longer in use. There’s no mechanism to migrate your settings from log.xml, you need to re-create them in log.properies or to use IDE actions to configure logging. MPS no longer relies on configuration files for default log configuration (done in code, instead), and you need to turn on the use of configuration file explicitly through command-line switches.
For a hand-written logging code, it’s recommended to replace log4j code with jetbrains.mps.logging.Logger.getLogger(Class<>) to minimize the changes. Users of jetbrains.mps.baseLanguage.logging language don’t need to bother, just regenerate the code with the new templates to get updated.

MPS.Core no longer exports unrelated stubs

MPS.Core no longer exports stubs available from MPS.Generator and MPS.Textgen. MPS.Generator and MPS.TextGen were introduced a year ago in 21.2, to keep dependencies focuse and to prevent MPS.Core growing into a monster hog with a lot of unrelated functionality. For a few releases, MPS.Core exported java stubs for the Generator and TextGen subsystems, along with designated MPS.Generator and MPS.TextGen stub solutions. In this release, we finalize the split and MPS.Core no longer exports stubs for these subsystems. There’s re-runnable migration to re-route references to MPS.Generator and MPS.TextGen stubs you may need to run it again in case your models still reference Generator/TextGen stubs through MPS.Core solution.

New api in lang.plugin to register shortcuts

You may notice changes in the generated code if you declare custom shortcut sets or override the existing shortcuts for your actions. This streamlined and simplifies the generated code.

False dependencies need to be corrected

The fact ‘deps.cp’ keeps a snapshot of actual module compile dependencies at transformation time may ruin hacks/workarounds when an unused dependency was added to a module/model to satisfy compilation-time (Java classpath) dependency. Instead, this dependency has to be introduced in a proper way (in majority of cases, it’s just a misconfigured runtime of an engaged language).

Changes to pathToFile in the Make facet

In the Make facet, the pathToFile(String,IFile) function parameter gone. It served few very specific cases and was unlikely you ever needed it. If you do, however, there has been a replacement, pathToFile(IFile, IFile), available for a few releases already.

Deputy concept in aspect declaration

EXPERIMENTAL: ‘Deputy’ concept in aspect declaration. You may notice these if you declare your own aspects. This is a work towards meaningful @descriptor models. MPS employs this for the ‘structure’ aspect now. If you feel this is the right move (or a wrong one), please share your opinion.

mpsCore import in build scripts (MPS-34554)

MPS used to re-export mpsCore project and the respective plug-in from mpsStandalone project. If the build project for your RCP used to bundle/import mpsCore, you need to add a direct project dependency to mpsCore for import to get resolved again.

An additional dependency needed for the build scripts

The lib/util_rt.jar file has to be added in the boot classpath of the MpsStartupScript roots of the existing projects that use the build language to create standalone IDEs. Otherwise, exception like this one may occur when you attempt to start your standalone IDE:

VM options changed

The VM options used to start MPS IDEs have changed. The existing build scripts for standalone IDEs have to be updated manually to provide all the necessary VM options. An intention is in the works that will add all the missing depedencies. Until it is in place, the recommended way is to generate a new build script and copy the just created MpsStartupScript root node into your build script, or just use the list of options below:

Re-create run configurations

Existing run configurations will not work because the VM options required to start Java processes in MPS have changed. You can either create new run configurations, which will inherit updated VM options automatically. Or you can update the value in the run configuration's Virtual Machine Parameters field to

Editor hints allowed only from extended languages

In the previous versions, when defining editors and assigning editor hints to them, MPS tolerated editor hints from other language modules available through mere 'default' dependency. Now MPS only allows editors to use editor hints from languages explicitly "extended" by the language holding the editors.

Obsolete custom VM options need to be removed

If you installed MPS 2021.2 EAP 2 from the toolbox you may have ended up with three custom VM options set:

Replace the deprecated needNoWriteAction property with accessMode

The node test cases got a new accessMode property. Previously, the node tests were executed wrapped in either runWithinCommand or runWithinRead methods of BaseTestBody. Now the tests are executed under runWithinCommand, runWithinRead or without any wrapping depending on the value of the accessMode property.
The ExecutionModeNodesTestCase migration removes the needsNoWriteAction deprecated property and sets the accessMode property to either command or nonedepending on the previous value of needsNoWriteAction.

Custom extensions of the test language and/or the node test cases that provide their own test methods should pay special attention in their generators to proper wrapping of the code of the custom test methods with locking. The runtime class BaseTestBody now provides two additional methods runWithinCommand and runWithinRead that should be used just like they are used in the switch_Test2Method template switch.

Add log4j to the build script

Build scripts created by the Build Script Wizzard in earlier versions of MPS may have problems finding the log4j jar file in 2021.3.

Re-route references to util.jar in MPS.IDEA to MPS.Boot

On our way towards replacing huge single-point-of-entry stub modules (like MPS.Core) with slim modules that target narrow usage scenarios, we extracted the MPS.Boot solutiion. It holds classes related to the startup of MPS as well as a few IntelliJ stubs related to the IDE startup logic, which used to be in MPS.IDEA. The migration re-targets the references pointing to the corresponding stub models of the solution MPS.IDEA to the new stub solution.

Replace ToRemove and ScheduledForRemoval with Deprecated

The ToRemove and ScheduledForRemoval annotation both mark deprecated code. The standard Deprecated annotation will be used insed of those. The version parameter of the two annotations is migrated into the "since" parameted of Deprecated. The migration only works for instances of IBLDeprecatable.

Adopt asynchronous update mechanism for UI Actions

There’s a major change in IDEA Platform to update UI actions in an asynchronous manner. Data necessary to update action state is collected and consumed asynchronously and independently. There’s a promise of more responsive UI and general performance improvements. MPS started to adopt the change, and unless you have some hand-written action code or custom UI components that serve as DataProviders, you should not notice anything. Actions generated from j.m.lang.plugin are not affected, if you stick to MPS actions/UI abstractions, your code doesn’t need additional attention. However, if you deal explicitly with IDEA’s DataProvider/DataContext APIs (e.g. provide custom UI view implementing DataProvider), you might need to apply some extra migration efforts.

Delayed model loading

There's experimental functionality to load models only when requested. MPS used to load all module’s models the moment the module becomes known (aka ‘attached’) to a repository. Now, publishing a module doesn’t force loading of its models, only when there’s a need to access models, MPS makes an attempt to load them. Generally, this happens quite soon after a module is published, the change is just a first step to make the model's lifecycle more independent of its module.

Notable API changes

• UI: The NewSolutionDialog has been replaced with a generic NewModuleDialog

• SModel: [openapi] SNode.setReference(SReferenceLink, SReference) has been deprecated, with few alternatives available.

• SModel: [impl] SNode.toString and node.presentation operation

• Make: changes in the runtime modules for few j.m.make.* languages. You might notice them if you write custom make facets.

• BaseLanguage: Support for the "[package]Classifier" reference notation has been removed

NodeTestCases need regeneration

When upgrading to 2021.2.6 all NodeTestCases have to be regenerated for them to run successfully. Otherwise you will be getting exceptions like

Replace implicit node.toString() with explicit smodel operation

A new node.presentation operation and a migration have been introduced to jetbrains.mps.lang.smodel. The migration replaces the usages of a node in string concatenation ("string" + node and node + "string") with the explicit node.presentation operation. At the moment, this operation delegates to the getPresentation() behavior method, which is what node.toString() used to do. Since MPS ceased to use the getPresentation() behavior method in the toString() method implementation, it is advised to use explicit node operations (like node.presentation, node.getPresentation() or any other tailored behavior) when you intend to show the node presentation to the end-user.

Split MPS.Core stub models into distinct modules

The stub models exposed through the MPS.Core module (lib/mps-core.jar, lib/mps-generator.jar and lib/mps-textgen.jar) have been separated into MPS.Generator and MPS.Textgen. This mostly impacts users who use the generator or the textgen APIs directly.

An automated migration merely updates references to use affected stubs to be used from the new modules. If it fails, the MPS.Generator and MPS.TextGen can be imported manually and then the classes from the proper modules must be selected in code using the code completion dialog.

For compatibility, MPS.Core still exposes the jars, but it will cease to expose them in 2021.3.

Plugin descriptor placement

The IntelliJ platform now loads plugins only if their plugin descriptor (the plugin.xml file) is located in a specific place in the plugin layout: plugin_folder/lib/one_of_the_plugins.jar!/META-INF/plugin.xml Previously, the META-INF/plugin.xml was allowed to be placed anywhere in the plugin folder.

Unless the plugin descriptor is mentioned explicitly in the plugin layout at the right location, an automatic transaction will generate it when the build script is generated. It will add the required jar file to the plugin layout and will make it hold hold the plugin descriptor. The code intended for adding during generation is displayed in a read-only section of the plugin layout:

Improved core.text language

The jetbrains.mps.core.text language has been improved and is now being used for comments in BaseLanguage. The CommentPart and TextCommentPart concepts have been deprecated. If your language utilizes these deprecated concepts, consider using the concepts like Text, Line and Word from the jetbrains.mps.core.text language instead. You'll then need to provide migrations for the users of your language that will migrate the text held in TextCommentParts to be transformed to instances of Words and Lines. The easiest way to implement such migrations is to:

• instantiate a Line

• instantiate a Word

• add the word to the line using Line.addTextElement()

• set the Word.value property to the text of a TextCommentLine

• call the Word.normalize() method to have the text of the word split properly into words, all belonging to the same line

The new migrations

MPS 2020.1 comes with four migrations that will update your projects to the latest versions of jetbrains.mps.baseLanguage, jetbrains.mps.lang.quotation and jetbrains.mps.lang.editor:

• UpdateSingleLineCommentToUseLinePerComment will update instances of SingleLineComment to use a different child to hold the textual description of the comment. The comment can now only hold a single line of text, so the migration has to split single line comments that spread across several lines.

• MigrateTryStatement will update instances of TryCatchStatement and TryFinallyStatement to TryUniversalStatement, which allows for JDK 8 features, such as multiple exceptions in a single catch clause and with-resource capabilities.

• LightQuotation_InitProperyExpression wraps property initialisers of light quotations into instances of NodeBuilderPropertyExpression.

• Migrate_MergeNamedAndDefaultMenus will upside definitions of transformation and substitute menus to the new concepts. Transformation menus (TM) and Substitute menus (SM) were refactored so that Named and Default concept variants were merged into one concept each: TransformationMenu and SubstitutionMenu, respectively. The distinction between default and named variants is still there, but is now handled by the type property of each concept instead of having a separate root concept for them.

Update the VCS settings

The MPS merge driver has been improved. Make sure your merge driver as well as the VCS settings are up-to-date before merging conflicting branches. The VCS subsystem of MPS needs Git to be configured in a certain way in order to function properly. An outdated VCS configuration of a project is indicated to the user upon opening the project.

When the installation completes, you can rely on the VCS system to be ready.

Recommended migration strategy

Merging two branches that both have been migrated to MPS 2020.1 separately is likely to give you headaches. Avoid it! Otherwise this will happen to you and your loved ones:

• All single line comments that spread across several lines will be split into new instances of single line comments, which will be different nodes in each branch and will be in conflict.

• New instances of TryUniversalStatement in both branches will be in conflict if there are additional changes inside this statement.

• Light quotations that the migration enhances with the NodeBuilderPropertyExpression wrappers, will be in conflict.

• All Transformation menus and Substitute menus will be in conflict and you will need to accept one or the other (root node's concept has changed and there are new child nodes in the menus). This is because the root nodes of Transform/Substitute menus changed their concepts and are in fact different instances. You can merge them one by one and in case the menu was not changed in either branch OR if the menu changed in just one branch you can use the Accept Yours or Accept Theirs strategy as appropriate.

The prefered scenario is:

• Merge all the branches to master.

• Migrate the master using the migration assistant.

• Run the Migrate try statement enhancement script.

• Start new branches off the migrated master.

Alternative migration strategy

If you can't help it and have to merge a not-migrated branch into a migrated master, you should follow the scenario described in this section:

• Resolve merge conflicts

• Execute re-runable migrations

• Manually check the diff

• Run the "Migrate try statement" enhancement script

• Manually check the diff

• Commit

Resolve merge conflicts

Conflicts in editor.mps file (jetbrains.mps.lang.editor)

This may happen if you try to merge a non-migrated branch to a migrated branch and your non-migrated branch contains some changes to the same menu that you have migrated in the other branch. In this case it's recommended to Accept Yours (keep the migrated menu) and apply the modifications done in the other branch manually.

Conflicts in SingleLineComment (jetbrains.mps.baseLanguage)

A merge conflict will be reported for all single-line comments that have been modified in the branch.

The single-line comments that have not been changed in the branch will be taken from the master and so will have been migrated already. These can be auto-resolved using the appropriate tool button.

The remaining conflicting changes have to be migrated manually, perhaps by accepting the changes from the branch (accept theirs). The not migrated instances of SingleLineComment will thus be re-inserted into the code.

Special care must be taken for single-line comments spreading across multiple lines, as is in the last comment in the illustrating code above. Since the migration separated the additional lines into standalone instances of SingleLineComment, which are hanging below the original SingleLineComment instance, and since merging the changes from the branch will only affect the original (top) instance of SingleLineComment, the lines below will be duplicating the text of the comment.

The duplicating trailing single-line comments can be deleted. Some of the lines, however, may hold changes to the text of the comment coming from the master branch. These must be manually copied into the single-line comment and only then the trailing comment can be deleted.

This way you resolve all the conflicts and close the dialog. The code now, however, contains not-migrated instances of SingleLineComment coming from the branch.

Conflicts between not-migrated TryCatchStatement/TryFinallyStatement and already migrated TryUniversalStatement (jetbrains.mps.baseLanguage)

A merge conflict will be reported if there were changes inside the non-migrated or the migrated try statement. There are 3 possible cases:

• changes were only inside the migrated try statement - This is the simplest case and there should be no conflict. Just accept changes if they were not accepted automatically.

• changes were only inside not-migrated try statement - Here you should accept the changes from the not-migrated branch and ignore those from the migrated one (actually there are no meaningful changes to loose, just the migration that you'll repeat in the next step, anyway).

• changes were inside the try statements in both branches - This is the most complicated case. Choose one of the branches (not-migrated or migrated) from which you'll accept the changes. We suggest to use the migrated branch but sometimes most of the changes are in not-migrated, in which case you should perhaps choose that one. Then accept the changes in try statements from the chosen branch and ignore the changes in try statements from the other branch. Finally manually copy/paste the changes from the other branch. You can conveniently do it directly in the 3-way merge dialog: copy the statements from the right or the left editor and then paste into the center one.

Conflicts between not-migrated and migrated light quotations

Depending on the changes made to either of the branches or both of them, handle the situation in a way similar to the previous case.

Execute re-runable migrations

Since the master after merge may contain code that has not been migrated, the migrations have to be re-run to upgrade the code to MPS 2020.1. Run the Execute Re-Runnable Migrations action from the menu to get that done easily.

Run the 'Migrate try statement' enhancement script

Just like in the normal migration scenario, run the Migrate try statement enhancement script, to attempt to migrate automatically the cases that the migration skipped to avoid breaking code.

Migration of structure's enumeration declarations

MPS 2019.2 features a new way of declaring structure enumerations. Therefore the existing enumeration declarations become deprecated by this feature, MPS provides a set of migration scripts to replace them as well as their usages with the new constructions. This article precisely describes how these migrations are processed.