9 ms·

And here I am still on Java 8 :/

rafaelturk 4y ago
Impressive how many companies are stuck on quite old java versions. We are a core API for payments services, and we need to force our customers to upgrade to newer Java versions as most of them don't support newer encriptyion protocols
- oaiey 4y ago
  Thank You for your service.
taftster 4y ago
I mean, that's OK though. Not sure why this is considered such a bad thing. You're missing out on some new language features, sure, but Java 8 is still reliable and rock solid. There's lots of companies that have hesitation or even inability to upgrade, hopefully there's at least some initiative and/or direction to do so. A company that is head-in-sand deliberately not upgrading from Java 8 is one thing. A company that is just being conservative and intentional about the upgrade path, that's another entirely different thing. I don't mind a company that has been using Java so much that it's just a slow process for them to get on the next thing. Old libraries that need to be recompiled for Java modules, etc. Hopefully it happens for you soon.
- logistark 4y ago
  I think that the main problem upgrading beyond Java 8 is Java 9 and module system and a lot of javax package classes that were removed. It will be very helpful a tool that can detect what modules or classes that are being used by your codebase and add them as maven or gradle dependencies and add them to the classpath.
  - rerdavies 4y ago
    The main problem with upgrading beyond Java 8 is that it's Android! And we all know how THAT went.
- FalconSensei 4y ago
  > I mean, that's OK though. Not sure why this is considered such a bad thing For existing software, sure. But the problem I guess is when there are a lot of newer projects starting and everyone is stuck on the older version
  - deleted 4y ago
    [deleted]
  - taftster 4y ago
    Totally fair. I guess I would hope in that case that the new effort would target a modern Java release, preferably Java 17 or greater. If a company is sticking with Java 8 for new initiatives, yeah, they probably have a culture problem and are not going to be happy with that decision.
- paulmd 4y ago
  There's very little reason not to upgrade from Java 8 at this point. Everything should be a drop-in replacement and there are significant performance benefits (garbage collection is leagues better) to doing so. The bigger problem is that a lot of places are stuck on Oracle JDK - 8u252 is the last free version so a lot of places just decided they'd never upgrade, nor do they want to look at whether Temurin or Coretto would work for them (the answer is usually yes).
  - TacoSteemers 4y ago
    > Everything should be a drop-in replacement It isn't at all, in my opinion. Consider the introduction of the module system, for example. Some libraries moved out of the core language.
  - taftster 4y ago
    Almost. The Java module system (introduced in Java 9 and enforced in Java 11) still plagues companies and/or slow-to-update libraries. Particularly companies that have written a lot of their own in-house libraries and such. Custom libraries have, unfortunately over the years, picked up the bad habits (by forking/following public libraries) relying on reflection and packages that shouldn't be directly used (sun.* packages, etc.). So companies are wedged in because they made the poor decision to rely on private packages. And now, Java 11+ enforces this by default. There are open source Java libraries today that don't run unless you "add-exports" to basically everything. google-java-format comes to mind, because it's using an internal java code parser from the JDK, for example.
    - dtech 4y ago
      In the latest LTS those all can still be enabled, so while it is a serious problem when they are finally removed, for now it's not really a good reason to block an upgrade.
      - taftster 4y ago
        I think that's fair. Yes, there is an escape hatch currently available. But what is hard is knowing if your application is relying on any internal/private behavior that it shouldn't. Since the dependency hierarchy of most Java projects is very deep, it's hard to know if any dependencies of A -> B -> C -> D are going to call into restricted areas. You might not even know you have a problem until runtime, because you've --add-exports everything and now you have a stacktrace to try and deal with in production. But yes, maybe not a good reason to completely block an upgrade. It's just postponing the pain, though.
0xDEF 4y ago
It's interesting how the introduction of "modules" has forced so many to stick with C++17 and Java 8.
- Longhanks 4y ago
  C++ has barely any feature complete compiler implementations and build systems aren’t ready for all of its additions, either (CMake and modules in particular). libstdc++ and libc++, gcc and clang are all not ready for production use or rather untested and/or buggy. Unless you’re targeting MSBuild Visual Studio Solutions and Windows only, C++17 is currently the most up to date, stable, and battle-proven version.
  - acuozzo 4y ago
    It's a shame "C with classes", as C++ originally was, didn't stick around for parallel development. I work with C daily and I'm well aware of its many shortcomings (e.g. its huge list of undefined behavior and its PDP11-centric view of modern architectures), but with some effort I believe it could function as a semi-portable second-level intermediate representation. Nim uses it as such, IIRC. Compiling to C first would introduce some of its own issues, for sure, but I imagine doing so would alleviate the pressure the C++ standards committee puts on compiler vendors each time they expand the size of the kitchen sink.
    - soulbadguy 4y ago
      Rust ?
      - acuozzo 4y ago
        Rust compiles to C and then passes that C to a C compiler to generate machine code?
  - ghostwriter 4y ago
    > gcc and clang are all not ready for production use or rather untested and/or buggy. Which items from this table are lying about GCC v11 support of C++20? [1] Which of the features are buggy in GCC v11-12? [1] https://en.cppreference.com/w/cpp/compiler_support#cpp20 https://en.cppreference.com/w/cpp/compiler_support#cpp20
