Chat Logs

  1. * kcomhnall joined #java
  2. * Tenchi joined #java
  3. * kcomhnall joined #java
  4. NeXeNarrg i forgot needed -Pproduction for vaadin
  5. * sa02irc joined #java
  6. * ferdna joined #java
  7. * Aedil joined #java
  8. * stfstfm joined #java
  9. * stfstfm joined #java
  10. * rvalue joined #java
  11. * ChaiTRex joined #java
  12. * ChaiTRex joined #java
  13. * skum joined #java
  14. Swayzenice catch jreicher
  15. Swayzei believe they are moving towards langauge server still :p
  16. Swayzeseems only for non-java languages
  17. Swayzetheir solution is considered superior if you believe the hype
  18. * hwpplayer1 joined #java
  19. * acidjnk joined #java
  20. * roomyk joined #java
  21. jreicherSwayze: I do keep hearing that jetbrains is still better than the Eclipse jdtls, but I'm very happy with jdtls.
  22. BombeUrgh, how do I test a component that gets handed in a Socket and then parses stuff out of it?
  23. BombeThe parser reads until the stream is EOF, but I can’t close the stream/socket in the test, because then I can’t read any replies out of it anymore.
  24. * jwisbell35 joined #java
  25. * MikeBux joined #java
  26. * Aedil joined #java
  27. * leppard joined #java
  28. * leppard|2 joined #java
  29. Swayzemock it till you make it
  30. Swayzenever let anything stop you, mock the universe if you must
  31. Swayzethe show must go on
  32. Swayzeo7
  33. Swayzeanyway the odds are about 100% that we're in a simulation anyway
  34. dreamrealyou okay, Swayze ?
  35. dreamrealIt doesn't matter if we're in a simulation - we'd still have our parts to play in it even so
  36. dreamreal(This is, incidentally, why I tend to act according to my own ethics even in games - in skyrim I'm a "good guy," such as there can be, and Baldur's Gate 3 fails to interest me because it's a game designed to make you a "bad guy" and I don't enjoy that. If we're in a simulation, so are they: my ethics remain and define me. Silly, I know.)
  37. BombeSwayze, I did, at first, but that’s even more horrible.
  38. * Guest2439 joined #java
  39. fizzieI might be missing something here, but it seems to me you could just use a real pair of sockets, and .shutdownOutput() one end to indicate an EOF of input to the other, while still continuing to read any data sent as a reply from it.
  40. BombeThat sounds pretty much exactly like what I need, I think.
  41. cheeserdreamreal: i take in game ethics, and indeed interactions with claude, as another chance to practice the kind of person i want to be however oblivious the target of my attention may be.
  42. dreamrealcheeser++
  43. nevetcheeser now has karma of 3.
  44. dreamrealI figure being a decent person is a habit, so I tell the LLMs "thank you" and say "please" and whatnot because that's the habit I want to live by, even though the object is, as you say, *completely* oblivious and I'm just using tokens by it
  45. cheeseryup
  46. dreamrealI don't want to be talking to an actual human and accidentally be brusque because it's a topic I might be discussing with an LLM or whatever. I can be brusque, of course, but it's a choice, and I live by that. It's situational.
  47. cheeser(these LLMs are really just college interns typing furiously away anyway. just like that spellcheck we all ignore.)
  48. dreamrealI don't ignore spelllcheck!
  49. * GreenResponse joined #java
  50. dreamrealIt'd be interesting to see an actual ethical survey of gamers/programmers
  51. dreamreallike, "what's your actual ethical stance" and "how do you apply this in these contexts" and a few others like that, to find the boundaries
  52. jreicherI bloody love spellcheck. And the first time I ever saw a language server and LSP I thought "oh, they took the ispell idea and ran with it"
  53. * jbosmans joined #java
  54. dreamrealHell, I felt that way about grammar checkers
  55. * kcomhnall joined #java
  56. * ferdna joined #java
  57. * rvalue joined #java
  58. * jreicher joined #java
  59. * MinusSeven_ joined #java
  60. * tabstar joined #java
  61. * jamezp joined #java
  62. * unit86 joined #java
  63. * stfstfm_ joined #java
  64. * stfstfm joined #java
  65. dreamrealhttps://bytecode.news/posts/2026/05/the-barrier-for-entry
  66. dreamrealdmlloyd: damn it
  67. * dmlloyd damns it
  68. dreamrealabout damn time
  69. dreamrealyou're making me mad, dude
  70. dmlloydwell, that is my single and solitary goal in life, so I guess I'm rocking it
  71. dreamrealindeed
  72. * dreamreal is having to write code that dmlloyd should have written
  73. dreamreal... because he's a JERKFACE
  74. dreamrealan absolute UNIT of a jerkface
  75. dreamrealFAAAAAAAACE
  76. dmlloydwell, I probably already wrote it, you just can't find it
  77. dreamrealThat's because you didn't publish it, you just dropped it like a freaking claymore and then focused on a whole lot of other things
  78. dmlloyd<obama voice> that's what I doooo
  79. dreamrealI'm having to write a lot of crap I don't want to have to write
  80. dreamrealand you're llikely to be better at it than I am, and this makes me unhappy
  81. dmlloydhave you looked at github.com/dmlloyd/lot_of_crap ?
  82. dreamrealnot only are you frustrating me, you're cruel. What did I ever do to you?
  83. dmlloydwhere to begin... well for one thing you *never* get to the point
  84. dreamrealI'm burying the lede like you do, you should be familiar with it, jerkface
  85. dreamrealyou dropped "offheap access" in varhandles and LEFT IT THERE
  86. dmlloydI have no idea what you're talking about (hides shovel behind back)
  87. dreamrealI'm writing up an example that YOU should have written
  88. dmlloydah, well, that's more of an FFM thing than a varhandles thing IMO
  89. dreamrealto some degree but it was BY FAR the thing that stood out most to me
  90. dmlloydand FFM would merit an entire article just by itself, well a book really
  91. dreamrealI was going OOOOOOOOO HELL TO THE HECK YES!!!!!! and... nothing
  92. dreamrealDM?
  93. dmlloydgo for it
  94. dreamrealI get that, and you're not wrong, but daaaaang
  95. dmlloydnote that varhandles can also wrap buffers so it's not *just* FFM stuff, which is the lede buried underneath the other lede
  96. nb-bendreamreal: claude did do what you wrote
  97. nb-bendreamreal: I think it also impedes the other end of the range though -- Juniors not really getting a chance to use their mind to simulate at the micro-level as much
  98. * stfstfm_ joined #java
  99. nb-benso because companies will expect juniors to use claude to be more productive, the barrier to entry for gaining skill to do actually depthful work increases as you're no longer paid to do manual work
  100. cheeserhey dmlloyd. your classlib backport, does it use the same package structure or do you namespace it away?
  101. dmlloydI think maybe it just shifts the focus... if the junior has to learn how to break down tasks *before* writing the code instead of *after* messing it up a few times, that's all to the good
  102. dmlloydcheeser, different package. the original is `java.lang.classfile` and the JDK blocks you from using that name in various ways in practice
  103. * cheeser nods.
  104. dmlloyd(incidentally, the project has moved to the SmallRye umbrella)
  105. cheeseri'm thinking of having claude replace all the gizmo stuff with your backport. then I can check for the "real" package at runtime and fall back to yours if need be.
  106. nb-benmy experience is that claude can let a junior seem productive by doing things that almost work for many months in the company, while not really gaining any ownership of anything
  107. dmlloydif a junior is going right from claude to production then you've got a structural issue, same as if you had a clueless yet highly prolific junior; they require the same oversight
  108. nb-benit puts the reviewer at the bottom of the food chain pretty much
  109. nb-benbecause people can relay the review to claude
  110. dmlloydyes but a reviewer can also reject large patches outright, and tell the junior to start over but take much smaller bites instead
  111. cheeserwe use the shit out of claude but all the reviews require human signoff.
  112. nb-benso kinda creates an inverse incentive there
  113. dmlloydbecause the cost of throwing away and starting over is negligible compared to with humans
  114. nb-bencheeser: yeah the signoff is OK if you can't excuse yourself for claude making mistakes. I guess it depends on how strong your organizational culture is
  115. dmlloydthe goal is to get to the point where the human and the AI work together at the same level of capability
  116. dmlloydif the junior is a beginner, then they should only be doing beginner things with claude
  117. nb-benif excusing for claude mistakes becomes acceptable then the signoff is meaningless
  118. dmlloydI can have claude write a complex project for me, because I have the knowledge to know how the code should look; a beginner doesn't have that knowledge so they'd have to start with something very simple else there's no practical expectation that they can review what claude is doing
  119. nb-benyeah no I agree the culture where I'm working right now isn't super great. Company grew from 15 to 50 in less than a year
  120. nb-benI'm just noticing the pressures it creates, and changes to incentives
  121. dmlloydyeah fast-growth overuse of claude fits the silicon valley ethos of low quality/fast delivery so well that I can't see systemic change happening really, not until after a major collapse anyway
  122. dmlloydmy feeling is if a reviewer ever looks at something and thinks "how the hell am I going to review this", they should just reject it
  123. * stfstfm joined #java
  124. nb-bendmlloyd: even not like this, like, as a committer, I can keep relaying what the reviewer tells me
  125. nb-benwants smaller PRs, I can tell claude to do that. No effort on my part, effort is on reviewer
  126. dmlloydI think using claude as a reviewer is not a good idea
  127. nb-benthat's how I feel when I review these commits.
  128. * mindCrime joined #java
  129. nb-benno not what I mean. I mean, I review a PR, and the person just sends my comments to claude
  130. nb-benmaybe very minimal additional work is done by them but most of the work is mine
  131. dmlloydah yeah. when that happens on our (OSS) projects, I tend to think "wow, thanks for the free tokens" :)
  132. Paranb-ben: you need to get into an environment where a person would get sued if they did that
  133. nb-benheh. in a company it's really a big shame. I can't outright accuse somebody because I don't monitor what they are doing
  134. Para(I'm in one, so I'm jesting)
  135. nb-benPara: lol, what kind of environment is that
  136. ParaGov't
  137. nb-benPara: what are you working on?
  138. ParaI'll
  139. ParaGov't
  140. Para:)
  141. ParaI can say that it's actually nothing exciting, but it is Stuff.
  142. * emaczen joined #java
  143. dreamrealOkay, hoseheads: written in pure fury. https://bytecode.news/posts/2026/05/david-m-lloyd-varhandle-fundamentals
  144. dmlloydputting the "dam" in "fundamentals"
  145. dreamrealbetter than just being mental, I guess
  146. nb-benPara: we also work for military / intelligence, we have a connectivity platform for drones and we also make some hardware. The critical bits are in separate libraries from the application, I wrote most of these and they are re-certified every year if there are changes
  147. dreamrealI wonder how many people here work in secure-ish environments
  148. Paranb-ben: Not military. Not intelligence. Over here we have this https://en.wikipedia.org/wiki/Total_defence
  149. nevetTotal defence - Wikipedia
  150. nb-benic
  151. ParaI'd love to explain the whole system but it's too foreign and offest of topics to explain in a channel about Java :)
  152. * stfstfm_ joined #java
  153. * kcomhnall joined #java
  154. dreamrealnow propagate that link, autobots (mine, not anyone else's)
  155. dreamrealdmlloyd: seriously, though, you know an editor IRL, you should consider asking him for a once-over to catch things like that :D
  156. dreamrealat the very least you could have (and should have, IMO) acknowledged the lede
  157. dreamrealI can guarantee you without a shadow of doubt that everyone on MY team would have read that going "Oooo! Is he gonna do the thing? he's gonna do the thing, right?" and you didn't
  158. * stfstfm joined #java
  159. dreamreal(and for the record, i showed some of them the writeup and they were like "oooo right, why didn't he?")
  160. * magla joined #java
  161. * stfstfm_ joined #java
  162. * tomaw_ joined #java
  163. * stfstfm joined #java
  164. * stfstfm_ joined #java
  165. jbosmansdreamreal, 2nd footnote on last link you shared, "sun.misc.Unsafe is probably going away in Java 26" - only some deprecations afaik? Unless i'm confused and 26 didn't get released in March
  166. dreamrealoh, crap, yeah
  167. dreamrealI don't track EA releases like I should
  168. jbosmanswho does !
  169. jbosmansit's not EA i guess
  170. dreamrealwell, by that I mean, *I* track LTS and all the others are just curiosities
  171. jbosmanstho graalvm only aligns with LTS apparently
  172. dreamrealI *do* have my own biases
  173. jbosmanswho doesn't ;)
  174. cheeserdreamreal: you know an editor IRL, you should consider asking him for a once-over to catch things like that
  175. cheeserdreamreal: dmlloyd can introduce you again if need be
  176. * kathadris joined #java
  177. dreamrealcheeser: I hear that guy's an ass though
  178. cheeserhe has his moments.
  179. cheeserdon't we all though?
  180. dreamrealsome of us get more than others :D
  181. dreamrealFWIW, dmlloyd DID get to see the draft of that entire thing as it was published before I posted it, so I blame him!
  182. cheeser*wink* *wink* *nudge* *nudge*
  183. dmlloydah I didn't even notice that
  184. dreamrealFixed now, the power of crowdsourcing. I actually want the ratio of posts made by me on that site to go down - I'm writing more than I'd like to, but it's sort of launching as I go, so that's expected
  185. cheeserwe all want that. ;)
  186. * dreamreal sighs
  187. dmlloydlol
  188. cheeser~hug dreamreal
  189. * javabot snuggles up to dreamreal and strokes dreamreal's hair affectionately.
  190. dreamrealWell, here's the thing: if you think it's actually NOT adding value to the world, tell me so, so i can either fix it or stop adding noise
  191. dreamrealand I get that you may have been speaking in jest and all that, but *I* am serious
  192. cheeserno, it's good, honestly.
  193. nb-ben+1
  194. dreamreal(Sorry, I'm a little sensitive: I'm doing the same thing now that I did at TSS, but my nominations for java champion were turned down because I was "just a journalist" and that still stings: it's fine, but even so, dang, people. I was a programmer first and always.)
  195. jbosmansi have to admin "java champion" is a term i mostly see in presentations/conf sessions from time to time
  196. dreamrealYeah, it's not got a lot of value in and of itself, it's just a sort of recognition by people who've kinda earned some industry rep
  197. jbosmansi always found them "invented for the provider, not the practitioner"
  198. jbosmansyeah
  199. dreamrealNah, the people who're java champions generally earn it. Maybe not Reza, but most of them deserve the recognition
  200. dmlloydheh
  201. dreamrealI don't think I've ever seen "Java Champion" and gone "oh that's why I should pay attention to them" but I've also never gone "Dang, why is HOLLY a java champion"
  202. dreamreal(Sorry, I have a hard time seeing Reza Rahman as a java champion. there's another one whose name escapes me who seems to have become a JC mostly from saying "java sucks and it's irredeemable" just like Reza but ... again, name escapes me.)
  203. jbosmansmaybe it's just something not-java-champion people (or i) say, i don't want to take away from it at all
  204. jbosmansgiven i know the term after all, maybe it's a success
  205. dreamrealWell, yeah, I suppose. I remember when they instituted it, and pretty much everyone who'd gotten it would be someone where you'd go "yep, of course"
  206. dreamrealI wouldn't have minded getting turned down but Kirk Pepperdine said the vote was close... and failed because of the journalist thing
  207. jbosmansit's been around a while afaik
  208. jbosmansi guess since oracle
  209. dreamrealit has, yes
  210. dreamrealsince before
  211. dmlloydI will not say a lot about it here but I will say that AI could be the greatest thing that ever happened to Reza
  212. jbosmansoh didn't know
  213. dreamrealdmlloyd: oh my. Really?
  214. dmlloydassuming anyone will hire him
  215. dreamrealoof
  216. jbosmansi remember iirc martijn verburgh saying
  217. dreamrealThat sounds like my sparkling opinion of him might be less unique than I thought
  218. dmlloydhe can just feed all his nonsense to AI and let it sort it all out
  219. jbosmansthose who can't do teach, those who can't teach write a book, those who can't write a book present at conferences :P
  220. dreamrealjbosmans: well... that may be true, but I can name a few people at conferences who *absolutely* are worth paying attention to
  221. jbosmansof course :)
  222. cheeser"close" meant 1 vote at the time because that's all it took then
  223. dreamrealI don't do the conference circuit and can't enjoy such things, but I know a lot of the names
  224. dreamrealcheeser: Kirk said it was like 48%-52%
  225. dmlloydI believe the original quote is "those who can, do; those who *understand*, teach"
  226. dreamrealI don't know, I was never on the inside of it
  227. dmlloydwhich isn't as fun
  228. cheeseri'm not sure how works out since it only took one negative vote then
  229. dreamrealOh, my. Ouch.
  230. jbosmansat conference it's usually some of the cooks (interesting), some BP's (interesting for vendor), some consultants (still interesting for vendor) and some wild ducks (maybe)
  231. dreamrealJosh Long said he'd endorse me submitting again, but *I* would have submit myself, and I have a really hard time doing that
  232. jbosmansoh yeah, people tend to pay for confs as well so, win/win/win :)
  233. dreamrealjbosmans: if you get a chance to hear Holly Cummins, 100% worth it
  234. jbosmansnever heard of a holly cummins, but i'm most probably not a good ref :)
  235. dmlloydshe co-hosts the quarkus insights podcast series almost every week
  236. jbosmansdidn't know ^
  237. jbosmansshe's on the dev team and/or .. ?
  238. dreamrealand a FANTASTIC speaker *and* a Good Human *and* smart as hell
  239. cheeseradjacent to the team
  240. dmlloydyeah she's on the quarkus dev team
  241. dreamrealThat's her one flaw! :D
  242. dmlloydin fact that team has a number of really awesome people on it
  243. dmlloydlol
  244. * MikeBux joined #java
  245. dreamrealdmlloyd: you know if quarkus is planning on adding EAI?
  246. cheeserhow badly does gradle suck? it's complaining about gradle 10 (eventual!) incompabilities in a plugin the build is using that I can do nothing about.
  247. dmlloydyou mean like camel and whatnot?
  248. dmlloydI'm not sure, but I think something exists in that space
  249. cheeserquarkus-camel is a thing last I checked.
  250. jbosmansi never did get further into "thinking in gradle" than i ever got into "thinking in maven", but at least maven is declarative (and yeah it doesn't bother me that it's XML)
  251. ParaI don't need to think Maven.
  252. ParaWhich makes it a winner, as I only have what, 14 Watts to spare.
  253. jbosmansi just think Less Is More
  254. jbosmansi may have been influenced by grunt vs gulp in js world
  255. jbosmans(i was using maven long before then)
  256. jbosmansgulp (iirc) was like, hey just write your build scripts in js!
  257. jbosmansthe joy
  258. dreamrealGradle's declarative, they just have different intentions than maven does
  259. cheeserdeclaratively shit
  260. jbosmansas in, a running daemon?
  261. dreamrealwell, the dev team for gradle has... different priorities than their userbase thinks they should, by and large :D
  262. dreamrealthey emphasize features and churn over, like, stability and predictability
  263. cheeseri disabled that shit, too. i was fighting a spotless failure today with "MISSING_LINE" in the error message. source looked fine. clean, apply. same error. rm -r .gradle. worked.
  264. cheeser╭∩╮(︶︿︶)╭∩╮ gradle
  265. jbosmansfor a few years it was all one could hear about @ gradle
  266. jbosmans"years long since passed"
  267. dreamrealif you're not locking gradle version you're insane
  268. dreamrealand that's actually why I stopped using gradle in my books
  269. dreamrealI was thinking "how do I explain why I locked in an old version of gradle without sounding like I'm telling some kids to stay off my lawn"
  270. * mwnaylor joined #java
  271. jbosmansfun thing is
  272. jbosmansgradle wrapper -> maven wrapper
  273. jbosmanssure
  274. dreamrealOne of the spring books' prior revs was on gradle 5, and getting it to work in gradle... 8 was basically a rewrite, and nope
  275. jbosmanslet's just make the build system work "automagically"
  276. jbosmansyou're writing code, but can't invoke a command
  277. dreamrealEasy enough to do but if you can't run a simple build with a modern version of the build tool, that's a flaw
  278. jbosmans? -> $$$$
  279. jbosmansdreamreal, it's not about that
  280. jbosmansit's about controlling the version used
  281. dreamrealwait, what is about ... what
  282. jbosmansi don't want some project to define the build tool
  283. jbosmans*ever*
  284. dreamrealsure, but if your build requires the build tool to work a specific way, the wrappers and locking in versions are how that happens
  285. jbosmans(nor a bunch of other things)
  286. jbosmanssure
  287. jbosmansfor playground stuff
  288. dreamrealyou're not dependent on some shlub having NOT updated to gradle 14
  289. dreamrealI can't afford to hope that nobody updated gradle at work
  290. dreamrealso at work: we lock in. We have a build that works; any change had better be justified.
  291. jbosmans:s
  292. jbosmanshopefully microservices then?
  293. dreamrealWith maven, there's a lot of protection against that, socially speaking: maven doesn't LIKE breaking things. So it's a little less important there. But for gradle... hell, they break thing in MINOR releases.
  294. dreamrealand the dev team's response to that is usually *shrug*
  295. jbosmansoh sorry, i was only talking about maven
  296. jbosmansimho everything cross company should compile && keep working with reasonable "recent" version of maven
  297. jbosmansnot something "project defined"
  298. dreamrealWell, I can see wanting maven to have compatibility, too, esp if mvnd is in the mix.
  299. dreamrealbut sure.
  300. dreamreal... in my books, I don't worry about locking maven versions. :D
  301. cheeseri've found those daemons more impediment than aid.
  302. dreamrealHow so?
  303. dreamreal(I'm curious what edges you've found: I've certainly found some myself.)
  304. cheesercache corruption, more often than not.
  305. jbosmansi only invoke maven directly for deployment builds, other stuff => intellij compilation (mostly)
  306. dreamrealFor me it's been resource usage: with testcontainers it can get *interesting*
  307. jbosmanshah cache corruptions would be a pain i figure :)
  308. cheeserguess what just happened again?
  309. * dreamreal had to delete his first response
  310. dreamreallet me guess: cache corruption with mvnd?
  311. cheeseri wish we used maven here...
  312. jbosmansdoes it save a lot overall?
  313. jbosmansoh right, sorry, gradle
  314. dreamrealoh, you're getting that with GRADLE?
  315. dreamrealHaha! Which version?
  316. jbosmansi'd hope "just always full clean && rebuild" would fix it
  317. jbosmanswell, && localinstall i guess
  318. cheeserdreamreal: yes and yes
  319. * johnjay joined #java
  320. * Ragnor joined #java
  321. * ztevoz joined #java
  322. * redj joined #java
  323. * luca0N joined #java