<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
@font-face
{font-family:"Iosevka Fixed SS16";
panose-1:2 0 5 9 3 0 0 0 0 4;}
@font-face
{font-family:"Times New Roman \(Body CS\)";
panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Aptos",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Iosevka Fixed SS16";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="#467886" vlink="#96607D" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">I generally agree. In this particular case, the distinction is clear and explained in the docs (perhaps it could be explained better, your suggestions are always welcomed).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">The new names, I think, fit better: getCaretShape() are far better than getCaretShapeWithInsets (what insets? why? what makes insets so special?).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">The proposed solution provides the new API without breaking the existing apps. The apps can take their time to migrate to the new API in due course. I believe we've done
this in the past where things got deprecated but not for removal.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">So I think this is a good compromise - things get fixed without immediately breaking the existing apps, a win-win.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">-andy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Michael Strauß <michaelstrau2@gmail.com><br>
<b>Date: </b>Monday, July 7, 2025 at 19:41<br>
<b>To: </b>Andy Goryachev <andy.goryachev@oracle.com><br>
<b>Cc: </b>openjfx-dev <openjfx-dev@openjdk.org><br>
<b>Subject: </b>[External] : Re: Enhanced Text/TextFlow APIs<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">In most cases, I would advise against having similarly-named methods<br>
that exhibit different semantics. If the behavior of the existing<br>
methods is indeed a bug (and not just different, but legitimate<br>
semantics), then fixing that would be best. We've done breaking<br>
changes in the past where appropriate, and expect applications to make<br>
necessary changes in their API use when switching to a new version of<br>
JavaFX. Always keeping old behavior around runs the risk of<br>
fossilizing the API in the long run.<br>
<br>
In rare cases, and especially when necessary changes would be more<br>
involved, there's the option to hide the previous behavior behind a<br>
system property. Setting a system property in lieu of changing code is<br>
a low-effort option for applications that are not prepared to fix<br>
their code just yet.<br>
<br>
If we want to keep the old methods around indefinitely, another option<br>
would be to make the new methods clearly different to indicate their<br>
changed semantics.<br>
<br>
For example, for the existing method `rangeShape(int, int)`, we could<br>
add another method `rangeShapeWithLineSpacing(int, int)`. This makes<br>
the semantics of the method abundantly clear to users, and keeps the<br>
old method around. It also avoids the proposed boolean argument<br>
`includeLineSpacing`, which is usually better API design.<br>
<br>
As another example, the existing method `caretShape(int, boolean)`<br>
could be paired with `caretShapeWithInsets(int, boolean)`.<br>
<br>
My main criticism is that method pairings like `rangeShape` and<br>
`getRangeShape` muddy the API waters. We'd never have done that, had<br>
we thought about the correct semantics earlier. Evolving an API is<br>
always hard, but the goal should be to have the new API fit well with<br>
the existing API, as if it had been thought of from the beginning.<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>