ByteCode.News
RSS
SubmitLog in

Community

Chat Logs

Wednesday, April 15, 2026

  1. deebogah, yourkit can't properly correlate virtual thread events (jsp+sql+tcp write etc), are there any other options currently?
  2. deebotrying 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
  3. [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
  4. [twisti]rules such as 'always use yoda conditions'. any suggestions i should look at ?
  5. deebohave not run into a tool that would be as "standard" as prettier is for nodejs projects
  6. ParaI've seen prettier being used for Java as well, but dunno how well it behaves.
  7. ParaSonarQube reports is one thing as well, ArchUnit can handle some corners...but no, can't think of a single tool for all of it.
  8. deebosonarqube requires a license post java8 or something, we had to abandon it ages ago even though it was really good
  9. deebosonarlint 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. MikeBuxI would look at A.I. to make the code prettier and refactor it.
  11. deebowe want formatted code, not yassified
  12. deebo"can you add a big pair of badonkers on IOStreamFactoryConnector.java"
  13. MikeBuxdeebo, then the formatting tools of the ide should work with the right settings
  14. [twisti]we have like seven different IDEs, good luck getting that to be 100% identical
  15. deeboproblem 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
  16. [twisti]shame that todays php tooling is better than java, we live in the worst timeline
  17. MikeBuxthen you need a formatter or checker in the pre commit hook
  18. MikeBuxthe only way to ensure it is run every time somebody commits
  19. MikeBuxthere are some articles on that topic
  20. MikeBux[twisti], https://dev.to/itsjjpowell/we-have-code-quality-at-home-open-source-java-code-quality-tools-4i84
  21. [twisti]yes, thats what i want it for
  22. dreamreal[twisti]: spotless?
  23. dreamreal[twisti]: what we do is run spotless in our actual build phases *and* commit hooks - one applies, the other checks
  24. dreamrealand 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
  25. 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
  26. dreamrealew
  27. dreamrealI don't think that's good advice
  28. dreamrealthere's definitely WORSE advice ("everyone should use netbeans!") but ... the ide shouldn't matter
  29. MikeBuxwell last company made me use VS-Code
  30. dreamrealokay?
  31. MikeBuxwhile i prefer intelliJ idea
  32. * dreamreal is waiting
  33. dreamrealMikeBux: 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
  34. deeboforcing an ide on devs is like forcing dvorak on HR
  35. dreamrealexcept HR deserves it
  36. MikeBuxdreamreal, well actually you are right, the advice is not really good. I used Netbeans, Eclipse, and some other ide's
  37. deeboat one job at a large enterprise client, they gave us laptops with no permissions to install jdk
  38. deebogot paid for a week without being able to do anything
  39. dreamrealMikeBux: 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
  40. deebodoes spotless integrate to e.g. idea as a 'on save' action?
  41. dreamrealdeebo: I have that problem TODAY. We actually can't access any of our corporate resources without going through a physical access chain of custody.
  42. dreamrealdeebo: it can through the build, sure
  43. dreamrealthere may be plugins to do it explicitly without the build
  44. deebohmpf, i like how well prettier integrates into everything
  45. deeboseems there's a plugin at least, but prettier plugin is first party
  46. * dreamreal shrugs
  47. dreamrealdo what works for you
  48. MikeBuxwell, 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
  49. dreamrealMikeBux: that's why the build does it. You build it, you get formatted code on a consistent level.
  50. dreamrealIf it's not formatted properly by the tool, then it wasn't compiled and should fail review right out of the gate.
  51. MikeBuxyes
  52. dreamrealso what formatters/linters do you guys use?
  53. dreamrealI use spotless pretty much everywhere just out of convenience; I know it well, it suits what I need, but what do you prefer, why?
  54. MikeBuxdreamreal, we used the one ide aproach in the last company
  55. MikeBuxand in the one before, too
  56. dreamrealMikeBux: 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?)
  57. MikeBuxdreamreal, yes we had to make sure the formatting rules were the same in all ides, like 2 space indent and stuff like that
  58. MikeBuxno precommit hooks and such things
  59. dreamrealYou need to find better employers :D
  60. dreamrealSorry, man.
  61. * 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
  62. deebowe just share an idea formatter profile and then nitpick in reviews, all nodejs projects use prettier
  63. dreamrealdeebo: 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?
  64. deebowould be nice to have ide importable rules in the project, with sql formatting too
  65. * dreamreal bleahs
  66. deebohavent found a good solution yet, spotless is something to look at
  67. dreamrealMy team has people who use vi, eclipse, idea, vscode... and one guy WANTS to use netbeans. IDE profiles are nice but rather isufficient.
  68. deebothere was also some gradle ide plugin that has generic settings to define and then it can generate it for any (most) ides
  69. dreamrealyeah, but... why? I use joe and vi and sublime text too
  70. dreamrealthe *central* flow for every last bit of code is the build
  71. deebowhen does the formatting actually happen for you?
  72. dreamrealevery compilation.
  73. deebofor all or changed files?
  74. dreamrealI'm not sure if spotless checks the update times. But it gets applied to all files.
  75. dreamrealI routinely work on builds with thousands of source files; it's not a problem for us.
  76. deeboyeah we would want changed only, i guess compile works ok since most ides just call gradle
  77. dreamrealWhy would it matter?
  78. deebowe try to avoid drive-by formatting/etc changes, it would balloon every change in review
  79. dreamrealI 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
  80. dreamrealthey'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.
  81. dreamrealThat INITIAL commit would be a chonker. After that, nothing.
  82. deeboyeah that would really annoyingly break blames for a while
  83. deebobut have to see what kind of changes it would make
  84. dreamrealSo 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.
  85. dreamrealYes, it would annoyingly break blames for a while.
  86. dreamrealWhich 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.
  87. dreamreallike I said, our environment has a certain conservatism in play.
  88. deebocould maybe sneak it in with spring boot 4 upgrades
  89. dreamrealYou can, BTW, set formatting for spotless; if you have IDE formatting your team likes, you can get spotless to mirror it.
  90. dreamrealThat may help with the blame problem, and also gives you a way to change formatting incrementally should you desire that.
  91. dreamrealdmlloyd: https://bytecode.news/posts/2026/04/methodhandles-why-you-actually-care
  92. dmlloydnice!
  93. deebois spotless + google style for example forcing a specific formatting? or does it "allow" or "deny" a formatting for something?
  94. dmlloydnice writeup, thanks
  95. dreamrealPLEASE sanity-check it for me, dmlloyd
  96. dreamrealI tried to do well, but you're the expert here
  97. dmlloydI did, it looks good
  98. dreamrealdeebo: you can apply it or validate it
  99. dreamrealdmlloyd: *nod* thank you
  100. dreamrealand well done on your part
  101. deebobut with a valid java input formatted in multiple random ways, the output is always the same?
  102. dmlloydthanks. with that kind of motivation, maybe I'll only wait 16 months for the next one
  103. dreamrealdeebo: if you *apply* spotless, it will generate consistent output, yes
  104. dreamrealdmlloyd: I tried to explain what your purpose was in writing without being judgemental about it
  105. dmlloydyeah that bit was fine
  106. dmlloydhonestly I feel a bit nihilistic when it comes to my blog so it's a lot more than I expected lol
  107. dreamrealmy biggest concern there is that I don't want to be projecting AND BCN doesn't criticize if it can help it, ever
  108. dreamrealif something's worth damning I'd rather just not write about it
  109. [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
  110. dreamreal[twisti]++
  111. nevet[twisti] now has karma of 2.
  112. Square3I'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.
  113. Square3By "converted" I mean A is inferred by a method reference to a no-arg method `anInstance::noArgMethod`
  114. dreamrealI'd want to see an actual test case
  115. Square3I'll see if I can produce one. Worrisome thing is that seems a bit random.
  116. dreamreal~jep 534
  117. javabot'JEP 534: Compact Object Headers by Default' can be found at http://openjdk.java.net/jeps/534
  118. nevetJEP 534: Compact Object Headers by Default
  119. dmlloydshrunken heads?
  120. DoofusCanadensis*snrk*