7 ms·

Honestly: the Java environment is exceedingly good at that. Backwards incompatible changes are truly minimal, and only those that are strictly necessary are add

Honestly: the Java environment is exceedingly good at that. Backwards incompatible changes are truly minimal, and only those that are strictly necessary are added. And since Java 8 the language is pretty nice and offers good functional idioms. Of course, major versions of libraries still change. But there's no match with the JS approach.

lvh 7y ago
I agreed until the disaster that was Jigsaw. Maybe Jigsaw didn't impact you particularly hard, but you can't argue the JVM has a policy of minimal backwards incompatible changes given that debacle.
- chrisseaton 7y ago
  I work on Java at a really deep level, and I haven't had to interact with Jigsaw at all. What is it breaking for you?
  - brabel 7y ago
    A lot of things like older versions of Gradle (which at some point was a blocker to move to Java 9, but not now), Groovy (also fixed, but still has some warnings), which we use heavily for tests, several reflection-heavy frameworks (think dependency injection, annotation-processors etc), which to this day require some ugly hacks like --patch-module to "open" packages, JUnit tests (which also need the same hacks to work), even the location of resources loaded with class.getResource() had to be modified when modularizing a jar, so that resources go into the proper packages that are visible to the loader... You seriously didn't suffer any of these?
    - chrisseaton 7y ago
      No I didn’t experience any issues like that myself.
- dhash 7y ago
  I’m a full time scala developer and have had basically no problems taking longer than a day to in moving to the LTS releases of 9+. It’s probably pretty helpful that the scala ecosystem doesn’t depend much on non-well trodden parts of the JDK
jrs95 7y ago
The downside is that also means a lot of the core APIs are a huge pain in the ass to work with, especially relative to something like Python, and the “solution” to this problem ends up being something like Spring which has to use so much reflection and metaprogramming to accomplish what it does that it also relies heavily on exceptions for control flow. So without even getting into the other issues, debugging becomes a lot more complicated than it would be otherwise. Personally I would second Go as a good answer for this. It has its limitations, but it’s simplicity and it’s standard library more than make up for that from a pragmatic standpoint imo
- nine_k 7y ago
  Either you have a stable platform, and it reflects the state of the art form the year of its inception, or you have a platform that keeps on improving, but this means you need to change your code along with it, to keep up with the improvements. You can't have it both ways, OTOH current JVM can still correctly run bytecode compiled by Java 1.0.1 (or maybe even earlier), so the backwards compatibility is indeed excellent.
  - mcny 7y ago
    I am not a go programmer but I would love to revisit this conversation but with golang twenty years from now. Please correct me if I am wrong but I believe golang is essentially complete, right? and golang programmers like golang?
    - Alupis 7y ago
      > Please correct me if I am wrong but I believe golang is essentially complete, right I'm confident every programming language thought it was complete at some point... but eventually it's users demand some new "hot" feature and then you're back to releasing new versions again. The C programming language just had a release in June 2018, C18. For a language released 47 years ago... and it's a pretty basic language compared to most other languages. Fortran was released 62 years ago, and just released Fortran 2018 in November of 2018.
    - 7y ago
deleted 7y ago
[deleted]
CamouflagedKiwi 7y ago
Yet we have multiple versions of Java at work (8 and 11) because some (pretty large) third-party components don't support the newer versions yet. Plus for things that do work there are a bunch of irritating warnings and whatnot. It's not "exceedingly good" at it, it's just alright. Go has done much better for us in this area.
- hgtr 7y ago
  Go has the whole gomodules thing, which I’m not a huge fan of. Go with vendored dependencies sounds really stable.
  - hsaliak 7y ago
    Pretty sure generics are coming, and this is going to change best practices, and cause re-writes.
  - sheeshkebab 7y ago
    go mod vendor is what you are looking for then
chaostheory 7y ago
How are people adapting to Oracle’s licensing changes?
- jakebasile 7y ago
  It's not really that big a deal in my experience. We switched to the Corretto[1] distribution of the OpenJDK from Amazon and it was seamless. If you want newer versions of the JDK, you can get them directly from Oracle[2] still, or from alternatives like AdoptOpenJDK[3]. [1]: https://aws.amazon.com/corretto/ https://aws.amazon.com/corretto/ [2]: https://jdk.java.net/13/ https://jdk.java.net/13/ [3]: https://adoptopenjdk.net https://adoptopenjdk.net
