8 ms·

I'm so confused, I didn't even know JDK9 was out yet! Reading elsewhere they are apparently moving to a 6 month release cycle. For people using Java in busine

by SCdF 9y ago

I'm so confused, I didn't even know JDK9 was out yet! Reading elsewhere they are apparently moving to a 6 month release cycle. For people using Java in businessey environments, I'd love to hear your thoughts on this. Do you think you'll be able to keep up with the JDK changing twice a year? When I was in this game we were always on versions that were years behind, but maybe this has changed.

BonesJustice 9y ago
This release cycle makes no sense to me. We haven’t even finished migrating all our components to compile with JDK8 yet, though they’ve all been running against it for a while now. We’re barely even discussing moving to JDK9 at this point. What company with a reasonably large software base is going to keep up with a six-month release schedule? Java isn’t a web browser or some other user application. Who would even _want_ to spend the kind of resources required to constantly be testing new JDK releases?
- naibafo 9y ago
  That's why they have LTS releases I think?
- akerro 9y ago
  >This release cycle makes no sense to me. We haven’t even finished migrating all our components to compile with JDK8 yet Why is it Oracles fault that you keep your components on Java version that has been deprecated and support dropped 4 years ago? >What company with a reasonably large software base is going to keep up with a six-month release schedule? What? No. That's now how it works. Every 3rd release is LTS and it support time is between 6 and 11 years as so far discussed. Java8 won't be supported after January 2019, Java11 (LTS) will be release in September this year. > Java isn’t a web browser or some other user application. Who would even _want_ to spend the kind of resources required to constantly be testing new JDK releases? You're not supposed to be testing it. You're supposed to write code to a contract, contract won't or shouldn't change. If you write code that follows implementation instead a contract (let's say you relay on HashSet order - I've seen it), it's your fault. We always make sure we write code that follows the contract. We're migrating our code base to Jigsaw now, after Spring 5 and SpringBoot1.5 were release with updated dependencies. If Spring and Tomcat teams made it available earlier, we would be on Java9 months ago.
  - piokoch 9y ago
    If that were so simple. What if your software gets deployed on an application server? If you upgrade, you need new support contract, this costs money plus leads to possible deployment/config changes, for instance going from JBoss 5 EAP to JBoss 6 EAP is not a pleasant experience as almost all configuration was radically changed. What if part of your application is audited and certified by some regulatory body, when you upgrade, you need to go through the process again. Java value is stability, you can assume your software will run for 20 years without touching it.
    - dragandj 9y ago
      No one is forcing anyone to upgrade. What worked on Java 8 3 years ago, will work on Java 8 in 17 years. If your team have extra requirements (audit, certification etc.), it seems it sells enterprise software. All those things cost money, but I assume you also charge money. So, what's exactly the problem? It is a bit naive to expect to get ultra stability for free from your suppliers, but charge top dollar from your customers...
      - coldtea 9y ago
        >No one is forcing anyone to upgrade. No, but they are restricting them from updating as easily as before -- unless they cough up dough.
        oblio 9y ago
        How are they restricting the updates? I'm not sure I understand.
        coldtea 9y ago
        By only providing fixes and security patches for a few months -- after that you need to move to the next version (with all that entails testing and adapting wise for large codebases), or you pay for enterprise support and get support for years. Before you could go to any version and expect it to be supported for years. Now, if you dare go to some version above 8, you're supposed to either pay (for long term support), jump directly to the next version after a few months, or stay without security fixes. (Or go OpenJDK and screw them).
- bhaavan 9y ago
  Given that your company is still on JDK7, and is already saying a "fuck you" to new features, I don't think anything will change for you at all. You can continue ignoring newer features, but that doesn't mean everybody should. If they find value, they should have an option to move fast.
