Closed HelloCoCooo closed 5 years ago
@dominikholler Could you help me review this PR? Thanks a lot. ^_^
@dominikholler Thanks! May I ask you a question? Have you ever encountered these types of semantic behavior inconsistency issues (the methods with the same signatures but different implementations) when upgrading libraries or dealing with dependency conflict issues?
How did you discover such inconsistency issues? (by testing, code review, user feedback, static analysis tool, inquiring in forum (e.g., stackoverflow) or in other ways?)
Thanks again, Coco
Have you ever encountered these types of semantic behavior inconsistency issues (the methods with the same signatures but different implementations) when upgrading libraries
Yes, even with this library. This resulted in the release of openstack-java-sdk-3.2.4 . As far as I understand Java, there is no version checking at runtime. If there is a java class in the path with a matching name at runtime, it will be used. If the class does not provide a method with exactly the expected signature, a NoSuchMethodError will be thrown.
or dealing with dependency conflict issues?
How did you discover such inconsistency issues? (by testing, code review, user feedback, static analysis tool, inquiring in forum (e.g., stackoverflow) or in other ways?)
Semantic changes can be detected by reading the git history of the library and (dynamic) testing.
Signature changes during a library update can be detected by static analyzers, e.g. https://lvc.github.io/japi-compliance-checker/ .
Please note that the change you introduced here is just about the compile time dependencies. On runtime the user of openstack-java-sdk is responsible to provide a compatible version of jackson-core-asl to the jre.
@dominikholler Thank you very much!
214 fix dependency conflict issue for org.codehaus.jackson:jackson-core-asl: jar