Classloader filtering of the javax package causes problems

[Quantum64]

Delegating all javax package loadClass calls to the parent classloader is not a good idea. This is because some libraries bundle specific javax packages that are only available in the Java EE runtime into the library jars so that they run on Java SE as well. Specifically, I was trying to use the Dagger 2 library with my mod which bundles the javax.inject package into the final jar. Since your classloader refuses to load javax classes, this will result in a ClassDefNotFound for Dagger 2 and any other dependency injection library.

d08c9b1300c65123d829c39a9907a22af05a297d

[cpw]

Interesting. I'll take a look. I explicitly didn't want transformers to operate on that namespace though.

[Quantum64]

Any update on this? Would it be possible to modify findClass so that it only transforms classes that do not match the filter instead of delegating all these classes to the parent?

[cpw]

No, quantum, that definitely would not work and would in fact break lots of things.

[Quantum64]

Just curious--what would that break specifically? The only difference I would expect from the current behavior is the loading of filtered packages from mod jars, and most mod jars don't have those packages in them anyway. The class files that don't match the filter would still be transformed and the filtered packages would still not be transformed.

[cpw]

There's some special classes in javax, and it's possible to break a lot of shit about classloading if they're not pulled in in the right context. I'll look into limiting the package filtering a little tho.

[thecodewarrior]

I'm encountering a similar issue where I'm trying to bundle the LWJGL Yoga bindings because forge adds org.lwjgl.* into the filter. Relocating the package isn't an option in this case because doing so prevents the natives from linking.

Maybe instead of outright skipping the mod classloader the filter could instead reverse priority? If I'm reading the source right, modlauncher first looks at mod classloaders and then at the root classloader. Would it be possible to make the filter invert this so it loads from the root classloader if possible, then falls back to the mod classloader if the class wasn't found? That way all the protected libraries will still be loaded without transformers, but classes in mods would still be available at runtime.

[thecodewarrior]

Is this even a possibility? Said "temporary solution" requires dependencies to add it to their development environment classpath, which won't work in production.

[Technici4n]

The package filter was removed starting with ML 9.

[Quantum64]

After 5 years I can finally sleep at night again