- jsiepkes 9y ago
  "We haven’t even finished migrating all our components to compile with JDK8 yet" Interested to hear which Java API you use which requires special modification in order to be compilable on Java 8? Usually most of this breakage is caused by the com.sun stuff which isnt public API.
  - mrighele 9y ago
    If you have written your regular enterprise web service you will probably not have very complex code (I'm not talking about business logic, but language features). But then you are using a 1 year old framework (if you're lucky) that depends on a version of library X that is 2 years old that depends on a 3 years old library etc. At the end of the chain you have a library that does low level stuff (bytecode instrumentation for example) and is a few years old. That is what may give you problems, and often the only practical solution is to update to a newer version of the framework, which can be quite expensive.
  - cesarb 9y ago
    For instance, if you depend on an old version of the Spring framework, using some Java 8 features (like lambdas) will break, since it generates bytecode Spring doesn't understand. Compiling as Java 7 prevents inadvertent use of these features.
  - delecti 9y ago
    I'm curious, how large of a company did you work for such that you were able to easily upgrade your JDK version? Because I worked at a fairly large tech company and every one of our applications required some amount of manual intervention beyond figuratively switching all the "7"s to "8"s. That's despite the fact that hardly any of them were doing anything particularly complicated, and absolutely none of them were doing anything involving hidden com.sun APIs. I think it's just a consequence of such a large build system.
    - shell_oil_101 9y ago
      Yeah the reality of the situation is that it's never as straight-forward as just recompiling with the latest JDK. From my experience it wasn't generally code written in-house that'd cause problems (but sometimes it was), it was dependencies and transitive deps that required the older JDK (sometimes they relied on old bugs or old tooling, sometimes they just couldn't be recompiled on the new JDK for whatever reason). Build tools that relied heavily on JVM internals often couldn't upgrade for some time. Third parties integrating with your software and the new JDK brings a slight change in it's SOAP/XML/ser-deser stuff etc. That said, Java has been the best at backwards compatibility that I've tried, given it's popularity, and most of the pain was in the early days (like anything I suppose, see the Javascript world atm). Microsoft's offerings probably do backwards compatibility well, but then you get all the rest of the technical- and wallet-pain that that environment brings with it.
- g051051 9y ago
  This is the same strategy that wrecked Eclipse and Firefox. Every 6 months is just too quick for most people to feel comfortable, and will cause fragmentation as the 3rd party ecosystem updates things at different rates.
  - oblio 9y ago
    Counter example: Chrome.
    - g051051 9y ago
      Chrome makes continuous small changes. It doesn't make big breaking changes every 6 months, whether the community and ecosystem are ready or not.
      - oblio 9y ago
        I don't get why Firefox gets flak, then. They broke compatibility with v57 exactly for that: to make continuous small changes. The previous situation was untenable since there was no API for extensions, the extensions could just go through Firefox internals and change at-will whatever they wanted. The whole point of WebExtensions is that they won't need to break compatibility after this huge leap.
        g051051 9y ago
        FireFox constantly broke all my extensions with just about every minor update. It was maddening. After being a die-hard FireFox/Netscape/Mozilla user since the 90's, I finally gave up a few years back and switched to Chrome. I can't recall a single time since then when my browser or extensions stopped working because of any update, not just a minor one.
        oblio 9y ago
        You should maybe check things out again, cause that’s why they made this huge change in Firefox 57.
- sudhirj 9y ago
  Not sure that’s how it works. You don’t really need to update anything. Ubuntu runs on y monthly releases, for instance, and sees plenty of enterprise usage. The Linux kernel itself is updated as often, if not more. Google Chrome updates all the time. Ruby does yearly major releases, as do other languages. Go does six months, I think. Teams in charge of software release whenever they want or can, clients are free to use whatever version whenever they want. The problems only happen with breaking changes - and I haven’t seen a single case of Java breaking backwards compatibility (not counting cases where users intentionally used or relied on private implementation details).
- barkingcat 9y ago
  I think it makes total sense to have the language evolving on a scheduled basis rather than stagnate. If your company is only discussing moving to JDK9 now, what difference does it make that JDK10 is out? If you are using the free version, there is no real support. If you are a paying customer, Oracle will support you to the end of time while wringing every last cent out of your company. What difference does it make if the language keeps evolving? Do you expect the entire world to revolve around you and your company?
mastazi 9y ago
They will have LTS versions, the next LTS will be version 11
sumnulu 9y ago
Java 8 and 11 has LTS http://www.oracle.com/technetwork/java/eol-135779.html http://www.oracle.com/technetwork/java/eol-135779.html
agumonkey 9y ago
Yeah I remember downloading a jdk9 prerelease not long ago and now jdk10 ... does not compute
madmulita 9y ago
You want the short or the long answer? We still have major components using java 1.4.2.
firebird84 9y ago
We intend to only switch to LTS versions. 8 is LTS, as will be 11. We'll switch a little while after 11 comes out once we believe any release bugs are ironed out (7's release worried me).
Traubenfuchs 9y ago
Modern enterprise Java uses Docker. At best, a Java upgrade means changing one line in the Dockerfile.
vbezhenar 9y ago
I'm stuck with Java 8, because there's no 32-bit support on newer Oracle JVM and I have to run my code on Windows 2003 servers. I guess it'll be like Delphi 7, best version which will stick around forever. I, personally, don't care about updates. If something works, it'll work.
- haspok 9y ago
  I think that if you still have Windows Server 2003 boxes (for which the official support ended 3 years ago) being stuck with Java 8 is the least of your problems...

