Versioning

[Pandrex247]

Hi,

What versioning system does this project use?
The last patch release (3.0.4) was a gigantic update of what looks like every single dependency this project uses.

The updates were extensive enough that this project no longer compiles under JDK 11 despite that being set as the minimum version. I believe this is due to it pulling in Spring 6.x rather than 5.x. This presumably slipped through due to the CI also being updated to compile using JDK 17, meaning the published artefacts require also you to be using JDK 17.

The dependency updates also include an update to OSGi R7, which is what brings in the fairly substantial change that, unless explicitly specified not to, the manifests of the modules will now include import statements for JDK packages and expect them to be resolved.

My personal stance is that all of these updates should have gone into a 3.1.0 or 4.0.0 release, not what would typically be seen as a bug fix or service release. I suggest that the active dev branch version is updated appropriately.

[reftel]

I believe this issue would have been found before release if the release process involved writing release notes. Could that please be considered?

[Pandrex247]

It looks like we're now bumping the required JDK version to 17 in a 3.0.5 release to satisfy the updated Spring dependency that dependabot brought in: #900

I would reiterate that this is not something that typically goes into a patch release and would push for a version increment to 3.1.0 or 4.0.0.

[Pandrex247]

Related 3.0.5 PR: #931

[arjantijms]

We need to do a 3.1 (or 3.2?) anyway, to support things like Jakarta Annotations 3. (for now in a milestone version)

[jonatan-ivanov]

This broke Micrometer the other day.
It seems jersey-hk2:3.0.12 brings in hk2-api:3.0.3 which is Java 8 compatible. Unfortunately jersey-hk2:3.0.13 brings in hk2-api:3.0.6 which needs Java 11.

Upgrading from org.glassfish.hk2:hk2-api:3.0.3 to 3.0.6 causes UnsupportedClassVersionError, it seems the Java baseline was elevated from Java 8 to 11 between those patch versions:

java.lang.UnsupportedClassVersionError: org/glassfish/hk2/api/ServiceLocatorFactory has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

Can somebody from the maintainer team comment on why the Java baseline was changed in a patch version or am I missing something?

[arjantijms]

Can somebody from the maintainer team comment on why the Java baseline was changed in a patch version or am I missing something?

I'm not exactly sure why it was, and in hindsight I guess we should have called the version 3.1 after 3.0.3 indeed.

If you want, you could try if you can make a 3.0.7 version that's compatible with JDK 8 again, or otherwise make a 3.0.3.x branch that remains JDK 8 compatible.

[jonatan-ivanov]

Re-releasing 3.0.6 as 3.0.7 but making it Java 8 compatible again would definitely help.
3.1 is still a minor version bump, I think doing something as big as changing the Java baseline should belong to a major version change (4.0.0).

[Pandrex247]

I had a very quick stab at downgrading things: https://github.com/Pandrex247/patched-src-hk2/tree/Issue-888

The first hurdle to cover in getting it back to compiling on Java 8 is the CleanerFactory class. This was introduced in a PR to helped alleviate an issue in Payara that there were performance drops with each new Java release.

#781

This CleanerFactory class uses java.lang.ref.Cleaner which was only introduced in Java 9, and so would need to be rewritten.