Chat Logs

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