Das ist neu in MPS 2022.2

Früher hat MPS Modelle in dem Moment erfasst, in dem sie in einem Repository registriert wurden. Das Erfassen eines Modells in einem regulären Projektmodul ging damit einher, dass das Dateisystem durchforstet wurde, um Dateien und ihre Typen zu finden und zumindest die Header-Informationen über das Modell zu analysieren.

Die Module führen jetzt die Modellerfassung erst durch, wenn Modelle angefordert werden. Eine neue SModule-API (SModule.forEachRegisteredModel()) ermöglicht den ausschließlichen Zugriff auf Modelle, die einem Modul bereits bekannt sind, ohne eine Modellerfassung oder ein Laden von Modellen auszulösen. Wenn Sie SModel-API-Clients verwenden, insbesondere Unterklassen von SRepositoryContentAdapter, empfiehlt es sich, die neue API zu übernehmen, um von den Verbesserungen zu profitieren.

MPS verfügt jetzt über eine einheitliche API zur Erstellung von Referenzen sowie eine überarbeitete interne Darstellung. Diese Änderungen sollen das für eine spätere Veröffentlichung vorgesehene Modellreferenz-/Persistenzsystem verbessern. Bereits jetzt können Sie jedoch mit dieser Änderung den Arbeitsspeicherbedarf jedes Modells um etwa 5% reduzieren.

MPS berücksichtigt jetzt versionierte jar-Einträge und stellt Java-Klassen mit einer Version bereit, die der tatsächlichen Java-Runtime entspricht.

Obwohl MPS und die IntelliJ-Plattform eine abgespeckte Version der Log4j-Bibliothek ohne bekannte Sicherheitsprobleme verwendeten, wurde bei beiden die Protokollierung auf das Standardpaket java.util.logging umgestellt. Es wurde eine Kompatibilitätsschicht implementiert (basierend auf SLF4J), um Aufrufe der Log4j-API an eine JUL-Implementierung umzuleiten.

Mit der Aktion Debug Log Settings können Sie DEBUG- und TRACE-Stufen nach Kategorien konfigurieren. Darüber hinaus gibt es jetzt eine bin/log.properties-Konfigurationsdatei, die das bekannte JUL-Konfigurationsformat verwendet. Im Gegensatz zur Datei log.xml in den Vorgängerversionen wird diese Konfigurationsdatei nicht standardmäßig eingelesen, aber Sie können über die Systemeigenschaft idea.log.config.properties.file den Zugriff auf diese (oder eine beliebige andere externe) Konfiguration anfordern.

Ant-Buildskripte, die MPS aus lang.build-Deklarationen generiert, verwenden separate Tasks zur Generierung und Kompilierung von Quelldateien (das MPS-eigene <generate> und das Ant-übliche <javac>). Es gibt jetzt einen neuen Task <mps.make>, der dem aus der IDE gestarteten Make-Prozess entspricht. Dieser ist für die vollständige Überführung eines Modells in kompilierten Code zuständig. Der Task kombiniert sowohl die Codegenerierung als auch die Kompilierung, was Zeit spart, da MPS ohnehin kompilierte Klassen für das Laden der Klassen in einem Modul benötigt (und <javac>-Tasks führen Kompilierungen, die bereits in <generate> stattgefunden haben, oft erneut durch). Außerdem nähern sich dadurch der Ant-Buildvorgang über die Befehlszeile und der aus der IDE angestoßene Make-Prozess einander an, was die Zuverlässigkeit Ihres Buildprozesses erhöht.

Weitere Informationen

MPS begrenzt die Zeit für die Modell-zu-Text-Umwandlung (M2T) im Hinblick auf mögliche Fehler in TextGen-Aspekten. Das Limit war bisher fest vorgegeben. In letzter Zeit haben jedoch einige große Modelle das Limit erreicht und eine ungewollte Zeitüberschreitung verursacht. Daher können Sie jetzt mit einer IDE-Einstellung das Zeitlimit steuern. Die Unterstützung von Befehlszeilen-Builds ist für ein zukünftiges Release geplant.

MPS hinterlegte Abhängigkeiten zwischen generierten BaseLanguage-Klassen in der Datei „dependencies“. Der Java-Compiler verwendet diese, um herauszufinden, ob abhängige Kompilierungsklassen eine Aktualisierung benötigen. Aber nachdem „dependencies“ in 2021.2 geändert wurde, um Abhängigkeiten auf höherer Ebene zu speichern, bestand keine Notwendigkeit mehr, Klassennamen pro Root zu sammeln und zu speichern. Dadurch verkürzt MPS die TextGen-Zeit sowohl für BaseLanguage-Code (da keine individuellen Abhängigkeiten mehr gesammelt werden müssen) als auch für den Java-Kompilierungsprozess (da es nicht mehr notwendig ist, individuelle Dateiabhängigkeiten zu analysieren, die Dateiabhängigkeiten den Modulen und Klassenpfaden zuzuordnen und den „Dirty“-Status zu propagieren).

In der neuen Datei deps.cp werden jetzt Abhängigkeiten modulweise gespeichert, damit MPS den Modul-Kompilierungsgraphen ableiten kann. Die Datei hält den Status der Transformation fest, sie ist also „versiegelt“ und maßgeschneidert (sie listet keine Abhängigkeiten auf, die nicht bei der Transformation verwendet wurden); dies steht im Gegensatz zu dem zur Laufzeit erfassten Abhängigkeitsgraphen, der auf den tatsächlichen Modulabhängigkeiten basiert.

MPS erstellt keine Runtime/Sandbox-Lösungen mehr, die unterhalb eines Sprachmoduls eingeordnet sind. Standardmäßig waren diese Module Geschwisterelemente des Sprachmoduls. Bei einer Umbenennung des „main“-Sprachmoduls wurden diese Module weiterhin als „verwandt“ erkannt und zusammen mit dem „main“-Modul umbenannt.

Weitere Informationen

Um die bisher eingeführte Funktionalität für zusammengesetzte Label-Schlüssel zu erweitern, unterstützt MPS die Speicherung zusammengesetzter Schlüssel in Checkpoint-Modellen.

Für jede größere Version erstellen wir eine Anleitung für die Migration von älteren MPS-Versionen, um einen reibungslosen Ablauf zu gewährleisten. Bitte prüfen Sie diese sorgfältig.