4 ms·

But they require a new JDK version, and a surprisingly high amount of Java projects are still stuck on JDK8.

pron 4y ago
JDK 8 is now a minority, and if we count only projects that are still undergoing significant development it's a significantly smaller minority. The main reason some projects are still stuck on 8 is because they use old libraries that have made breaking changes, and don't have resources to adapt their use, let alone take on new ones.
- yakubin 4y ago
  Or they develop for Android. Not a minority.
  - crummy 4y ago
    Are most android devs still working with Java or Kotlin?
    - yakubin 4y ago
      I’ve worked for 2 companies so far which maintain a bit of Android code and neither used Kotlin. GitHub search for “#android language:Java” reports 49K repositories, while “#android language:kotlin” reports 25K repositories. GitHub is biased towards greenfield projects, not legacy corporate codebases, so I’d expect the ratio of Java to Kotlin code in non-open-source software to be much higher. I wouldn’t be surprised if it’s more than 10 times higher.
  - pjmlp 4y ago
    At least the lucky ones having Android 12 as baseline can now make use of Java 11 subset (because as usual Google only takes the parts of standard library they care about).
  - pron 4y ago
    Android isn't Java, but at less than 1/4 the size of the Java ecosystem, even if it were Java it would still be a minority.
- Matthias247 4y ago
  Maybe in the open source world? In some closed source company codebases that are known to me, there were still million lines of code on JDK8, since efforts to port everything to a newer JDK don't necessarily enjoy a high priority. As an application developer in such an environment one then might even not have the possibiltiy to pick the JDK version of their choice on their own, since as you mentioned there might be dependencies which haven't been updated. In such an environment solutions which don't require a JDK upgrade (Lombok, Kotlin, etc) can certainly help developers. If the upgrade is feasible, I would definitely use the new builtin language features.
  - pron 4y ago
    > Maybe in the open source world? Here's a report from New Relic about Java use among their customers (who write closed source) from a year ago, and the Java 8 exodus is continuing: https://newrelic.com/resources/report/2022-state-of-java-ecosystem https://newrelic.com/resources/report/2022-state-of-java-eco.... Java 8 is still definitely used in applications that no longer see much development, and it will be some time for before it mostly disappears, but those applications don't benefit from new libraries either.
- erik_seaberg 4y ago
  The way I heard it, Java 9 breaks Spark 2.4 badly with no good workaround to disable Jigsaw (which we otherwise don’t care about), and that’s is a problem for a lot of data pipelines in our monorepo. It sounds like other large projects also had a lot of trouble working around Jigsaw, especially for proxying and mocking, and you are blocked at least as long as any of your dependencies are blocked (which was also one reason the Python 3 migration was so slow and painful).
  - pron 4y ago
    A lot of code broke on Java 9, but that had little to do with Jigsaw (accessibility remained unchanged from 8 until JDK 16). Code broke because it was not portable and relied on internal implementation details that then changed. Still, Java 8 is now a minority (most applications had to upgrade their non-portable dependencies to new versions).

pron 4y ago

JDK 8 is now a minority, and if we count only projects that are still undergoing significant development it's a significantly smaller minority. The main reason some projects are still stuck on 8 is because they use old libraries that have made breaking changes, and don't have resources to adapt their use, let alone take on new ones.

yakubin 4y ago
Or they develop for Android. Not a minority.
- crummy 4y ago
  Are most android devs still working with Java or Kotlin?
  - yakubin 4y ago
    I’ve worked for 2 companies so far which maintain a bit of Android code and neither used Kotlin. GitHub search for “#android language:Java” reports 49K repositories, while “#android language:kotlin” reports 25K repositories. GitHub is biased towards greenfield projects, not legacy corporate codebases, so I’d expect the ratio of Java to Kotlin code in non-open-source software to be much higher. I wouldn’t be surprised if it’s more than 10 times higher.
- pjmlp 4y ago
  At least the lucky ones having Android 12 as baseline can now make use of Java 11 subset (because as usual Google only takes the parts of standard library they care about).
- pron 4y ago
  Android isn't Java, but at less than 1/4 the size of the Java ecosystem, even if it were Java it would still be a minority.
Matthias247 4y ago
Maybe in the open source world? In some closed source company codebases that are known to me, there were still million lines of code on JDK8, since efforts to port everything to a newer JDK don't necessarily enjoy a high priority. As an application developer in such an environment one then might even not have the possibiltiy to pick the JDK version of their choice on their own, since as you mentioned there might be dependencies which haven't been updated. In such an environment solutions which don't require a JDK upgrade (Lombok, Kotlin, etc) can certainly help developers. If the upgrade is feasible, I would definitely use the new builtin language features.
- pron 4y ago
  > Maybe in the open source world? Here's a report from New Relic about Java use among their customers (who write closed source) from a year ago, and the Java 8 exodus is continuing: https://newrelic.com/resources/report/2022-state-of-java-ecosystem https://newrelic.com/resources/report/2022-state-of-java-eco.... Java 8 is still definitely used in applications that no longer see much development, and it will be some time for before it mostly disappears, but those applications don't benefit from new libraries either.
erik_seaberg 4y ago
The way I heard it, Java 9 breaks Spark 2.4 badly with no good workaround to disable Jigsaw (which we otherwise don’t care about), and that’s is a problem for a lot of data pipelines in our monorepo. It sounds like other large projects also had a lot of trouble working around Jigsaw, especially for proxying and mocking, and you are blocked at least as long as any of your dependencies are blocked (which was also one reason the Python 3 migration was so slow and painful).
- pron 4y ago
  A lot of code broke on Java 9, but that had little to do with Jigsaw (accessibility remained unchanged from 8 until JDK 16). Code broke because it was not portable and relied on internal implementation details that then changed. Still, Java 8 is now a minority (most applications had to upgrade their non-portable dependencies to new versions).