TheRealPomax 4y ago
Perfectly fine for already written codebases or codebases that need to target hardware that's stuck in the past? Just don't use it for new projects on modern hardware. Be on at least the current LTS version for that and enjoy a much more expressive language on a much better JVM.
SPBS 4y ago
My codebase at work is written in Java 8, I honestly don't see what other benefits upgrading the language would bring. There's already so much business code written in the old Java 8 style (which works), don't go trying to change how the code is written now. To me Java 8 is simple and boring like Go, with some imperfections like the lack of a native map data type. I'd still upgrade for the new VM's better performance/security patches or whatever, but I don't need any language changes.
- spacephysics 4y ago
  Big reason is security patches. But if the services are running in a VPN and don’t interact with outside world, it’s fine
  - keester 4y ago
    My understanding is that jdk8 has support from Oracle until 2030.
    - kaba0 4y ago
      paid support. I’m not convinced that most of those companies that use older versions even know where their JDK comes from.
- riku_iki 4y ago
  We migrated our codebase because multi line string literals somewhere in jdk14 made writing large SQL queries in java code so much easier.
- dtech 4y ago
  I unfortunately encounter this mindset so much in Java programmers, and the similar "we don't need no feature X" even if the feature has proven themselves for a long time in a large amount of languages. I'm hesitant to bring it up, but I see a lot of Blub Paradox [1] among Java programmers. Heck, a lot of places disallow `var`, while over here in Kotlin-Python-Rust-C#-Typescript-Go-etc-land that's been the default since forever. Taking this comment in good faith, the following language features from 9+ are incredibly useful for everyday programmers, you should give them a serious try before dismissing them: - `var` local type inference - record classes - text blocks - switch expressions - sealed classes and interfaces [1] http://paulgraham.com/avg.html http://paulgraham.com/avg.html

Impressive how many companies are stuck on quite old java versions. We are a core API for payments services, and we need to force our customers to upgrade to newer Java versions as most of them don't support newer encriptyion protocols

oaiey 4y ago
Thank You for your service.

taftster 4y ago

I mean, that's OK though. Not sure why this is considered such a bad thing. You're missing out on some new language features, sure, but Java 8 is still reliable and rock solid. There's lots of companies that have hesitation or even inability to upgrade, hopefully there's at least some initiative and/or direction to do so. A company that is head-in-sand deliberately not upgrading from Java 8 is one thing. A company that is just being conservative and intentional about the upgrade path, that's another entirely different thing. I don't mind a company that has been using Java so much that it's just a slow process for them to get on the next thing. Old libraries that need to be recompiled for Java modules, etc. Hopefully it happens for you soon.

logistark 4y ago
I think that the main problem upgrading beyond Java 8 is Java 9 and module system and a lot of javax package classes that were removed. It will be very helpful a tool that can detect what modules or classes that are being used by your codebase and add them as maven or gradle dependencies and add them to the classpath.
- rerdavies 4y ago
  The main problem with upgrading beyond Java 8 is that it's Android! And we all know how THAT went.
FalconSensei 4y ago
> I mean, that's OK though. Not sure why this is considered such a bad thing For existing software, sure. But the problem I guess is when there are a lot of newer projects starting and everyone is stuck on the older version
- deleted 4y ago
  [deleted]
- taftster 4y ago
  Totally fair. I guess I would hope in that case that the new effort would target a modern Java release, preferably Java 17 or greater. If a company is sticking with Java 8 for new initiatives, yeah, they probably have a culture problem and are not going to be happy with that decision.
paulmd 4y ago
There's very little reason not to upgrade from Java 8 at this point. Everything should be a drop-in replacement and there are significant performance benefits (garbage collection is leagues better) to doing so. The bigger problem is that a lot of places are stuck on Oracle JDK - 8u252 is the last free version so a lot of places just decided they'd never upgrade, nor do they want to look at whether Temurin or Coretto would work for them (the answer is usually yes).
- TacoSteemers 4y ago
  > Everything should be a drop-in replacement It isn't at all, in my opinion. Consider the introduction of the module system, for example. Some libraries moved out of the core language.