by SCdF 9y ago

BonesJustice 9y ago

This release cycle makes no sense to me. We haven’t even finished migrating all our components to compile with JDK8 yet, though they’ve all been running against it for a while now. We’re barely even discussing moving to JDK9 at this point. What company with a reasonably large software base is going to keep up with a six-month release schedule? Java isn’t a web browser or some other user application. Who would even _want_ to spend the kind of resources required to constantly be testing new JDK releases?

naibafo 9y ago
That's why they have LTS releases I think?
akerro 9y ago
>This release cycle makes no sense to me. We haven’t even finished migrating all our components to compile with JDK8 yet Why is it Oracles fault that you keep your components on Java version that has been deprecated and support dropped 4 years ago? >What company with a reasonably large software base is going to keep up with a six-month release schedule? What? No. That's now how it works. Every 3rd release is LTS and it support time is between 6 and 11 years as so far discussed. Java8 won't be supported after January 2019, Java11 (LTS) will be release in September this year. > Java isn’t a web browser or some other user application. Who would even _want_ to spend the kind of resources required to constantly be testing new JDK releases? You're not supposed to be testing it. You're supposed to write code to a contract, contract won't or shouldn't change. If you write code that follows implementation instead a contract (let's say you relay on HashSet order - I've seen it), it's your fault. We always make sure we write code that follows the contract. We're migrating our code base to Jigsaw now, after Spring 5 and SpringBoot1.5 were release with updated dependencies. If Spring and Tomcat teams made it available earlier, we would be on Java9 months ago.
- piokoch 9y ago
  If that were so simple. What if your software gets deployed on an application server? If you upgrade, you need new support contract, this costs money plus leads to possible deployment/config changes, for instance going from JBoss 5 EAP to JBoss 6 EAP is not a pleasant experience as almost all configuration was radically changed. What if part of your application is audited and certified by some regulatory body, when you upgrade, you need to go through the process again. Java value is stability, you can assume your software will run for 20 years without touching it.
  - dragandj 9y ago
    No one is forcing anyone to upgrade. What worked on Java 8 3 years ago, will work on Java 8 in 17 years. If your team have extra requirements (audit, certification etc.), it seems it sells enterprise software. All those things cost money, but I assume you also charge money. So, what's exactly the problem? It is a bit naive to expect to get ultra stability for free from your suppliers, but charge top dollar from your customers...
    - coldtea 9y ago
      >No one is forcing anyone to upgrade. No, but they are restricting them from updating as easily as before -- unless they cough up dough.
      - oblio 9y ago
        How are they restricting the updates? I'm not sure I understand.
        coldtea 9y ago
        By only providing fixes and security patches for a few months -- after that you need to move to the next version (with all that entails testing and adapting wise for large codebases), or you pay for enterprise support and get support for years. Before you could go to any version and expect it to be supported for years. Now, if you dare go to some version above 8, you're supposed to either pay (for long term support), jump directly to the next version after a few months, or stay without security fixes. (Or go OpenJDK and screw them).
bhaavan 9y ago
Given that your company is still on JDK7, and is already saying a "fuck you" to new features, I don't think anything will change for you at all. You can continue ignoring newer features, but that doesn't mean everybody should. If they find value, they should have an option to move fast.
jsiepkes 9y ago
"We haven’t even finished migrating all our components to compile with JDK8 yet" Interested to hear which Java API you use which requires special modification in order to be compilable on Java 8? Usually most of this breakage is caused by the com.sun stuff which isnt public API.
- mrighele 9y ago
  If you have written your regular enterprise web service you will probably not have very complex code (I'm not talking about business logic, but language features). But then you are using a 1 year old framework (if you're lucky) that depends on a version of library X that is 2 years old that depends on a 3 years old library etc. At the end of the chain you have a library that does low level stuff (bytecode instrumentation for example) and is a few years old. That is what may give you problems, and often the only practical solution is to update to a newer version of the framework, which can be quite expensive.
- cesarb 9y ago
  For instance, if you depend on an old version of the Spring framework, using some Java 8 features (like lambdas) will break, since it generates bytecode Spring doesn't understand. Compiling as Java 7 prevents inadvertent use of these features.
