<div dir="ltr"><div>Ok, thanks for elaborating. I'll submit a PR for review soon.</div><div><br></div><div>Take care,</div><div><br></div><div>Daniel</div><div><br></div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Aug 22, 2025 at 7:11 AM Philip Race <<a href="mailto:philip.race@oracle.com">philip.race@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
I suppose they won't be that surprised, since it has been the
behaviour already.<br>
<br>
I think it unlikely that an app throws null at TextLayout on purpose
knowing it won't work.<br>
That's the realm of conformance tests, not real programs, so I'm not
terribly worried about that.<br>
<br>
What I was getting at, in part, is that it seems possible to me that
this was not checked<br>
because the thinking was in this case, null was allowed and meant a
default FRC.<br>
If we change the exception type it makes it one step harder if we
find out that's where we want to end up.<br>
I don't see a lot of supporting evidence for that, so I am just
throwing it out there.<br>
It could also be that it was added at a different time by some one
not following the rest of the API<br>
<br>
But this point is minor. The big question is around the empty
string.<br>
It certainly was a pain for me when doing printing when I had needed
to use TextLayout<br>
and had to be careful of this case.<br>
<br>
It would be 'ideal' if "" was just silently handled and didn't cause
issues for existing code - other than conformance tests<br>
which shouldn't be testing unspecified behaviour anyway.<br>
<br>
-phil.<br>
<br>
<div>On 8/19/25 4:29 AM, Daniel Gredler
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div><span>Hi Phil,</span></div>
<div><span><br>
</span></div>
<div><span>>> First, there is a related
API oddity in that null FontRenderContext </span></div>
<div><span></span></div>
<span>>> parameters passed to the
TextLayout constructors cause a <br>
>> NullPointerException, rather than an
IllegalArgumentException (like <br>
</span>
<div><span>>> all other parameters). Can
this behavior also be changed?<br>
</span></div>
<div><br>
</div>
<div>> It is a bit odd that frc is the only one not
explicitly checked so the <br>
> NPE is just what 'happens'.<br>
> I'd be reluctant to change the NPE without a good reason
[...]</div>
<div>> I'd say just specify what happens for complete
compatibility.<span><br>
</span></div>
<div><span><br>
</span></div>
<div><span>I guess I'm hesitant to promote an
"accidental" NPE to official behavior here, when all other
null parameter values are handled with an explicit IAE. This
inconsistency is going to surprise developers, and avoiding
that surprise would be ideal. How likely is it that adding
an explicit IAE-generating null FRC check here will break
existing code?</span></div>
<div><span><br>
</span></div>
<div><span>Take care,</span></div>
<div><span><br>
</span></div>
<div><span>Daniel</span></div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Aug 11, 2025 at
7:12 PM Philip Race <<a href="mailto:philip.race@oracle.com" target="_blank">philip.race@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 8/11/25 9:20 AM, Daniel Gredler wrote:<br>
> Hi all,<br>
><br>
> I was thinking of taking a stab at JDK-4138921 [1], and I
have a <br>
> couple of questions.<br>
><br>
> First, there is a related API oddity in that null
FontRenderContext <br>
> parameters passed to the TextLayout constructors cause a
<br>
> NullPointerException, rather than an
IllegalArgumentException (like <br>
> all other parameters). Can this behavior also be changed?<br>
<br>
None of these are documented .. they all should be.<br>
<br>
It is a bit odd that frc is the only one not explicitly
checked so the <br>
NPE is just what 'happens'.<br>
I'd be reluctant to change the NPE without a good reason and
I'm <br>
half-wondering if a null FRC was<br>
supposed to default to a default FRC ?? But somewhere along
the line the <br>
implementation changed.<br>
I'd say just specify what happens for complete compatibility.<br>
<br>
><br>
> Second, changing all three TextLayout constructors to
accept empty <br>
> strings sort of implies that we should also allow empty
strings in <br>
> AttributedString instances (this is currently only
allowed if the <br>
> attribute map is empty). Is it OK to change this behavior
as well?<br>
<br>
I don't think I ever understood why this was dis-allowed on
TextLayout.<br>
Perhaps it was to prevent some incorrect usage from ever
slipping into <br>
being acceptable ?<br>
<br>
AttributedString is part of the java.base module, I don't have
any say <br>
over that, although in the very beginning<br>
there was a decent overlap in the people working on that and
TextLayout etc.<br>
I'd start by asking Naoto (cc'ed).<br>
<br>
-phil.<br>
<br>
><br>
> Let me know your thoughts!<br>
><br>
> Daniel<br>
><br>
> [1] <a href="https://bugs.openjdk.org/browse/JDK-4138921" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-4138921</a><br>
><br>
><br>
<br>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote></div>