I compiled in Forge build 1450 (mc 1.8 ), and I am trying to run in Forge client build 1655 (mc 1.8.8 ) which was supposed to be compatible. Maybe I need some conditional code?

 

Near as I can tell, this method exists, although the newer version might return a subclass of what I'm looking for. I can't figure out why this blows sky high.

 

My method, the problem line near the top:

 

 

  public JRFmod (String m, boolean testing) {

    ClassLoader mcl = Loader.instance ().getModClassLoader ();  // <-- Line 122, which crashes

 

    this.testing = testing;

 

    if (side.isServer ()) {            // Dedicated server

      proxy = new classProxy (m);

      return;

    } // else

 

    // Else we're loading client-side

    try {                              // Use reflection to create client-side proxy without importing

      proxy = (classProxyClient) Class.forName (m + ".classModProxyClient", true, mcl).newInstance ();

    } catch (Exception e) {

      System.out.println (m + " failed to instantiate classModProxyClient because " + e.toString ());

      throw new LoaderException (e);

    }

    if (testing && tabTest == null) {  // testing should always be false by the time a mod goes to server

      tabTest = new CreativeTabs ("Testing") {

 

        public Item getTabIconItem() {

          return Items.brewing_stand;

        }

      };

    }

  }

 

 

 

Crash report:

 

 

net.minecraftforge.fml.common.LoaderException: java.lang.NoSuchMethodError: net.minecraftforge.fml.common.Loader.getModClassLoader()Ljava/lang/ClassLoader;

at net.minecraftforge.fml.common.LoadController.transition(LoadController.java:162)

at net.minecraftforge.fml.common.Loader.loadMods(Loader.java:536)

at net.minecraftforge.fml.client.FMLClientHandler.beginMinecraftLoading(FMLClientHandler.java:205)

at net.minecraft.client.Minecraft.func_71384_a(Minecraft.java:417)

at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:329)

at net.minecraft.client.main.Main.main(SourceFile:124)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)

at net.minecraft.launchwrapper.Launch.main(Launch.java:28)

Caused by: java.lang.NoSuchMethodError: net.minecraftforge.fml.common.Loader.getModClassLoader()Ljava/lang/ClassLoader;

at jrfshare.classJRFmod.<init>(classJRFmod.java:122)

at jrfwalls.classAnystoneWallsMod.<init>(classAnystoneWallsMod.java:24)

...

 

 

In version 1.8.8, the getModClassLoader method returns a URLClassLoader instance, which should be an extension of ClassLoader, therefore assignable to my local variable. Am I reading this wrong, or have I missed a key rule in Java?

AFAIK 1.8 mods are not compatible with 1.8.8

It seems that Java bytecode explicitly stores the return type of the method, so it's looking for a method that returns

ClassLoader

rather than

URLClassLoader

(even though one is a subclass of the other). Recompiling against 1.8.8 without any changes to the code should work, but using code compiled against 1.8 won't (at least in this specific case).

 

Side note: Why are you using the

ClassLoader

? It looks like you're reinventing the

@SidedProxy

system.

It seems that Java bytecode explicitly stores the return type of the method, so it's looking for a method that returns

ClassLoader

rather than

URLClassLoader

(even though one is a subclass of the other). Recompiling against 1.8.8 without any changes to the code should work, but using code compiled against 1.8 won't (at least in this specific case).

 

I'll try a cast, and then I'll see if code compiled for 1.8.8 will run in a 1.8 world (1.8.9 has already failed, so I am pessimistic).

 

Side note: Why are you using the

ClassLoader

? It looks like you're reinventing the

@SidedProxy

system.

Yup, that's it, copied almost line for line. It's in an abstract "mod" class that is parent to each mod's main class.

It's a lost cause. I nerfed the offending line to see what I could see beyond, and it wasn't pretty. My mods ran afoul of some other missing elements (complaints about BlockCompressed among other things). I think that a mod compiled in mc 1.8 and using certain features simply can't run (or can't run simply) in a Forge for 1.8.8. Some classes and their methods are just not quite compatible.

 

Now a client compiled by and running 1.8.8 or 1.8.9 might be able to login successfully to a server and world using just 1.8, but I'm not being paid enough to port a bunch of mods to a risky level just to find out.

 

So I'll try to revise my compatibility checklist at CurseForge and aim my 1.8 client and server at the latest Forge build for 1.8 (not 1.8.8 ). When I'm ready to start another whole new world, I'll skip all of the way to a recommended Forge build for 1.9+ with no expectation of compatibility.

 

@D7, regarding why: Each of my mods' main classes is an extension of a home-grown abstract mod class. That abstract class sets up many elements, including proxies, common to all of my mods. It also has some comments to remind me to do some other routine things I couldn't express in Java.

 

Yes, it's a pain when it changes, forcing all of my mods to a new version so they can continue to operate together. However, it's nice when I get something to work just right in that one place, and every mod (including the next one I write) inherits that success.

 

It's probably poor style, but my common proxy benefits from being declared inside of that abstract mod class where it gains visibility to a few fields such as mod name. My mods' various (external) client proxies eventually use methods that access those fields. It's all horribly incestuous, but like the compatibility fight, I'm not being paid enough to go much beyond having fun with it (and devising a workable abstract mod class was actually fun).