Back to the channels

#java

03:42 NeXeN reflection is so slow in static analysis
03:57 jreicher Huh? Isn't that a contradiction?
04:26 NeXeN i mean with graal
04:26 NeXeN if you don't pre-configure it you know
04:27 NeXeN anyways i'm just complaining
04:28 NeXeN so what's up, what are you working on, jreicher?
04:44 jreicher Nothing 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. :(
05:05 NeXeN fun fun fun under the gun
05:35 deebo i loathe helm charts, they're basically "%s %s %s %s %s %s %s".formatted(service,deployment,ingress,...) in yaml format, it's terrible imo :)
05:36 deebo i 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
06:43 jreicher I'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.
08:11 NeXeN jreicher: that is sometimes the truth
08:17 nimaje hm, "simple" and "yaml", seems like a contradiction
08:32 NeXeN yaml is simple. simple is sometimes stupid
08:33 NeXeN remember kiss, keep it simple or stupid
09:26 hwpplayer1 What are the differences between 17 and 21 Java ?
09:26 deebo about 4
09:27 hwpplayer1 Any backward compatibilities ?
09:27 deebo and 25 is current "lts", so moving to 21 is a weird sidestep
09:27 hwpplayer1 Okay thanks
09:28 deebo plenty of feature lists on the interwebs (and youtube if you're into that), don't think backwards compatibility has ever been an issue really
09:28 hwpplayer1 I see
09:36 Bombe When we recently switched from 11 to 21, we did have to fix a small number of source files.
09:39 dreamreal https://bytecode.news/posts/2026/04/openjdk-says-structured-concurrency-now-writed-in-python
09:44 hwpplayer1 I gotta go thanks
09:48 Bombe “Writed?”
09:48 Bombe I mean, it would fit the topic… :D
09:52 * dreamreal shrugs
09:52 dreamreal Remember who the author is... single-layer jokes are a lot less funny than 12-layers. :D
09:53 dreamreal I thought about having an AI literally write it, and I tried that, but it was ungood
09:59 deebo emdash enthusiast
10:01 Para Is that a weekly or monthly publication?
10:16 dreamreal what, bytecode.news?
10:16 dreamreal deebo: damn it
10:17 dreamreal deebo: 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?"
13:14 dreamreal BTW, 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
13:15 dreamreal and 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
14:15 mitch0 dreamreal: nit on the fonts: it's kinda hard to read (at least on mobile)
14:18 mitch0 (probably it's just me getting old though)
14:18 dreamreal the serifs are a problem? kinabalu says he's going to address the mobile rendering at some point
14:19 dreamreal I didn't design the UI - the UI *I* put together is... uh... not exactly normal-human friendly
14:20 mitch0 I bet it would suit me just fine :) (I mean, your UI version)
14:22 dreamreal I doubt it, I don't really see information the same way others do
14:22 dreamreal If MY innate UI would suit you, that's concerning :D
14:23 dreamreal I probably need to revise it, though: the nextjs UI has advanced some things that the original reference UI hasn't kept up with
14:25 dreamreal Actually, 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
14:26 dreamreal or 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")
14:49 Square2 Aiui, you can put several spring boot app war's in an ear and deploy it?
14:49 Square2 (wo using ejb in those wars?)
14:50 Square2 ...don't ask me why I wanna do that. Some managers seem to love the idea with "one installation".
14:51 dreamreal Square2: are you asking if you can do that?
14:52 dreamreal I don't know what "aiui" means
14:52 DoofusCanadensis aiui == As I Understand It
14:52 dreamreal ah
14:52 dreamreal Square2: in that case, yes.
14:53 Square2 dreamreal, thanks
14:53 dreamreal Square2: it's actually spring's original raison d'etre, which makes your question kinda funny
14:54 Square2 dreamreal, oh, I didn't know. I though .ear's fell out of fashion after ejb 2.1.
14:54 dreamreal they're still in fashion, just very different from the 1.x-2.x cycle
14:54 dreamreal largely influenced by... spring
14:56 Square2 Oh ok. I though people solved these multi-deploys with k3s/k8s these days
14:56 Square2 thought
14:58 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* -
14:58 dreamreal like, EJB deployed on server A, used from a WAR on server B - and it was like 2% of the audience.
14:59 dreamreal THAT'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.*
15:00 dreamreal App 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.)
15:01 Square2 dreamreal, oh, you mean inter war dependencies wasn't a big thing?
15:01 dreamreal Square2: inter-WAR dependencies aren't really a thing even now
15:02 Square2 gotcha! Intersting to hear.
15:02 dreamreal inter-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.
15:03 cheeser the good old days
15:03 Square2 when I say inter-war dependencies I meant any dependency... even http (local) remoting etc.
15:05 dreamreal well... 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.
16:02 Para fwiw 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.
19:59 jbosmans well, April 1st about over and done with here, so far so good :)
19:59 dreamreal We still have eight hours, you fool!
20:00 jbosmans timezones, you fool !
20:02 dreamreal mine is the only one that matters
20:03 jbosmans ;)
20:07 jbosmans while i joke about timezones, it did bite me during upgrades. fwiw i ended up doing;
20:07 jbosmans mount /etc/timezone into container
20:07 dreamreal haha
20:08 jbosmans mount etc/localtime into container
20:08 jbosmans pass -Duser.timezone=Europe/Brussels to java
20:09 jbosmans i think the latter is most impactfull, but as always ymmv
20:10 jbosmans who knew time(stamps) mattered