Classes that should be shade-relocated throw a ClassNotFoundException

Geolykt commented 3 years ago

Edit: this is intended behaviour, with some unfortunate side effects, but hey

What is the current behavior?

ClassNotFound exceptions for Classes/Packages such as net.engio.mbassy or org.spongepowered.configurate
- Affects both external dependencies and shaded (latter is ignorable as it's fixable on the developer's part)
These cannot be used via external dependencies
The hypothetical class org.spongepowered.bork.Borkton will throw a ClassNotFoundException even if it is defined in the same jar!
What is the expected behavior?
These classes can be used via external dependecies without issues
You don't have to shade them in and relocate them (Bukkit works without issues! - even when not relocated)
The hypothetical class org.spongepowered.bork.Borkton can be used without issues

What steps will reproduce the problem?

(For example, all Configurate libraries can reproduce it - whether self compiled or not and independent from the groupId)

Have org.spongepowered:configurate-hocon:4.0.0 as an artifact (found in maven central)
Call org.spongepowered.configurate.ConfigurateException.class.toString(); or similar within the initialize method.
Enjoy your ClassNotFoundException!
Have a class in the org.spongepowered package
Use that Class

What operating system and java version is being used?

Java 11.0.9.1 (OpenJDK obtained from vendor)
Fedora 33

If there is an exception, use pastebin/hastebin (NB: no expiry date!) to send the stacktrace

https://hastebin.com/anasoruzom.properties

Additional information / Possible thoughts on why this bug is happening

This is likely an issue with Minestom's Classloader since Bukkit loads just fine. The org.spongepowered issue in itself could be a seperate issue (since it might be something to do with Mixins), but since the symptoms are exactly the same I won't open a seperate issue.

I've already spent far too much time researching into this issue (probably over 15 hours at this point) with almost no progress so I'll stop to do other things now especially since I found a workaround, but that it a hacky one at best since it's not obvious.

Geolykt commented 3 years ago

After a few coincidences I was able to identify that jar signing is at fault (or at least I believe, haven't run the (tests)) yet. To anyone that has the same issue and also has no idea what to do, you have to shade the dependencies and use one of the solutions provided at https://stackoverflow.com/questions/34855649/ You have also to relocate the packages, so in full it might look something like

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-shade-plugin</artifactId>
                <version>3.2.4</version>
                <executions>
                    <execution>
                        <configuration>
                            <relocations>
                                <!-- Spongepowered bricks the Minestom classloader -->
                                <relocation>
                                    <pattern>org.spongepowered</pattern>
                                    <shadedPattern>org.borkpowered</shadedPattern>
                                </relocation>
                            </relocations>
                            <!-- The following files are here to prevent the class(es) from not being openable -->
                            <filters>
                                <filter>
                                    <artifact>*:*</artifact>
                                    <excludes>
                                        <exclude>META-INF/*.SF</exclude>
                                        <exclude>META-INF/*.DSA</exclude>
                                        <exclude>META-INF/*.RSA</exclude>
                                    </excludes>
                                </filter>
                            </filters>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

~~Edit Nr. 1: Never mind, that is a completely other issue in itself that just happened to be able to be reproducible with the same artifact.~~

Edit Nr. 2: After reproducing this even when the dependency is shaded I have to assume that the issue lies in the library; While I think this has probably something to do with the signing, while that can - at least to some extend - be detected a bit better, I doubt that Minestom has much say it this. I'll try to build unsigned artifacts, and edit this as needed, but in the meantime I'll close this issue unless I can verify that Minestom is at fault (which I doubt that it is now)

Edit Nr. 3: Since I cannot reproduce the issue with the default Classloader (or at least the Classloader used when I launch it via Eclipse) I have to verify that as a bug on Minestom's side, to be exact the used Classloader is the issue. Even when manually using Class.forName() the issue can be reproduced, even when the dependency is self compiled (not signed!) and when I threw out Gradle out in favour of Maven nothing really happened differently. I really got no idea to why as it would not find a class that's obviously there and to be honest I'm a bit tired of checking what it could be. I'll try to use a non-Minestom Classloader to load all the Classes, hopefully that works.

Edit Nr. 4: Tried the system classloader: Also didn't work. Fernflower doesn't want to decompile the jar either, so I have to assume that the classes are somehow corrupt, which would be backed by the fact that their last modification data was February 1st 1980.

Edit Nr. 5: Added the relocation hint

Geolykt commented 3 years ago

Verified to be a Minestom issue with a dual-boot bukkit/Minestom jar.

mavenerr-0.0.1-SNAPSHOT.zip (ZIP file has to be renamed to .jar - did that due to limitations of Github's attachments)

Geolykt commented 3 years ago

Updated the issue to contain the most root cause without digging at Minestom's source, have fun with this!

Minestom / Minestom