fabric-loader
fabric-loader copied to clipboard
FabricMC
Thinking about a post Java 8 world
Thinking about a post Java 8 world
It seems quite likely that minecraft will recieve an update of Java in the near future. The latest version of the launcher has support for alternate Java versions, and the latest snapshot dropped support for the old GPUs that were forcing the use of an ancient version of Java 8.
My guess is Java 16 will be the target, mainly due to having some neat features that I can see Mojang wanting to make use of, most notably records.
This issue is just a place to gather thoughts / be a todo list of what would would need to required to get the whole fabric toolchain updated to support this. In someways most of the work has already been done over time. Moving our CI/CD setup to github actions means we already test, build and release from Java 15. (While targeting Java 8)
A lot of the following items in the "todo list" assumes that records are being used as this is where most of the work left is. The following list is somewhat in order of what would need to be done, however some of the tasks can be done independently of each other, or even at a later date.
Items with a :mag: emoji might already be done/need investigating.
Record mapping
-
Record fields and methods should be mapped as usual. Record components can just be based off the field names and reuse the field javadoc. This removes the need to update the mapping format and removes the pain with V1.
-
Tiny remapper and friends will need updating to support this.
Yarn/Intermediary
This section contains what would need to be done to get Yarn/Intermediary working.
- Matcher
- Support the above record changes.
- Support matching records :mag:
- Stitch
- Jar Merging - Used by Loom and Yarn
- Remove/dont update: Intermediary gen/updating as matcher can do this.
- Engima
- Add support for records in the mapping format
- :mag: Check record remapping, I did brefily check this a while back and it seemed ok on the surface. I imagine the saving/loading will be missing.
- Intermediary
- Should generate the same field and method names for record components,
comp_x?
- Should generate the same field and method names for record components,
- Yarn
- Should be quite easy once all the tools/libs are in place, just update them in the build.gradle
- Should be able to build and remap a namedJar before releasing intermediary or yarn!
- Should be quite easy once all the tools/libs are in place, just update them in the build.gradle
Fabric Loader
- Should just work in theory?
- Might have issues with a mismatching guava version assuming that gets updated at the time time
- Java 8 support should be kept here for the foreseeable future for older minecraft versions and other games.
Loom
- New branch
- Bump to build against J16 and Gradle 7 (Required for J16)
Fabric API
- Should be quite simple in theory, Just update loom / Target J16
- Modules? - Should not be forced onto modders.
Access Widener
- Sealed Classes support? Easy to do, still in preview so prob unlikely its being used.
There are going to be quite a few unforseen issues ontop of this, but I dont believe I have missed anything major. This clearly will take some time to handle, but it doesnt need to be perfect on the first go, we target snapshots so we have time to break things.
Feel free to point out stuff I've missed/provide ideas on things this is just what I have in my head.
PRs working to support this:
fabric-loom : Javadoc support for records intellij-fernflower : pulls in upstream changes containg a number of useful fixes.
Tiny remapper, needs to supoort remapping record components and their resident annotations.
I'm not sure it's especially necessary to have a specific mapping type for records. As ever the JLS is specifically vague; but either the record components do have to match the field/accessor name in which case field mappings should be used as the fields have to remain consistent with their respective record component (though leaves Enigma and Matcher responsible for keeping the accessor name consistent), or they don't in which case it doesn't matter (unless someone especially reflected the vanilla record type).
Why specifically Java 16? At least according to wikipedia, Java 16 will stop recieving updates once 17 (the next LTS) is released. It doesn't really make much sense for mojang to switch to a Java version which will only be officially supported for a few months.
@Hnaguski Peterix has hinted in MultiMC Discord that Minecraft may be based on Java 15 or a newer version. In short, the existing information does not confirm or falsify that Minecraft must be based on the LTS version.
I would like to hope they would be able to keep up with java updates, I dont see why this wouldnt be possible.
Not having anything special for records might make things easier, would be easy enough to verify that the name are alinged.
Just a quick note: Java 15 was added to some launcher meta this snapshot, so it now looks really likely that they'll be going for 15 and not 16. Loom and fapi should therefore target 15 (and not 16) once Minecraft does.
Java 16 was also released yesterday, so they might've just not updated it yet.
Yes, 16 would be nice but 15 seems like the safe option. We need to make sure we are in a position to keep up assuming mojang keeps upto date.
I do want to enable preview features (would allow records if it is java 15) at runtime but allow modders to opt-into them if they wish. I dont see much of a downside to this, I have used preview features for some other projects without issue.
Just a quick note: Java 15 was added to some launcher meta this snapshot, so it now looks really likely that they'll be going for 15 and not 16. Loom and fapi should therefore target 15 (and not 16) once Minecraft does.
There's no release actually using it yet, so you can't be sure yet.
Ive had a deeper dive into records and do think that basing the component names off the field names is the way to go. Javadoc can be pulled from the fields as well.
Intermediary will need to output the same name for the fields and methods, will prob need a new counter imo.
I do want to enable preview features (would allow records if it is java 15) at runtime but allow modders to opt-into them if they wish. I dont see much of a downside to this, I have used preview features for some other projects without issue.
I don't like the idea of Fabric using potentially fragile, or subject to change, features by default.
It would be up to the modder to opt in for their mod. I think its worth the risk for the benefits, I see it being ulikely to cause issues outside of the experimental features.
Experimental features are fine in the situation where Minecraft is not on the latest Java version, and the feature is still in preview in the version Minecraft is compiled for, but in the current latest Java version, the feature is out of preview and has remained unchanged since it was in preview.
Ive had a deeper dive into records and do think that basing the component names off the field names is the way to go. Javadoc can be pulled from the fields as well.
Intermediary will need to output the same name for the fields and methods, will prob need a new counter imo.
You're being held by both the field and method counters to which ID a record would use, so you'd either have to skip forward which ever counter was lower or introduce a new counter entirely. Presume you're thinking of both fields and methods called record_x for them to be the same name, rather than a method called field_x?
Yes, adding a new counter and keeping the name the same between the fields and methods would be the solution here. Keeps the main bulk of the record specific code to intermediary. While the existing toolchain should be able to most ingore the fact that its working with a record.
I do want to enable preview features (would allow records if it is java 15) at runtime but allow modders to opt-into them if they wish. I dont see much of a downside to this, I have used preview features for some other projects without issue.
Imo this should be controlled by the launcher like other vm args than turned on by fabric loader.
The fact that preview featues being enabled prevents your class from being loaded on a newer jvm is probably reason enough to gate that feature to the jvm args
Preview features wont be enabled, there is little to gain in j16 with them.
hmm, can we actually enable preview after a jvm starts (beside calling native stuff)? If we do add it, will it be a command line argument for launcher to add?
In addition, we have #40, where we think about putting code into modules. Imo we can make a custom module finder that reports minecraft code as one module, possibly an automatic one (need to consider dedi server where libs and minecraft are mixed); then mods that want to depend on minecraft can use some module features, I suppose.
Are there any issues left here? The list hasn't been updated since March 17.
Other than a few edge cases, Fabric works fine on 1.17 (and thus Java 16).
We haven't encountered actual records in minecraft code yet. Maybe this can serve as a tracking issue.
More precisely MC doesn't appear to use any Java 16 feature yet, it looks like Java 8 code built with Javac 16. So the breakage is yet to come ;)
Yes, they are probably compiling with source compatibility 8 and target compatibility 16 (where there are nest mates, indy string concat, etc).