Version 1.9.0 not compatible with Spring Boot 2.7.x
scordio opened this issue · 7 comments
Version 1.9.0 upgrades Spring Boot to version 3 which requires bumping the source compatibility to Java 17.
This means projects using Spring Boot 2.7.x with Java < 17 cannot work with 1.9.0.
For example, a failure like the following is thrown during context startup on a project using Java 11 and Spring Boot 2.7.7:
java.lang.UnsupportedClassVersionError: com/github/gavlyukovskiy/boot/jdbc/decorator/DataSourceDecoratorProperties has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0
In case a reproducer is needed, please let me know and I will prepare one.
Being 1.9.0 a minor version upgrade from 1.8.1, it's not obvious that there is a breaking change caused by the underlying upgrade of Spring Boot.
Would you consider releasing the 1.9.0 content as 2.0.0 and also the 1.8.1 content as 1.9.1?
This way, the 1.x line would stay compatible with Spring Boot 2 and Java < 17, while 2.x would follow Spring Boot 3.
Related to #83.
With this other versions of Spring boot (2.1.8 in my case) the error does not even pop up but and the logging does not happen.
Hi @gavlyukovskiy, have you had the chance to think about my proposal?
@scordio this is a good suggestion and I should have done that. Though I think re-releasing older version as 1.9.1 would bring more problems for those who have already migrated.
I will keep this in mind for next time.
Though I think re-releasing older version as 1.9.1 would bring more problems for those who have already migrated.
That would be addressed by releasing version 2.0.0 with the content of 1.9.0. Whoever already migrated would have no trouble moving to that one immediately.
In my case, I'm working on some projects stuck on 2.7 / Java 11 (thanks to RHEL 7), and happens quite often that colleagues use your project for query analysis but forget that the latest version is not compatible.
In case you still prefer not to release both 1.9.1 and 2.0.0, would you accept a small PR to highlight this limitation in the README?
Maybe this issue could be pinned until the next release so it doesn't disappear once closed.
Thank you for the PR! I didn't realize that your use case includes adding and removing the dependency frequently, now it makes more sense as in my mind you'd only upgrade once and either everything works with 1.9.0 or you simply stay on 1.8.1. I think either way, there would be problems when people would apply 2.0.0 on spring boot 2.7 applications because it's not apparent without proper compatibility matrix, so your note is very helpful.
That would be addressed by releasing version 2.0.0 with the content of 1.9.0. Whoever already migrated would have no trouble moving to that one immediately
The reason I think that's a bad idea, is that people on 1.9.0 would consider 1.9.1 as a patch that should surely not break anything, but since they are already on spring boot 3.0, that would break everything.
I didn't realize that your use case includes adding and removing the dependency frequently
To share more details about our use case, the dependency (mostly the P6Spy one) is never part of the productive scope and also not permanently included in the test scope, but used locally and on-demand to analyze what Spring Data Jpa + QueryDSL + Hibernate would produce under the hood.
The reason I think that's a bad idea, is that people on 1.9.0 would consider 1.9.1 as a patch that should surely not break anything, but since they are already on spring boot 3.0, that would break everything.
Absolutely fair 👍 and thanks for taking the time to think about it!