Mumfrey
commented
3 years ago I don't really want to have issues just for tracking individual parts of the JVM spec. I already mentioned in the release notes for 0.8.2 that the plan is now to push forward with updating Mixin's support for newer JVM versions with 0.8.4 bringing the level to JAVA_11.
It's safe to assume that if I've added a feature to LanguageFeatures that I plan to support it, and you'll note that the flag is gated behind JAVA_15 which is when RECORDS and SEALED_CLASSES were added as preview features.
I'm not keen to have JVM-version or JVM-feature issues in the same way that I don't really want issues for "Make Mixin better" or "Fix the bugs", they just don't add anything to the conversation that shouldn't be obvious from understanding what the goals of the project are in the first place.
If a particular feature needs to be supported to achieve a level that Mixin already claims to support then that's a bug, fair enough.
I've closed issues in the past which just say "support Java X" and since this issue is basically "support part of Java 15", I'm just going to close it as frivolous.
That said, if there's a proposal for a particular way to add support for a thing, then that's different. Like you have some ultra-novel way to achieve a feature that isn't obvious (eg. the obvious ways being via just declaring the permits on the mixin, or via an annotation for this specific request), then by all means open an issue describing your proposal so it can be discussed. But I'm pretty much always gonna be of the opinion that issues saying "do this thing you were pretty obviously gonna do anyway" do nothing but pollute the issues list with pointless cruft.
Now that Java 17 is released, I can see it being useful that a mixin could add a permitted class to a sealed class. Note that this may have similar ramifications to adding enum constants, see #387 for a detailed discussion on that