<div dir="ltr">Hi Johan,<div><br></div><div>Sorry for not replying earlier.</div><div>Since this is a real small fix, I think it makes sense to backport it to 17/21. </div><div>I'm a bit hesitant because of JEP 14 [1] and the current discussions on the Tip&Tail approach [2] , where it is explicitly discouraged to backport anything apart from vulnerabilities and critical errors. Since this is a P4 bug, I don't think it qualifies -- hence my doubt.</div><div><br></div><div>This is a situation that I believe could be discussed in jdk-dev -- not for this issue in particular, but rather the principle: what is the recommendation with backport requests for P4 bugs that are "small" and "guaranteed to have no regression"?</div><div><br></div><div>I don't think it's good to have the discussion at 2 places, but to summarize some of the key reasons on why not backporting non-criticial things:</div><div>* we do not want to break existing work in LTS releases (software that relies on some undocumented internal JavaFX behavior might go wrong if the behavior is changed)</div><div>* we need to make sure the CPU fixes can "easily" be backported.</div><div>* time spent in tail-backporting can not be spent in tip-development. And unfortunately, I learned the hard way that backporting is much more time-consuming (and error-prone) than I hoped for.</div><div><br></div><div>Having said that, I definitely don't want to reject this upfront -- just want to clarify the complexity and I very much welcome other input.</div><div><br></div><div>- Johan</div><div><br></div><div>[1]  <a href="https://openjdk.org/jeps/14">https://openjdk.org/jeps/14</a></div><div>[2] <a href="https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009433.html">https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009433.html</a></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op di 5 nov 2024 om 11:40 schreef Johan Corveleyn <<a href="mailto:jcorvel@gmail.com">jcorvel@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Oct 7, 2024 at 5:01 PM Johan Corveleyn <<a href="mailto:jcorvel@gmail.com" target="_blank">jcorvel@gmail.com</a>> wrote:<br>
><br>
> On Tue, Oct 1, 2024 at 10:30 PM Johan Corveleyn <<a href="mailto:jcorvel@gmail.com" target="_blank">jcorvel@gmail.com</a>> wrote:<br>
> ><br>
> > On Mon, Sep 30, 2024 at 5:23 PM Kevin Rushforth<br>
> > <<a href="mailto:kevin.rushforth@oracle.com" target="_blank">kevin.rushforth@oracle.com</a>> wrote:<br>
> > ><br>
> > > Gluon maintains JavaFX 17 and 21, so Johan can answer that.<br>
> > ><br>
> > > There is no maintainer for the JavaFX 8 or 11 code lines in OpenJDK.<br>
> ><br>
> > Ah yes, for 8 we use the Oracle JDK which includes its JavaFX build.<br>
> > So for backport to Oracle Java 8 I guess we'd need to ask Oracle.<br>
> ><br>
> > Having this fix backported into OpenJFX 17 and 21 would be great though.<br>
><br>
> Coming back to this: any chance this fix could be backported to<br>
> OpenJFX 17 and 21?<br>
<br>
One last try: anyone able to backport this deadkey fix to 17 and 21?<br>
Or even take it into consideration for inclusion in OpenJFX 11 or JDK<br>
8?<br>
<br>
-- <br>
Johan<br>
</blockquote></div>