Bananeweizen

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

I‘m honored that I gained now Committer status on project #Operaton 🎉🎁 Currently I‘m investing a huge amount of my spare time, working on build tasks, dependency upgrades and modernizing the #Camunda 7 based code. I’m incrementally upgrading 30k JUnit 4 test cases to JU5.

@odrotbohm For non-IDE use cases, Spotbugs can report that and also checks the mentioned annotation. See #rv-method-ignores-return-value-is-this-ok-rv-return-value-ignored-inferred" target="_blank" rel="nofollow noopener">spotbugs.readthedocs.io/en/stable/bugD… and following

Given that more and more #Java APIs use a builder style with only some methods provided being terminal ones, I wonder if it made sense to be able to mark those, for example, with an annotation. It would help (IDEs) to detect missing calls to such methods.

@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?

📢 #OCX24 starts tomorrow! Here is some information to help you get the most out of a busy, productive, and fun event! 📍 Plan your journey: hubs.la/Q02V3vSq0 🗓 Check the agenda: hubs.la/Q02V3qYM0

@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.

So I'm not a big fan of JUnit's MethodSource, it moves test arguments too far out of sight for my taste. CsvSource is pretty sweet though, in particular with text blocks. Nice intro, by @mikemybytes 👍. 👉 mikemybytes.com/2021/10/19/par…

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

🚀 Theia AI Sneak Preview: Learn how to orchestrate AI agents for seamless collaboration in custom tools and IDEs. eclipsesource.com/blogs/2024/09/… #EclipseTheia #TheiaIDE #EclipseCloudDevTools

@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.

When it comes to tests, I feel DRY isn't that useful. I prefer readable self-contained test cases which tell a "story" end-to-end over having highly normalized code extracting commonalities. There are so many small deviations between test cases which often make that hard to grok.

@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.

I love Java and its ecosystem, I really do. But what is it with these super-deep call stacks?! How can it be 140+ frames from the main class to my code under test (top four frames!) in a JUnit test? Is this a thing with other languages, too?

@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.

How comes the #Java API still has no method String#isNullOrBlank()? Have yet to see a project where this is not one of the first utilities to be added.

@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.

Pull requests are great for low-trust environments like OSS with many external contributors. For stable teams e.g. in-house, I feel that they are too wasteful of a process and slow. Make sure to have alignment on the big picture, anything else can also be improved after merging.

@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").

Has the #Java Language considered to support method references in annotation parameters? @UIColorAnnotation(method = Person::getAgeColor) public int getAge() { It's a common problem for our API design. Annotations can reference classes, but not fields nor methods. @BrianGoetz

@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.

@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.

Pepperidge Farm remembers @EclipseCollect using JUnit 3.x. I spent two hours tonight reviewing a 450 file PR created in 15 minutes by two refactorings using OpenRewrite. This will be one of many PRs to move EC from JUnit 4.x to 5.x. ~170,000 unit tests are both boon and burden.

We started @EclipseCollect on J2SE 1.4. We're baselined on Java 11 for the next release. I see the great features added since Java 11 and think "Wow!" We're fortunate to have the Core #Java team driving steady progress. I want to get EC to Java 21 now! Excited for the future!🙏

@gunnarmorling Similar to the JUnit Pioneer extension, but more explicitly named: github.com/claudioaltamur…

Build plug-in idea: check for TODO markers with a due date in source code and fail the build once that date has passed: ``` Build failed. TODO SomeClass.java:45 is overdue: // TODO 2024-06-30 Remove legacy endpoint ``` Is there such a thing?

@gunnarmorling I recommend github.com/gaul/modernize… and #IllegalImport" target="_blank" rel="nofollow noopener">checkstyle.org/checks/imports… to avoid anyone in a team using classes that are "deprecated as agreed by the team".

That's excellent! There's no reason really to use the legacy date/time types of the JDK in this time and age. Them not being deprecated unfortunately leads to further usage even in new code, so that's a great step into the right direction.

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

A hill I'm willing to have a nap on every day of the week: builds should be reproducible by default. You shouldn't have to jump through any config hoops at this time and day for getting stable artifacts out of your source code.

@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.

@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.

0% was the answer. Not a single one out of room of 20-30 IT students raise their hands when I asked if they did anything in/with opensource. I had expected at least one or two. They all just consumed. That surprised me.

@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.

Anyone played around with API breakages/deprecation cycles based on time remaining instead of version? Like version X deprecates an API, X+1 issues a warning and X+1 at a certain date starts to error out. Kinda client-side brownout to target specific usage patterns

@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.

Want to easily reduce your companies CO2 footprint? 🏭Finally disable those lint builds that retrigger a full build pipeline because of that missing space 🍃🌱

@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...

@Bananeweizen @renovatebot Haha, I think you're overthinking this. Not going to generate a rule for a missing square bracket. Have you read the alt text? 😁😉

I won't be able to sleep tonight unless I find a reason to edit my @renovatebot's renovate.json file! 🥵 #developernightmare #]