Reverting JENKINS-20679

[Basil Crow]

Hi all,

As part of my work on Java platform support in Jenkins, I have
encountered the subsystem introduced in JENKINS-20679, which allows
plugins to request a newer version of Java than the corresponding
core. Based on a preliminary search of sources across the ecosystem,
this functionality appears to be unused. In my opinion this subsystem
introduces unnecessary complexity, and I would like to remove it to
simplify the implementation of future Java platform changes. In other
words, I am proposing a revert of JENKINS-20679 across all relevant
repositories: core, plugin-pom, maven-hpi-plugin, update-center2, and
any other places where JENKINS-20679 code might have spread. I would
like to thank the original authors of this code for providing a
valuable subsystem that served its purpose faithfully, having now
reached what I consider to be end-of-life.

Since the amount of work involved in testing these changes (including
searching for usages in binaries, both open-source and proprietary)
and preparing written justifications for the relevant PRs is
non-trivial, I would like to gather at least notional consensus on
this list regarding whether this is a direction we would like to go
in. If the consensus is favorable, I will proceed with testing and
preparing pull requests. However, if there are non-trivial objections
I will focus my time and energy on other areas.

Thank you,
Basil

[Daniel Beck]

Seems reasonable if really unused. A few considerations:

1. IIRC I've seen plugins requiring Java 11 that just don't declare it. So it's not unused because it isn't needed, but perhaps because plugin authors are unaware of it?

2. Will this be replaced by a different system (assuming this is future proof in principle)? Or will plugins be unable to require higher Java versions than what their core baseline requires to run? Or will there be surprises for admins when attempting to install such plugins? I think the core support for this was essentially a warning in plugin manager.

[Basil Crow]

On Tue, Mar 29, 2022 at 10:25 PM 'Daniel Beck' via Jenkins Developers
<jenkin...@googlegroups.com> wrote:
>
> Seems reasonable if really unused.

Thanks. Of course I will verify this systematically before proposing the PRs.

> 1. IIRC I've seen plugins requiring Java 11 that just don't declare it. So it's not unused because it isn't needed, but perhaps because plugin authors are unaware of it?

I am not familiar with such cases, but I seriously doubt there are
enough of them to justify a subsystem of this complexity. If it is
really the case that some plugin requires a newer JRE at runtime it
can just be documented in the plugin's README rather than with the
elaborate and hard-to-maintain subsystem that is in place now.

> 2. Will this be replaced by a different system (assuming this is future proof in principle)? Or will plugins be unable to require higher Java versions than what their core baseline requires to run? Or will there be surprises for admins when attempting to install such plugins? I think the core support for this was essentially a warning in plugin manager.

Yes the core support for this was essentially a warning in the plugin
manager, and no I am not planning on replacing this with something
else. Plugins will just have to evolve in lockstep with the minimum
Java version required by their core baseline. This is effectively the
case in practice everywhere I've looked, and it also seems like a
reasonable requirement to me.

[Daniel Beck]

On Wed, Mar 30, 2022 at 7:32 AM Basil Crow <m...@basilcrow.com> wrote:

> 1. IIRC I've seen plugins requiring Java 11 that just don't declare it. So it's not unused because it isn't needed, but perhaps because plugin authors are unaware of it?

I am not familiar with such cases, but I seriously doubt there are
enough of them to justify a subsystem of this complexity. If it is
really the case that some plugin requires a newer JRE at runtime it
can just be documented in the plugin's README rather than with the
elaborate and hard-to-maintain subsystem that is in place now.

> 2. Will this be replaced by a different system (assuming this is future proof in principle)? Or will plugins be unable to require higher Java versions than what their core baseline requires to run? Or will there be surprises for admins when attempting to install such plugins? I think the core support for this was essentially a warning in plugin manager.

Yes the core support for this was essentially a warning in the plugin
manager, and no I am not planning on replacing this with something
else. Plugins will just have to evolve in lockstep with the minimum
Java version required by their core baseline. This is effectively the
case in practice everywhere I've looked, and it also seems like a
reasonable requirement to me

Makes sense. Worst case is that we change our minds a few years down the road and restore this subsystem. And if there's a plugin somewhere that uses this after all, it's basically going to be an unused entry in the Manifest IIRC.

+1 and thanks for starting this conversation.

(Just in case, I do not think a JEP is needed for what amounts to removal of unused code.)

[Tim Jacomb]

+1

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtLefPYhzwK%3DvDQeNGy-vJMN1B9%3DTPrbOQ9zHc0MvmH5ew%40mail.gmail.com.

[Mark Waite]

+1 from me as well

On Wednesday, March 30, 2022 at 6:00:20 AM UTC-6 Tim wrote:

+1

[Basil Crow]

FTR this generated the following PRs:

https://github.com/jenkinsci/jenkins/pull/6549
https://github.com/jenkinsci/maven-hpi-plugin/pull/341
https://github.com/jenkinsci/plugin-pom/pull/549
https://github.com/jenkins-infra/update-center2/pull/591