On Tue, 24 Mar 2026 20:29:46 GMT, Andy Goryachev <[email protected]> wrote:
>> There is some interesting research about this matter - like how much things
>> we can remember at once when reading code and so on. I took that from there.
>>
>> In any case, it is a matter of taste.
>> For me, the `IntStream` is a common pattern so I do not see how a utility
>> method helps, other then making the class bigger with a method that is used
>> in 4/80 tests (as an example).
>> Same for lambdas, big lambdas inline are IMHO not readable anymore,
>> especially with many if-else. A method reference will help a lot, since the
>> method name should already provide some information.
>>
>> Regarding lambda fomratting, I don't use the `{..}` if I don't need to. It
>> will just add extra clutter for no improvement. And IntelliJ also marks that
>> as 'can be removed, not needed for a single line'. And I agree with that.
>
> inability to set a breakpoint on a lambda in some IDEs is not exactly a
> matter of taste, but of convenience. thanks for making my life less
> convenient.
>
> I still can't believe `IntStream.range(0, 15).boxed().map(integer -> "Item "
> + integer).toList()` is considered to have less cognitive load than a simple
> function call. it's hilarious! :-)
OK, there seem to be some misunderstandings here.
So, cognitive complexity is a topic of discussion, my favourite example is
Lombok.
Some people think it’s absolutely great, others don’t. A common setting there
is: Generate `hashCode()` with all private fields except X, Y, and Z.
Some people like this because they no longer have to see the method. Others
don’t like it as much because they suddenly have to remember exactly what’s
included and, if necessary, recheck the exclusion because you forgot already.
Without generation, you can very easily jump to the` hashCode()` method with
your IDE and see the truth right in front of you.
The same concept applies here as well. The IntStream code is so common, and I,
for example, parse it immediately. With a method, I’d first have to look it up
-> jump to it -> away from the test -> Remember it -> go back. And all for
what’s basically just a simple one-liner. If every test class is very different
(and you need to adjust multiple classes) and they all have some more util
methods, it quickly just adds a bit more overhead. That doesn’t mean you can’t
understand it. We are smart developers after all. But it also doesn’t mean it’s
actually better.
My idea, therefore, would be to unify the tests more in the future so that
everyone uses the same thing. Then you only have to learn one method for
writing tests (StageLoader, EventFirer, and maybe also methods for quickly
generating such list with data). Then you only have to understand this one
class and can use it to understand all JavaFX tests very quickly. This is
something I have in the pipeline already.
As for Eclipse: It’s hard to draw a line here. Should we not use some Java
language features just because an IDE doesn’t support them?
What if another contributor uses a very exotic IDE that doesn’t support
lambdas? Should we go back to writing inner classes just because of one person?
I know that sounds silly, but I want to make it clear that it’s not that simple.
And Eclipse is not used that often (anymore). Doesn't mean we need to exclude
it, but it's also weird to forbid a valid (and shorter and IMO easier to read)
method because of that.
Beside, isn't there a functionality already for this in Eclipse: `Toggle Lambda
Entry Breakpoint`?
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/2118#discussion_r2984254560
