On Thu, 22 May 2025 15:05:02 GMT, Michael Strauß <mstra...@openjdk.org> wrote:
>> I would have agreed with the proposed change, if it were a public API. >> >> This is an internal method, so it was made as low level as possible. The >> return value is documented, and the consumer is another part of internal >> code. No need to make it more complicated, in my opinion. > > The point is that it's less complicated to have self-describing, strongly > typed, and compiler-checked code. Your code is more complicated because it's > brittle, untyped, and less robust against refactoring. > > Just to make sure that we're on the same page here: "so it was made as low > level as possible" sounds like you deliberately chose to forgo strong > typing... to achieve _what_? There are exactly two internal consumers of that internal API (`PrismLayoutInfo` and `TextUtils.getCaretShape`), and the return value is documented. I don't want to add any more internal classes, just to repackage the thing into what is eventually delivered via public API, and I cannot use the public API data objects because they are different in the two different use cases. I don't think it's worth to add a bunch of classes at this level, float[] works just fine. Is this something you consider to be so important to be an integration blocker? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2102821738
