6 ms·

>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

by 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).
badpun 9y ago
Enterprise Java is mostly about writing glue code that combines dozens of libraries and frameworks. How can you tell (without testing) if tens of millions of lines of code in those libraries are not doing anything stupid, like depending on implementation instead of contract?
- javajosh 9y ago
  The most important contract, the JVM spec, is really good in Java, and that makes up for almost everything. Javalang and the standard library is generally very good about maintaining backward compatibility (almost to a fault, some would say). Of course, there is code in the wild that depends on, for example, the com.sun packages and so on, and that extend the JVM using JNI - in those cases, all bets are off. But that was always true, and I'd argue that such contortions are generally as ill-advised as they are rare. So, yeah, I think a faster release cadence is a good idea! Upgrading the runtime should be as simple as upgrading any other dependency.
pgsandstrom 9y ago
> Java8 won't be supported after January 2019, Java11 (LTS) will be release in September this year. Are they dropping support for the latest LTS just four month after releasing a new LTS? That sounds a bit harsh.
- akerro 9y ago
  This is all subject to change, but so far it looks like it http://www.oracle.com/technetwork/java/eol-135779.html http://www.oracle.com/technetwork/java/eol-135779.html
- mason55 9y ago
  This is my only problem with it. I can’t imagine it stays like that. I feel like there has to be at least a year of overlap between release of one LTS and deprecation of support for the previous one. Or at least a commitment to continue with security patches for longer (while stopping bug fixes and enterprise support)
  - u02sgb 9y ago
    I would be surprised if that's the case for paying customers...
  - Yeroc 9y ago
    You'll be OK as long as you're dropping off suitcases of money at Oracle's door, but currently it appears that freely available fixes/security updates will cease as soon as the next LTS is released.
lovelearning 9y ago
"Contract won't or shouldn't change" seems unrealistically idealistic to me. Java migration - or any platform for that matter - is not just migrating its language features but also its ecosystem - runtime, VM, GC, frameworks. There are many examples of migration problems for any platform - just have to google it. When information that can challenge our assumptions is just a google search away, I don't see why one should hold on to blind faith in idealistic assumptions. Here's one writeup of a system whose performance suffered simply by migrating to Java 8 without involving any code changes [1]. [1]: http://engineering.indeedblog.com/blog/2016/09/job-search-web-app-java-8-migration/ http://engineering.indeedblog.com/blog/2016/09/job-search-we...
derriz 9y ago
Linus may be occasionally obnoxious but I believe his "don't break user space" mantra is a significant reason why Linux is so popular. A similar attitude guided Windows development (until Vista) and it dominated the desktop world. In comparison your attitude seems user hostile to me. No "user" is interested in comparing theoretical specs with the behaviour of the reference implementation. They just want a tool to deliver solutions that work. For the first time in years, I'm looking at alternatives to Java for my next project. Java was always seemed to offer a pragmatic compromise in terms of language design and features and the availability of developers and libraries. Rapid breaking releases destroys most of the value of Java for me.
- yaseenk 9y ago
  Java is backwards compatible though. Code that was written in the 90s will still compile and run on JDK 10. It’s just now Java gets to iterate and improve more frequently and regularly. Regardless there are still LTS releases (every 3 years) for people who lean more conservative.
  - evgeniysharapov 9y ago
    Not always and not quite. Here's an example of some type-foo with generics that works on Java 7 and not on Java 8 https://stackoverflow.com/questions/34659055/java-8-incompatible-types https://stackoverflow.com/questions/34659055/java-8-incompat...
    - hyperpape 9y ago
      If I read that correctly, the “breakage” is a bug fix, as that particular Java 7 compiler isn’t behaving according to the spec. You can argue that breaks backwards compatibility, but in the smallest, most innocuous way possible.
    - kelnos 9y ago
      My understanding after reading the answer to that SO question is that the behavior in 7 was a bug. New releases of javac aren't required to be bug-compatible with previous releases.
earenndil 9y ago
> Java8 won't be supported after January 2019, Java11 (LTS) will be release in September this year So we basically just have 3 months to migrate to the next LTS version??

