5 ms·

jdk 8 is not rock solid nor performant. You should look at your codebase, you might be doing some strange things that changed in newer JDKs (e. g. String split

by krzyk 5y ago

jdk 8 is not rock solid nor performant. You should look at your codebase, you might be doing some strange things that changed in newer JDKs (e. g. String split no longer uses the sour String, but I don't remember when they changed that). Some options were deprecated because they are also always on (not all probably).

DarkmSparks 5y ago
3 years uninterupted uptime and counting. what in 17 do you think is worth risking downtime?
- fridif 5y ago
  Nothing for you, but something for us.
- sigzero 5y ago
  Why would there be downtime? It's faster. Less RAM hungry. Tons of new great features. I mean, if you don't want or feel the need to upgrade then don't. There are plenty of reasons to do so IMO.
  - DarkmSparks 5y ago
    Because the core system dates back to jre... 1.4, has had ~2 decades of painful testing and big chunks of code dont currently work on anything newer than 8. a bug that takes 100 hours to manifest takes multiples of that to fix. compute and ram is crazy cheap these days, developers are not, and finding good ones is harder than ever.
    - stuff4ben 5y ago
      Yeah I'm gonna say you're an edge case and that the majority of users will see performance benefits. Maybe not you, but that's legacy code for ya and an awful lot of technical debt that's likely not worth it.
      - DarkmSparks 5y ago
        every java dev was an edge case, from small houses building blockbusters like triage through to the likes of gazprom and google building their entire backend on it with tens of thousands of devs. since you threw them out, which "majority of users" are you thinking of?
        stuff4ben 5y ago
        Nah, I'm just saying you have a lot of legacy code you're either incapable of fixing or not willing to fix. And no, not every java developer is an edge case. If that were true then no one would be able to upgrade and they wouldn't bother creating more Java releases, we'd still all be on 8. See I too can make sweeping assumptions with no basis in reality. Sorry your codebase sucks, good luck!
        DarkmSparks 5y ago
        I know you have a lot of freshly written code that will crash multi times a week for the first few years its used in the wild. If you are wondering why no one wants to pay for it, that is why.
        stuff4ben 5y ago
        LOL, you know nothing about what I do. And it sounds like you have experience with "freshly written code that crashes multiple times a week for the first few years"... here's a hint, it's probably you and your development team to blame, not the JDK. Maybe you should quit being lazy, learn the new JDK APIs and features, and convert that POS legacy codebase into something that's not dependent upon a platform released 7 years ago. But then again, maybe you're not a competent enough developer to do so, so you blame the JDK developers instead.
        DarkmSparks 5y ago
        heres a real hint. Im in a yacht in the med, will fly my private helicopter home soon. I also dont want to know anything about you. Well done.
    - krzyk 5y ago
      What will you do with this system when Java 8 stop being supported (no more security fixes)?
      - DarkmSparks 5y ago
        thats actually less of an issue than it sounds for a jvm build that hasn't had a relevant and important security issue found for over a decade, is now open source and all the others found and fixed any time recently give better assurance over any recent code that hasnt had the same scrutiny.
- rualca 5y ago
  > 3 years uninterupted uptime and counting. Didn't you had to install updates and patches during the past three years? Or were those sacrificed to keep an uptime streak that matters nothing?
  - Spivak 5y ago
    People still take outages for patching? I think the parent means service uptime.
    - rualca 5y ago
      Taking a node down does not mean outage at all. Service uptime also reads like a non-sequitur given the comment on the JDK11 crashes sounded like OP was doing something weird with the new JDKs, not with the old prod system running JDK8. JDK11 was released way back in 2018. Any claim that it's unstable these days is not credible.
  - DarkmSparks 5y ago
    Sure, but no other updates or patches require massive rewrites to work as well as it does now, and they can be applied one machine at a time. e.g. a non insignificant portion relies on corba/rmi. it works, and works fine. switching, e.g. https://stackoverflow.com/questions/51710274/is-there-a-replacement-library-for-corba-in-jdk-11 https://stackoverflow.com/questions/51710274/is-there-a-repl... might break in unexpected ways, bringing down everything that needs it. I see 17 is potentially ripping out security manager, why? wth? So suddenly jars that expect to throw an exception if 3pd code wants to do something they arent allowed to will now just run fine? Really really very sad face.
    - derefr 5y ago
      > I see 17 is potentially ripping out security manager, why? wth? Because Security Manager — which enforces runtime access capabilities, like an OS kernel does — exists for the sake of Java applets, and Java applets have been dead for a long time. The Security Manager enables secure execution of "mobile" (i.e. untrusted, not-auditable-at-time-of-release) code — cases where the "host" and "guest" codebases are compiled separately with the "host" having no ability to introspect the "guest" during the "host's" compilation, because the "guest" doesn't exist yet. Security Manager does not exist for the sake of fighting against your own project's dependencies. There are much simpler and more runtime-efficient solutions (like linters / static-analysis tools) for the case where the "host" can see the "guest's" code at compile time. Security Manager doesn't exist for the sake of "plugins" (e.g. WARs, Java Agents, etc), either. Even if you don't have a plugin's source code available in your project worktree at build time, you can still validate the plugin's behavior at release time by statically analyzing its bytecode before building it into your release fatJar. Which still allows you to make much stronger guarantees than Security Manager can.

by krzyk 5y ago

DarkmSparks 5y ago

3 years uninterupted uptime and counting. what in 17 do you think is worth risking downtime?

fridif 5y ago
Nothing for you, but something for us.
sigzero 5y ago
Why would there be downtime? It's faster. Less RAM hungry. Tons of new great features. I mean, if you don't want or feel the need to upgrade then don't. There are plenty of reasons to do so IMO.
- DarkmSparks 5y ago
  Because the core system dates back to jre... 1.4, has had ~2 decades of painful testing and big chunks of code dont currently work on anything newer than 8. a bug that takes 100 hours to manifest takes multiples of that to fix. compute and ram is crazy cheap these days, developers are not, and finding good ones is harder than ever.
  - stuff4ben 5y ago
    Yeah I'm gonna say you're an edge case and that the majority of users will see performance benefits. Maybe not you, but that's legacy code for ya and an awful lot of technical debt that's likely not worth it.
    - DarkmSparks 5y ago
      every java dev was an edge case, from small houses building blockbusters like triage through to the likes of gazprom and google building their entire backend on it with tens of thousands of devs. since you threw them out, which "majority of users" are you thinking of?
      - stuff4ben 5y ago
        Nah, I'm just saying you have a lot of legacy code you're either incapable of fixing or not willing to fix. And no, not every java developer is an edge case. If that were true then no one would be able to upgrade and they wouldn't bother creating more Java releases, we'd still all be on 8. See I too can make sweeping assumptions with no basis in reality. Sorry your codebase sucks, good luck!
        DarkmSparks 5y ago
        I know you have a lot of freshly written code that will crash multi times a week for the first few years its used in the wild. If you are wondering why no one wants to pay for it, that is why.
        stuff4ben 5y ago
        LOL, you know nothing about what I do. And it sounds like you have experience with "freshly written code that crashes multiple times a week for the first few years"... here's a hint, it's probably you and your development team to blame, not the JDK. Maybe you should quit being lazy, learn the new JDK APIs and features, and convert that POS legacy codebase into something that's not dependent upon a platform released 7 years ago. But then again, maybe you're not a competent enough developer to do so, so you blame the JDK developers instead.
        DarkmSparks 5y ago
        heres a real hint. Im in a yacht in the med, will fly my private helicopter home soon. I also dont want to know anything about you. Well done.
  - krzyk 5y ago
    What will you do with this system when Java 8 stop being supported (no more security fixes)?
    - DarkmSparks 5y ago
      thats actually less of an issue than it sounds for a jvm build that hasn't had a relevant and important security issue found for over a decade, is now open source and all the others found and fixed any time recently give better assurance over any recent code that hasnt had the same scrutiny.
rualca 5y ago
> 3 years uninterupted uptime and counting. Didn't you had to install updates and patches during the past three years? Or were those sacrificed to keep an uptime streak that matters nothing?
- Spivak 5y ago
  People still take outages for patching? I think the parent means service uptime.
  - rualca 5y ago
    Taking a node down does not mean outage at all. Service uptime also reads like a non-sequitur given the comment on the JDK11 crashes sounded like OP was doing something weird with the new JDKs, not with the old prod system running JDK8. JDK11 was released way back in 2018. Any claim that it's unstable these days is not credible.
- DarkmSparks 5y ago
  Sure, but no other updates or patches require massive rewrites to work as well as it does now, and they can be applied one machine at a time. e.g. a non insignificant portion relies on corba/rmi. it works, and works fine. switching, e.g. https://stackoverflow.com/questions/51710274/is-there-a-replacement-library-for-corba-in-jdk-11 https://stackoverflow.com/questions/51710274/is-there-a-repl... might break in unexpected ways, bringing down everything that needs it. I see 17 is potentially ripping out security manager, why? wth? So suddenly jars that expect to throw an exception if 3pd code wants to do something they arent allowed to will now just run fine? Really really very sad face.
  - derefr 5y ago
    > I see 17 is potentially ripping out security manager, why? wth? Because Security Manager — which enforces runtime access capabilities, like an OS kernel does — exists for the sake of Java applets, and Java applets have been dead for a long time. The Security Manager enables secure execution of "mobile" (i.e. untrusted, not-auditable-at-time-of-release) code — cases where the "host" and "guest" codebases are compiled separately with the "host" having no ability to introspect the "guest" during the "host's" compilation, because the "guest" doesn't exist yet. Security Manager does not exist for the sake of fighting against your own project's dependencies. There are much simpler and more runtime-efficient solutions (like linters / static-analysis tools) for the case where the "host" can see the "guest's" code at compile time. Security Manager doesn't exist for the sake of "plugins" (e.g. WARs, Java Agents, etc), either. Even if you don't have a plugin's source code available in your project worktree at build time, you can still validate the plugin's behavior at release time by statically analyzing its bytecode before building it into your release fatJar. Which still allows you to make much stronger guarantees than Security Manager can.