Back to the channels

#java

08:58 deebo gah, yourkit can't properly correlate virtual thread events (jsp+sql+tcp write etc), are there any other options currently?
08:59 deebo trying to figure out what is actually causing 10x response times on a cold instance, and if it could be improved a bit or warmed up for service
09:37 [twisti] we are looking for a (cli, for CI) tool to help with our code style mess in our old java projects. we need these features: the tool should have a mode to automatically fix all found issues, the tool needs a mode to just throw errors when it would want to make any changes, and the tool obviously needs to be configurable as well as overridable per line. ideally, something that detects more than just syntax style issues like whitespace, and allows
09:37 [twisti] rules such as 'always use yoda conditions'. any suggestions i should look at ?
09:42 deebo have not run into a tool that would be as "standard" as prettier is for nodejs projects
09:43 Para I've seen prettier being used for Java as well, but dunno how well it behaves.
09:44 Para SonarQube reports is one thing as well, ArchUnit can handle some corners...but no, can't think of a single tool for all of it.
09:45 deebo sonarqube requires a license post java8 or something, we had to abandon it ages ago even though it was really good
09:46 deebo sonarlint is ok, not sure if it integrates to ci/cd better these days, it used to just be a custom maven/gradle plugin that errored the build if it ran into violations
10:09 MikeBux I would look at A.I. to make the code prettier and refactor it.
10:11 deebo we want formatted code, not yassified
10:11 deebo "can you add a big pair of badonkers on IOStreamFactoryConnector.java"
10:13 MikeBux deebo, then the formatting tools of the ide should work with the right settings
10:14 [twisti] we have like seven different IDEs, good luck getting that to be 100% identical
10:14 deebo problem there is that people use what they use, but for java projects there's (afaik) nothing as good as prettier to define encforced formatting styles
10:14 [twisti] shame that todays php tooling is better than java, we live in the worst timeline
10:18 MikeBux then you need a formatter or checker in the pre commit hook
10:19 MikeBux the only way to ensure it is run every time somebody commits
10:19 MikeBux there are some articles on that topic
10:22 MikeBux [twisti], https://dev.to/itsjjpowell/we-have-code-quality-at-home-open-source-java-code-quality-tools-4i84
10:37 [twisti] yes, thats what i want it for
10:58 dreamreal [twisti]: spotless?
10:59 dreamreal [twisti]: what we do is run spotless in our actual build phases *and* commit hooks - one applies, the other checks
11:00 dreamreal and spotless can be pretty aggressive about checks, don't know if it'd be aggressive enough for you but may be an option or similar to what you want, what you want might be out there in different form
11:13 MikeBux [twisti], I would recommend to use one IDE for the whole team, that way everybody knows the ide, too. Might be hard for some people, but best for avoiding issues in the furture
11:13 dreamreal ew
11:14 dreamreal I don't think that's good advice
11:14 dreamreal there's definitely WORSE advice ("everyone should use netbeans!") but ... the ide shouldn't matter
11:14 MikeBux well last company made me use VS-Code
11:15 dreamreal okay?
11:15 MikeBux while i prefer intelliJ idea
11:16 * dreamreal is waiting
11:17 dreamreal MikeBux: I mean, that sucks for you... but the IDE shouldn't be dictated, IMO. Use build tools to normalize the team's output, period. That way someone who thinks like kent beck can use eclipse, someone who likes suffering can use vscode, someone who REALLY likes working in 2010 can use netbeans, and good coders can use idea
11:18 deebo forcing an ide on devs is like forcing dvorak on HR
11:18 dreamreal except HR deserves it
11:19 MikeBux dreamreal, well actually you are right, the advice is not really good. I used Netbeans, Eclipse, and some other ide's
11:20 deebo at one job at a large enterprise client, they gave us laptops with no permissions to install jdk
11:20 deebo got paid for a week without being able to do anything
11:20 dreamreal MikeBux: I actually don't care which IDE someone uses - I know good coders who use each of those, the IDE is not very relevant to your work product
11:21 deebo does spotless integrate to e.g. idea as a 'on save' action?
11:21 dreamreal deebo: I have that problem TODAY. We actually can't access any of our corporate resources without going through a physical access chain of custody.
11:21 dreamreal deebo: it can through the build, sure
11:21 dreamreal there may be plugins to do it explicitly without the build
11:21 deebo hmpf, i like how well prettier integrates into everything
11:23 deebo seems there's a plugin at least, but prettier plugin is first party
11:23 * dreamreal shrugs
11:23 dreamreal do what works for you
11:26 MikeBux well, the worst is that the team can't commit because the code is not formatted and the devs only want to review actual code changes and not the whole formatted class
11:27 dreamreal MikeBux: that's why the build does it. You build it, you get formatted code on a consistent level.
11:28 dreamreal If it's not formatted properly by the tool, then it wasn't compiled and should fail review right out of the gate.
11:28 MikeBux yes
12:08 dreamreal so what formatters/linters do you guys use?
12:08 dreamreal I use spotless pretty much everywhere just out of convenience; I know it well, it suits what I need, but what do you prefer, why?
12:11 MikeBux dreamreal, we used the one ide aproach in the last company
12:12 MikeBux and in the one before, too
12:12 dreamreal MikeBux: so you said. Did you also enforce the code formatting across the board? (And my goodness, that sounds horrible - TWO of those companies in a row?)
12:15 MikeBux dreamreal, yes we had to make sure the formatting rules were the same in all ides, like 2 space indent and stuff like that
12:15 MikeBux no precommit hooks and such things
12:16 dreamreal You need to find better employers :D
12:17 dreamreal Sorry, man.
12:17 * dreamreal says that as his work is *just now* standardizing on a code formatter as part of the build: our deployment is pure hell and enforces a certain conservatism we're just fighting our way past
12:20 deebo we just share an idea formatter profile and then nitpick in reviews, all nodejs projects use prettier
12:21 dreamreal deebo: makes sense, but why not use the prettier mindset for java projects, too? I mean, that's the right way to do it, why not do it?
12:21 deebo would be nice to have ide importable rules in the project, with sql formatting too
12:21 * dreamreal bleahs
12:21 deebo havent found a good solution yet, spotless is something to look at
12:22 dreamreal My team has people who use vi, eclipse, idea, vscode... and one guy WANTS to use netbeans. IDE profiles are nice but rather isufficient.
12:22 deebo there was also some gradle ide plugin that has generic settings to define and then it can generate it for any (most) ides
12:22 dreamreal yeah, but... why? I use joe and vi and sublime text too
12:23 dreamreal the *central* flow for every last bit of code is the build
12:23 deebo when does the formatting actually happen for you?
12:24 dreamreal every compilation.
12:24 deebo for all or changed files?
12:24 dreamreal I'm not sure if spotless checks the update times. But it gets applied to all files.
12:25 dreamreal I routinely work on builds with thousands of source files; it's not a problem for us.
12:25 deebo yeah we would want changed only, i guess compile works ok since most ides just call gradle
12:25 dreamreal Why would it matter?
12:26 deebo we try to avoid drive-by formatting/etc changes, it would balloon every change in review
12:26 dreamreal I mean, if I have files j0-999.java that are unchanged, and j1001.java that IS (not real names, obv) - those 1000 files aren't going to get diffs
12:26 dreamreal they'll always format the same. There's no DIFF. Only the j1001.java would get changed; and that'd be part of your review ANYWAY because you changed it.
12:26 dreamreal That INITIAL commit would be a chonker. After that, nothing.
12:27 deebo yeah that would really annoyingly break blames for a while
12:27 deebo but have to see what kind of changes it would make
12:27 dreamreal So you have a branch for "integrate spotless/whatever into the build" and ... use it. It formats every file and ONLY formats every file. rebase. Done.
12:27 dreamreal Yes, it would annoyingly break blames for a while.
12:28 dreamreal Which is why you do it early. :D Our project dates from 2007; it's not a minor cost. But should have been done years ago.
12:28 dreamreal like I said, our environment has a certain conservatism in play.
12:29 deebo could maybe sneak it in with spring boot 4 upgrades
12:29 dreamreal You can, BTW, set formatting for spotless; if you have IDE formatting your team likes, you can get spotless to mirror it.
12:31 dreamreal That may help with the blame problem, and also gives you a way to change formatting incrementally should you desire that.
12:36 dreamreal dmlloyd: https://bytecode.news/posts/2026/04/methodhandles-why-you-actually-care
12:37 dmlloyd nice!
12:38 deebo is spotless + google style for example forcing a specific formatting? or does it "allow" or "deny" a formatting for something?
12:38 dmlloyd nice writeup, thanks
12:39 dreamreal PLEASE sanity-check it for me, dmlloyd
12:39 dreamreal I tried to do well, but you're the expert here
12:39 dmlloyd I did, it looks good
12:39 dreamreal deebo: you can apply it or validate it
12:39 dreamreal dmlloyd: *nod* thank you
12:39 dreamreal and well done on your part
12:40 deebo but with a valid java input formatted in multiple random ways, the output is always the same?
12:40 dmlloyd thanks. with that kind of motivation, maybe I'll only wait 16 months for the next one
12:40 dreamreal deebo: if you *apply* spotless, it will generate consistent output, yes
12:41 dreamreal dmlloyd: I tried to explain what your purpose was in writing without being judgemental about it
12:41 dmlloyd yeah that bit was fine
12:42 dmlloyd honestly I feel a bit nihilistic when it comes to my blog so it's a lot more than I expected lol
12:42 dreamreal my biggest concern there is that I don't want to be projecting AND BCN doesn't criticize if it can help it, ever
12:43 dreamreal if something's worth damning I'd rather just not write about it
12:57 [twisti] had to step out. spotless is on the list, thanks dreamreal. MikeBux: note that it is your LAST company; forcing tools on grown ass adults is a good way to have everyone who has options leave for less unpleasant leadership
12:58 dreamreal [twisti]++
12:58 nevet [twisti] now has karma of 2.
13:22 Square3 I'm having problems with FunctionalInterfaces. At one place we have a "serializable suppplier" (B) converted to a functional interface A. When this whole thing is deserialized I get a ClassCastException from SerializedLamba to A. If I manually create a `record C(B supplier) implements A { get() {..} }` things work.
13:24 Square3 By "converted" I mean A is inferred by a method reference to a no-arg method `anInstance::noArgMethod`
13:32 dreamreal I'd want to see an actual test case
14:18 Square3 I'll see if I can produce one. Worrisome thing is that seems a bit random.
17:45 dreamreal ~jep 534
17:45 javabot 'JEP 534: Compact Object Headers by Default' can be found at http://openjdk.java.net/jeps/534
17:45 nevet JEP 534: Compact Object Headers by Default
18:20 dmlloyd shrunken heads?
18:21 DoofusCanadensis *snrk*