Technical details about 1.17/Java 16 issues

[bitjeep]

Hi, I'm new to the forum, but a longtime programmer who recently got into Minecraft mods through my son (I've worked with Java on and off over the years).  I'm curious if there are any technical details around getting Forge to work with Minecraft 1.17/Java 16?

[0xx06]

what are you asking? it doesnt really make sense at all

[DaemonUmbra]

Each version of Forge targets a single version of Minecraft, so we have Forge versions for 1.15, Forge versions for 1.16... the first version of Forge for 1.17 is still being worked on

[bitjeep]

  On 7/11/2021 at 10:20 AM, 0xx06 said:

what are you asking? it doesnt really make sense at all

Expand  

My apologies for the delayed response, work has been a bit crazy.

Anyways, there was a comment about how, with Java 16 being used with Minecraft 1.17 (instead of Java 8), it broke reflection.  Which I assume is what Forge uses to patch itself in at runtime (examining Minecraft's Java classes and adding the necessary infrastructure for mods to work).  I'm curious to know the technical details of how they're working around that problem as I enjoy low-level technical work like that.

[bitjeep]

  On 7/29/2021 at 5:00 PM, diesieben07 said:

Forge doesn't use reflection to patch Minecraft.

The main blocker to Java 16 was that Forge used reflection into some JDK internals during the loading process (mainly regarding jar files). Java 16 blocks this by default (you can no longer reflect into JDK internals).

Expand  

Thanks for the clarification on that.  I see that there's a beta release of Forge now for 1.17, so I'll take a look at how it all works under the hood.

[bitjeep]

  On 7/29/2021 at 5:00 PM, diesieben07 said:

Forge doesn't use reflection to patch Minecraft.

Expand  

btw, the reason I thought that is because I used to program in Objective-C a lot, where you had the ability to reroute existing functions at runtime (method swizzling).  Which was a great way to create a patcher that keeps working over time if things don't change too much.  I wasn't sure if the same thing was possible using reflection in Java (haven't delved into JVM internals in years).

[bitjeep]

  On 7/29/2021 at 5:32 PM, diesieben07 said:

You can't change what things do. For that Forge uses bytecode patching.

Expand  

Yeah, that would be the only other way to do it.  Is there an easy way to search out the locations you need to patch in situations where not much has changed (aside from the offset) in a new Minecraft version?  i.e. find the same functions when they've simply moved a bit?  Just thinking from past experience with finding function offsets in C/C++ dynamic libraries as they change.  I really should just look at the code (use the source Luke).  Damn work getting in the way of personal curiosities!

[bitjeep]

Thanks for bearing with me and answering my questions @diesieben07.  The MCPConfig scripts/tools look like a good place to start down the rabbit hole when I get more time.  Funny enough, it might actually help my work since I've been swearing at Gradle a lot lately for being the most convoluted build system since the GNU Autotools. 😂