I previously thought that class loading only occurs when a class is referenced anywhere as long as the class it is referenced is loaded.

However, I came across this post today:

and if I understood correctly, casting would trigger class loading.

However, I am slightly confused by this:

1 hour ago, diesieben07 said:

Because Minecraft#player is of a different type (ClientPlayerEntity) than PlayerEntity this triggers classloading (the JVM needs to load both classes to verify they are compatible). To make the code work you need to adjust your variable player to be the same type.

Even if OP changed the type of player to ClientPlayerEntity, wouldn't that still cause the loading of the class?

Similarly, the OP in the linked post called Minecraft::getMinecraft in his packet code, which is loaded on both sides. Despite the method being called in enqueued work, would this still cause a crash when loaded on a server?

One way around this is to have your second lambda be a method annotated with @OnlyIn.

https://github.com/Cadiboo/NoCubes/blob/2cebf4e0e61eac96ab8490d3830f35953a8e9575/src/main/java/io/github/cadiboo/nocubes/network/S2CRemoveTerrainSmoothable.java#L45-L65

 

Thank you for the explaination. I was previously confused about the difference between a reference to a class and the loading of a class.

 

Does this mean that the only appropiate place to load client-only classes in modern versions of Minecraft is client-only event bus subscribers?

Just now, DavidM said:

Does this mean that the only appropiate place to load client-only classes in modern versions of Minecraft is client-only event bus subscribers?

In all versions client only code should be accessed exclusively from other client only code. In most circumstances though it will not crash.

4 minutes ago, Cadiboo said:

One way around this is to have your second lambda be a method annotated with @OnlyIn.

https://github.com/Cadiboo/NoCubes/blob/2cebf4e0e61eac96ab8490d3830f35953a8e9575/src/main/java/io/github/cadiboo/nocubes/network/S2CRemoveTerrainSmoothable.java#L45-L65

 

Thanks for the tip. However I am concerned that this might be concerned hacky (although I am not aware of the direct consequences) due to the direct deletion of part of the class on certain side to avoid class loading.

Edited January 6, 20205 yr by DavidM

3 minutes ago, diesieben07 said:

Yay, even more stupid ASM hacks, just so we don't need to admit that it was a bad idea and bring back @SidedProxy.

@SidedProxy had its own issues. It really is best to not stringly type your code and let the compiler do its work. I agree that it is a bit of a dirty hack though.

Edited January 6, 20205 yr by Cadiboo

1 hour ago, diesieben07 said:

(lord behold someone doesn't do the "same class" optimization during verification that I described above... suddenly this stuff no longer works).

Quote

...remember to check the hundreds of things you know to see if they’ve been updated or broken and make sure they all still work together and that nobody fixed the bug in one of them that you exploited to do something you thought was really clever one weekend when you were drunk. You’re all up to date, so that’s cool, then everything breaks.

“Double you tee eff?” you say, and start hunting for the problem. You discover that one day, some idiot decided that since another idiot decided that 1/0 should equal infinity, they could just use that as a shorthand for “Infinity” when simplifying their code. Then a non-idiot rightly decided that this was idiotic, which is what the original idiot should have decided, but since he didn’t, the non-idiot decided to be a dick and make this a failing error in his new compiler. Then he decided he wasn’t going to tell anyone that this was an error, because he’s a dick, and now all your snowflakes are urine and you can’t even find the cat.

Still Drinking