通常の Kotlin プロジェクトではソースセットを使用することで、異なるプラットフォームごとにコードを分離することができます。MPS ではこれをルートレベルで導入し、Kotlin ルートノードごとにサポート対象プラットフォームのセットを指定するオプションを実装しました。これらのソースセットは、インテンションアクションを使用してルートノードレベルで構成できます。

実際の開発では、以下のメリットがあります。

• 特定のソースセットに含まれるコードから互換性のあるプラットフォームの宣言にのみアクセスできます。たとえば、JVM 固有のコードは JVM 固有のコードと JVM をターゲットする共通コードにのみアクセスできます。
• 生成されたソースがソースセット固有のディレクトリの下で構造化されます。ディレクトリが指定されていない場合は、モジュールのデフォルトに対応するデフォルトのソースセットが使用されます。
• expected および actual 宣言がサポートされるようになりました。

デフォルトではプラットフォームが明示的に指定されていない Kotlin コードは JVM を使用するため、下位互換性が維持されます。

スタブが改善され、新しいマルチプラットフォームのユースケースをサポートするようになりました。以前の MPS は Kotlin と Kotlin/JVM スタブに個別のオプションを提供しており、それぞれに共通スタブと JVM スタブを読み込んでいました。

これらの 2 つのオプションが Kotlin スタブのオプションに統一され、提供されたアーティファクトが共通コード、JVM コード、または他のプラットフォームのコードを公開するかどうかが自動的に判定されるようになっています。

共通ライブラリとプラットフォーム固有のライブラリの間で宣言が重複していたため（どちらのアーティファクトもすべての必要な宣言を含むため）、スタブを整理するために新しい重複排除の仕組みを導入しました。同じモジュールの下で宣言されているプラットフォーム固有のライブラリは共通の宣言にアクセスできるため、再度宣言する必要はありません。

依存関係の構成は以前と同じです。

• 共通ライブラリとプラットフォーム固有のライブラリはどちらもスタブとして使用可能です。
• JVM ライブラリは共通コードを JVM にコンパイルするために必要であり、Java ファセット内で宣言する必要があります。

たとえば、共通コードを書く場合は共通ソースセットを使用してスタブ用の共通ライブラリを使用するだけでなく、Java ファセット内で Java アーティファクトを宣言する必要もあります。

MPS の Kotlin コードは CodeRules ベースの Kotlin Typesystem プラグインが利用できない場合に多数の typesystem エラーとスコープエラーを発生させていました。可読性とテスト可能性を改善するため、該当するチェックとエラーを CodeRules ベースの typesystem プラグインを利用できない場合にはミュートするようにしました。

その場合は Kotlin 言語のすべてのスコープが互換性のある概念のすべてのノードを含むデフォルトのスコープに置き換えられます。これによってすべての有効なノードがスコープに収まり、誤検出エラーがなくなります。

Kotlin コードの取り扱いに関するガイドラインは以前と同じままです。

• Kotlin コードの作成とチェックは、CodeRules が有効で Kotlin Typesystem プラグインがインストールされている状態で実行する必要があります。
• Kotlin の読み取りと生成は、これらがなくても安全に実行できます。

Logical View（論理ビュー）ペインに非同期アーキテクチャベースが採用されたことで、UI の応答性はそのままに IDE の全体的なパフォーマンスが改善されました。この新しい実装により、拡張と変更もさらに容易になりました。詳細については、ナレッジベースの「ProjectPane implementation on top of ProjectViewTree」という記事をご覧ください。

この新しい実装により、次のいくつかの重要な変更が発生しました。

• エラーと警告のインジケーターが提供されなくなりました。
• 階層内で見つかったエラーと警告がいずれも赤の下線で表示されるようになりました。
• Show Descriptor Models（記述子モデルを表示する）オプションがすべての記述子モデルに影響するようになりました。
• 一部のドラッグアンドドロップ操作の動作が変わっています。
• Logical View（論理ビュー）ペインの設定が少しだけ模様替えされています。

新しいスタイルを BaseLanguage に導入しました。このスタイルを使用すると、値（子ノードまたは参照）が欠落している場合に定数セルをプレースホルダーとして機能させることができます。たとえば、クラスにコンストラクターが存在しない場合は <no default constructor> プレースホルダーセルを代わりに表示することができます。このスタイルにより、定数セルがプレースホルダーセルに期待される動作を示すようになります。カーソルは最初の位置にのみ配置でき、値を編集することはできません。関連付けられた変換メニューによる変更のみが可能です。

