back to article '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 …

  1. Anonymous Coward
    Anonymous Coward

    I'm still using Java 1.4

    I'm still using Java 1.4

    1. Anonymous Coward
      Anonymous Coward

      Re: I'm still using Java 1.4

      Although all my code still compiles in Java 1.3, you have to run Java 1.4 or SSL won't work

      1. Anonymous Coward
        Anonymous Coward

        Re: I'm still using Java 1.4

        “Although all my code still compiles in Java 1.3, you have to run Java 1.4 or SSL won't work”

        SSL in 1.4 is barely supported - you pretty much have to use Java 7 to use SSL with modern browsers (For TLS1.2, AES and Diffie-Hellman > 1024 bit support).

        1. Anonymous Coward
          Anonymous Coward

          Re: I'm still using Java 1.4

          I just got TLS 1.2 running on Java 1.4 using Bouncy Castle and Apache Http commons.

    2. Daniel von Asmuth Bronze badge

      Re: I'm still using Java 1.4

      Programming languages should not add new features. You want to be able to run source code written in the early nineties.

      1. hellwig Silver badge

        Re: I'm still using Java 1.4

        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!

      2. Mr Benny

        Re: I'm still using Java 1.4

        I can still compile C code I wrote in the 90s on the latest gcc C++ compilers albeit with some warnings.

      3. whoseyourdaddy

        Re: I'm still using Java 1.4

        Isn't that just a part of the problem? If everything is there already, you won't need to search for that ancient ADO or .net include that you need to compile.

        I need Java 10?

        Install that. Done.

      4. yoganmahew

        Re: I'm still using Java 1.4

        As we're playing one-up compile, I can still assemble (though the young uns call it compile nowadays) IBM 360 assembler my Dad wrote before I was born.

        1. Anonymous Coward
          Anonymous Coward

          Re: I'm still using Java 1.4

          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.

        2. Michael Wojcik Silver badge

          Re: I'm still using Java 1.4

          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.

  2. Version 1.0 Silver badge

    Updates

    It's not a big deal really - when did an update not break something? Don't panic - there will be another update soon.

    1. Paul Crawford Silver badge

      Re: Updates

      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).

      1. Charlie Clark Silver badge

        Re: Updates

        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.

        1. Mr Benny

          Re: Updates

          "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*.

      2. Anonymous Coward
        Anonymous Coward

        Re: Updates

        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.

        1. CrazyOldCatMan Silver badge

          Re: Updates

          carnal desire

          I'm not sure how the desire for sex ties in with Java version numbering..

          1. Anonymous Coward
            Anonymous Coward

            Re: Updates

            You've never met an Oracle sales rep. There's little they love more than screwing customers.

          2. Anonymous Coward
            Anonymous Coward

            Re: Updates

            I'm not sure how the desire for sex ties in with Java version numbering - it will be a while until Java 69 gets here.

        2. Mr Benny

          Re: Updates

          "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.

      3. Doctor Syntax Silver badge

        Re: Updates

        "But then the fskers in marketing decided that we should have big number changes because that is what sells, etc."

        It might sell to manglement but to those who've had their fingers burned a few times it's a big warning sign.

        1. Anonymous Coward
          Anonymous Coward

          Re: Updates

          Damn straight. Ipswitch products come to mind...

      4. Britt Johnston
        Facepalm

        Re: Updates

        even Apple left version 9-0, and skipped to X, 9.0 is jinxed

  3. Anonymous Coward
    Anonymous Coward

    Customers? Who needs them?

    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.

    1. Anonymous Coward
      Anonymous Coward

      Re: Customers? Who needs 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..

    2. jilocasin
      Boffin

      Re: Customers? Who needs them?

      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.

      1. a_yank_lurker Silver badge

        Re: Customers? Who needs them?

        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.

    3. CrazyOldCatMan Silver badge

      Re: Customers? Who needs them?

      customers aren't as gullible or as stupid as you think they are

      Actually, some of them may well be. But probably not enough to sustain business.

    4. Irongut

      Re: Customers? Who needs them?

      "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."

      Someone should tell him that these two phrases are mutually exclusive.

    5. Anonymous Coward
      Anonymous Coward

      Re: Customers? Who needs them?

      In the past customers may have let vendors applications significantly lag behind current releases, but the combination of security issues and OpenJDK support are putting a lot of pressure on vendors to move to newer releases that historically wasn’t present.

  4. Caspian Prince

    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.

    1. Bronek Kozicki Silver badge

      I haven't used Eclipse for years; maybe it is time for you to try IntelliJ ?

      (just being smart-ass, sorry)

      1. james_smith

        Even Netbeans is preferable to that steaming pile known as Eclipse.

        1. Michael Wojcik Silver badge

          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.

    2. baud

      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.

  5. tiggity Silver badge

    Back compatiblity lost

    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

  6. iGNgnorr

    Some extra difficulties with the OpenJxx parts

    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.

    1. This post has been deleted by its author

    2. Michael Wojcik Silver badge

      Re: Some extra difficulties with the OpenJxx parts

      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.

  7. revilo

    compatibility

    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.

    1. stiine Bronze badge
      Facepalm

      Re: compatibility

      Ok, lots of (broken) things make sense now.

  8. pstiles

    "little used apis"

    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 :(

    1. Doctor Syntax Silver badge

      Re: "little used apis"

      "I can't even finish on a joke"

      You could have moved the bit about everyone should be writing web apps down to the end.

      1. pstiles

        Re: "little used apis"

        Good point, and that must be what cost me a downvote...

        Now if only reg told you who downvoted you it would be so helpful...

  9. JimmyPage Silver badge
    Stop

    There is an argument that if Jave 8 code won't compile on Java 9

    then it's not "Java" is it ?

    It was a while ago, but I recall the pain (and slating) MS got when it emerged that VB.NET would not compile VB6 code - even in a "compatibility mode".

  10. Bronek Kozicki Silver badge

    Java, meet Python

    Another language with codebase bifurcated into two major, and mutually incompatible, versions.

    1. Korev Silver badge
      Joke

      Re: Java, meet Python

      Do you have any other PERL6 of wisdom?

      1. DCFusor Silver badge

        Re: Java, meet Python

        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.

    2. Phil Lord

      Re: Java, meet Python

      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.

    3. a_yank_lurker Silver badge

      Re: Java, meet Python

      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.

  11. Anonymous Coward
    Anonymous Coward

    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.

    1. JohnFen Silver badge

      I'm skipping Java 11 for as long as I possibly can as well.

    2. James Anderson

      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.

      1. Anonymous Coward
        Anonymous Coward

        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.

        1. JohnFen Silver badge

          "If and when you do decide that running on a more efficient, more flexible, easier to use [...]"

          I want those things, but I don't think the newest versions of Java offer them.

  12. Doctor Syntax Silver badge

    "Unfortunately, The Register can't run an article that says 'Java now more free than ever'. People won't click on it."

    Oh, go on. You know you want to.

    1. Hans 1 Silver badge
      Big Brother

      'Java now more free than ever'

      Slavery!

    2. Dan 55 Silver badge

      Well they could use that headline, but not if the story is about Oracle setting up a licensing trap ready for you to walk into.

      Everyone can see it from a mile off, which is why nobody is upgrading.

    3. jelabarre59 Silver badge

      "Unfortunately, The Register can't run an article that says 'Java now more free than ever'. People won't click on it."

      Oh, go on. You know you want to.

      They just needed Dabbsy to write it...

    4. Michael Wojcik Silver badge

      I'd like them to run an article with the actual title "The Register can't run an article that says 'Java now more free than ever", with "People won't click on it" as the sub-head. I don't even care what the content is.

  13. cschneid

    Santayana

    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.

  14. LuckyDip23

    Surely its down to lack of support ....

    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.

    1. W.S.Gosset Bronze badge

      Re: Surely its down to lack of support ....

      "shor" is the best typo ever

  15. JohnFen Silver badge

    Java is a bit of nightmare

    It shouldn't be necessary that I have to keep three different versions installed on my dev machine, but it is.

    1. jelabarre59 Silver badge

      Re: Java is a bit of nightmare

      It shouldn't be necessary that I have to keep three different versions installed on my dev machine, but it is.

      So is it:

      "Java: write once, run nowhere"

      or

      "Java: write once, fail everywhere"

  16. Anonymous Coward
    Anonymous Coward

    Lol java

    Lol java devs be like, who moved my cheese? Rest of world be literally like, yo Mr Slow, yo cheese is lame baby food, try some solids and java devs be like, waaaaah want mommy!

  17. pip25
    Meh

    I honestly see no reason to upgrade

    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.

    1. JohnFen Silver badge

      Re: I honestly see no reason to upgrade

      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.

  18. JJKing Bronze badge
    Paris Hilton

    Even Paris is upset with Java.

    I am so glad I was sitting down when I read that headline. I was shocked, shocked I tell you to learn that Java breaks things. Next you'll be telling me Flash is full of holes.

  19. John70

    Will Google emulate these breaking changes in their version of Java on Android?

    Or will it be yet another version of Java people will need to remember.

  20. cat_mara

    IME, when people hear the words "Oracle" and "more free" in the same sentence...

    ... they start wondering what the catch is, or where the sneak licence auditor is hiding...

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019