ByteCode.News
Submit RSS Atom Sign in

Back to the channels

#java

  1. * kcomhnall joined #java
  2. * Tenchi joined #java
  3. * kcomhnall joined #java
  4. NeXeN arrg 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. Swayze nice catch jreicher
  15. Swayze i believe they are moving towards langauge server still :p
  16. Swayze seems only for non-java languages
  17. Swayze their solution is considered superior if you believe the hype
  18. * hwpplayer1 joined #java
  19. * acidjnk joined #java
  20. * roomyk joined #java
  21. jreicher Swayze: I do keep hearing that jetbrains is still better than the Eclipse jdtls, but I'm very happy with jdtls.
  22. Bombe Urgh, how do I test a component that gets handed in a Socket and then parses stuff out of it?
  23. Bombe The 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. Swayze mock it till you make it
  30. Swayze never let anything stop you, mock the universe if you must
  31. Swayze the show must go on
  32. Swayze o7
  33. Swayze anyway the odds are about 100% that we're in a simulation anyway
  34. dreamreal you okay, Swayze ?
  35. dreamreal It 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. Bombe Swayze, I did, at first, but that’s even more horrible.
  38. * Guest2439 joined #java
  39. fizzie I 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. Bombe That sounds pretty much exactly like what I need, I think.
  41. cheeser dreamreal: 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. dreamreal cheeser++
  43. nevet cheeser now has karma of 3.
  44. dreamreal I 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. cheeser yup
  46. dreamreal I 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. dreamreal I don't ignore spelllcheck!
  49. * GreenResponse joined #java
  50. dreamreal It'd be interesting to see an actual ethical survey of gamers/programmers
  51. dreamreal like, "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. jreicher I 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. dreamreal Hell, 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. dreamreal https://bytecode.news/posts/2026/05/the-barrier-for-entry
  66. dreamreal dmlloyd: damn it
  67. * dmlloyd damns it
  68. dreamreal about damn time
  69. dreamreal you're making me mad, dude
  70. dmlloyd well, that is my single and solitary goal in life, so I guess I'm rocking it
  71. dreamreal indeed
  72. * dreamreal is having to write code that dmlloyd should have written
  73. dreamreal ... because he's a JERKFACE
  74. dreamreal an absolute UNIT of a jerkface
  75. dreamreal FAAAAAAAACE
  76. dmlloyd well, I probably already wrote it, you just can't find it
  77. dreamreal That'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. dreamreal I'm having to write a lot of crap I don't want to have to write
  80. dreamreal and you're llikely to be better at it than I am, and this makes me unhappy
  81. dmlloyd have you looked at github.com/dmlloyd/lot_of_crap ?
  82. dreamreal not only are you frustrating me, you're cruel. What did I ever do to you?
  83. dmlloyd where to begin... well for one thing you *never* get to the point
  84. dreamreal I'm burying the lede like you do, you should be familiar with it, jerkface
  85. dreamreal you dropped "offheap access" in varhandles and LEFT IT THERE
  86. dmlloyd I have no idea what you're talking about (hides shovel behind back)
  87. dreamreal I'm writing up an example that YOU should have written
  88. dmlloyd ah, well, that's more of an FFM thing than a varhandles thing IMO
  89. dreamreal to some degree but it was BY FAR the thing that stood out most to me
  90. dmlloyd and FFM would merit an entire article just by itself, well a book really
  91. dreamreal I was going OOOOOOOOO HELL TO THE HECK YES!!!!!! and... nothing
  92. dreamreal DM?
  93. dmlloyd go for it
  94. dreamreal I get that, and you're not wrong, but daaaaang
  95. dmlloyd note that varhandles can also wrap buffers so it's not *just* FFM stuff, which is the lede buried underneath the other lede
  96. nb-ben dreamreal: claude did do what you wrote
  97. nb-ben dreamreal: 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-ben so 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. cheeser hey dmlloyd. your classlib backport, does it use the same package structure or do you namespace it away?
  101. dmlloyd I 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. dmlloyd cheeser, 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. cheeser i'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-ben my 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. dmlloyd if 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-ben it puts the reviewer at the bottom of the food chain pretty much
  109. nb-ben because people can relay the review to claude
  110. dmlloyd yes but a reviewer can also reject large patches outright, and tell the junior to start over but take much smaller bites instead
  111. cheeser we use the shit out of claude but all the reviews require human signoff.
  112. nb-ben so kinda creates an inverse incentive there
  113. dmlloyd because the cost of throwing away and starting over is negligible compared to with humans
  114. nb-ben cheeser: 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. dmlloyd the goal is to get to the point where the human and the AI work together at the same level of capability
  116. dmlloyd if the junior is a beginner, then they should only be doing beginner things with claude
  117. nb-ben if excusing for claude mistakes becomes acceptable then the signoff is meaningless
  118. dmlloyd I 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-ben yeah 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-ben I'm just noticing the pressures it creates, and changes to incentives
  121. dmlloyd yeah 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. dmlloyd my 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-ben dmlloyd: even not like this, like, as a committer, I can keep relaying what the reviewer tells me
  125. nb-ben wants smaller PRs, I can tell claude to do that. No effort on my part, effort is on reviewer
  126. dmlloyd I think using claude as a reviewer is not a good idea
  127. nb-ben that's how I feel when I review these commits.
  128. * mindCrime joined #java
  129. nb-ben no not what I mean. I mean, I review a PR, and the person just sends my comments to claude
  130. nb-ben maybe very minimal additional work is done by them but most of the work is mine
  131. dmlloyd ah yeah. when that happens on our (OSS) projects, I tend to think "wow, thanks for the free tokens" :)
  132. Para nb-ben: you need to get into an environment where a person would get sued if they did that
  133. nb-ben heh. 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-ben Para: lol, what kind of environment is that
  136. Para Gov't
  137. nb-ben Para: what are you working on?
  138. Para I'll
  139. Para Gov't
  140. Para :)
  141. Para I can say that it's actually nothing exciting, but it is Stuff.
  142. * emaczen joined #java
  143. dreamreal Okay, hoseheads: written in pure fury. https://bytecode.news/posts/2026/05/david-m-lloyd-varhandle-fundamentals
  144. dmlloyd putting the "dam" in "fundamentals"
  145. dreamreal better than just being mental, I guess
  146. nb-ben Para: 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. dreamreal I wonder how many people here work in secure-ish environments
  148. Para nb-ben: Not military. Not intelligence. Over here we have this https://en.wikipedia.org/wiki/Total_defence
  149. nevet Total defence - Wikipedia
  150. nb-ben ic
  151. Para I'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. dreamreal now propagate that link, autobots (mine, not anyone else's)
  155. dreamreal dmlloyd: seriously, though, you know an editor IRL, you should consider asking him for a once-over to catch things like that :D
  156. dreamreal at the very least you could have (and should have, IMO) acknowledged the lede
  157. dreamreal I 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. jbosmans dreamreal, 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. dreamreal oh, crap, yeah
  167. dreamreal I don't track EA releases like I should
  168. jbosmans who does !
  169. jbosmans it's not EA i guess
  170. dreamreal well, by that I mean, *I* track LTS and all the others are just curiosities
  171. jbosmans tho graalvm only aligns with LTS apparently
  172. dreamreal I *do* have my own biases
  173. jbosmans who doesn't ;)
  174. cheeser dreamreal: you know an editor IRL, you should consider asking him for a once-over to catch things like that
  175. cheeser dreamreal: dmlloyd can introduce you again if need be
  176. * kathadris joined #java
  177. dreamreal cheeser: I hear that guy's an ass though
  178. cheeser he has his moments.
  179. cheeser don't we all though?
  180. dreamreal some of us get more than others :D
  181. dreamreal FWIW, 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. dmlloyd ah I didn't even notice that
  184. dreamreal Fixed 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. cheeser we all want that. ;)
  186. * dreamreal sighs
  187. dmlloyd lol
  188. cheeser ~hug dreamreal
  189. * javabot snuggles up to dreamreal and strokes dreamreal's hair affectionately.
  190. dreamreal Well, 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. dreamreal and I get that you may have been speaking in jest and all that, but *I* am serious
  192. cheeser no, 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. jbosmans i have to admin "java champion" is a term i mostly see in presentations/conf sessions from time to time
  196. dreamreal Yeah, 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. jbosmans i always found them "invented for the provider, not the practitioner"
  198. jbosmans yeah
  199. dreamreal Nah, the people who're java champions generally earn it. Maybe not Reza, but most of them deserve the recognition
  200. dmlloyd heh
  201. dreamreal I 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. jbosmans maybe it's just something not-java-champion people (or i) say, i don't want to take away from it at all
  204. jbosmans given i know the term after all, maybe it's a success
  205. dreamreal Well, 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. dreamreal I wouldn't have minded getting turned down but Kirk Pepperdine said the vote was close... and failed because of the journalist thing
  207. jbosmans it's been around a while afaik
  208. jbosmans i guess since oracle
  209. dreamreal it has, yes
  210. dreamreal since before
  211. dmlloyd I 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. jbosmans oh didn't know
  213. dreamreal dmlloyd: oh my. Really?
  214. dmlloyd assuming anyone will hire him
  215. dreamreal oof
  216. jbosmans i remember iirc martijn verburgh saying
  217. dreamreal That sounds like my sparkling opinion of him might be less unique than I thought
  218. dmlloyd he can just feed all his nonsense to AI and let it sort it all out
  219. jbosmans those 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. dreamreal jbosmans: well... that may be true, but I can name a few people at conferences who *absolutely* are worth paying attention to
  221. jbosmans of course :)
  222. cheeser "close" meant 1 vote at the time because that's all it took then
  223. dreamreal I don't do the conference circuit and can't enjoy such things, but I know a lot of the names
  224. dreamreal cheeser: Kirk said it was like 48%-52%
  225. dmlloyd I believe the original quote is "those who can, do; those who *understand*, teach"
  226. dreamreal I don't know, I was never on the inside of it
  227. dmlloyd which isn't as fun
  228. cheeser i'm not sure how works out since it only took one negative vote then
  229. dreamreal Oh, my. Ouch.
  230. jbosmans at 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. dreamreal Josh Long said he'd endorse me submitting again, but *I* would have submit myself, and I have a really hard time doing that
  232. jbosmans oh yeah, people tend to pay for confs as well so, win/win/win :)
  233. dreamreal jbosmans: if you get a chance to hear Holly Cummins, 100% worth it
  234. jbosmans never heard of a holly cummins, but i'm most probably not a good ref :)
  235. dmlloyd she co-hosts the quarkus insights podcast series almost every week
  236. jbosmans didn't know ^
  237. jbosmans she's on the dev team and/or .. ?
  238. dreamreal and a FANTASTIC speaker *and* a Good Human *and* smart as hell
  239. cheeser adjacent to the team
  240. dmlloyd yeah she's on the quarkus dev team
  241. dreamreal That's her one flaw! :D
  242. dmlloyd in fact that team has a number of really awesome people on it
  243. dmlloyd lol
  244. * MikeBux joined #java
  245. dreamreal dmlloyd: you know if quarkus is planning on adding EAI?
  246. cheeser how 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. dmlloyd you mean like camel and whatnot?
  248. dmlloyd I'm not sure, but I think something exists in that space
  249. cheeser quarkus-camel is a thing last I checked.
  250. jbosmans i 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. Para I don't need to think Maven.
  252. Para Which makes it a winner, as I only have what, 14 Watts to spare.
  253. jbosmans i just think Less Is More
  254. jbosmans i may have been influenced by grunt vs gulp in js world
  255. jbosmans (i was using maven long before then)
  256. jbosmans gulp (iirc) was like, hey just write your build scripts in js!
  257. jbosmans the joy
  258. dreamreal Gradle's declarative, they just have different intentions than maven does
  259. cheeser declaratively shit
  260. jbosmans as in, a running daemon?
  261. dreamreal well, the dev team for gradle has... different priorities than their userbase thinks they should, by and large :D
  262. dreamreal they emphasize features and churn over, like, stability and predictability
  263. cheeser i 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. jbosmans for a few years it was all one could hear about @ gradle
  266. jbosmans "years long since passed"
  267. dreamreal if you're not locking gradle version you're insane
  268. dreamreal and that's actually why I stopped using gradle in my books
  269. dreamreal I 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. jbosmans fun thing is
  272. jbosmans gradle wrapper -> maven wrapper
  273. jbosmans sure
  274. dreamreal One 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. jbosmans let's just make the build system work "automagically"
  276. jbosmans you're writing code, but can't invoke a command
  277. dreamreal Easy 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. jbosmans dreamreal, it's not about that
  280. jbosmans it's about controlling the version used
  281. dreamreal wait, what is about ... what
  282. jbosmans i don't want some project to define the build tool
  283. jbosmans *ever*
  284. dreamreal sure, 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. jbosmans sure
  287. jbosmans for playground stuff
  288. dreamreal you're not dependent on some shlub having NOT updated to gradle 14
  289. dreamreal I can't afford to hope that nobody updated gradle at work
  290. dreamreal so at work: we lock in. We have a build that works; any change had better be justified.
  291. jbosmans :s
  292. jbosmans hopefully microservices then?
  293. dreamreal With 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. dreamreal and the dev team's response to that is usually *shrug*
  295. jbosmans oh sorry, i was only talking about maven
  296. jbosmans imho everything cross company should compile && keep working with reasonable "recent" version of maven
  297. jbosmans not something "project defined"
  298. dreamreal Well, I can see wanting maven to have compatibility, too, esp if mvnd is in the mix.
  299. dreamreal but sure.
  300. dreamreal ... in my books, I don't worry about locking maven versions. :D
  301. cheeser i've found those daemons more impediment than aid.
  302. dreamreal How so?
  303. dreamreal (I'm curious what edges you've found: I've certainly found some myself.)
  304. cheeser cache corruption, more often than not.
  305. jbosmans i only invoke maven directly for deployment builds, other stuff => intellij compilation (mostly)
  306. dreamreal For me it's been resource usage: with testcontainers it can get *interesting*
  307. jbosmans hah cache corruptions would be a pain i figure :)
  308. cheeser guess what just happened again?
  309. * dreamreal had to delete his first response
  310. dreamreal let me guess: cache corruption with mvnd?
  311. cheeser i wish we used maven here...
  312. jbosmans does it save a lot overall?
  313. jbosmans oh right, sorry, gradle
  314. dreamreal oh, you're getting that with GRADLE?
  315. dreamreal Haha! Which version?
  316. jbosmans i'd hope "just always full clean && rebuild" would fix it
  317. jbosmans well, && localinstall i guess
  318. cheeser dreamreal: yes and yes
  319. * johnjay joined #java
  320. * Ragnor joined #java
  321. * ztevoz joined #java
  322. * redj joined #java
  323. * luca0N joined #java