• Recently Browsing

    No registered users viewing this page.

  • Posts

    • It works, most of the time. To understand when it does not work, you have to know a lot about how lambdas are implemented and how the JVM loads class files. If you write a lambda, that code becomes a static method in the same class. If you write two lambdas (even if they are nested within each other), the code is still present in the containing class file, as two static methods. The JDK will then at runtime use whatever means it sees fit (currently it just creates new class files using ASM) to turn those static methods into actual instances of the interface. Now, when the JVM loads your class file it has to verify it, so that there are no unsound type operations in the bytecode, for example. So, if you e.g. do: ClientWorld world = Minecraft.getMinecraft().world  The JVM has to check that the type of Minecraft#world (ClientWorld) is actually assignable to ClientWorld. In this case this is trivial, because obviously ClientWorld is-a ClientWorld.   In this case the JVM can verify this code without loading any classes (i.e. it doesn't need to load ClientWorld). Your class (containing the two static methods for the lambdas) loads fine, even on the server.   Now, let's do a very subtle change: World world = Minecraft.getMinecraft().world Suddenly, your code will crash on the server. Why? Because the JVM has to now load World and ClientWorld to see if ClientWorld is assignable to World. It will fail to find ClientWorld and boom, your code crashes with a NoClassDefFoundError on a server.   This is why I really do not like this approach, because it is brittle and requires deep understanding of many mechanics that you normally never need to worry about in Java development to use correctly. Yes, it's argueably a lot more convenient than @SidedProxy, but @SidedProxy made it very clear that we are dealing with classes that are potentially absent here, thus reflection must be used, it is the only truly safe way to interact with classes that are potentially absent. It is also still unclear if this optimization the JVM does (not loading the classes at all if they are equal) is actually specified in the JVM specification, or if this whole approach relies on an implementation detail that HotSpot (OpenJDK's main JVM) does.
    • Does it not? I've used the double supplier trick in a lot of code and it's all worked just fine on dedicated servers.
    • Just as a note, it doesn't actually do this properly.
    • Updating entities, updating blocks, everything that "happens in game". Look up what a game loop is.
    • DistExecutor is used for physical side, whether you are using a minecraft client or dedicated server (in this case, this is the relevant information as only physical clients do rendering)   isRemote references the logical side, where true is the logical client. Logical client just means if it's not running the gameserver instance on that thread, so isRemote could return false on clients on the server thread. Also, isRemote checks do not properly avoid classloading, unlike DistExecutor which avoids them by utilizing the double supplier trick.
  • Topics

  • Who's Online (See full list)