by akerro 9y 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).

badpun 9y ago

Enterprise Java is mostly about writing glue code that combines dozens of libraries and frameworks. How can you tell (without testing) if tens of millions of lines of code in those libraries are not doing anything stupid, like depending on implementation instead of contract?

javajosh 9y ago
The most important contract, the JVM spec, is really good in Java, and that makes up for almost everything. Javalang and the standard library is generally very good about maintaining backward compatibility (almost to a fault, some would say). Of course, there is code in the wild that depends on, for example, the com.sun packages and so on, and that extend the JVM using JNI - in those cases, all bets are off. But that was always true, and I'd argue that such contortions are generally as ill-advised as they are rare. So, yeah, I think a faster release cadence is a good idea! Upgrading the runtime should be as simple as upgrading any other dependency.

pgsandstrom 9y ago

> Java8 won't be supported after January 2019, Java11 (LTS) will be release in September this year. Are they dropping support for the latest LTS just four month after releasing a new LTS? That sounds a bit harsh.

akerro 9y ago
This is all subject to change, but so far it looks like it http://www.oracle.com/technetwork/java/eol-135779.html http://www.oracle.com/technetwork/java/eol-135779.html
mason55 9y ago
This is my only problem with it. I can’t imagine it stays like that. I feel like there has to be at least a year of overlap between release of one LTS and deprecation of support for the previous one. Or at least a commitment to continue with security patches for longer (while stopping bug fixes and enterprise support)
- u02sgb 9y ago
  I would be surprised if that's the case for paying customers...
- Yeroc 9y ago
  You'll be OK as long as you're dropping off suitcases of money at Oracle's door, but currently it appears that freely available fixes/security updates will cease as soon as the next LTS is released.

lovelearning 9y ago

"Contract won't or shouldn't change" seems unrealistically idealistic to me. Java migration - or any platform for that matter - is not just migrating its language features but also its ecosystem - runtime, VM, GC, frameworks. There are many examples of migration problems for any platform - just have to google it. When information that can challenge our assumptions is just a google search away, I don't see why one should hold on to blind faith in idealistic assumptions. Here's one writeup of a system whose performance suffered simply by migrating to Java 8 without involving any code changes [1]. [1]: http://engineering.indeedblog.com/blog/2016/09/job-search-web-app-java-8-migration/ http://engineering.indeedblog.com/blog/2016/09/job-search-we...

derriz 9y ago

Linus may be occasionally obnoxious but I believe his "don't break user space" mantra is a significant reason why Linux is so popular. A similar attitude guided Windows development (until Vista) and it dominated the desktop world. In comparison your attitude seems user hostile to me. No "user" is interested in comparing theoretical specs with the behaviour of the reference implementation. They just want a tool to deliver solutions that work. For the first time in years, I'm looking at alternatives to Java for my next project. Java was always seemed to offer a pragmatic compromise in terms of language design and features and the availability of developers and libraries. Rapid breaking releases destroys most of the value of Java for me.

yaseenk 9y ago
Java is backwards compatible though. Code that was written in the 90s will still compile and run on JDK 10. It’s just now Java gets to iterate and improve more frequently and regularly. Regardless there are still LTS releases (every 3 years) for people who lean more conservative.
- evgeniysharapov 9y ago
  Not always and not quite. Here's an example of some type-foo with generics that works on Java 7 and not on Java 8 https://stackoverflow.com/questions/34659055/java-8-incompatible-types https://stackoverflow.com/questions/34659055/java-8-incompat...
  - hyperpape 9y ago
    If I read that correctly, the “breakage” is a bug fix, as that particular Java 7 compiler isn’t behaving according to the spec. You can argue that breaks backwards compatibility, but in the smallest, most innocuous way possible.
  - kelnos 9y ago
    My understanding after reading the answer to that SO question is that the behavior in 7 was a bug. New releases of javac aren't required to be bug-compatible with previous releases.

earenndil 9y ago

> Java8 won't be supported after January 2019, Java11 (LTS) will be release in September this year So we basically just have 3 months to migrate to the next LTS version??