Chat Logs

  1. * Munnu joined #java
  2. * CodeGeek!~codegeek@about/java/CodeGeek changed the topic to: Welcome! || Read Channel Rules at https://javachannel.org/ before participating. || Paste limit is two lines; ~pastebin lists options. || No applets, please. || Minecraft, Android, and Javascript all have their own channel. || You are being logged.
  3. * nevet joined #java
  4. * jjj333_p joined #java
  5. * mitch0 joined #java
  6. * Aedil joined #java
  7. NeXeNreflection is so slow in static analysis
  8. jreicherHuh? Isn't that a contradiction?
  9. * mlxdy joined #java
  10. NeXeNi mean with graal
  11. NeXeNif you don't pre-configure it you know
  12. NeXeNanyways i'm just complaining
  13. NeXeNso what's up, what are you working on, jreicher?
  14. * Nitrousoxide_ joined #java
  15. jreicherNothing in Java at the moment unfortunately. Been hit with a lot of new compliance rules for kubernetes deployments, so I'm grappling with helm charts and pipelines written by other people. :(
  16. NeXeNfun fun fun under the gun
  17. deeboi loathe helm charts, they're basically "%s %s %s %s %s %s %s".formatted(service,deployment,ingress,...) in yaml format, it's terrible imo :)
  18. deeboi always end up just writing out a simple multi document yaml file, no idea why kubectls kustomize didn't "take off", much easier to read and understand than helm
  19. jreicherI've never put together a deployment from scratch so I've never had the chance to step back and make this kind of choice myself. I always end up with what other people have chosen.
  20. * lostlazy_ joined #java
  21. * tomboy64 joined #java
  22. * akaWolf joined #java
  23. * metalmaniac joined #java
  24. * stewi joined #java
  25. NeXeNjreicher: that is sometimes the truth
  26. nimajehm, "simple" and "yaml", seems like a contradiction
  27. NeXeNyaml is simple. simple is sometimes stupid
  28. NeXeNremember kiss, keep it simple or stupid
  29. * Afroboy joined #java
  30. * kathadris joined #java
  31. * graves joined #java
  32. * MikeBux joined #java
  33. * jbosmans joined #java
  34. * Ragnor joined #java
  35. * hwpplayer1 joined #java
  36. hwpplayer1What are the differences between 17 and 21 Java ?
  37. deeboabout 4
  38. hwpplayer1Any backward compatibilities ?
  39. deeboand 25 is current "lts", so moving to 21 is a weird sidestep
  40. hwpplayer1Okay thanks
  41. deeboplenty of feature lists on the interwebs (and youtube if you're into that), don't think backwards compatibility has ever been an issue really
  42. hwpplayer1I see
  43. * jbosmans joined #java
  44. * stfstfm_ joined #java
  45. BombeWhen we recently switched from 11 to 21, we did have to fix a small number of source files.
  46. dreamrealhttps://bytecode.news/posts/2026/04/openjdk-says-structured-concurrency-now-writed-in-python
  47. hwpplayer1I gotta go thanks
  48. * agnivn joined #java
  49. * waznot joined #java
  50. Bombe“Writed?”
  51. BombeI mean, it would fit the topic… :D
  52. * dreamreal shrugs
  53. dreamrealRemember who the author is... single-layer jokes are a lot less funny than 12-layers. :D
  54. dreamrealI thought about having an AI literally write it, and I tried that, but it was ungood
  55. deeboemdash enthusiast
  56. ParaIs that a weekly or monthly publication?
  57. * sa02irc joined #java
  58. dreamrealwhat, bytecode.news?
  59. dreamrealdeebo: damn it
  60. dreamrealdeebo: that would have been perfect, to have Hanz Franz have a comment in monotype, with em-dashes and a very neutral, formal tone, finalizing with "... did I do it right, Human?"
  61. * Square2 joined #java
  62. * virtualmeat joined #java
  63. * akaWolf joined #java
  64. * akaWolf joined #java
  65. * Inline joined #java
  66. * Pixi joined #java
  67. * domicron joined #java
  68. dreamrealBTW, the stuff that goes on bytecode.news is the stuff I'd like to have seen the java channel blog get, or theserverside.com back in the day: it's not purely java focused because pure java isn't that interesting, we live in a wider ecosystem, but it's got a core focus on the JVM
  69. dreamrealand if you want to contribute, well, *that's the point* - and it has an editorial oversight so you're not just posting stuff without trying to make it look good
  70. * jamezp joined #java
  71. * domicron joined #java
  72. * metalmaniac joined #java
  73. mitch0dreamreal: nit on the fonts: it's kinda hard to read (at least on mobile)
  74. mitch0(probably it's just me getting old though)
  75. * kcomhnall joined #java
  76. dreamrealthe serifs are a problem? kinabalu says he's going to address the mobile rendering at some point
  77. dreamrealI didn't design the UI - the UI *I* put together is... uh... not exactly normal-human friendly
  78. * akaWolf joined #java
  79. mitch0I bet it would suit me just fine :) (I mean, your UI version)
  80. dreamrealI doubt it, I don't really see information the same way others do
  81. dreamrealIf MY innate UI would suit you, that's concerning :D
  82. dreamrealI probably need to revise it, though: the nextjs UI has advanced some things that the original reference UI hasn't kept up with
  83. * akaWolf joined #java
  84. dreamrealActually, that's an interesting tech problem: I need to have a way to capture the way the "real UI" works at the transport level so the other UIs have "endpoints" to work against to validate their behavior
  85. dreamrealor I could burn down the reference UI and have it literally be a reference UI (the whole goal was to say "this is not usable but does exercise the API properly")
  86. * akaWolf joined #java
  87. * tronexte joined #java
  88. Square2Aiui, you can put several spring boot app war's in an ear and deploy it?
  89. Square2(wo using ejb in those wars?)
  90. Square2...don't ask me why I wanna do that. Some managers seem to love the idea with "one installation".
  91. dreamrealSquare2: are you asking if you can do that?
  92. dreamrealI don't know what "aiui" means
  93. DoofusCanadensisaiui == As I Understand It
  94. dreamrealah
  95. dreamrealSquare2: in that case, yes.
  96. Square2dreamreal, thanks
  97. dreamrealSquare2: it's actually spring's original raison d'etre, which makes your question kinda funny
  98. Square2dreamreal, oh, I didn't know. I though .ear's fell out of fashion after ejb 2.1.
  99. dreamrealthey're still in fashion, just very different from the 1.x-2.x cycle
  100. dreamreallargely influenced by... spring
  101. Square2Oh ok. I though people solved these multi-deploys with k3s/k8s these days
  102. Square2thought
  103. dreamreal"these days" isn't really everything. You can do that, but even so: Spring's *original deployment model* was indeed multiple wars in an app server, multiple wars in an .ear was fully acceptable, with no EJBs in sight. In 2004, at the TSSJS in Las Vegas, Floyd asked the audience how many people used EJBs: they were EVERYWHERE. Then he asked how many of them used them to invoke processes *remotely* -
  104. dreamreallike, EJB deployed on server A, used from a WAR on server B - and it was like 2% of the audience.
  105. dreamrealTHAT's what Spring fixed, because that entire audience was using a *remote technology* for *local invocation* and paying a cost in development time, because ejbc *suuuuuuucked.*
  106. dreamrealApp servers like orion did it well: no ejbc, and it actually *optimized* local invocation even though you had to use remote semantics until EJB2. (On websphere, if you used a *remote interface* then it was going to use the network layer by god.)
  107. Square2dreamreal, oh, you mean inter war dependencies wasn't a big thing?
  108. dreamrealSquare2: inter-WAR dependencies aren't really a thing even now
  109. Square2gotcha! Intersting to hear.
  110. dreamrealinter-WAR dependencies are remote HTTP calls. Network dependencies were what the EJB was for. You have a service here, you want to invoke it from THERE, you use RMI-IIOP to invoke it and get good semantics around it.
  111. cheeserthe good old days
  112. Square2when I say inter-war dependencies I meant any dependency... even http (local) remoting etc.
  113. dreamrealwell... there's a lot of room for definition there. The thing is, the resources in war1 are NOT available to war2 - they don't share classpath resources. They're peers. an EJB *is* in their classpath.
  114. * Inline joined #java
  115. * agnivn joined #java
  116. * agnivn_ joined #java
  117. * Shell joined #java
  118. * michele joined #java
  119. Parafwiw I'm fairly sure Kubernetes didn't solve any actual problem, but it's good enough that it was okay to let the management believe it solves enough issues to become a standard.
  120. * matrixisme2 joined #java
  121. * michele joined #java
  122. * B_fd joined #java
  123. * matrixisme2 joined #java
  124. * mindCrime joined #java
  125. * Inline joined #java
  126. * leppard joined #java
  127. * stfstfm joined #java
  128. * Betal joined #java
  129. * B_fd joined #java
  130. * hwpplayer1 joined #java
  131. * Inline joined #java
  132. jbosmanswell, April 1st about over and done with here, so far so good :)
  133. dreamrealWe still have eight hours, you fool!
  134. jbosmanstimezones, you fool !
  135. dreamrealmine is the only one that matters
  136. jbosmans;)
  137. * kcomhnall joined #java
  138. jbosmanswhile i joke about timezones, it did bite me during upgrades. fwiw i ended up doing;
  139. jbosmansmount /etc/timezone into container
  140. dreamrealhaha
  141. * kcomhnal1 joined #java
  142. jbosmansmount etc/localtime into container
  143. jbosmanspass -Duser.timezone=Europe/Brussels to java
  144. jbosmansi think the latter is most impactfull, but as always ymmv
  145. jbosmanswho knew time(stamps) mattered
  146. * metalmaniac joined #java
  147. * kathadris joined #java
  148. * domicron joined #java
  149. * Square2 joined #java
  150. * B_fd joined #java
  151. * Everything joined #java
  152. * waznot joined #java
  153. * waz_ joined #java
  154. * metalmaniac joined #java