- brabel 7y ago
  The biggest change I've seen is that people are using OpenJDK itself (rather than Oracle's official distribution) a lot more, not only from the official OpenJDK distribution, but also the new Amazon's Corretto version, Azul's Zulu (the one I use at work, which has been backporting lots of security improvements to Java 8, which is very useful!), RedHat's OpenJDK, and even AdoptOpenJDK, all of which are completely free and open source... If you want to quickly and easily switch between distributions, I highly recommend https://sdkman.io/ https://sdkman.io/ - it lets you install and use any of the above mentioned JVMs with a simple CLI... e.g. `sdk use 13.0.1.j9-adpt` or `sdk use java 8.0.232-zulu`. I would guess that Oracle's JVM popularity has gone down from around 75% of Java users, to something like 20% after the changes, even though I don't actually have the numbers.
outworlder 7y ago
> Honestly: the Java environment is exceedingly good at that. I would argue that the .NET Framework is way better. The way you can have multiple versions installed side by side and have the framework pick the correct one to run is awesome. Granted, you can do something similar with the JVM by mucking around with env vars, but it's not the same thing.
- scarface74 7y ago
  Well, .Net Framework is analogous to Python 2.7. It will never receive anything but compatibility, security, and bug fixes going forward according to MS. The Future is .Net Core.
  - tahdig 7y ago
    Just for the sake of redundancy: Python 2.7 is not getting any kind of updates including security and bugfixes.
vvillena 7y ago
Not really. The newer open versions still don't match Oracle JDK 8. Wanna bundle a JVM with your app so your users don't have to worry about the Java runtime? Well, you can't do that anymore. Wanna use JavaFX? You have to jump to Java 11 and hope your dependencies don't fail with module packaging errors. Do you use Scala? GLHF. Standing still in the Java ecosystem is fine. Keeping on with the advances is painful and exhausting. The Java tech stack is awesome when it works, but to solve issues you have to go so deep into the tech stack that I'm starting to think it just can't be done unless you're at least a mid-sized company with JVM specialists on the payroll. Not developers, but systems people.
- sgift 7y ago
  > Wanna bundle a JVM with your app so your users don't have to worry about the Java runtime? Why would that be the case? > Wanna use JavaFX? You have to jump to Java 11 and hope your dependencies don't fail with module packaging errors. Dependencies which still fail with module errors are basically abandoned and should probably be replaced. But even for those there's an escape hatch if you really want to continue using them, so that seems to be a non-issue? > The Java tech stack is awesome when it works, but to solve issues you have to go so deep into the tech stack that I'm starting to think it just can't be done unless you're at least a mid-sized company with JVM specialists on the payroll. Not developers, but systems people. I've worked either directly or indirectly with so many companies of all sizes using Java without any dedicated JVM specialists I'm pretty sure you're doing something very, very wrong with all the problems you seem to have.
  - vvillena 7y ago
    > Why would that be the case? I have a desktop Java app with platform-specific installers (.msi, .deb, .dmg). The Windows and Mac installers include a Java runtime, so the user doesn't have to worry about installing an external runtime. I'm forced to use Oracle JVM, because it's the only Java distribution that includes the tools needed. There's ongoing development on a tool that should bring these and more related features to the open JVMs, but it's not done yet. > Dependencies which still fail with module errors are basically abandoned and should probably be replaced. But even for those there's an escape hatch if you really want to continue using them, so that seems to be a non-issue? The issue is that the upgrade path isn't smooth. I have to upgrade everything at the same time, because what works on Java 11 doesn't work in Java 8, and viceversa. It makes everything way harder than it should be, if there was a clear migration path. > I've worked either directly or indirectly with so many companies of all sizes using Java without any dedicated JVM specialists I'm pretty sure you're doing something very, very wrong with all the problems you seem to have. What I do falls into a niche. It's not "very wrong" but it's uncommon. The main issue is that Java was a non-issue, a stable platform to build upon. But the recent Oracle license change forced us to move to fully open versions of Java that do not have the same features, do not bundle the same libraries, and do not have documentation detailing all these differences. I'm not asking for a community to finish whatever feature I need, or for a company to make what I need free to use. I'm just trying to explain my own problems caused by Oracle forcing us to move to open distributions of the Java platform.
