JDK-4138921: TextLayout handling of empty strings

[Philip Race]

I suppose they won't be that surprised, since it has been the behaviour 
already.

I think it unlikely that an app throws null at TextLayout on purpose 
knowing it won't work.
That's the realm of conformance tests, not real programs, so I'm not 
terribly worried about that.

What I was getting at, in part, is that it seems possible to me that 
this was not checked
because the thinking was in this case, null was allowed and meant a 
default FRC.
If we change the exception type it makes it one step harder if we find 
out that's where we want to end up.
I don't see a lot of supporting evidence for that, so I am just throwing 
it out there.
It could also be that it was added at a different time by some one not 
following the rest of the API

But this point is minor. The big question is around the empty string.
It certainly was a pain for me when doing printing when I had needed to 
use TextLayout
and had to be careful of this case.

It would be 'ideal' if "" was just silently handled and didn't cause 
issues for existing code - other than conformance tests
which shouldn't be testing unspecified behaviour anyway.

-phil.

On 8/19/25 4:29 AM, Daniel Gredler wrote:
> Hi Phil,
>
> >> First, there is a related API oddity in that null FontRenderContext
> >> parameters passed to the TextLayout constructors cause a
> >> NullPointerException, rather than an IllegalArgumentException (like
> >> all other parameters). Can this behavior also be changed?
>
> > It is a bit odd that frc is the only one not explicitly checked so the
> > NPE is just what 'happens'.
> > I'd be reluctant to change the NPE without a good reason [...]
> > I'd say just specify what happens for complete compatibility.
>
> 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?
>
> Take care,
>
> Daniel
>
>
> On Mon, Aug 11, 2025 at 7:12 PM Philip Race <philip.race at oracle.com> 
> wrote:
>
>
>
>     On 8/11/25 9:20 AM, Daniel Gredler wrote:
>     > Hi all,
>     >
>     > I was thinking of taking a stab at JDK-4138921 [1], and I have a
>     > couple of questions.
>     >
>     > First, there is a related API oddity in that null FontRenderContext
>     > parameters passed to the TextLayout constructors cause a
>     > NullPointerException, rather than an IllegalArgumentException (like
>     > all other parameters). Can this behavior also be changed?
>
>     None of these are documented .. they all should be.
>
>     It is a bit odd that frc is the only one not explicitly checked so
>     the
>     NPE is just what 'happens'.
>     I'd be reluctant to change the NPE without a good reason and I'm
>     half-wondering if a null FRC was
>     supposed to default to a default FRC ?? But somewhere along the
>     line the
>     implementation changed.
>     I'd say just specify what happens for complete compatibility.
>
>     >
>     > Second, changing all three TextLayout constructors to accept empty
>     > strings sort of implies that we should also allow empty strings in
>     > AttributedString instances (this is currently only allowed if the
>     > attribute map is empty). Is it OK to change this behavior as well?
>
>     I don't think I ever understood why this was dis-allowed on
>     TextLayout.
>     Perhaps it was to prevent some incorrect usage from ever slipping
>     into
>     being acceptable ?
>
>     AttributedString is part of the java.base module, I don't have any
>     say
>     over that, although in the very beginning
>     there was a decent overlap in the people working on that and
>     TextLayout etc.
>     I'd start by asking Naoto (cc'ed).
>
>     -phil.
>
>     >
>     > Let me know your thoughts!
>     >
>     > Daniel
>     >
>     > [1] https://bugs.openjdk.org/browse/JDK-4138921
>     >
>     >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250821/c51e5060/attachment-0001.htm>