It's not "exceedingly good" at it, it's just alright. Go has done much better for us in this area.
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.
You seriously didn't suffer any of these?
It’s probably pretty helpful that the scala ecosystem doesn’t depend much on non-well trodden parts of the JDK
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
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.
> You can't have it both ways,
You can have a continuously improving platform with full backward compatibility, and all the improvements that aren't just efficiency of established operations are opt-in.
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.
I'm also coming around on Go. The simplicity was a turn off at first, but now that I've used it to implement a graphql server I like the simplicity. I don't want to have to be a programming language researcher to quickly get work done. IMO Go delivers in that mission.
Can you give some references for the patents issue you mentioned?
With Spring-Boot you can even start treating Spring and friends like a "Black Box", and stop caring about how it does what it does.
Springboot takes an opinionated approach to a lot of things, but always lets you override it and do whatever you want wherever you want.
I suppose that's more of a greybox...
You end up making your own framework that has all that in it, so that you just change a few things here and there and can start getting to the business logic that much quicker.
Then you realize you're maintaining all of that code... when you'd much rather maintain the business logic bits...
Which leads to using Spring Boot and letting them maintain everything else.
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.
The Future is .Net Core.
Python 2.7 is not getting any kind of updates including security and bugfixes.
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.
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.
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.
I'm currently working on a web service that was written under Java 8.
For giggles, I just ran the end-to-end tests suite under Java 8, 11, and 13. The only error I got was an incompatibility with Google's Error Prone linter, which I was able to fix with one line change.
This represents a few hundred thousand lines of production code that works just fine under every important JDK in use today.
Oracle JDK 8 contained some small parts that were proprietary. And they mostly had the proper package name. You took the risk.
> 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.
You mean, bundling a JVM exactly like all JetBrains IDEs currently do?
> Wanna use JavaFX? You have to jump to Java 11 and hope your dependencies don't fail with module packaging errors.
JavaFX is a bit of a strange thing, and yes, it can be painful. And some modules struggle with the new module system. The module system is a breaking change, and in fact it took quite a while.
> Scala
That's a problem with the Scala compiler AFAIK, not with Java.
I did not. Some libraries I depend on did.
> You mean, bundling a JVM exactly like all JetBrains IDEs currently do?
Yes. I'm researching how they do it. Previously it could be done with one command. Jetbrains use their own patched JVM and have JVM experts on their payroll. What they do goes way beyond my current skills.
> That's a problem with the Scala compiler AFAIK, not with Java.
From a JVM point of view, Scala is just one more library. The problem with Scala right now is that it doesn't support the module system. This means yet another dive at a lower level to try to fix any issue that appears.
If you want to quickly and easily switch between distributions, I highly recommend 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.
If you want newer versions of the JDK, you can get them directly from Oracle[2] still, or from alternatives like AdoptOpenJDK[3].
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.