Marazan 7y ago
Except, you know, fundamental stuff like how many cores does the JRE think it is running on. The dance over that as we've gone from 8 to 9 to 10 to 11 is mind boggling.

lvh 7y ago

I agreed until the disaster that was Jigsaw. Maybe Jigsaw didn't impact you particularly hard, but you can't argue the JVM has a policy of minimal backwards incompatible changes given that debacle.

chrisseaton 7y ago
I work on Java at a really deep level, and I haven't had to interact with Jigsaw at all. What is it breaking for you?
- brabel 7y ago
  A lot of things like older versions of Gradle (which at some point was a blocker to move to Java 9, but not now), Groovy (also fixed, but still has some warnings), which we use heavily for tests, several reflection-heavy frameworks (think dependency injection, annotation-processors etc), which to this day require some ugly hacks like --patch-module to "open" packages, JUnit tests (which also need the same hacks to work), even the location of resources loaded with class.getResource() had to be modified when modularizing a jar, so that resources go into the proper packages that are visible to the loader... You seriously didn't suffer any of these?
  - chrisseaton 7y ago
    No I didn’t experience any issues like that myself.
dhash 7y ago
I’m a full time scala developer and have had basically no problems taking longer than a day to in moving to the LTS releases of 9+. It’s probably pretty helpful that the scala ecosystem doesn’t depend much on non-well trodden parts of the JDK

jrs95 7y ago

The downside is that also means a lot of the core APIs are a huge pain in the ass to work with, especially relative to something like Python, and the “solution” to this problem ends up being something like Spring which has to use so much reflection and metaprogramming to accomplish what it does that it also relies heavily on exceptions for control flow. So without even getting into the other issues, debugging becomes a lot more complicated than it would be otherwise. Personally I would second Go as a good answer for this. It has its limitations, but it’s simplicity and it’s standard library more than make up for that from a pragmatic standpoint imo

nine_k 7y ago
Either you have a stable platform, and it reflects the state of the art form the year of its inception, or you have a platform that keeps on improving, but this means you need to change your code along with it, to keep up with the improvements. You can't have it both ways, OTOH current JVM can still correctly run bytecode compiled by Java 1.0.1 (or maybe even earlier), so the backwards compatibility is indeed excellent.
- mcny 7y ago
  I am not a go programmer but I would love to revisit this conversation but with golang twenty years from now. Please correct me if I am wrong but I believe golang is essentially complete, right? and golang programmers like golang?
  - Alupis 7y ago
    > Please correct me if I am wrong but I believe golang is essentially complete, right I'm confident every programming language thought it was complete at some point... but eventually it's users demand some new "hot" feature and then you're back to releasing new versions again. The C programming language just had a release in June 2018, C18. For a language released 47 years ago... and it's a pretty basic language compared to most other languages. Fortran was released 62 years ago, and just released Fortran 2018 in November of 2018.
  - 7y ago

deleted 7y ago

[deleted]

CamouflagedKiwi 7y ago

Yet we have multiple versions of Java at work (8 and 11) because some (pretty large) third-party components don't support the newer versions yet. Plus for things that do work there are a bunch of irritating warnings and whatnot. It's not "exceedingly good" at it, it's just alright. Go has done much better for us in this area.

hgtr 7y ago
Go has the whole gomodules thing, which I’m not a huge fan of. Go with vendored dependencies sounds really stable.
- hsaliak 7y ago
  Pretty sure generics are coming, and this is going to change best practices, and cause re-writes.
- sheeshkebab 7y ago
  go mod vendor is what you are looking for then

chaostheory 7y ago

How are people adapting to Oracle’s licensing changes?

