Changing Class<T> to Class<T extends Library> for Native.loadLibrary#861
Conversation
It was possible to pass a non-library class into this method and get a runtime exception, when the same check can be done at compile-time, so this fix changes it to be done at compile-time. After erasure, with this change the return type changes from `Object` to `Library`. So as far as backwards compatibility: 1. If you were assigning the result to `Object`, that will still work 2. If you were passing something that wasn't a `Class<? extends Library>`, your code will now not compile, instead of failing at runtime. 3. I can't remember the rules for binary compatibility. Fixes java-native-access#822.
|
This indeed breaks binary compatibility. The problem is, that the return type is part of the method signature. And the constraint on the generic changes the return type from I'm inclined to merge this, as your argument is sound. But please give me some time to think this through. |
|
Ok - I don't see a painless solution. Having both variants in the source code (one marked deprecated) would be contrary to the recent cleanup of deprecated methods and also does not comply with the java language (javac comes to the conclusion, that the generic erasure is identical). I tested ASM and was able to readd bridge methods via byte code injection, but that also does help a bit, as from the tool perspective, the old methods are still there and can be called (maybe with a deprecation warning) and the bytecode manipulation has also be done somewhere, so maintanance cost rises. Being at the point where backwards compatibility is already broken and major number bumped, I'll merge this in the next few days, if noone raises objections or comes up with a better plan. |
3 participants
It was possible to pass a non-library class into this method and get a runtime exception, when the same check can be done at compile-time, so this fix changes it to be done at compile-time.
After erasure, with this change the return type changes from
ObjecttoLibrary. So as far as backwards compatibility:Object, that will still workClass<? extends Library>, your code will now not compile, instead of failing at runtime.Fixes #822.