Hacker News Reader

Comment by kelp | Hacker News Reader

Dumb question here. Why is this necessary? Does Jetbrains not include their latest Jetbrain Runtime release in their IDE builds?

Or maybe Jetbrains Runtime releases run a bit ahead of what gets bundled in with the various Jetbrains IDEs?

View on HN

It is recommended to use the currently bundled JBR version (JDK 11). Although later versions are available for testing, they are less stable as the author of this blog post mentions at the end.

JetBrains' attitude to this has been horrendous.

Try running their products on a more recent JVM. They are actually usable and don't leave you feeling like you've been thinking in molasses. Ironic for a company called "jet" brains.

They (JetBrains) have been actively fucking a portion of their (one would think, technically savvy) customers by not giving them the most responsive system they can to run, then acting all paternalistic and gaslighty by saying "oh we don't recommend you use anything other than the one we ship." [1] when people complain.

Listen, JetBrains: I have wasted enough time (while my thoughts race ahead trying to work on my projects) sat on my phatass 64Gb NVMe-equipped Xeon, nvidia (native driver) Debian workstation waiting for pycharm et al to mooch along like at a stately pace redrawing the screen like it's a 1994 486 with an HDD. In the end my thoughts stopped racing and I began to think, yeah, well, I just gotta endure it... and then asking myself if I'm alone in this particular slow-motion hell-hole or is the world really like this?!

Once I had got to the bottom of it (notes here https://iam.georgecox.com/2021/11/24/making-jetbrains-ides-r...) I _instantly_ began to regain the feeling of fluidity of thought in my work. It was the biggest single productivity gain I've made in the past year, and I have had zero stability problems. Some debugging features are not available, but I haven't missed them.

At this point JetBrains would do well to take a leaf out of Apple's playbook from 2009 when they shipped the Snow Leopard release (Yes I am one of those that thinks that Snow Leopard was the best release of Mac OS X...) which concentrated solely on quality and speed, and no new features. [2]

Thank you for your attention. Merry Christmas ;-)

[1] a fact which gets parroted around various fora without any understanding of the problem because "it works on their computer" It seems that much of the improvements are for the benefit of MacOS X users, while the policy of sticking with a version 11 JDK is to the detriment of users on other platforms.

[2] quality and speed are features, too!

Not sure what your problem with them is.

JetBrains is simply trying to provide a stable development platform.

And since it took me about about a minute to switch to JDK17 it's not like they are going out of their way to make it difficult.

Not sure what your problem with them is.

I explained it in full above.

And since it took me about about a minute to switch to JDK17 it's not like they are going out of their way to make it difficult.

When you restarted in JDK17 you didn't get any access errors? What app, OS, and JDK vendor is this?

If you look in the post, they explain what flag they use to avoid those access issues.

I am sorry to hear about your productivity issues. I also experienced some slowness in recent builds, although I think our issues are not directly related, since I primarily use IntelliJ IDEA and not PyCharm. Following a recent issue I encountered on JDK 17, I was also advised to downgrade to JDK 11. [1] I think maybe they are waiting until JDK 17 is more stable for release, but anecdotally speaking, JDK 17 runs pretty well for me on osx-aarch64, save for a few minor hiccups. If the issue you are experiencing is a persistent one, you might also consider reporting a performance problem [2].

I've heard good things about JetBrains Fleet. [3] Although it has not yet been released, it seems to have many of the same features as the full IDEs and is more responsive in the editor department. Anyhow, I hope your experience improves and you have a Merry Christmas as well!

[1] https://youtrack.jetbrains.com/issue/IDEA-278926#focus=Comme...

[2]: https://intellij-support.jetbrains.com/hc/en-us/articles/207...

[3]: https://www.jetbrains.com/fleet/

I'm doing fine now -- PyCharm and IDEA benefit greatly from using JDK16. Remember, I'm on Linux, you're on OSX where they had to make some font changes which, AIUI, are Mac-specific, and it seems like that has made them decide to stick with JDK11.

