5 ms·

In other news, we have an upgrade path at work to go from Java 8 to Java 11 pretty soon.

by acheron 3y ago

hmottestad 3y ago
Going from 11 to 21 is a lot easier.
- leapis 3y ago
  Depends- one of the hardest parts of the 11-20 upgrade for us was that cms gc was removed. If you run a bunch of different microservices with distinct allocation profiles, all with high allocation pressure and performance constraints, and you've accomplished this w/ the help of a very fine-tuned CMS setup, migrating that over to G1/ZGC is non-trivial
  - hmottestad 3y ago
    Is that what happened at your company?
    - leapis 3y ago
      Yup. We've clearly benefitted- G1 and generational ZGC have large advantages over CMS- but it's a lot of experimentation and trial-and-error to get there, whereas other deprecations/removals are usually easier to resolve.
      - kaba0 3y ago
        Isn't the default config correct for pretty much all workloads, unless you have very special requirements? Like, at most one should just change the target max pause time in case of G1, depending on whether they prefer better throughput at the price of worse latency, or the reverse.
  - xxs 3y ago
    Java sort of suck for microservices (microservices suck on their own) as it has relatively high bootstrap cost. High allocation rate feels weird with micro services - I suppose that depends a lot on the coding style. G1GC is meant for generally large setups, with several cores at least. E.g. the default setup of 2048 areas on 2GB heap means, allocations over 1MB require special care.
    - threeseed 3y ago
      If you GraalVM Native Image or one of the frameworks based on it then bootstrap cost disappears: https://quarkus.io https://quarkus.io
      - wice 3y ago
        GraalVm is great, it made our Spring REST API app go from 10+ seconds to 0.5 seconds on startup (not to mention the lower mem and cpu requirements). Except… when we try to build it with Jenkins on a Kubernetes cluster, this happens: https://github.com/oracle/graal/issues/7182 https://github.com/oracle/graal/issues/7182
  - bberrry 3y ago
    I can't help but think if you're teetering on a knife's edge, only holding on thanks to hyper tuned GC params, then you should take a step back and consider getting out of that predicament.
taf2 3y ago
do/i/still/need/to/create/sub/directories/for/the/things/i/want/namespace?
- mdaniel 3y ago
  Only if you're using vim like someone from the 70s, otherwise any sane IDE handles those things for you But, yes, namespaces are still mapped to paths, it's not like they rewrote the JVM to use blockchain or something
  - ttyyzz 3y ago
    Yeah I really like my IDE doing stuff in the background without me knowing shit about it.
    - piva00 3y ago
      Yeah, I do like my IDE doing the tedious work for me. It's also really nice to unzip any JAR I need to troubleshoot and know exactly where to navigate to find exactly the file with the code I need. I like Golang a lot but the standardisation and verbosity in Java-land has some benefits after you get used to it enough to learn to ignore the boilerplate, it's pretty good to have some kind of consistency enforced by the VM when working in large codebases.
      - quickthrower2 3y ago
        Yes some C# codebases end up with wildly inconsistent namespacing as you can do anything you like
    - threeseed 3y ago
      I don't understand how it is doing stuff in the background. You literally ask it to move some class and then it does it. And it's very obvious what it's doing.
    - Too 3y ago
      Then you’d be thrilled to hear about all the stuff your NVME drivers are doing in the background without you knowing shit about it. Or maybe you prefer to engrave your ones and zeroes in stone by hand? Abstractions exist for a reason. In Java, that abstraction is coding in classes and packages, not files of text.
kyawzazaw 3y ago
8 to 17 for us
- minhtran 3y ago
  Try with 8 --> 11 first then 11 --> 17
  - kyawzazaw 3y ago
    we are going ahead to 17. too much resources spent to do an intermediate step
MBCook 3y ago
We (finally) upgraded last year from 8 to 17. Lots of nice things, I’m so glad we were finally able to. But it was a big project due to some dependencies and how some things were done internally. I can’t wait for 21, but I’m not sure when we’ll switch. At least it will be trivial compared to leaving 8.
rendaw 3y ago
What were the backward incompatibilities preventing that move? I thought Java was pretty backward compatible, but I've heard this a lot.
- chii 3y ago
  It's more likely that there's some dependency that is not easy to upgrade, because the upgrade also includes api changes (from the dependency, not from the jdk). Compound this with multiple dependencies that exhibit this issue. If you have a "legacy" application that does not require active development, there's zero business incentive to invest into the upgrade. Unless you could prove value in having the upgrade, it just doesn't get prioritized.
- wscp-dev 3y ago
  Java has in recent times actually removed some apis from the standard library, and made some inaccessible (undocumented internal apis especially) so any advanced frameworks that use them would have been affected.
deleted 3y ago
[deleted]
sebazzz 3y ago
7 -> 8, but JBOSS 6 is a pain to migrate away from.
approxim8ion 3y ago
We made the jump from 8 to 17 this year! Some of our developers of course still write 1.6 level code, of course