- delecti 9y ago
  I'm curious, how large of a company did you work for such that you were able to easily upgrade your JDK version? Because I worked at a fairly large tech company and every one of our applications required some amount of manual intervention beyond figuratively switching all the "7"s to "8"s. That's despite the fact that hardly any of them were doing anything particularly complicated, and absolutely none of them were doing anything involving hidden com.sun APIs. I think it's just a consequence of such a large build system.
  - shell_oil_101 9y ago
    Yeah the reality of the situation is that it's never as straight-forward as just recompiling with the latest JDK. From my experience it wasn't generally code written in-house that'd cause problems (but sometimes it was), it was dependencies and transitive deps that required the older JDK (sometimes they relied on old bugs or old tooling, sometimes they just couldn't be recompiled on the new JDK for whatever reason). Build tools that relied heavily on JVM internals often couldn't upgrade for some time. Third parties integrating with your software and the new JDK brings a slight change in it's SOAP/XML/ser-deser stuff etc. That said, Java has been the best at backwards compatibility that I've tried, given it's popularity, and most of the pain was in the early days (like anything I suppose, see the Javascript world atm). Microsoft's offerings probably do backwards compatibility well, but then you get all the rest of the technical- and wallet-pain that that environment brings with it.
g051051 9y ago
This is the same strategy that wrecked Eclipse and Firefox. Every 6 months is just too quick for most people to feel comfortable, and will cause fragmentation as the 3rd party ecosystem updates things at different rates.
- oblio 9y ago
  Counter example: Chrome.
  - g051051 9y ago
    Chrome makes continuous small changes. It doesn't make big breaking changes every 6 months, whether the community and ecosystem are ready or not.
    - oblio 9y ago
      I don't get why Firefox gets flak, then. They broke compatibility with v57 exactly for that: to make continuous small changes. The previous situation was untenable since there was no API for extensions, the extensions could just go through Firefox internals and change at-will whatever they wanted. The whole point of WebExtensions is that they won't need to break compatibility after this huge leap.
      - g051051 9y ago
        FireFox constantly broke all my extensions with just about every minor update. It was maddening. After being a die-hard FireFox/Netscape/Mozilla user since the 90's, I finally gave up a few years back and switched to Chrome. I can't recall a single time since then when my browser or extensions stopped working because of any update, not just a minor one.
        oblio 9y ago
        You should maybe check things out again, cause that’s why they made this huge change in Firefox 57.
sudhirj 9y ago
Not sure that’s how it works. You don’t really need to update anything. Ubuntu runs on y monthly releases, for instance, and sees plenty of enterprise usage. The Linux kernel itself is updated as often, if not more. Google Chrome updates all the time. Ruby does yearly major releases, as do other languages. Go does six months, I think. Teams in charge of software release whenever they want or can, clients are free to use whatever version whenever they want. The problems only happen with breaking changes - and I haven’t seen a single case of Java breaking backwards compatibility (not counting cases where users intentionally used or relied on private implementation details).
barkingcat 9y ago
I think it makes total sense to have the language evolving on a scheduled basis rather than stagnate. If your company is only discussing moving to JDK9 now, what difference does it make that JDK10 is out? If you are using the free version, there is no real support. If you are a paying customer, Oracle will support you to the end of time while wringing every last cent out of your company. What difference does it make if the language keeps evolving? Do you expect the entire world to revolve around you and your company?

mastazi 9y ago

They will have LTS versions, the next LTS will be version 11

sumnulu 9y ago

Java 8 and 11 has LTS http://www.oracle.com/technetwork/java/eol-135779.html http://www.oracle.com/technetwork/java/eol-135779.html

agumonkey 9y ago

Yeah I remember downloading a jdk9 prerelease not long ago and now jdk10 ... does not compute

madmulita 9y ago

You want the short or the long answer? We still have major components using java 1.4.2.

firebird84 9y ago

We intend to only switch to LTS versions. 8 is LTS, as will be 11. We'll switch a little while after 11 comes out once we believe any release bugs are ironed out (7's release worried me).

Traubenfuchs 9y ago

Modern enterprise Java uses Docker. At best, a Java upgrade means changing one line in the Dockerfile.

vbezhenar 9y ago

I'm stuck with Java 8, because there's no 32-bit support on newer Oracle JVM and I have to run my code on Windows 2003 servers. I guess it'll be like Delphi 7, best version which will stick around forever. I, personally, don't care about updates. If something works, it'll work.

haspok 9y ago
I think that if you still have Windows Server 2003 boxes (for which the official support ended 3 years ago) being stuck with Java 8 is the least of your problems...