Make the Java mod contain additional information

[YTG1234]

The Issue

Currently, the built-in java mod has a version format of vJAVA_MAJOR_VERSION.

This version does not contain the minor and patch versions of Java (e.g. it is only 15 when running Java 15.0.2) and does not contain the vendor and VM.

My Proposed Solution

For the Java version, include the minor and patch versions as well. This may have problems with older Java versions that use the 1.x versioning system, but it shouldn't be too difficult to implement.

I also propose including the vendor and the VM type in the build metadata (ignored in version comparisons) of the version.

Examples

• Version 15.0.2 from vendor AdoptOpenJdk running HotSpot would look like v15.0.2+adopt-hotspot
• Version 14.0 from vendor OpenJdk running J9 would look like v14.0.0+openjdk-j9
• Version (1.)8.0_282 from vendor AdoptOpenJdk running HotSpot would look like v8.0.282+adopt-hotspot

Why Would This be Useful?

A mod may be known to be incompatible with J9. It could just perform a check on the java version to see if it ends with -j9 and throw an exception with a detailed error if that is the case.

Or, a mod may have a special compatibility mode for J9 or HotSpot. It would do the same thing.

Although Java is not made by our friends at Mojank, there can be a rare case of a mod breaking (native mods?) with a minor Java version upgrade. They could insert a breaks dependency to that minor version (combined with the reason property PR, this would be even more useful).

[liach]

One piece of valuable information imo would be whether this current jvm supports preview features; mods can specify preview feature dependency in their fabric.mod.json. However, I haven't found out how the fabric loader can obtain this information besides trying to load a class with a specific version and catch an error, which is a bit ugly.

Otherwise, for vendor and vm, I recall those are available as system properties. Is there particular significance that they need to be integrated as part of mod dependencies, like failing mod resolution accordingly?

[sfPlayer1]

While introducing the feature we decided against including more version parts because only the specification version is reliable across vendors, everything else is at best convention that is already not followed by everyone. This makes it useless or even dangerous for dep matching. The same info is still available the same way we retrieve it - querying system properties. The proposed build metadata approach doesn't have a real benefit over querying those, both have to be checked manually and don't feed into the dependency solving.

I don't think preview features are not worth supporting explicitly, if really needed mods can still do some checking/gating internally.

[liach]

good point. but why was java added as a builtin mod initially?

[haykam821]

Mods can depend on newer Java features even if Minecraft does not provide that Java version by default. The Minecraft dependency on Java (#437) later on as well.

[liach]

hmm, i still think previews should be included for versions. if a mod adds a custom handler, they need to compile some classes in a non-preview javac, which is quite painstaking. also preview detection isn't quite easy to implement either.