I will update the post I made on my blog with the JVM options for JDK17. [1]

I have had mixed success reporting bugs to JB, as is to be expected for a company their size.

[1] it's Christmas, so why wait... it's this lot

    --illegal-access=warn
    --add-exports java.desktop/com.apple.eawt.event=ALL-UNNAMED
    --add-exports java.desktop/com.apple.eawt=ALL-UNNAMED
    --add-exports java.desktop/com.apple.laf=ALL-UNNAMED
    --add-exports java.desktop/sun.font=ALL-UNNAMED
    
    --add-opens java.base/java.lang=ALL-UNNAMED
    --add-opens java.base/java.util=ALL-UNNAMED
    --add-opens java.desktop/java.awt.event=ALL-UNNAMED
    --add-opens java.desktop/java.awt.peer=ALL-UNNAMED
    --add-opens java.desktop/java.awt=ALL-UNNAMED
    --add-opens java.desktop/javax.swing.plaf.basic=ALL-UNNAMED
    --add-opens java.desktop/javax.swing.text.html=ALL-UNNAMED
    --add-opens java.desktop/javax.swing=ALL-UNNAMED
    --add-opens java.desktop/sun.awt=ALL-UNNAMED
    --add-opens java.desktop/sun.font=ALL-UNNAMED
    --add-opens java.desktop/sun.swing=ALL-UNNAMED

I previously used IntelliJ IDEA on Linux for over eight years, so I can sympathize with your struggles. [1] Recently I started using OSX because my Thinkpad finally died and I could not find another laptop I liked. So far, it's been pretty bumpy, although I noticed that some things have improved (like fonts and build times). The downside is that many things currently do not work on aarch64 right now, and I somewhat regret making the switch this early. I recently started writing some Haskell, which was a pain to setup on my local machine but now that GHCi and Stack finally support it [2], I think it's getting stable. Hopefully more native libraries will offer support for aarch64, because despite the minor speedups (faster JVM), overall it's been a productivity-killer. Very few native libraries provide M1-compatible builds right now.

[1]: http://breandan.net/2014/08/18/shell-script/

[2]: https://github.com/haskell/haskell-language-server/issues/20...

I tried this on my Intel Mac, using the JBR 17 (JCEF) download from Jetbrains. IDEA did start up, but the menus didn't work at all. The top-level menus were there, but they did not open any submenus. Other than that, things seemed to work. I wonder if there is a workaround.

> quality and speed are features, too!

So much this, the amount of people who refuse to believe this (even after a decent argument in favour) is infuriating.

The good thing with that kind of software is that you are not forced to use it and that there are a lot of alternatives adapted to everybody's preference. I'm happy to live in a world like that.

> JetBrains' attitude to this has been horrendous.

> Try running their products on a more recent JVM.

Isn't JDK17 literally two or three months old?

JDK17 was released on sep 17 2021. Meanwhile, IntelliJ 2021.2 was released on July 27 2021, and IntelliJ 2021.3 on November 30 2021.

Who in their right mind would dump a stable LTS release in favour of the latest and greatest in the middle of a point release? Specially on a production project which is expected to be rock solid, and quite possibly wouldn't be able to recover from a reputation hit caused by regressions introduced by hasty ill-advised migrations?

"more recent" does not mean "the most recent"

> "more recent" does not mean "the most recent"

JDK17 is the latest LTS release.

The previous LTS release was JDK11, which is already shipped with IntelliJ.

What, exactly, are you trying to argue?

What, exactly, are you trying to argue?

Disingenuous HN snark never stops; (re-)read the whole thread to find out what you've missed.

You literally write:

> Try running their products on a more recent JVM.

> ...

> while the policy of sticking with a version 11 JDK is to the detriment of users on other platforms.

