Contributing various small OpenJDK fixes: IKVM

[Aleksey Shipilev]

On 23.07.24 04:46, David Holmes wrote:
>> Actually, this is pragmatic. Unless the fix is really 8u-specific, it
>> should be fixed in mainline, and then backported all the way to all
>> currently supported releases. Otherwise, the same issue would reappear
>> once Jerome moves past JDK 8.
> 
> And if that were to happen that would be tomorrow's problem IMO. I think
> it completely impractical, and unreasonable, to require this to be fixed
> in an environment they do not work (mainline) and filter it through all
> update releases until it makes its way back to 8u.

Yes, it is more work than just pushing the patch into JDK Xu. I disagree on "completely impractical" 
and "unreasonable".

The usual way we deal with issues affecting previous JDKs is:
  1. There is an issue affecting JDK Xu.
  2. A fix is developed/tested/verified on JDK Xu or on mainline, whatever is more convenient.
  3. A fix is committed into mainline, gets stabilized there, accrues follow-ups.
  4. Downstream builds cherry-pick mainline patch in their private JDK Xu builds.
  5. After a while, mainline fix gets backported to update releases with associated follow-ups.
  6. Downstreams replace the cherry-picked fix with the upstream JDK Xu backport.

The long-term benefits are important: a) the problem is fixed everywhere going forward; b) the 
problem is fixed in all currently supported LTSes; c) if there is a problem with the fix that 
affects some other build configs, the first thing it would break is mainline, not LTS.

For these reasons, a recurrent ask from maintainers is to do the fixes into mainline/latest releases 
first, and then backport, unless there is a compelling reason to bypass those steps. There might be 
some leeway on case by case basis, but it is rare. I am writing this down so that it does not come 
up as surprise to Jerome and others.

Granted, when we manage downstream builds, we often pick up things directly (see step 4 above) 
without regard of upstream timelines. This is not how I see JDK Updates work, however: they are much 
more future-looking, and "that would be tomorrow's problem" is not the usual way they approach things.

For example, see https://wiki.openjdk.org/display/JDKUpdates/How+to+contribute+or+backport+a+fix:
"There are two general types of fixes: [...] new fixes: *rarely*, there is a need for a net new 
change for an updates repository, e.g., *because a fix would not apply to higher OpenJDK versions* 
that are in maintenance. *Fix the issue in the highest release it is applicable to.* [...]"

Thanks,
-Aleksey



Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597