Back to the channels

#java

10:08 ferret guys i need your help
10:08 ferret we cant end LTS Java
10:08 ferret i need a community
10:09 ferret i know its 3 years but EOL
10:09 ferret please
10:09 ernimril uh? what?
10:10 ferret https://developers.slashdot.org/story/26/06/14/0534214/four-lts-java-versions-get-end-of-support-in-a-three-year-window-2029-2032
10:10 javabot ferret's title: "Four LTS Java Versions Get End-of-Support in a Three-Year Window (2029-2032) - Slashdot"
10:11 ernimril if you can not get off of java 8 until 2030 you do have a problem, but the support for java aint one of them
10:11 ferret please its important
10:12 Harzilein you need a community -> you need external consultants but those need oversight?
10:12 ernimril well. this channel has nothing to do with oracle and its plan for LTS
10:13 ferret im scared
10:13 Harzilein try #psychology?
10:15 ferret it will protect critical infrastructure against vulnerabilities while minimizing the risks and costs associated with frequent disruptive code migrations
10:15 ferret its so important
10:15 ferret i cant do this alone
10:16 ernimril ferret, what jvm are you currently using? oracle? openjdk? adoptium?
10:58 comrad if he needs LTS then he simply should pay oracle
10:58 comrad did he expect that someone here volunteers? :)
11:01 Para I wish someone paid me to learn why hanging onto an old LTS is worth getting anxious about on Sunday.
11:10 Drixtan god I love the humour of this channel
11:16 dreamreal I love how peopple say "help me" withput saying what that help means
11:17 dreamreal THAT guy's answers were clear
11:17 dreamreal based on what he was saying, but he never actually said
11:21 dreamreal comrad:
11:21 dreamreal comrad: he has other options, too: cheerpj, azul, oracle as was suggested
11:22 dreamreal he was far from "oh no nothing will work" even if he needs specific maintenance support
11:22 comrad dreamreal: sure, but oracle would be the google search first result probably
11:23 dreamreal oh, definitely. And what he REALLY should do is what was suggested: move off of EOL
11:25 dreamreal There are so many benefits to doing so that it makes no sense to stay on older versions
11:25 dreamreal the only thing that really hurts that is the securitymanager
11:27 comrad sometimes some certification stuff keeps you on that pinned version
11:27 dreamreal Sure, can see it, but ... got any examples?
11:28 Para I'm kinda interested about the whole thing. In an anthropological sense, that is. Why some places can't see why updating versions would be sensible, what's the fallacy/fear. There's always some reason, but rarely it's about the tech itself.
11:29 dreamreal Yeah, although I *do* want to figure out the security manager thing
11:29 dreamreal I get that it was rarely used by the hoi polloi, but ... I mean...
11:30 dreamreal so now I can just write a servlet that calls System.exit()?
11:30 Para App I'm working on has that as REST endpoint!
11:31 Para Yes, it has admin account permission check around it, but still...
11:32 dreamreal System.exit() is only the worst offender
11:32 dreamreal how do things like glot.io expect to prevent filesystem access, network access, exit access outside of an isolated VM? That's the smart play ANYWAY, I guess, but those isolated containers ain't exactly security fortresses either
11:38 Para Seems that's a nix based service, so I suppose they're heavily relying on immutable fs being the magic wand.
11:38 Para (figured this out by printing System/getProperties and System/getenv...yeah not a good sandbox)
11:39 comrad dreamreal: i supported and developed an application that was certified by the german calibration office which included the working environment. and the jvm was part of that. So we could not change it without recerficiation - certification was valid for 10 years
11:40 comrad dreamreal: otherwise aviation or medicine maybe? but then he should already know what their boundaries were and how to mitigate them by buying support from a company
11:44 dreamreal Aviation can't be java, I am not sure medicine can either
11:44 dreamreal I've got code on planes, but it's not aviation code
11:45 dreamreal (I've deployed java in medicine, too, but that's not on medical devices, for the same reason)
12:51 Drixtan dreamreal: cannot be on aviation / medecine (devices), why are you saying that? because of the GC STW?
12:57 dreamreal no, because the executable code isn't the same as the deliverable code
12:57 dreamreal in aviation you verify every executable path, period
12:58 dreamreal you could use non-JIT java for that purpose if you wanted but why
13:01 Drixtan I didn't know that, that's interesting
13:01 dreamreal You really don't want the software that controls your ailerons to be unpredictable in *any* way
13:01 dreamreal same for the software regulating your heartbeat
13:02 Drixtan but C code is predictable in *all* cases am I right...
13:02 dreamreal Analysis, entertainment, sure, whatever. But when you depend on dropping control rods into a nuclear pile, you, uh, don't want the compiler to go "oh wait, that wasn't the happy path"
13:03 dreamreal well, C doesn't recompile on the fly: when gcc emits linked code, what you run is what you delivered
13:05 Drixtan hear me here, I am just trying to understand. But in what case, with all the UB, or potential memory management mistakes that are possible in C, how comes C is "predictable" where the JIT is not? In what circonstances the JIT would be "unpredictable" on your javacode, when you "emitted" your bytecode, that's what is going to run/delibered.
13:05 dreamreal Java's written in C, so it's obviously *doable*, but not normally. There are, as usual, tradeoffs for everything: writing code that performs excellently in Java takes less effort than the same code in C, but C is *more predictable*, which is why I have a relatively low opinion of most rank and file coders
13:05 dreamreal the metrics people use to judge environments are often stupid
13:06 dreamreal "but it's go so many lines of code, it's so verbose, C is faster" ... uh
13:06 dreamreal I get it, but think for just a few minutes before speaking, it really does help
13:06 Drixtan how insulting me helps the situation here?
13:07 dreamreal Did I insult you?
13:07 Drixtan "think for a few minutes before speaking" <- that sounds like an insult, barely "you said something stupid" kind of thing
13:07 dreamreal Bytecode doesn't run very often. It gets JIT-compiled and reanalyzed all the time.
13:07 dreamreal Drixtan: did you say something stupid, though?
13:08 dreamreal I mean, wouldn't that be part of the equation?
13:08 Drixtan well, I am asking, did I ask something stupid?
13:08 dreamreal I didn't say you did, so do the math
13:08 dreamreal and unpredictability on the part of the *programmer* is not the same as unpredictability on the part of the *deliverable*
13:09 dreamreal if you have a malloc(), a usage, a free(), that is *absolutely* traceable
13:09 Drixtan anyway, back to it then - the JIT compiled is reanalyzed all the time, I don't see it becomes less predictables still
13:09 dreamreal and if that usage is remarkably complex, involving 4M of executable code, it's STILL traceable because it doesn't mutate at runtime, period, unless the programmer does that specifically
13:09 Drixtan the 1+1 will and always be 2, jit, bytecode / or binary on a platform XYZ
13:09 dreamreal Drixtan: you're measuring outcomes, not process
13:10 dreamreal in C, if you do a BCD 2+2, you've got representations that work *that way* - BCD, BCD, addition, outcome is BCD
13:11 dreamreal At runtime the compiler is never ever ever going to go "oh, haha, this is bigdecimal, but it's always integer math, let's optimize for integer math and make it take 3 cycles instead of 432"
13:12 Drixtan https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Optimization-and-Ordering.html
13:12 Drixtan the code can totally be re-ordered
13:12 dreamreal and THAT optimization is flexible (check!) and occasionally unpredictable (check!) and MIGHT BE WRONG (check! What happens if the input is integral 99,999 times out of 100k?)
13:12 dreamreal Drixtan: and ... when
13:13 dreamreal when is that reordering done?
13:13 Drixtan compilation said
13:13 dreamreal and when is Java's reordering done?
13:13 Drixtan well, quoting you: 08:57 dreamreal no, because the executable code isn't the same as the deliverable code
13:14 Drixtan in both cases, dliberable code = pre-compilation
13:14 dreamreal Drixtan: so what's your point? You're saying the same thing I'm saying, I'm sayingit's actually meaningful
13:14 dreamreal reordering at compilation time before delivery != reordering at RUNTIME compilation time
13:14 dreamreal and java reorders multiple times
13:14 Drixtan it's not once JIT it's jit for good?
13:14 dreamreal java delivers bytecode; C delivers executable code
13:15 dreamreal Drixtan: no, java recompiles constantly
13:15 Drixtan that was the part missing in my understanding I believe
13:15 dreamreal if you have code with two paths and one path is run most of the time, it optimizes for that path... but if at runtime the happy path CHANGES it will recompile for the other path
13:16 dreamreal now imagine that over the *entire application library*
13:16 dreamreal generally predictable, sure, but absolutely predictable, god no
13:17 dreamreal and in flight, medical, energy code you DO NOT want code to take 16 cycles here, 64 cycles there
13:17 dreamreal you want to know
13:17 Drixtan or a STW
13:17 Drixtan right in your peacemaker, can't miss a beat isn't it
13:17 dreamreal WHat's a STW?
13:17 Drixtan stop the world
13:18 dreamreal Well, Java wouldn't MISS THE BEAT but it'd be less predictable in terms of time. JME could do it as it has no GC and no JIT (constrained devices) but JME is heavy when alternatives exist
13:18 Harzilein hmm
13:20 dreamreal STW is controllable in a lot of ways, it's hardly the bogeyman it was for java 1.2
13:20 dreamreal some VMs even have "you will not STW for longer than this period" options
13:20 dreamreal and some don't have STW at all, plus you can select which GC strategy you want
13:20 Drixtan oh, I did not know the STW was deterministic, or could be deterministic
13:21 dreamreal GC is definitely a thing to watch, but they've had different strategies for it since 2002
13:22 dreamreal still an issue, like I said, I had to fix a GC issue at work a few weeks ago in the year 2026 CE, which feels slightly crazy to me, but hey
13:22 Drixtan and having different strategies is making it predictable, or at least, there is a strategy so it is predictable...
13:22 dreamreal well, it's optimizable
13:22 Drixtan ah ok, so when I asked first if it was because of the STW and you answered no, it was actually "yes" ?
13:23 dreamreal No, it wasn't. Our problem wasn't STW.
13:24 dreamreal A STW issue is almost always remedied by changing a few strategies. In our case, it was 20 minutes of work to fix a problem that had gone ignored for years.
13:24 dreamreal (Write tests, people. Focused tests. And pay attention to your effing results. Grrr.)
13:25 dreamreal We had a cartesian expansion of memory consumption: not STW GC, but OOME... vs a 2000% increase in TIME consumption
13:26 dreamreal and since that process was the last step in a long chain of events, the time consumption was handwaved off
13:26 Drixtan that's a specific case, an anecdote, I wasn't talking about that case.
13:27 dreamreal "this takes 40m, sounds right" when, well, okay, it should have taken 35m, nanometers are still *this* long
13:27 dreamreal sure, but it's a generalizable anecdote, STWs are not common in modern VMs
13:28 dreamreal you could create a problem with STW GCs if you tried hard enough. Quick, what would you have to do?
13:29 dreamreal hold on, give me a minute, I need to figure out what an actual answer would be
13:29 dreamreal I tried thinking of a few scenarios already but ... nah, they'd be easily addressed without tuning a single damn thing
13:30 dreamreal striping long-retained information while heavily over-allocating at the same time, AND choosing the wrong GC model... CCMS? No, that'd be fine
13:31 dreamreal it'd be slow, but fine, unless maybe you VERY heavily overthreaded at the same time...
13:31 Drixtan at one point, you have to clean up the allocated objects no? isn't that a stw
13:31 dreamreal no
13:32 Drixtan oh, how does it unallocate the heap then
13:32 dreamreal by not having a "the heap"
13:32 dreamreal that's not been a thing since java 7
13:32 Drixtan creating an arraylist, adding stuff in it doesn't go in the heap
13:33 dreamreal sure, but you have now said "the heap" multiple times, and that's not how memory works in the VM
13:33 Para Lucene internals is apparently very interesting if you want to learn how to deal with near-zero allocation code in JVM.
13:33 dreamreal there is a "the heap" but "the heap" has multiple regions to work with
13:33 Drixtan ok, because you just said "not having the heap"
13:33 Drixtan that's not been a thing since java 7
13:33 dreamreal I said "the heap" with the definite article being very much an important part of the phrasing
13:33 Drixtan so I guess, since java 8 there is "no heap"
13:33 dreamreal Sure, there's a heap, there are actual MANY heaps
13:34 dreamreal even on java 1 there were multiple REGIONS
13:34 dreamreal cleaning up some of those regions WAS a STW
13:34 Drixtan ok, and that "non heap heap" isn't cleared by the gc
13:34 dreamreal but that model hasn't been dominant or default (or AVAILABLE) in the VM for years now
13:34 Drixtan or aka, the stw
13:34 dreamreal no, it's always...
13:34 dreamreal *sigh*
13:34 dreamreal Drixtan: okay, let's peer through history, back to a bygone age: memory was in four regions.
13:35 dreamreal THIS IS NO LONGER THE CASE, okay?
13:35 dreamreal But there were four regions: short term, survivor, two long-lived regions
13:36 dreamreal you could instant-allocate the sizes by using -client and -server for the java process; server got really large generational spaces and a relatively small eden, client got a giant eden with relatively small generational spaces
13:36 dreamreal STW is when those generational spaces had to be cleaned up, because eden got swept instantly and quickly but those generational spaces had to be checked thoroughly
13:36 dreamreal now let's go to ... oh... 2007.
13:37 dreamreal Now the eden space still exists but the generational regions *exploded*. They're smaller, because they're sized by the GC: you have 20G of RAM? Cool, maybe you have 20 regions now.
13:37 dreamreal ("Maybe" is important, because YOU CAN CHOOSE THE GC STRATEGY you want and they change from VM to VM.)
13:38 dreamreal so if you have 20 regions to clean up, for one thing the GC runs as a thread, plus it only cleans up 1G at a time when that region gets crowded - and it usually does so by blitting things out at need and then just wiping that section, which is really fast
13:39 dreamreal STW would happen in catastrophic circumstances when you fill up EVERY region with worst-case stuff
13:39 dreamreal it's not going to happen casually
13:39 dreamreal also worth noting: the GC stuff is written by some of the smartest programmers on earth, people whose shoes I am not fit to shine
13:40 Drixtan when allocating something new, it goes in eden?
13:40 dreamreal ... usually
13:41 Drixtan where else if it's a new allocation?
13:41 Drixtan anyway, so when eden is full, what is happening? filtering what is to keep, what is not to keep, and pushing what to keep in an older generation "section" ?
13:41 dreamreal depends on size: the thing king might say "this is eating up a lot of room in eden, let's put it elsewhere out of the gate" because the programmer decided to allocate an arraylist with 4m slots
13:41 dreamreal that is what happens, yes
13:41 Drixtan don't you have to stop new allocations to happen so nothing happen new to eden?
13:42 dreamreal no
13:42 dreamreal it's still using threads: copy stuff out, deallocate teh region. Eden is not large on purpose.
13:42 dreamreal Is free() slow?
13:42 Drixtan yea, but don't you have to stop new allocations thou?
13:43 Drixtan thread, copy stuff, great, but -allocations-
13:43 dreamreal for the VM, it's just memcpy() and adjust pointer refs
13:44 dreamreal stuff still has to happen, sure, but it's *fast*
13:44 Drixtan ok, but you have to stop new allocations to eden
13:44 dreamreal if it's not, well, that's why linux and BSD and windows are so slow: turns out doing stuff still requires teh speed of light to be respected
13:44 dreamreal you... don't
13:45 Drixtan so during the change to older generations and cleanup of what to be cleaned, you do not stop new allocations happening to eden when you cleanup eden
13:45 dreamreal right
13:45 dreamreal what programming languages are you familiar with?
13:45 Drixtan C
13:45 dreamreal okay. You know how processes work in C, yeah?
13:45 Drixtan yea
13:46 dreamreal okay, imagine that instead of malloc() you have a process that does the allocation/free/access for you
13:46 dreamreal (like a multithreaded malloc(), salloc(), free(), calloc())
13:47 dreamreal you're just dispatching to something that calls you back when it's done WHATEVER, right?
13:47 dreamreal That's the memory manager for every OS, for what it's worth, except the JVM has its own representation of it
13:47 dreamreal and I gotta run
13:47 dreamreal have a good one, all!
13:54 Drixtan reading this: https://docs.oracle.com/cd/E19900-01/819-4742/6n6sfgmkr/index.html I think it says something like: "The frequent young space collections are quick (a few milliseconds)" suggesting a pause and for your CMS you mentionned: Other GC algorithms, such as the Concurrent Mark Sweep (CMS) algorithm, are incremental [...] high probability of small pauses
13:54 javabot Drixtan's title: "Managing Memory and Garbage Collection (Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide)"
13:54 nevet Managing Memory and Garbage Collection (Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide)
13:54 Drixtan all this seems to suggests there is a pause anyway
13:54 Para Depends on GC algorithm.
13:55 Para That page is from 2010 so it might be a tad outdated :)
13:56 Para https://www.javacodegeeks.com/2026/04/the-jvm-garbage-collector-decision-in-2026-g1-vs-zgc-vs-shenandoah-for-real-workloads.html
13:58 Para PermGen got replaced with Metaspace in Java 8, Java 9 made G1 the default, 15 brought in concurrent low-pause algos... Also different JDK distributions may have different GC algos as well.
13:58 Drixtan ok, I see 3 GCs here and in the table, they all have "pauses"
13:58 Drixtan so, to come back to the initial question "why not in aviation / medical devices", the STW still present here
13:59 Drixtan there is no case where there is no STW
13:59 Drixtan if we keep the focus on the initals
13:59 Para Well, kinda yes. Modern algos minimize the pauses and generally do the cleanup in different threads etc. so unless you're introduing tons of memory pressure it should be effectively unnoticeable.
14:00 Para Of course planes are the kind of devices where "effectively" isn't good enough :)
14:00 Drixtan the point is not if someone notice, the point is there /is/ one pause
14:02 Para JVM guarantees allocation, or rather the code can never proceed beyond "new" unsuccesfully. It can get stuck and throw OutOfMemoryErrors and whatever, but it won't progress or -I think- deadlock either on "new".
14:03 Para Stuckness usually is the GC algo panicking because it can't do its work to free enough space for the allocation, so it'll grind to halt and then OOMEs, but from human point of view it gets stuck.
14:04 Drixtan yea, but even on a good day, you have some pauses, that's a normal jvm/gc behaviour and it's not acceptable when realtime is a requirement
14:04 dreamreal and again, as I drive by, STWs are not "the reason" - it's predictability of the runtime code as the primary lever, because there are heap managers that are zero-allocations, so no STW because there's no cleanup
14:05 Para I don't think any of us are in disagreement here?
14:05 Drixtan no, it's not a "you are right I am right, we are wrong", like I said; hear me out here, I want to understand
14:05 Para There at leats used to be some very specific constraints (hw+sw+os+version) to have realtime Java but I'm fairly certain that's from a bygone era.
14:05 Drixtan I have something else to do than winning an argument, but if I want to understand, I need it to be clear and not just take words for it
14:05 Drixtan if that makes sense to you
14:05 dreamreal that's not what realtime means: realtime is not "is slow," realtime is "will occur in this timespan"
14:06 dreamreal realtime can be "350ms" if the 350ms is guaranteed
14:06 Drixtan I never said that realtime = slow
14:06 Drixtan whre did I say that
14:06 dreamreal you did not. I was clarifying, because a "STW that runs in 350ms" is acceptable in realtime terms if the SLA allows it.
14:07 dreamreal STW is not the problem, like I keep saying.
14:07 dreamreal And it's worth noting that realtime != fast
14:08 dreamreal "realtime" makes guarantees about time, but does not make an assertion about what those guarantees ARE except for the specific circumstances of deployment
14:26 yamada where is all remote method invocation documentation in java 26
14:29 Bombe In the EU, medical software is a medical device, too, according to 2017/745 Medical Device Regulation, so technically, medical devices can run on Java. :)
14:29 Bombe (But for hardware, it is pretty much 100% as dreamreal says.)
14:30 Para Our company has one (and two in progress) medical device certified applications.
14:30 Para And yeh, it's a JVM app.
14:30 Bombe Yeah, I’m working on one as well. :)
14:30 Para It basically does some statistical data digging on input and gives a ranking of how certain certain decisions could be data wise.
14:31 Para "78% of people with these issues respond well (3.8/5 on quality scale) to this treatment"
14:32 Para The wording afaik was almost the hardest part to get right, as the software is not allowed to tell "give them ibuprofen end yeet the patient" or any other direct recommendations/advice.
14:45 Drixtan I made a prescription "giver" on pda back then, so the doctors could walk to the patient, prescribe directly from the pda and print it on thermal paper, give it right away and move on
14:45 Bombe Yeah, we’re analyzing hardware recordings and make it easy to diagnose stuff, but we don’t do the diagnosis, that’s the user’s job.
14:45 Drixtan java version old-something
14:46 Para 1.enough
14:46 Drixtan kind of :)
14:53 gaxar Hello. I have a question. Is it necessary to learn how type erasure works when learning Java?
14:53 Para I'd say yes, but it's not hard.
14:53 gaxar Oh okay.
14:54 Para It's all just Objects.
14:55 gaxar Well, I struggle to read and concentrate a long time. So, I just practiced upperbounded wildcards, and the guidelines on whether to use upperbound or lowerbound. Then, while reading about type erasure, I felt resistant to the activity and stopped.
14:55 gaxar I don't know why, but I get tired easily.
14:56 Para Get rid of your smartphone.
14:56 Para Also that stuff is not very common in practice.
14:56 gaxar Oh.
14:56 gaxar Why not?
14:56 Para Good to know but not by heart; just know where to read to refresh your memory when needed.
14:56 gaxar ok.
14:57 gaxar What makes you think my smart phone is the problem?
14:57 Para Most people just use simple generics, MyType<T>. Also type erasure just means that during runtime every generics is Object and the necessary casts are done on the background.
14:57 gaxar Okay.
14:58 gaxar Thank you.
14:58 avu I can't remember when I last wrote an upper or lower bound wildcard in Java and I still write Java almost every day :o
14:58 Para gaxar: Process of elimination, most people have fried their brains these days with the insta-dopamine trickling provided by all the shit social media etc :)
14:58 gaxar oh.
14:58 Drixtan or AI
14:58 Drixtan learning new stuff/concept IS tiring too, so do not blame yourself and keep going ;)
14:59 Para It feels tedious because learning _is_ tedious. You're literally feeling yourself learning.
14:59 gaxar I don't go on social media most of the time, but I keep scrolling through my news feed on google and the home media page on Android.
14:59 avu trying to diagnose why somebody gets easily tired from a few sentences on IRC is a bit wild :)
14:59 gaxar ok
14:59 Para avu: I'm not a certified medical device.
14:59 gaxar ok
14:59 avu good to know 8)
15:02 gaxar Well, thanks for the information.
15:02 gaxar I'll probably be back later.
23:00 jreicher Drixtan: I think maybe you misunderstand what "predictable" means. Consider a pseudo random number generator. In principle it's predictable because it's entirely deterministic, but in practice it's not because its behaviour is infeasibly complex, which is largely the goal of it. So predictability is more about simplicity than anything else. You have to decide whether the JVM is sufficiently simple. But it should be uncontroversial to
23:00 jreicher say that when you are in control of the entire runtime, as is the case writing in C, you can make things as simple as you want.