Bananeweizen

Open Source Developer at night

[Bananeweizen @Bananeweizen]

@kthoms Use openrewrite to automate most of that. It works really well for such tasks. I use it regularly on our product code.

[Bananeweizen @Bananeweizen]

@odrotbohm For non-IDE use cases, Spotbugs can report that and also checks the mentioned annotation. See https://t.co/qOboj2KWL2 and following

[Bananeweizen @Bananeweizen]

@EclipseCon The website mentions an event app, but I find no details. Can you share the details publicly, or will we get details tomorrow in person, or is there no app?

[Bananeweizen @Bananeweizen]

@gunnarmorling @mikemybytes MethodSource is good for quickly converting from JUnitParams parametersForTestMethodName (if you still have that!), but that should be refactored to one of the other variants afterwards.

[Bananeweizen @Bananeweizen]

@eclipsesource Next step: agent to improve the (hardcoded) prompts of the other agents over time. :)

[Bananeweizen @Bananeweizen]

@gunnarmorling Disagree. Use AssertJ with fluent API, lambda based filtering/mapping or even custom assertions (when enough similar tests) to avoid lengthy low level repetition. Avoid test utils classes by extracting custom JUnit annotations instead, which are composable without inheritance.

[Bananeweizen @Bananeweizen]

@gunnarmorling It's the cost of abstraction for functional programming idioms to be mapped to concepts existing before FP. When doing Smalltalk development, 100-200 frames were normal during debugging. Smalltalk uses blocks (equivalent to lambdas) far more often than Java.

[Bananeweizen @Bananeweizen]

@gunnarmorling We use NonNull annotations with a compiler that can propagate nullness (ecj), and basically don't need that, even in MLOC projects.
In the case of calling external nullable code, we rather use guard pattern (if null return; if blank return; if badcondition return;) for readablty.

[Bananeweizen @Bananeweizen]

@gunnarmorling Disagree. Mob programming is better than reviews (of PRs). But for people working asynchronously, a PR with review is still better than no exchange of knowledge and practices. Having the same team goals doesn't automatically lead to a consistent implementation by many authors.

[Bananeweizen @Bananeweizen]

@GeoffreyDeSmet @BrianGoetz Wondering if an annotation is the best solution, if you need that much flexibility. An adapter pattern might fit better. IMO annotations often work with conventions (like just looking for a method with the same name as the annotated one +"Color").

[Bananeweizen @Bananeweizen]

@lukaseder Experienced too many failures from developers running the generator wrongly. Therefore regenerate in each build. Also ensures that a checkout on new machine can fully build without manual intervention.

[Bananeweizen @Bananeweizen]

@TheDonRaab @EclipseCollect I'd really, really recommend to change the assertion library to AssertJ, while refactoring the tests. Use Jupiter for running and writing extensions, but don't even spend time exploring the assertion methods. Replacing JUnit assert with AssertJ is trivial with Open rewrite.

[Bananeweizen @Bananeweizen]

@gunnarmorling Similar to the JUnit Pioneer extension, but more explicitly named: https://t.co/XBy1PbNaCc

[Bananeweizen @Bananeweizen]

@gunnarmorling I recommend https://t.co/BGTjAXTD4j and https://t.co/7U9EJB72dd to avoid anyone in a team using classes that are "deprecated as agreed by the team".

[Bananeweizen @Bananeweizen]

@gunnarmorling If someone is looking for how to: https://t.co/mKRirHmNre. And even large projects can have binary reproducible builds, as the Adoptium Temurin project shows (check their blog and github repos for details).

[Bananeweizen @Bananeweizen]

@gunnarmorling Full ack. Unfortunately, too often when I contribute a maven default goal, a .mvn/jvm.config, an enforcer goal or a plugin management section with version numbers to open source project builds, that has to be discussed over and over again.

[Bananeweizen @Bananeweizen]

@maxandersen The young generation is used to free apps, and probably doesn't care about the difference between free and open. Also the attention economy of today leads to people just jumping to the next interesting thing. It needs focus to work on a contribution.

[Bananeweizen @Bananeweizen]

@bmuskalla Bad idea. You can't test reliably (especially with multiple features expiring on multiple dates). Bug reports suddenly have the reporting date as critically important field (besides the version). Users can't control the expiration (which they can when upgrading explicitly). etc.

[Bananeweizen @Bananeweizen]

@bmuskalla People are lazy. Checking formatting rules in the build is easier than enforcing a uniform formatting right in the IDE (which I do). Failing a build on broken format is okay, since otherwise the next dev changing that file will get formatting-only noise in his PR.

[Bananeweizen @Bananeweizen]

@bmarwell @renovatebot Sure. :) Still that suggestion makes a lot of sense on a lot of renovate configs all the time, so I was going to spread it, given the chance...