ビルド言語のモジュールの doNotCompile ブール値オプションが Java 列挙型に置き換えられたため、以下のケースを区別しやすくなりました。

• モジュールにまったくコードが含まれていない。
• モジュールにコードが含まれているが、コードが MPS 以外のツールでコンパイルされている。

従来は上記のどちらのケースも値 true で表現されていました。

新しい Java 列挙型では、以下の 3 つの値が可能です。

• compile in MPS
• compile externally
• no code

2024.1 に移行する場合、doNotCompile の元の false 値は compile in MPS に移行され、doNotCompile の true 値は compile externally に移行されます。

小さな新しい実験的機能により、フォーク対象の元のプランを実際に変更せずに生成プランのフォークを追加できるようになっています。生成プランは別の生成プランのフォークとしてマークできます。マークされたプランは明示的な参照であるかのように扱われ、フォークされた生成プランの先頭に標準の fork ステートメントが追加されます。

また、フォークを定義する際にはトリガーとして機能する文字列修飾子を使用できます。このフォークは、生成対象モデルが文字列トリガーに一致するファセット ID を持つ生成ターゲットファセットを含むモジュールによって所有されている場合にのみ発生します。

MPS の JUnit テストで Vintage 形式と Jupiter 形式でだけでなく、Open Test Reporting 形式でもテストレポートを生成できるようになりました。ビルド言語のテストオプションでは、生成されたレポートに Open Test レポートが含めるかどうかを設定するための新しいオプションが提供されています。このオプションが true に設定されている場合、junit-platform-events*-$BUILD_NAME$.xml という名前のレポートファイルがプロジェクトディレクトリに作成されます。

このオプションが false の場合は従来の Vintage および Jupiter エンジンのレポートが作成されます。

MPS のテストレポートが JUnit の @DisplayName アノテーションを認識し、テストレポートツールウィンドウに表示されるレポートに名前を伝搬するようになりました。

ノードまたはエディターテストを実行する際、従来の MPS はテストモデル全体を一時的なモデルにコピーし、テストケースノードごとに追加のコピーを作成していました（ルート NodeTestCase または EditorTestCase から）。大規模なテストモデルの場合、これは往々にしてパフォーマンスに重大な影響を及ぼしていました。また、テストノードが重複した非常に奇妙な構成にもなっていました。MPS 2024.1 ではテストを含むモデルはコピーされなくなり、NodeTestCase または EditorTestCase の TestNode 子要素のみがそれぞれの環境ノード（その参照のターゲット）と共にコピーされるようになりました。

MPS プロジェクトを開いておく必要のあるテストで TestInfo 宣言が不要になりました。この変更は、JUnit テストを実行するすべての方法に適用されます。

• テストが IDE から実行される場合はプロセス内かプロセス外かを問わず、その時点で開いているプロジェクトが使用されます。
• テストが <launchtests> タスクで実行される場合、project path をタスクの追加のプロジェクトパスオプションとして指定できます。指定がない場合は現在のプロジェクトのホームディレクトリに対応する ${basedir} が使用されます。
• 上記のどの方法も使用できない特殊ケースでは、-Dmps.test.project.path システムプロパティでプロジェクトの場所を指定できます。

既存の TestInfo 宣言は引き続きサポートされていますので、そのまま残せます。

クラスの読み込みをモデルのアクセスから分離して ReloadableSModule を廃止する取り組みの中で、モジュールのクラスの読み込みの仕組みを変更しました。エンドユーザーにとって著しい変更が発生しないように努力しましたが、この更新によって以前は存在しなかったクラス読み込みの問題が発生する可能性があります。

この改良の一環として、MPS がモジュールファイルに散在する情報に基づいて起動時に依存関係の計算を試みるのではなく、デプロイされたモジュールの module.xml で宣言された依存関係に従うようになりました。設計段階では、依存関係はモデルの変換段階で収集された情報から導出され、ここでも再計算されません。.mpl または .msd ファイルからモジュールの依存関係を解析する以前のロジックは、新しい方法が失敗した場合のフォールバックとして引き続き使用されます。

これらの変更は、Java モジュールファセットとモジュールファセット全般を改善する進行中の取り組みの一環です。

デフォルトのスコープ計算を使用する場合、コメントアウトされた潜在的なターゲットノードがスコープから自動的に除外されるようになりました。