The answer is, quote: "JDK17 is the latest LTS release. The previous LTS release was JDK11, which is already shipped with IntelliJ."

What exactly do you want of JetBrains?

Interim releases receive only 6 months of support. They'd have to switch the runtime version mid-flight, or leave users with an unsupported runtime, or dedicate a ton of resources to supporting JDK themselves (in addition to all the patches they do now).

JDK 11 would be fine, but why have such a bad default config for the JVM? They literally use a deprecated GC algorithm instead of the default and set a way too low max heap size (I guess so people don’t say that it uses too much RAM, but all it does is making the GC run constantly)

It's for people using 8GB ram laptops.

> while the policy of sticking with a version 11 JDK

JDK 11 is an LTS release. JDK 17 only shipped a few months ago.

As a personal anecdote: I tried to upgrade a small microservice to Java 17 from Java 11. It took me a week hunting weird bugs and obscure undocumented things that suddenly just broke.

But sure. JetBrains should drop everything and move to JDK 17 the moment JDK 17 ships because?... Because what exactly?

"more recent" does not mean "the most recent"

Jetbrains includes JBR11 by default.

For now, Java 17 has only been out for a few months. They'll likely switch with their next major release. 17 and 11 were both LTS releases.

I've used Intellij for quite some time and there has always been quite a bit of magical thinking surrounding the performance topic that stems from a poor understanding of how things work, broken assumptions about how things should work, and so on.

Intellij has lots of performance baggage. And addressing this and overstating the effects of mitigations is a long standing tradition in release notes. Despite numerous supposed fixes and improvements to the IDE, compiler, etc. even in just the last year, I still find myself waiting for it to do whatever for minutes on end every day. A half minute recompile after a 1 character code change.

Rendering, garbage collection, and other things people like to point at are not even close to being a root cause for this. The real cause is that it simply does a lot of work and moves around a lot of data. The edge cases where that just requires noticeably slow re-computation happen a lot and when they do, things get slow.

JetBrains' fork is not regularly merged, and is somewhat old at the moment.

In any other product, this would be a red flag. What is special about it? What unstable APIs have they used? If they've done that, what other things have they done?

Should every vendor ship their own version of the JVM?

I mean sure, in an ideal world one Java should work for everything. In practice, there are too many things that can go wrong with untested combinations. For better or worse, the world is moving towards bundled dependencies (Snap, Flatpak, Docker, etc). On my system, I see at least DBeaver and Arduino that ship their own JVM. I don't think it's a red flag.

Why do they do that in each case? Why do they need a specific version such that it it unreasonable for the regular user to have already in place?

If we look at something like Minecraft - it now bundles Java. This lets them upgrade java versions without bothering every 12 year old to figure out how to do that.

Good for them, but Minecraft is neither DBeaver nor Arduino.

Because as an industry we have collectively failed - both in dependency management and in version control. There are unreliable, and they are incomprehensible to an average user, no matter which operating system you use.

It is because of the strange belief that a piece of software can work reliably against a set of libraries when they were not tested together (just because somebody says they're compatible). Dependency management can work only if every piece of software is able to link directly to the versions of libraries to which they were originally released.

The dependency management must be of exact versions of libraries that must be present to work with the installed software. Instead, people believe that it is possible to manage dependencies by stated compatibility: this will never work.

If operating systems had dependency-library versioning, lookup, retrieval and verification facilities built directly into the core exposed with a proper C-API, all these problems could go away.

Our industry builds technology as advanced as jet engines, but with stone tools.

Because different releases are different. So just package up the releases you know work with your app.

Yeah imo while it’s pretty wasteful, I’m still in favor of this trend. Given the decreasing cost of storage, I’ll happily trade a bit of disk space for less wasted time on configuration, bugs, performance issues, etc.

Shipping your own JVM is actually the Oracle recommended way. It's why they created jlink to create your own minimal runtime and jpackage to create your installer with that image.

Reply on news.ycombinator.com