javabotferret's title: "Four LTS Java Versions Get End-of-Support in a Three-Year Window (2029-2032) - Slashdot"
* ultralan joined #java
ernimrilif you can not get off of java 8 until 2030 you do have a problem, but the support for java aint one of them
ferretplease its important
Harzileinyou need a community -> you need external consultants but those need oversight?
ernimrilwell. this channel has nothing to do with oracle and its plan for LTS
ferretim scared
Harzileintry #psychology?
ferretit will protect critical infrastructure against vulnerabilities while minimizing the risks and costs associated with frequent disruptive code migrations
ferretits so important
ferreti cant do this alone
ernimrilferret, what jvm are you currently using? oracle? openjdk? adoptium?
* leppard joined #java
comradif he needs LTS then he simply should pay oracle
comraddid he expect that someone here volunteers? :)
ParaI wish someone paid me to learn why hanging onto an old LTS is worth getting anxious about on Sunday.
Drixtangod I love the humour of this channel
dreamrealI love how peopple say "help me" withput saying what that help means
dreamrealTHAT guy's answers were clear
dreamrealbased on what he was saying, but he never actually said
dreamrealcomrad:
dreamrealcomrad: he has other options, too: cheerpj, azul, oracle as was suggested
* blacknova joined #java
dreamrealhe was far from "oh no nothing will work" even if he needs specific maintenance support
comraddreamreal: sure, but oracle would be the google search first result probably
dreamrealoh, definitely. And what he REALLY should do is what was suggested: move off of EOL
dreamrealThere are so many benefits to doing so that it makes no sense to stay on older versions
dreamrealthe only thing that really hurts that is the securitymanager
comradsometimes some certification stuff keeps you on that pinned version
dreamrealSure, can see it, but ... got any examples?
ParaI'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.
dreamrealYeah, although I *do* want to figure out the security manager thing
dreamrealI get that it was rarely used by the hoi polloi, but ... I mean...
dreamrealso now I can just write a servlet that calls System.exit()?
ParaApp I'm working on has that as REST endpoint!
ParaYes, it has admin account permission check around it, but still...
dreamrealSystem.exit() is only the worst offender
dreamrealhow 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
ParaSeems that's a nix based service, so I suppose they're heavily relying on immutable fs being the magic wand.
Para(figured this out by printing System/getProperties and System/getenv...yeah not a good sandbox)
comraddreamreal: 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
comraddreamreal: 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
* SJrX joined #java
dreamrealAviation can't be java, I am not sure medicine can either
dreamrealI've got code on planes, but it's not aviation code
dreamreal(I've deployed java in medicine, too, but that's not on medical devices, for the same reason)
Drixtandreamreal: cannot be on aviation / medecine (devices), why are you saying that? because of the GC STW?
dreamrealno, because the executable code isn't the same as the deliverable code
dreamrealin aviation you verify every executable path, period
dreamrealyou could use non-JIT java for that purpose if you wanted but why
DrixtanI didn't know that, that's interesting
dreamrealYou really don't want the software that controls your ailerons to be unpredictable in *any* way
dreamrealsame for the software regulating your heartbeat
Drixtanbut C code is predictable in *all* cases am I right...
dreamrealAnalysis, 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"
dreamrealwell, C doesn't recompile on the fly: when gcc emits linked code, what you run is what you delivered
Drixtanhear 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.
dreamrealJava'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
dreamrealthe metrics people use to judge environments are often stupid
dreamreal"but it's go so many lines of code, it's so verbose, C is faster" ... uh
dreamrealI get it, but think for just a few minutes before speaking, it really does help
Drixtanhow insulting me helps the situation here?
dreamrealDid I insult you?
Drixtan"think for a few minutes before speaking" <- that sounds like an insult, barely "you said something stupid" kind of thing
dreamrealBytecode doesn't run very often. It gets JIT-compiled and reanalyzed all the time.
dreamrealDrixtan: did you say something stupid, though?
dreamrealI mean, wouldn't that be part of the equation?
Drixtanwell, I am asking, did I ask something stupid?
dreamrealI didn't say you did, so do the math
dreamrealand unpredictability on the part of the *programmer* is not the same as unpredictability on the part of the *deliverable*
dreamrealif you have a malloc(), a usage, a free(), that is *absolutely* traceable
Drixtananyway, back to it then - the JIT compiled is reanalyzed all the time, I don't see it becomes less predictables still
dreamrealand 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
Drixtanthe 1+1 will and always be 2, jit, bytecode / or binary on a platform XYZ
dreamrealDrixtan: you're measuring outcomes, not process
dreamrealin C, if you do a BCD 2+2, you've got representations that work *that way* - BCD, BCD, addition, outcome is BCD
dreamrealAt 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"
dreamrealand 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?)
dreamrealDrixtan: and ... when
dreamrealwhen is that reordering done?
Drixtancompilation said
dreamrealand when is Java's reordering done?
Drixtanwell, quoting you: 08:57 dreamreal no, because the executable code isn't the same as the deliverable code
Drixtanin both cases, dliberable code = pre-compilation
dreamrealDrixtan: so what's your point? You're saying the same thing I'm saying, I'm sayingit's actually meaningful
dreamrealreordering at compilation time before delivery != reordering at RUNTIME compilation time
dreamrealand java reorders multiple times
Drixtanit's not once JIT it's jit for good?
dreamrealjava delivers bytecode; C delivers executable code
dreamrealDrixtan: no, java recompiles constantly
Drixtanthat was the part missing in my understanding I believe
dreamrealif 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
dreamrealnow imagine that over the *entire application library*
dreamrealgenerally predictable, sure, but absolutely predictable, god no
dreamrealand in flight, medical, energy code you DO NOT want code to take 16 cycles here, 64 cycles there
dreamrealyou want to know
Drixtanor a STW
Drixtanright in your peacemaker, can't miss a beat isn't it
dreamrealWHat's a STW?
Drixtanstop the world
dreamrealWell, 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
Harzileinhmm
dreamrealSTW is controllable in a lot of ways, it's hardly the bogeyman it was for java 1.2
dreamrealsome VMs even have "you will not STW for longer than this period" options
dreamrealand some don't have STW at all, plus you can select which GC strategy you want
Drixtanoh, I did not know the STW was deterministic, or could be deterministic
dreamrealGC is definitely a thing to watch, but they've had different strategies for it since 2002
dreamrealstill 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
Drixtanand having different strategies is making it predictable, or at least, there is a strategy so it is predictable...
dreamrealwell, it's optimizable
Drixtanah ok, so when I asked first if it was because of the STW and you answered no, it was actually "yes" ?
dreamrealNo, it wasn't. Our problem wasn't STW.
dreamrealA 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.
dreamreal(Write tests, people. Focused tests. And pay attention to your effing results. Grrr.)
dreamrealWe had a cartesian expansion of memory consumption: not STW GC, but OOME... vs a 2000% increase in TIME consumption
dreamrealand since that process was the last step in a long chain of events, the time consumption was handwaved off
Drixtanthat's a specific case, an anecdote, I wasn't talking about that case.
dreamreal"this takes 40m, sounds right" when, well, okay, it should have taken 35m, nanometers are still *this* long
dreamrealsure, but it's a generalizable anecdote, STWs are not common in modern VMs
dreamrealyou could create a problem with STW GCs if you tried hard enough. Quick, what would you have to do?
dreamrealhold on, give me a minute, I need to figure out what an actual answer would be
dreamrealI tried thinking of a few scenarios already but ... nah, they'd be easily addressed without tuning a single damn thing
dreamrealstriping long-retained information while heavily over-allocating at the same time, AND choosing the wrong GC model... CCMS? No, that'd be fine
dreamrealit'd be slow, but fine, unless maybe you VERY heavily overthreaded at the same time...
Drixtanat one point, you have to clean up the allocated objects no? isn't that a stw
dreamrealno
Drixtanoh, how does it unallocate the heap then
dreamrealby not having a "the heap"
dreamrealthat's not been a thing since java 7
Drixtancreating an arraylist, adding stuff in it doesn't go in the heap
dreamrealsure, but you have now said "the heap" multiple times, and that's not how memory works in the VM
ParaLucene internals is apparently very interesting if you want to learn how to deal with near-zero allocation code in JVM.
dreamrealthere is a "the heap" but "the heap" has multiple regions to work with
Drixtanok, because you just said "not having the heap"
Drixtanthat's not been a thing since java 7
dreamrealI said "the heap" with the definite article being very much an important part of the phrasing
Drixtanso I guess, since java 8 there is "no heap"
dreamrealSure, there's a heap, there are actual MANY heaps
dreamrealeven on java 1 there were multiple REGIONS
dreamrealcleaning up some of those regions WAS a STW
Drixtanok, and that "non heap heap" isn't cleared by the gc
dreamrealbut that model hasn't been dominant or default (or AVAILABLE) in the VM for years now
Drixtanor aka, the stw
dreamrealno, it's always...
dreamreal*sigh*
dreamrealDrixtan: okay, let's peer through history, back to a bygone age: memory was in four regions.
dreamrealTHIS IS NO LONGER THE CASE, okay?
dreamrealBut there were four regions: short term, survivor, two long-lived regions
dreamrealyou 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
dreamrealSTW 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
dreamrealnow let's go to ... oh... 2007.
dreamrealNow 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.
dreamreal("Maybe" is important, because YOU CAN CHOOSE THE GC STRATEGY you want and they change from VM to VM.)
dreamrealso 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
dreamrealSTW would happen in catastrophic circumstances when you fill up EVERY region with worst-case stuff
dreamrealit's not going to happen casually
dreamrealalso worth noting: the GC stuff is written by some of the smartest programmers on earth, people whose shoes I am not fit to shine
Drixtanwhen allocating something new, it goes in eden?
dreamreal... usually
Drixtanwhere else if it's a new allocation?
Drixtananyway, 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" ?
* GreenResponse joined #java
dreamrealdepends 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
dreamrealthat is what happens, yes
Drixtandon't you have to stop new allocations to happen so nothing happen new to eden?
dreamrealno
dreamrealit's still using threads: copy stuff out, deallocate teh region. Eden is not large on purpose.
dreamrealIs free() slow?
Drixtanyea, but don't you have to stop new allocations thou?
Drixtanthread, copy stuff, great, but -allocations-
dreamrealfor the VM, it's just memcpy() and adjust pointer refs
dreamrealstuff still has to happen, sure, but it's *fast*
Drixtanok, but you have to stop new allocations to eden
dreamrealif 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
dreamrealyou... don't
Drixtanso 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
dreamrealright
dreamrealwhat programming languages are you familiar with?
DrixtanC
dreamrealokay. You know how processes work in C, yeah?
Drixtanyea
dreamrealokay, imagine that instead of malloc() you have a process that does the allocation/free/access for you
dreamreal(like a multithreaded malloc(), salloc(), free(), calloc())
dreamrealyou're just dispatching to something that calls you back when it's done WHATEVER, right?
dreamrealThat's the memory manager for every OS, for what it's worth, except the JVM has its own representation of it
dreamrealand I gotta run
dreamrealhave a good one, all!
Drixtanreading 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
javabotDrixtan's title: "Managing Memory and Garbage Collection (Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide)"
nevetManaging Memory and Garbage Collection (Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide)
Drixtanall this seems to suggests there is a pause anyway
ParaDepends on GC algorithm.
ParaThat page is from 2010 so it might be a tad outdated :)
ParaPermGen 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.
Drixtanok, I see 3 GCs here and in the table, they all have "pauses"
Drixtanso, to come back to the initial question "why not in aviation / medical devices", the STW still present here
Drixtanthere is no case where there is no STW
Drixtanif we keep the focus on the initals
* Fiji_ joined #java
ParaWell, 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.
ParaOf course planes are the kind of devices where "effectively" isn't good enough :)
Drixtanthe point is not if someone notice, the point is there /is/ one pause
ParaJVM 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".
ParaStuckness 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.
Drixtanyea, 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
dreamrealand 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
ParaI don't think any of us are in disagreement here?
Drixtanno, it's not a "you are right I am right, we are wrong", like I said; hear me out here, I want to understand
ParaThere 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.
DrixtanI 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
Drixtanif that makes sense to you
dreamrealthat's not what realtime means: realtime is not "is slow," realtime is "will occur in this timespan"
dreamrealrealtime can be "350ms" if the 350ms is guaranteed
DrixtanI never said that realtime = slow
Drixtanwhre did I say that
dreamrealyou did not. I was clarifying, because a "STW that runs in 350ms" is acceptable in realtime terms if the SLA allows it.
dreamrealSTW is not the problem, like I keep saying.
dreamrealAnd it's worth noting that realtime != fast
dreamreal"realtime" makes guarantees about time, but does not make an assertion about what those guarantees ARE except for the specific circumstances of deployment
yamadawhere is all remote method invocation documentation in java 26
BombeIn the EU, medical software is a medical device, too, according to 2017/745 Medical Device Regulation, so technically, medical devices can run on Java. :)
Bombe(But for hardware, it is pretty much 100% as dreamreal says.)
ParaOur company has one (and two in progress) medical device certified applications.
ParaAnd yeh, it's a JVM app.
BombeYeah, I’m working on one as well. :)
ParaIt basically does some statistical data digging on input and gives a ranking of how certain certain decisions could be data wise.
Para"78% of people with these issues respond well (3.8/5 on quality scale) to this treatment"
* leppard joined #java
ParaThe 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.
DrixtanI 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
BombeYeah, 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.
Drixtanjava version old-something
Para1.enough
Drixtankind of :)
* gaxar joined #java
gaxarHello. I have a question. Is it necessary to learn how type erasure works when learning Java?
ParaI'd say yes, but it's not hard.
gaxarOh okay.
ParaIt's all just Objects.
gaxarWell, 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.
gaxarI don't know why, but I get tired easily.
ParaGet rid of your smartphone.
ParaAlso that stuff is not very common in practice.
gaxarOh.
gaxarWhy not?
ParaGood to know but not by heart; just know where to read to refresh your memory when needed.
gaxarok.
gaxarWhat makes you think my smart phone is the problem?
ParaMost 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.
gaxarOkay.
gaxarThank you.
avuI can't remember when I last wrote an upper or lower bound wildcard in Java and I still write Java almost every day :o
Paragaxar: Process of elimination, most people have fried their brains these days with the insta-dopamine trickling provided by all the shit social media etc :)
gaxaroh.
Drixtanor AI
Drixtanlearning new stuff/concept IS tiring too, so do not blame yourself and keep going ;)
gaxarI 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.
avutrying to diagnose why somebody gets easily tired from a few sentences on IRC is a bit wild :)
gaxarok
Paraavu: I'm not a certified medical device.
gaxarok
avugood to know 8)
gaxarWell, thanks for the information.
gaxarI'll probably be back later.
* Betal joined #java
* hwpplayer1 joined #java
* sweatiest_ joined #java
* sweatiest joined #java
* metalmaniac joined #java
* punit_arya joined #java
* hwpplayer1 joined #java
* magla joined #java
* simon816 joined #java
* punit_arya joined #java
* domicron joined #java
* punit_arya joined #java
* punit joined #java
* punit joined #java
* ztevoz joined #java
* ferdna joined #java
* mindCrime joined #java
* metalmaniac joined #java
* kelt0m joined #java
* mindCrime joined #java
* monkeyPlus joined #java
* baboonPlus joined #java
* ephapticpulse joined #java
* ephapticpulse left #java (ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.3))
* mindCrime joined #java
* Fiji_ joined #java
* kelt0m joined #java
* fgarcia joined #java
* pr070cal joined #java
* kelt0m joined #java
* jreicher joined #java
* genpaku joined #java
* hwpplayer1 joined #java
jreicherDrixtan: 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
jreichersay 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.