In other news, we have an upgrade path at work to go from Java 8 to Java 11 pretty soon.

hmottestad 3y ago

Going from 11 to 21 is a lot easier.

leapis 3y ago
Depends- one of the hardest parts of the 11-20 upgrade for us was that cms gc was removed. If you run a bunch of different microservices with distinct allocation profiles, all with high allocation pressure and performance constraints, and you've accomplished this w/ the help of a very fine-tuned CMS setup, migrating that over to G1/ZGC is non-trivial
- hmottestad 3y ago
  Is that what happened at your company?
  - leapis 3y ago
    Yup. We've clearly benefitted- G1 and generational ZGC have large advantages over CMS- but it's a lot of experimentation and trial-and-error to get there, whereas other deprecations/removals are usually easier to resolve.
    - kaba0 3y ago
      Isn't the default config correct for pretty much all workloads, unless you have very special requirements? Like, at most one should just change the target max pause time in case of G1, depending on whether they prefer better throughput at the price of worse latency, or the reverse.
- xxs 3y ago
  Java sort of suck for microservices (microservices suck on their own) as it has relatively high bootstrap cost. High allocation rate feels weird with micro services - I suppose that depends a lot on the coding style. G1GC is meant for generally large setups, with several cores at least. E.g. the default setup of 2048 areas on 2GB heap means, allocations over 1MB require special care.
  - threeseed 3y ago
    If you GraalVM Native Image or one of the frameworks based on it then bootstrap cost disappears: https://quarkus.io https://quarkus.io
    - wice 3y ago
      GraalVm is great, it made our Spring REST API app go from 10+ seconds to 0.5 seconds on startup (not to mention the lower mem and cpu requirements). Except… when we try to build it with Jenkins on a Kubernetes cluster, this happens: https://github.com/oracle/graal/issues/7182 https://github.com/oracle/graal/issues/7182
- bberrry 3y ago
  I can't help but think if you're teetering on a knife's edge, only holding on thanks to hyper tuned GC params, then you should take a step back and consider getting out of that predicament.

taf2 3y ago

do/i/still/need/to/create/sub/directories/for/the/things/i/want/namespace?

mdaniel 3y ago
Only if you're using vim like someone from the 70s, otherwise any sane IDE handles those things for you But, yes, namespaces are still mapped to paths, it's not like they rewrote the JVM to use blockchain or something
- ttyyzz 3y ago
  Yeah I really like my IDE doing stuff in the background without me knowing shit about it.
  - piva00 3y ago
    Yeah, I do like my IDE doing the tedious work for me. It's also really nice to unzip any JAR I need to troubleshoot and know exactly where to navigate to find exactly the file with the code I need. I like Golang a lot but the standardisation and verbosity in Java-land has some benefits after you get used to it enough to learn to ignore the boilerplate, it's pretty good to have some kind of consistency enforced by the VM when working in large codebases.
    - quickthrower2 3y ago
      Yes some C# codebases end up with wildly inconsistent namespacing as you can do anything you like
  - threeseed 3y ago
    I don't understand how it is doing stuff in the background. You literally ask it to move some class and then it does it. And it's very obvious what it's doing.
  - Too 3y ago
    Then you’d be thrilled to hear about all the stuff your NVME drivers are doing in the background without you knowing shit about it. Or maybe you prefer to engrave your ones and zeroes in stone by hand? Abstractions exist for a reason. In Java, that abstraction is coding in classes and packages, not files of text.

kyawzazaw 3y ago

8 to 17 for us

minhtran 3y ago
Try with 8 --> 11 first then 11 --> 17
- kyawzazaw 3y ago
  we are going ahead to 17. too much resources spent to do an intermediate step

MBCook 3y ago

We (finally) upgraded last year from 8 to 17. Lots of nice things, I’m so glad we were finally able to. But it was a big project due to some dependencies and how some things were done internally. I can’t wait for 21, but I’m not sure when we’ll switch. At least it will be trivial compared to leaving 8.

rendaw 3y ago

What were the backward incompatibilities preventing that move? I thought Java was pretty backward compatible, but I've heard this a lot.

chii 3y ago
It's more likely that there's some dependency that is not easy to upgrade, because the upgrade also includes api changes (from the dependency, not from the jdk). Compound this with multiple dependencies that exhibit this issue. If you have a "legacy" application that does not require active development, there's zero business incentive to invest into the upgrade. Unless you could prove value in having the upgrade, it just doesn't get prioritized.
wscp-dev 3y ago
Java has in recent times actually removed some apis from the standard library, and made some inaccessible (undocumented internal apis especially) so any advanced frameworks that use them would have been affected.

deleted 3y ago

[deleted]

sebazzz 3y ago

7 -> 8, but JBOSS 6 is a pain to migrate away from.

approxim8ion 3y ago

We made the jump from 8 to 17 this year! Some of our developers of course still write 1.6 level code, of course