Refactor JavaModifiers

[jra-se]

Proposal to adapt JavaModifiers in MCCommonStatements.

Currently, an enumeration is used to represent JavaModifiers. Internally, this ensures that constants are generated in ASTConstantsMCCommonStatements, which can be read from a JavaModifier using the getModifier() method.

This refactoring replaces the enumeration with a JavaModifier interface. To ensure conservative refactoring, the interface is given a getModifier() method. The individual modifiers are moved to separate production rules. Finally, the getModifier() methods are implemented using the TOP mechanism, which continues to return the generated constants.

Why:
The current implementation has several disadvantages in terms of extensibility, as it is not possible to extend the enumeration.

Specific problem cases (from JavaDSL):

• JavaLight only allows the use of JavaModifiers in many places. In Java itself, however, annotations are often allowed in these places. In JavaDSL, we want to allow annotations as JavaModifiers. (Currently in the JavaDSL, annotations are redefined as extensions of JavaModifier.)
• With Java 16, the definition of a contextual keyword had to be adjusted in the Java Language Specification to support new types of contextual keywords. Such new keywords like sealed and non-sealed should therefore be introduced in JavaDSL instead of MCCommonStatements to prevent impacts on other languages.

Finally, this adjustment will also allow for additional features in the future, such as linking the access modifier to the existing infrastructure for access modifiers, which would enable simpler visibility checks, for example.

[github-actions]

✔️ Changes pass the MontiVerse

Project	Status

details

Project	Status
montiarc	✅
umlp	✅
sd	✅
montifun	✅
fd	✅
automaton	✅
sc	✅
guidsl	✅
artifacts	✅
ocl	✅
od	✅
ucd	✅
langexperiments	✅
json	✅
xml	✅
cd2gui	✅
mlc	✅
cd4analysis	✅
monticore_basic	✅
class2mc	⏩

The MontiVerse is a collection of (internal and public) language projects.