feat: Remove support for Java 8 #

[kuisathaverat]

Since this PR the compatibility with Java 8 is not guaranteed and is not supported.

• fix: remove deprecated java.level property
• feat: bump Jenkins core to 2.361

[jtnord]

Since this PR the compatibility with Java 8 is not guaranteed and is not supported.

does not make sense to me - the maven compiler is set to use release and testRelease with level 8 (ref) as that is what the version of Jenkins that is being targeted as (via the maven-hpi-plugin). Only once this depends on a version of Jenkins that itself requires java 11 will java8 support be broken.

Can you explain what is you mean behind this sentence? if it is just that you are not doing any manual testing on Java8 JVMs that is fine - but should not affect the plugins ability to run?

[kuisathaverat]

I think we have first issue related, even though it is in the release notes https://issues.jenkins.io/browse/JENKINS-69229

I have detected the incompatibility with Java 8 a few weeks ago trying to compile trilead-ssh2 with Java 8, one of the dependencies require Java 11 so the compatibility is broken

[daniel-beck]

feat: bump Jenkins core to 2.346.2

Please bump the core dependency to 2.357 or newer, otherwise this will be offered to users of Jenkins that could still be running on Java 11. Meanwhile, jenkins-infra/update-center2#629

[jtnord]

or downgrade the parent of the trilead-ssh to 1.76 so it uses java8 not java11 (there is no code that requires java11 there - build and tests pass, but with a lost of spotbugs issues)

[jtnord]

jenkinsci/trilead-ssh2#106

[jglick]

You would need to amend

trilead-api-plugin/Jenkinsfile

Line 2 in 9e7860a

buildPlugin(platforms: ['linux'])

to request JDK 11.

[lcorsini]

well this breaks also situation where master is on jdk11 and agents are still on jdk8 and is silent since this plugin gets installed as a dependency from a lot of other plugins, so I think that a requirement bump to 2.357 (which removes jdk8 support) is more safe to avoid breaking people installations (like ours)

[kuisathaverat]

well this breaks also situation where master is on jdk11 and agents are still on jdk8 and is silent since this plugin gets installed as a dependency from a lot of other plugins, so I think that a requirement bump to 2.357 (which removes jdk8 support) is more safe to avoid breaking people installations (like ours)

Jenkins core >=2.357 will require Java 11. If you use trilead-api >= 1.71.v9e7860a_67a_df, the agents connected to this Jenkins must use Java 11 too. The recommendation is to use the same JDK on the Jenkins Controller and Jenkins Agents.
If your requirement to use Java 8 is to compile and test your software, you can still do it. You can use different JDKs to run the remoting process on JEnkins Agents and to build and test your software, it is a matter of configure it.

[jglick]

recommendation is to use the same JDK on the Jenkins Controller and Jenkins Agents

Probably best, but to be clear, this is not required; you can use any version of Java (BTW could be a JRE not JDK) for the controller, and independently any version for the agent, so long as both are sufficiently new: until recently, 8 or later; as of 2.357, 11 or later. The recommendation by the Jenkins project for a year or so has been to use Java 11 (for both controller and agents); Java 17 also runs well with recent versions.

[lcorsini]

as stated before is a recommendation, we are migrating from jdk8 but it requires some effort, this is why we still have jdk8 agent, and we won't update to 2.357 until the migration is complete.
but having trilead-api >= 1.71.v9e7860a_67a_df with breaking compatibility on jdk8 depend on 2.319 onward is plain wrong IMHO since it could break legacy situations like ours, and others too since it seems to have been pulled from update center https://issues.jenkins.io/browse/JENKINS-69229
what I'm saying is that is not wrong going onward to jdk11 just don't break older situations making this update available to jdk8 installations

[jglick]

is plain wrong

Yes, we know that, which is why it was pulled from the UC; merging this PR would publish a correction that should be safe to appear on the UC. If you installed the broken version, revert.

[kuisathaverat]

next week I will merge this PR

[jtnord]

next week I will merge this PR

the upstream bom is available - I do not understand why waiting is going to make things better for anyone?

[kuisathaverat]

next week I will merge this PR

the upstream bom is available - I do not understand why waiting is going to make things better for anyone?

It will not make anything better, I am simply not available to attend to any issue, so I will wait until I can do it