'Java 9, it did break some things,' Oracle bod admits to devs still clinging to version 8 Java has a problem – the language and platform is evolving faster than ever, but many developers are stuck on the five-year-old Java 8. When Trisha Gee, a developer advocate for Java tool company JetBrains, surveyed Twitter ahead of a talk at QCon conference in London this week, 78 per cent stated they were using Java 8 – and …
But that's the thing, Java is not being distinguished between the language itself and the distributed libraries and the run time environment. As far as I know, all old Java code will still "compile" (they haven't altered the syntax), but the issue is incompatibilities with other libraries.
And that's what Oracle is also licensing. They have no control over the language, but if you want their implementations of common libraries in their JDK and JRE, you have to abide by their licensing rules, or find something else.
It's the same with other scripting languages (yes, I went there). The advantage of Python, Perl, Node.JS, etc... is the collection of default libraries and the distribution network of others. I mean, for chrissake, if you had to write bare Python, you'd never do it. Important Whitespace? HAH!
bah, youngsters,
I can still hand code assembler into opcodes..(and count the clock cycles to optimise the code).
Sometimes you also had to work out fancy opcode patterns to save space, 1k rom filled with 2 bytes left but customer wants changes that will take 20bytes
Programmers today wastrels, they throw away MB's to do fuck all.
I can still assemble (though the young uns call it compile nowadays) IBM 360 assembler my Dad wrote before I was born
Old COBOL, FORTRAN, and LISP still generally works fine with the latest implementations, too, provided the programs don't rely too heavily on specifics of the underlying machine.
Our customers routinely build and run COBOL source code from the '80s and '70s, and there's probably some older stuff still in production somewhere. While newer versions of the languages and implementations have lots of new features, backward compatibility remains important. So you can mix COBOL-66 source and OO COBOL source in the same program, and build the thing to run natively or under JVM or CLR.
But as others have pointed out, that's often true for old Java source code too (albeit for a shorter timeframe since Java's only a couple decades old). The big problems are third-party components which aren't compatible with the newer language versions, churn caused by the short-lifetime releases (9 and 10), and the FUD caused by Oracle's change in licensing terms. While there are now a number of viable free Java releases (AdoptOpenJDK, Azul Community, perhaps the Amazon one, maybe some others), there was a period of several months when many organizations didn't have a lot of confidence in any of the available options.
There was a time when only major number updates would break something (other than occasional obscure bugs or features that were not intended for open use). But then the fskers in marketing decided that we should have big number changes because that is what sells, etc. Hence the stupid situation of 8->9 being major pain but 9->10->11 being minor pain.
But Java is not the only language to suffer from braking changes and no sensible mitigation, just look at Python 2.7 -> 3 (but hey, at least they numbered it correctly even if they failed to add a "use 3.X syntax" option to avoid breaking stuff unnecessarily).
braking changes
What? Like going from disc to electromagnetic? ;-)
Sometimes you do have to decide to break an API. Python's move from 2 to 3 has lots of examples of what to avoid but at least it happened. You can sometimes cause more problems in the long term if you're not prepared to break stuff. I think this has affected both C++ and Perl in the past.
Ideally add new stuff provisionally, then start deprecating older stuff, then start removing it, ie. major changes should happen over three major versions and make sure you communicate it. Exceptions prove the rule.
Python 2's EOL in 2020 was announced in 2014, IIRC, and we're now starting to see libraries actively informing users that future versions will not officialy support it, though everyone knows that Python 2 code will still be in production for many years to come. It took us a while to learn to do this, but at least we did.
"Python's move from 2 to 3 has lots of examples of what to avoid but at least it happened."
And the advantage was what? Clearly not much given that 10 years later people are still wrtiting new code in Python 2. 3 should have been an evolutionary change, not a revolutionary one. Backwards compatibility *matters*.
The move from decimal to whole numbering of releases was idiotic, clearly the decision of truly clueless executives acting out of either pure hubris or carnal desire. It's a trend whose origin goes back to Microsoft's moronic adoption of a "model year" paradigm in naming its operating systems that has forced people to become conversant in development build numbers to preserve their own sanity.
"The move from decimal to whole numbering of releases was idiotic,"
Agreed, there is a reason for version numbers and it isn't just to simply denote a newer version. Major.minor.bugfix was a damn useful system and to throw it out was uttely moronic. Firefox went down the same stupid route but have since gone back to decimal numbering though we now have the ridiculous situation of the currentlyl release being 65.0.1.
There is no fundamental reason why your Java code won't run on Java 9+. You may need to change access to old APIs etc. But it's not a different language
Now there is a technical guy who doesn't understand customers. "change access to old APIs" means a new release of a product. Maybe it only means a few small changes, but it might be in a mature product, not in full development, tried & tested by its customers. Now there'll have to be a whole new release, new QA cycle, new bugs, new support contracts for the new version. Customers who have certified that product with other applications or standards now have to redo all their certifications. "change access to old APIs" is not a trivial thing, and it really pisses customers off.
One of the biggest confusing things that we've done is to give the new six-month releases integer version numbers.
So why do it?
The answer, of course, is Marketing. 1.7 -> 1.8 seems like a minor change, 7 -> 8 looks much flashier. A whole new product, new improved features, well worth the upgrade. Except that it isn't, it's just marketing willy-waving. The competition has replaced version "3" with version "4" of their stuff, we can't possibly only replace "3" with "3.1", it will look like we're falling behind.
I have news for you guys, customers aren't as gullible or as stupid as you think they are, and treating them like that is a good way to lose them.
But this is even more strange for Java. The 'customers' are all quite tech savvy, they should also be more risk adverse and would find big number jumps more of an issue than minor version jumps.
As devs prefer stability and not breaking stuff and as a programming language and JDK they aren't goingt ot be comparing to the 'competition'. It's not as if they will re-write their application in python just because Python has started having higher version numbers. Far better to have the 9.x releases all compatible and the 10.x branch potential not compatible with the 9.x releases so you develop to a major version number with assured backwards compatibility for that major release..
The answer is even more sinister (this is Oracle we are talking about) it's about money and lawyers (OK so basically the same thing). If you go to Oracle's site to download the JDK or run times, you'll notice at least two things. First they only support downloads back a couple of versions, and two, their licensing changes are based on major version numbers. If they did the sensible thing and released Java 9.1, 9.2, 9.x it would be all the more obvious just what they are doing. Using major version numbers they can say, we only support the latest couple of versions (even though they are basically the same thing) _unless_ you purchase an expensive support contract with us. You can only down load the _current_ JRE/JDK, _unless_ you purchase an expensive support contract with us.
Oracle thinks that this is good for them as it drives people's perceptions of needing the current version and when they go to Oracle's website to download the JRE they can only get the latest version. Unfortunately, developers realize that; it's a lot of work rewriting working code, and if they are going to have to rewrite it for java 9+ they may as well switch to OpenJDK and avoid the whole Oracle licensing shell game.
What we are seeing is Oracle employees at Oracle panels upset that developers aren't following their master plan.
Major language releases should have a definite, hard good until date such as 5 (many years not to be specific) years from the release of the next major version. This allows for transitional period for devs to migrate code to a new version if they plan to continue the code base. Leisure Larry does not grasp there are 2 different products with Java; the language and the JVM. There are many languages that use the JVM that as long as that language's compiler produces valid byte code they do not care what happens to the language. With the openJDK there is an option to avoid the minions and many will do so.
The update was indeed quite painful from 8 (straight to 11 but all the problems that had to be faced were introduce in 9).
However it turns out that most of the issues were actually caused by Eclipse, which is just plain rubbish in its support of modules, and when it's not rubbish it's just broken. With Eclipse misbehaving at every turn, it made trying to figure out how the module system worked almost impossible. Other IDEs are apparently slightly better.
The module system though is rather hugely complex and overengineered for a lot of Java development. Java's biggest strength was that it was like developing with fluffy Fischer-Price gloves. Any idiot like me could do it, and I have been for 20 years. The upgrade to JDK11 was so difficult I felt like an idiot and couldn't get anything to work. No wonder everyone's sticking with Java 8.
Personally I like vim + javac + make, but ed + javac + Bourne shell scripts would probably be preferable to Eclipse.
Every time I use Eclipse I am amazed at the vast amount of functionality coupled with the vast number of usability mistakes. And I say that despite suffering the grievous UX of Venomous Studio on a regular basis, whenever I have to debug CLR code (which is fairly often, alas). You'd think Eclipse would look better by comparison, but somehow it does not.
We're finishing our update from java 8 (well, we compiled with the jdk 8 using a java 7 target) to java 7, at least on the code side of things, there are still tests to be done. We didn't used a single module so the upgrade was mostly removing the unsupported APIs. I agree with modules being way too complicated (and also not very useful when taking into account our build system), so when we were preparing for the upgrade, I pushed for ignoring them altogether.
Is the major cause of "legacy code" stuck on an old version of a language & platform tools
Unless the change to get software working on new version are quick and easy to implement, then management, with time pressure to add new features, have devs working on other software, will often make a choice to keep software on the old version as cannot spare time / resources. As the old version becomes more and more obsolete, then chances are port to latest and greatest version gets more and more difficult, so even more likely the legacy code languishes on old version.
Obviously other issues can creep in due to lack of upgrade (e.g. security / performance bugs due to being on old version)
Most language / development tool providers are guilty of this.
Full back compatibility might cause oracle (etc.) grief, but would ensure software was updated to use new versions.
Could be in the interest of Oracle etc.
Seen cases where rewrite for new version was so non trivial that decision was made to implement a new version (using different language and toolset) from scratch
It's not just the language. OpenJDK has no installer, which is a significant challenge for some users. It also does not include JavaFX, so you need OpenJFX which also has no installer. Neither OpenJDK nor OpenJFX have a method of notifying users that an update is available either. Most Linux distros seem to be well behind on OpenJDK currency, and quite likely lacking OpenJFX, so even Linux users may have to face the no-installer issue if they want to stay current.
This post has been deleted by its author
If you need an OpenJDK installer, have you tried AdoptOpenJDK or Azul Community?
For JavaFX, my understanding (haven't verified this personally) is that:
- JavaFX for Java 11 is available on Maven Central
- Zulu have their own JavaFX port for both Java 8 and Java 11, which I think is available for Zulu Community (i.e. you don't need the commercial Zulu version to use it)
- Amazon Correto appears to include JavaFX
Basically, widespread opinion seems to be to avoid using the "raw" OpenJDK distribution, and go with AOJ, Azul, Correto, or one of the other maintained distributions.
it is good that languages evolve, but pivotal that old stuff still works. Even tiny small things can break a lot of old code. Even with major restructoring, it should still be possible to keep depreciated parts working. Yes, it might make the language a bit heavier but who cares. As long as old code works and the new stuff works, things should be dandy. There had been recently some change in regex where suddenly unescaped left brace in regex was become illegal. The right way to make the change would have been to allow the new and old syntax to work simultaneously. It is unbelievable in how many places things can break with only tiny changes of the language.
you're having a giraffe!
Removing the reliable way of deploying a thick program to people's desktops basically blocks an awful lot of "older" (but good) java code from even being deployed under these newer Javas.
Yes everyone should be writing web apps these days (c) but there's a lot of enterprise apps that have just been crippled by successive releases of Java just because Oracle wants to ignore that fact that in many cases running a program on a PC is a really good solution to an awful lot of problems. Let's not talk about the addition of mandatory signed JNLP files added as a minor-release that broke hundreds of users of the app wot we wrote, let's just instead look at the shoddy stick that's been rubbed all over JavaFX - a great GUI tool kit that came of age and got added into Java 8 as a standard part of the install. Only to be ejected in Java 11 because - well Desktop.
Oh yeah, and let's mention Paid Support for Java 8 only; although you could instead go to the six-month-cycle of upgrade and carp that's being forced on us; that's if you've worked out a way to deploy the stuff again. Maybe we're back to a network drive with a ".bat" file on... All for another Island for Larry...
>> The problem is "what do you pay?" its the usual complete cluster-cluck of opaque Oracle Pricing designed to make the simplest of situations as complex as possible. Mumble, mumble, grumble.
There are lots of wishes I'd use a time machine for, but top of the list these days would to try to persuade IBM to buy Java; or Redhat. In fact anyone other than Oracle or Microsoft; although these days MS look like softies.
I can't even finish on a joke, because I've found nothing to laugh about recently :(
Funny, but no one expects that perl5 code will run in perl6 (Rakudo would be a better name for the new language perhaps), and perl5 is *still maintained for real*.
Whereas to run the Java for a Chinese Virtual Network Analyzer I bought, that has roughly zero chance of being updated, ever - I had to install an older JRE on my linux system and set it as default instead, since unlike the shebang line in perl, this isn't automatic in Java it would seem. I'm not a java programmer, so it took a bit to get it going again (or I could just throw away >$300 of hardware).
Helpful link: http://ask.xmodulo.com/change-default-java-version-linux.html
I actually have more luck with perl running cross platform without debugging everything for each one. But that's just anecdotal and I write good code and ensure I think about that a little when doing it.
Python 2 and Python 3 were formal "forks" and Python 2 was supported for a long, long time. It is starting to finalize now, though, and Python3 is taking over. JDK8 is not really supported any more, nor did they plan to.
The main problem though was that Oracle let Java get stale and then did a massive release. Bit odd, really.
Except that Python made the situation more obvious and has continued support for 2.7.x for quite sometime. So while the migration to 3 from 2 is not trivial, there was a lot of time to make the migration while the old code was still supported. Or to make a decision if the project was going to be retired.
Java developers skipping versions 9 and 10 isn't a problem, it's by design. Java 11 is an LTS release. The whole purpose of Java 9 and Java 10 was to allow Java to release API breaking changes in a more frequent, but stable (i.e. not a dev build) manner to allow us to prep for Java 11. You'll see most major frameworks and libraries switch to Java 11 support in the next 3-6 months, and they'll mostly find it painless once they're over the Java 9 hump.
It took absolutely fucking years for people to adopt Java 8, and they only started doing it once major frameworks got opinionated about dropping Java 7 support. This time there's not going to be such a long grace period and that is a good thing.
Forcing developers to stop working on stuff the business wants and need, and instead work on making changes to stuff that used to work because some arrogant language pedants cannot be bothered with backward compatibility.
Even a few one line changes will require the full dev, unit test, integration test and user acceptance test cycle, and it all eats up man hours.
How would you feel if the electric company told you 220 volts was old hat and forced you to switch to the technically superior 177 volts?
No wonder big companies stick with COBOL.
Who's forcing you to do anything? If you want to stick on Java 8 then you can do that. Of course the only way you're going to get updates is to pay for them, but if you value "working on stuff the business wants and need" so highly then that's surely an easy proposition.
The reality is the upstream community has limited resources. Those resources are best spent on keeping the modern code base up to date, not helping dinosaurs who want to run on a 6 year old runtime keep their lights on for free.
If and when you do decide that running on a more efficient, more flexible, easier to use and more broadly supported runtime is the right thing to do, you'll be pleased to know that by releasing non-LTS J9 and J10, J11 is well baked and well supported across the usual suspect enterprise vendors.
In the mainframe space, famous for its backward compatibility, IBM sells a COBOL compiler and has for the last half century or so. In ~1985, when IBM introduced their VS COBOL II compiler which implemented at least some of the 1985 standard, they broke some things that worked in their OS COBOL compiler which VS COBOL II replaced. Not necessarily everything that broke was standards-related, but still, VS COBOL II was a complete rewrite of the COBOL compiler from the ground up. It was kind of a big deal to migrate from one product to the next.
Over the next 30 years IBM continued to release new major and minor versions of their COBOL compiler under various names (COBOL/370, COBOL for MVS and VM, COBOL for OS/390 and VM, et. al.), implementing new features as they went. These products all had essentially the same "engine" powering source code parsing and object code generation. Upgrades were essentially a doddle.
Fast forward to the release of v5 of IBM Enterprise COBOL. This product breaks some things because it is a complete rewrite from the ground up. And customers are surprised to discover they have code that has relied on decades-old non-standards-conforming undocumented behavior which went away in the rewrite. It's kind of a big deal to migrate from versions prior to v5 to v5 or later.
That it only took Java ~20 years to reach a version/release that broke things is the surprise, what with time moving at the speed of the internet and all.
Given that we now have these shor term support releases, are you really surprised that businesses have declined to use them?
No company in their right mind would have picked Java 9 (or 10 for that matter) to start a new project in given the knowledge that security updates, bugfixes & the like would not be published 6 months after release, meaning you would then be forced to (pay developers to) upgrade the versions.
Thats fine from a dev point of view - we like new shiny things and tech - but a damn hard sell to a customer whose response has been to use the latest LTS release (in my experience unless theres a genuine technical reason to use those versions like i need X feature).
Your probably going to find commercial adoption of these releases almost non existant - Which makes me wonder if the current release cadence is sensible from a commercial point of view.
I did not run into compatibility issues with Java 9 and above yet - simply because I never bothered to try upgrading. There was little reason for it, so far. Java 5 and 8 were huge releases, game changers in their own right for the language. These new versions aren't, at least not yet.
The module system, the biggest feature we've been waiting for years, is a large unwieldy mess. They went back and forth on whether is should be for the JDK's internal use only or not, and man, it shows. There is pretty much zero incentive to convert existing programs to use modules, and even with newer programs I'd think twice, heck, I'd probably sooner adopt OSGi for my project. JLink might be useful in some cases, but I've never run into a situation where the size of the JDK was crucial... and so on and so forth. Java 11 looks like a huge number on paper, but it's more like 1.9.2 at best.
Pretty much this. Different devs have different needs, of course, but I don't see anything in Java 9+ that really benefits me. That makes it all cost, no benefit. I haven't needed to yet, but the only reason that I'd install it is if there were some outside requirement to do so.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
