On Tue, 24 Mar 2026 21:11:37 GMT, Andy Goryachev <[email protected]> wrote:
>> 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`? > >> We are smart developers after all. > > I am certainly not. > >> Should we not use some Java language features just because an IDE doesn’t >> support them? > > it's not that, it's the convenience, both during the review and while > debugging. > >> this in Eclipse: Toggle Lambda Entry Breakpoint? > > where is it? `<joke>` Grundstücksverkehrsgenehmigungszuständigkeitsübertragungsverordnung `</joke>` I understand it now :-) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2118#discussion_r2984325581