- taftster 4y ago
  Almost. The Java module system (introduced in Java 9 and enforced in Java 11) still plagues companies and/or slow-to-update libraries. Particularly companies that have written a lot of their own in-house libraries and such. Custom libraries have, unfortunately over the years, picked up the bad habits (by forking/following public libraries) relying on reflection and packages that shouldn't be directly used (sun.* packages, etc.). So companies are wedged in because they made the poor decision to rely on private packages. And now, Java 11+ enforces this by default. There are open source Java libraries today that don't run unless you "add-exports" to basically everything. google-java-format comes to mind, because it's using an internal java code parser from the JDK, for example.
  - dtech 4y ago
    In the latest LTS those all can still be enabled, so while it is a serious problem when they are finally removed, for now it's not really a good reason to block an upgrade.
    - taftster 4y ago
      I think that's fair. Yes, there is an escape hatch currently available. But what is hard is knowing if your application is relying on any internal/private behavior that it shouldn't. Since the dependency hierarchy of most Java projects is very deep, it's hard to know if any dependencies of A -> B -> C -> D are going to call into restricted areas. You might not even know you have a problem until runtime, because you've --add-exports everything and now you have a stacktrace to try and deal with in production. But yes, maybe not a good reason to completely block an upgrade. It's just postponing the pain, though.

0xDEF 4y ago

It's interesting how the introduction of "modules" has forced so many to stick with C++17 and Java 8.

Longhanks 4y ago
C++ has barely any feature complete compiler implementations and build systems aren’t ready for all of its additions, either (CMake and modules in particular). libstdc++ and libc++, gcc and clang are all not ready for production use or rather untested and/or buggy. Unless you’re targeting MSBuild Visual Studio Solutions and Windows only, C++17 is currently the most up to date, stable, and battle-proven version.
- acuozzo 4y ago
  It's a shame "C with classes", as C++ originally was, didn't stick around for parallel development. I work with C daily and I'm well aware of its many shortcomings (e.g. its huge list of undefined behavior and its PDP11-centric view of modern architectures), but with some effort I believe it could function as a semi-portable second-level intermediate representation. Nim uses it as such, IIRC. Compiling to C first would introduce some of its own issues, for sure, but I imagine doing so would alleviate the pressure the C++ standards committee puts on compiler vendors each time they expand the size of the kitchen sink.
  - soulbadguy 4y ago
    Rust ?
    - acuozzo 4y ago
      Rust compiles to C and then passes that C to a C compiler to generate machine code?
- ghostwriter 4y ago
  > gcc and clang are all not ready for production use or rather untested and/or buggy. Which items from this table are lying about GCC v11 support of C++20? [1] Which of the features are buggy in GCC v11-12? [1] https://en.cppreference.com/w/cpp/compiler_support#cpp20 https://en.cppreference.com/w/cpp/compiler_support#cpp20

TheRealPomax 4y ago

Perfectly fine for already written codebases or codebases that need to target hardware that's stuck in the past? Just don't use it for new projects on modern hardware. Be on at least the current LTS version for that and enjoy a much more expressive language on a much better JVM.

SPBS 4y ago

My codebase at work is written in Java 8, I honestly don't see what other benefits upgrading the language would bring. There's already so much business code written in the old Java 8 style (which works), don't go trying to change how the code is written now. To me Java 8 is simple and boring like Go, with some imperfections like the lack of a native map data type. I'd still upgrade for the new VM's better performance/security patches or whatever, but I don't need any language changes.

spacephysics 4y ago
Big reason is security patches. But if the services are running in a VPN and don’t interact with outside world, it’s fine
- keester 4y ago
  My understanding is that jdk8 has support from Oracle until 2030.
  - kaba0 4y ago
    paid support. I’m not convinced that most of those companies that use older versions even know where their JDK comes from.
riku_iki 4y ago
We migrated our codebase because multi line string literals somewhere in jdk14 made writing large SQL queries in java code so much easier.
dtech 4y ago
I unfortunately encounter this mindset so much in Java programmers, and the similar "we don't need no feature X" even if the feature has proven themselves for a long time in a large amount of languages. I'm hesitant to bring it up, but I see a lot of Blub Paradox [1] among Java programmers. Heck, a lot of places disallow `var`, while over here in Kotlin-Python-Rust-C#-Typescript-Go-etc-land that's been the default since forever. Taking this comment in good faith, the following language features from 9+ are incredibly useful for everyday programmers, you should give them a serious try before dismissing them: - `var` local type inference - record classes - text blocks - switch expressions - sealed classes and interfaces [1] http://paulgraham.com/avg.html http://paulgraham.com/avg.html