Improve shading

[otbutz]

• properly handles Multi-Release dependencies
• removes any module-info.class during shading

[karussell]

properly handles Multi-Release dependencies

Should these warnings disappear or what is the exact purpose?

[WARNING] javax.activation-api-1.2.0.jar, jakarta.activation-api-1.2.2.jar define 31 overlapping classes: 
[WARNING]   - javax.activation.CommandInfo$Beans$1
[WARNING]   - javax.activation.ObjectDataContentHandler
[WARNING]   - javax.activation.DataContentHandlerFactory
[WARNING]   - javax.activation.DataContentHandler
[WARNING]   - javax.activation.CommandObject
[WARNING]   - javax.activation.SecuritySupport$2
[WARNING]   - javax.activation.FileTypeMap
[WARNING]   - javax.activation.CommandInfo

[otbutz]

That's a different story as we're mixing javax and jakarta in our dependencies. Both provide the same API, so we end up with overlapping classes. (Background: https://www.baeldung.com/java-enterprise-evolution)

My changes enable Multi-Release functionality which allows dependencies to make use of newer Java APIs at runtime. You can extract the shaded jar and check the META-INF/versions directory to see which classes are using this mechanism:

I'm also removing any module-info.class files. The strong encapsulation doesn't make sense in a shaded jar hence the previous warning:

[WARNING] Discovered module-info.class. Shading will break its strong encapsulation.

[otbutz]

Any objections?

[karussell]

My changes enable Multi-Release functionality which allows dependencies to make use of newer Java APIs at runtime.

What does this mean?

I don't want to break something and I do not see an advantage at the moment.

That's a different story as we're mixing javax and jakarta in our dependencies. Both provide the same API, so we end up with overlapping classes. (Background: https://www.baeldung.com/java-enterprise-evolution)

Thanks for this clarification.

[otbutz]

My changes enable Multi-Release functionality which allows dependencies to make use of newer Java APIs at runtime.

What does this mean?

See https://openjdk.org/jeps/238. The JVM is capable since version 9 to load alternative class implementations targeting different Java versions. The is all transparently handled by the JVM.

e.g. you could ship a jar that still works with Java 8 but provides an alternative implementation for a class that uses Java 17 features.

While GH might not use this mechanism itself, we break it for our shaded dependencies that might require it.

[otbutz]

An example where this caused problems in the past: komoot/photon#731