Comment by StevePerkins | Hacker News Reader

Comment by StevePerkins | Hacker News Reader

Interesting that all of the discussion is rambling about IntelliJ in general (e.g. Is it slow? Is it better than this other IDE? Ermagherd, Java sucks! Etc).

Nothing about the actual specific topic, which is that one of the most prominent development tools in the Java ecosystem now expects the current Java version to be installed.

Expecting the current version might sound mundane to a Rubyist or Node person (and it might sound like a pipe dream to a wistful Pythonist!). However, it's a pretty big change in the Java world. Backwards compatibility is highly prized...and tool or library authors have always been reluctant to use current language features, for fear of excluding users stuck on old versions.

Back when I was working in "the enterprise world", it wasn't unheard to see shops still stuck on 1.4 long after Java 7 had been released. Up until a few years ago, it was sometimes still a big deal for libraries to start incorporating generics (introduced with Java 5 in 2004).

Java 8 was SUPPOSED to an even bigger shift than Java 5, with an even slower adoption rate. However, for some reason it feels like the opposite is proving true. I'm seeing tools and libraries move to Java 8 shockingly soon compared to past experience.

I wonder why this is. Perhaps after the rocky Java 5 migration, large companies embraced the practice of updating their deployed versions more frequently? Maybe it's Oracle releasing new Java versions every two years now, and being more aggressive about end-of-life'ing the prior versions? Or perhaps it's just that I've been out of the enterprise environment and working for startups instead these past several years, and the situation in large companies is still as conservative and outdated as ever?

Honest question: why is backward compatibility an issue for development machines? It's an IDE, right, so you will still be able to edit the project that is backwards-compatible with 1.4 with it?

It affects development of huge ecosystem of plugins for IntelliJ.

Intellij can be configured to target older versions of the Java language (so it will basically error if you use newer language constructs than the ones you've set) but I can imagine that it might be very difficult for you to capture quirks of java 1.x if you're using java 1.y. Difficult enough that most developers would just decide they haven't time for the trouble and install an old, unsupported, and insecure version of the jvm on their work machine.

EDIT: To be clear, those quirks would exist on your production deployment running java 1.x which is why they may be important to emulate.

The IDE itself uses Java 8. You can still work on projects that utilize previous versions of Java.

Just like you could have Java 8 projects before this change.

I believe that, with JetBrains tools, it installs its own JRE as part of the product installation (at least it does for RubyMine on OS X).

So if your corporate overlords allow the IDE itself, you're good.

They just started doing that this year

There's been 8 years between Java 1.0 and Java 5. It was probably too many release for the enterprise world. It took TEN years from Java 5 to Java 8. It was probably due to the gap of Java 7 when Oracle bought Sun. Companies are also much more used to auto-upgradable software now, and the Moore law is over for desktops, hence everyone was awaiting for the Java 8 upgrade.

> Maybe it's Oracle releasing new Java versions every two years now, and being more aggressive about end-of-life'ing the prior versions?

This is a big part of it.

If you want support for older JDKs, you have to pay Red Hat for OpenJDK support. Which isn't even "real" Java, in the eyes of many companies.

Add in the clamour of major libraries and platforms pushing everyone to go to Java 8 so they can slash great chunks of boilerplate code and it's a smooth ride downhill.

You can also buy support directly from Oracle: http://www.oracle.com/us/technologies/java/standard-edition/...

From the above site:

* Direct access to secure versions of older releases of Java SE via My Oracle Support

* Rigorous and on-going regression testing and fixes for EOL’d versions of Java SE

You're absolutely right. I always forget this one.

"Java 8 was SUPPOSED to an even bigger shift than Java 5" No, it's not, Java 8 is mostly lambdas and unlike generics which requires coordinate effort between the client side and the API side, lambdas are just syntactic sugar at client side and plain old interfaces at API side.

Because of that, Java 8 is supposed to be a smaller shift than Java 5.

> lambdas are just syntactic sugar at client side

No they are not, as they make use of invokedynamic. Certified JVMs must make use of the opcode and not generate anonymous nested classes, as many think they translate to.

But at the library API level it's a much smaller mandatory change.

No, invokedynamic is not mandatory for lambda. It's a proposed translation, which has the advantage to make lambdas that do not capture values to be seen as constant by the VM.

But you're right that certified Java 7 VM must have an invokedynamic opcode.

You can use latest Idea to write code on Java 1.4, I guess. The topic is about JRE used to launch Idea itself. You can use any JRE to launch your projects from Idea.

Sure, but developers in the corporate enterprise world often don't have control over the software installed on their workstations.

I realize that Hacker News skews toward a different industry segment, and it's hard for people outside of the enterprise to fully grasp its horrors. But believe it or not, expecting the current version of Java to be installed on a Java developer's machine is actually a pretty big shift!

I understand and agree that in corporate enterprise you usually do not control which software is installed in your workstation.

I should note that this JDK 8 migration is for EAP releases (ie early alpha/beta versions of the next major release) and that all installers (windows, osx and linux) offered by Jetbrains come with its own JDK bundled in the installer. So if you happen to work in one of those corporate environments, if you manage to get permission to run this IDEA version, you also get the required JRE to execute the ide included.

IDEA comes with its own JDK bundled, so if you have permission to run IDEA, you have the updated Java (installed to the subdirectory that IDEA resides in, nonconflicting with the system JRE). What's so hard about that?

Or is your question about how JetBrains expects to get permission from the pointyhair bosses to purchase the new IDEA version for their developers in the first place? If that's your question then it's not really JetBrain's business if megacorps decide developer productivity is not worth the money to spend on buying a new copy of IDEA.

Reply on news.ycombinator.com