jakebasile 7y ago
It's not really that big a deal in my experience. We switched to the Corretto[1] distribution of the OpenJDK from Amazon and it was seamless. If you want newer versions of the JDK, you can get them directly from Oracle[2] still, or from alternatives like AdoptOpenJDK[3]. [1]: https://aws.amazon.com/corretto/ https://aws.amazon.com/corretto/ [2]: https://jdk.java.net/13/ https://jdk.java.net/13/ [3]: https://adoptopenjdk.net https://adoptopenjdk.net
brabel 7y ago
The biggest change I've seen is that people are using OpenJDK itself (rather than Oracle's official distribution) a lot more, not only from the official OpenJDK distribution, but also the new Amazon's Corretto version, Azul's Zulu (the one I use at work, which has been backporting lots of security improvements to Java 8, which is very useful!), RedHat's OpenJDK, and even AdoptOpenJDK, all of which are completely free and open source... If you want to quickly and easily switch between distributions, I highly recommend https://sdkman.io/ https://sdkman.io/ - it lets you install and use any of the above mentioned JVMs with a simple CLI... e.g. `sdk use 13.0.1.j9-adpt` or `sdk use java 8.0.232-zulu`. I would guess that Oracle's JVM popularity has gone down from around 75% of Java users, to something like 20% after the changes, even though I don't actually have the numbers.

outworlder 7y ago

> Honestly: the Java environment is exceedingly good at that. I would argue that the .NET Framework is way better. The way you can have multiple versions installed side by side and have the framework pick the correct one to run is awesome. Granted, you can do something similar with the JVM by mucking around with env vars, but it's not the same thing.

scarface74 7y ago
Well, .Net Framework is analogous to Python 2.7. It will never receive anything but compatibility, security, and bug fixes going forward according to MS. The Future is .Net Core.
- tahdig 7y ago
  Just for the sake of redundancy: Python 2.7 is not getting any kind of updates including security and bugfixes.

vvillena 7y ago

Not really. The newer open versions still don't match Oracle JDK 8. Wanna bundle a JVM with your app so your users don't have to worry about the Java runtime? Well, you can't do that anymore. Wanna use JavaFX? You have to jump to Java 11 and hope your dependencies don't fail with module packaging errors. Do you use Scala? GLHF. Standing still in the Java ecosystem is fine. Keeping on with the advances is painful and exhausting. The Java tech stack is awesome when it works, but to solve issues you have to go so deep into the tech stack that I'm starting to think it just can't be done unless you're at least a mid-sized company with JVM specialists on the payroll. Not developers, but systems people.

sgift 7y ago
> Wanna bundle a JVM with your app so your users don't have to worry about the Java runtime? Why would that be the case? > Wanna use JavaFX? You have to jump to Java 11 and hope your dependencies don't fail with module packaging errors. Dependencies which still fail with module errors are basically abandoned and should probably be replaced. But even for those there's an escape hatch if you really want to continue using them, so that seems to be a non-issue? > The Java tech stack is awesome when it works, but to solve issues you have to go so deep into the tech stack that I'm starting to think it just can't be done unless you're at least a mid-sized company with JVM specialists on the payroll. Not developers, but systems people. I've worked either directly or indirectly with so many companies of all sizes using Java without any dedicated JVM specialists I'm pretty sure you're doing something very, very wrong with all the problems you seem to have.
- vvillena 7y ago
  > Why would that be the case? I have a desktop Java app with platform-specific installers (.msi, .deb, .dmg). The Windows and Mac installers include a Java runtime, so the user doesn't have to worry about installing an external runtime. I'm forced to use Oracle JVM, because it's the only Java distribution that includes the tools needed. There's ongoing development on a tool that should bring these and more related features to the open JVMs, but it's not done yet. > Dependencies which still fail with module errors are basically abandoned and should probably be replaced. But even for those there's an escape hatch if you really want to continue using them, so that seems to be a non-issue? The issue is that the upgrade path isn't smooth. I have to upgrade everything at the same time, because what works on Java 11 doesn't work in Java 8, and viceversa. It makes everything way harder than it should be, if there was a clear migration path. > I've worked either directly or indirectly with so many companies of all sizes using Java without any dedicated JVM specialists I'm pretty sure you're doing something very, very wrong with all the problems you seem to have. What I do falls into a niche. It's not "very wrong" but it's uncommon. The main issue is that Java was a non-issue, a stable platform to build upon. But the recent Oracle license change forced us to move to fully open versions of Java that do not have the same features, do not bundle the same libraries, and do not have documentation detailing all these differences. I'm not asking for a community to finish whatever feature I need, or for a company to make what I need free to use. I'm just trying to explain my own problems caused by Oracle forcing us to move to open distributions of the Java platform.

Marazan 7y ago

Except, you know, fundamental stuff like how many cores does the JRE think it is running on. The dance over that as we've gone from 8 to 9 to 10 to 11 is mind boggling.