Chat Logs

  1. NeXeNreflection is so slow in static analysis
  2. jreicherHuh? Isn't that a contradiction?
  3. NeXeNi mean with graal
  4. NeXeNif you don't pre-configure it you know
  5. NeXeNanyways i'm just complaining
  6. NeXeNso what's up, what are you working on, jreicher?
  7. 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. :(
  8. NeXeNfun fun fun under the gun
  9. 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 :)
  10. 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
  11. 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.
  12. NeXeNjreicher: that is sometimes the truth
  13. nimajehm, "simple" and "yaml", seems like a contradiction
  14. NeXeNyaml is simple. simple is sometimes stupid
  15. NeXeNremember kiss, keep it simple or stupid
  16. hwpplayer1What are the differences between 17 and 21 Java ?
  17. deeboabout 4
  18. hwpplayer1Any backward compatibilities ?
  19. deeboand 25 is current "lts", so moving to 21 is a weird sidestep
  20. hwpplayer1Okay thanks
  21. 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
  22. hwpplayer1I see
  23. BombeWhen we recently switched from 11 to 21, we did have to fix a small number of source files.
  24. dreamrealhttps://bytecode.news/posts/2026/04/openjdk-says-structured-concurrency-now-writed-in-python
  25. hwpplayer1I gotta go thanks
  26. Bombe“Writed?”
  27. BombeI mean, it would fit the topic… :D
  28. * dreamreal shrugs
  29. dreamrealRemember who the author is... single-layer jokes are a lot less funny than 12-layers. :D
  30. dreamrealI thought about having an AI literally write it, and I tried that, but it was ungood
  31. deeboemdash enthusiast
  32. ParaIs that a weekly or monthly publication?
  33. dreamrealwhat, bytecode.news?
  34. dreamrealdeebo: damn it
  35. 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?"
  36. 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
  37. 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
  38. mitch0dreamreal: nit on the fonts: it's kinda hard to read (at least on mobile)
  39. mitch0(probably it's just me getting old though)
  40. dreamrealthe serifs are a problem? kinabalu says he's going to address the mobile rendering at some point
  41. dreamrealI didn't design the UI - the UI *I* put together is... uh... not exactly normal-human friendly
  42. mitch0I bet it would suit me just fine :) (I mean, your UI version)
  43. dreamrealI doubt it, I don't really see information the same way others do
  44. dreamrealIf MY innate UI would suit you, that's concerning :D
  45. dreamrealI probably need to revise it, though: the nextjs UI has advanced some things that the original reference UI hasn't kept up with
  46. 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
  47. 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")
  48. Square2Aiui, you can put several spring boot app war's in an ear and deploy it?
  49. Square2(wo using ejb in those wars?)
  50. Square2...don't ask me why I wanna do that. Some managers seem to love the idea with "one installation".
  51. dreamrealSquare2: are you asking if you can do that?
  52. dreamrealI don't know what "aiui" means
  53. DoofusCanadensisaiui == As I Understand It
  54. dreamrealah
  55. dreamrealSquare2: in that case, yes.
  56. Square2dreamreal, thanks
  57. dreamrealSquare2: it's actually spring's original raison d'etre, which makes your question kinda funny
  58. Square2dreamreal, oh, I didn't know. I though .ear's fell out of fashion after ejb 2.1.
  59. dreamrealthey're still in fashion, just very different from the 1.x-2.x cycle
  60. dreamreallargely influenced by... spring
  61. Square2Oh ok. I though people solved these multi-deploys with k3s/k8s these days
  62. Square2thought
  63. 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* -
  64. dreamreallike, EJB deployed on server A, used from a WAR on server B - and it was like 2% of the audience.
  65. 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.*
  66. 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.)
  67. Square2dreamreal, oh, you mean inter war dependencies wasn't a big thing?
  68. dreamrealSquare2: inter-WAR dependencies aren't really a thing even now
  69. Square2gotcha! Intersting to hear.
  70. 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.
  71. cheeserthe good old days
  72. Square2when I say inter-war dependencies I meant any dependency... even http (local) remoting etc.
  73. 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.
  74. 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.
  75. jbosmanswell, April 1st about over and done with here, so far so good :)
  76. dreamrealWe still have eight hours, you fool!
  77. jbosmanstimezones, you fool !
  78. dreamrealmine is the only one that matters
  79. jbosmans;)
  80. jbosmanswhile i joke about timezones, it did bite me during upgrades. fwiw i ended up doing;
  81. jbosmansmount /etc/timezone into container
  82. dreamrealhaha
  83. jbosmansmount etc/localtime into container
  84. jbosmanspass -Duser.timezone=Europe/Brussels to java
  85. jbosmansi think the latter is most impactfull, but as always ymmv
  86. jbosmanswho knew time(stamps) mattered