search

gavlyukovskiy / spring-boot-data-source-decorator

Spring Boot integration with p6spy, datasource-proxy, flexy-pool and spring-cloud-sleuth
Apache License 2.0
871 stars 83 forks source link

Version 1.9.0 not compatible with Spring Boot 2.7.x #84

Closed scordio closed 1 year ago

scordio commented 1 year ago

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.

GaetanoPiazzolla commented 1 year ago

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.

scordio commented 1 year ago

Hi @gavlyukovskiy, have you had the chance to think about my proposal?

gavlyukovskiy commented 1 year ago

@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.

scordio commented 1 year ago

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.

scordio commented 1 year ago

Raised #92 in case you prefer not to release 1.9.1 and 2.0.0.

gavlyukovskiy commented 1 year ago

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.

scordio commented 1 year ago

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!