Live data from Hacker News

IntelliJ IDEA 2021.1

blog.jetbrains.com

71–77 of 77 posts

Re: IntelliJ IDEA 2021.1

#71
post #12

Earlier quoted context omitted.

They really need to update the default memory footprint. The 750MB default isn't enough for any projects these days and they don't exactly make it obvious how to update it to 2-4GB.

No need as you’ll get a warning on low memory if you’re on a large project, and IDE will advice you to increase heap size (just click provided option) and you can manually choose how much memory to provide. So it’s fine that default is relatively low.

In my experience, IDEA becomes GC bound quite readily during indexing which in combination with indexing blocking most operations stalls the UI.

It's not that the IDE OOMs, it's that it burns cpu cleaning up objects in stop the world collections. These stop the world events can be mitigated with additional memory.

Re: IntelliJ IDEA 2021.1

#72
post #70

Earlier quoted context omitted.

I never once said Java was slow. I was saying that JIT compiling is a bad fit for an IDE. The workloads present in an IDE cause lots of problems for JIT compilers. And those problems actually can be exacerbated by an evolving code base with lots of new features.

> The workloads present in an IDE cause lots of problems for JIT compilers This would suggest the JIT is a problem. But that is not true, the "workload problem" really means "bloat". Any software is written for the machine it runs on and Java programs are written for JVM. No machine is perfect and writing performant software requires that you understand peculiarities of the architecture you are working on. If you ign…

Yes, the JIT is the problem. And no, this has absolutely nothing to do with OOP or bloated abstractions. Java is a great language, and the Jetbrains IDEs are written extremely well and have very high coding standards. It is all about the JIT. JITs do really well for code with lots of hot loops and few branches, because inlining and loop optimizations are the classic case for needing execution profiles. But IDEs are the opposite of that...there are branches everywhere, and very few hot loops. JITs are the worst possible compilation model for this type of code, because it is constantly going to be optimizing, deoptimizing, and reoptimizing code. The JIT is just constant overhead for something that should just be profiled and compiled one time.

Re: IntelliJ IDEA 2021.1

#73
post #63
post #59

Earlier quoted context omitted.

IntelliJ comes (optionally, but by default) with it's own packaged JRE/JDK/Java version iirc, so that wouldn't be an issue...

Apparently they couldn't be bothered to provide an AppCDS archive in modern JVM to go alongside InteliJ.

I also have the feeling that's only pjmlp and maybe 100 enterprises around the world that do use some features like these!

You always seem to mention them (class sharing, Java AOT compilers, etc), but nobody (for values of somebody < enough) seems to be actually using them :-)

Re: IntelliJ IDEA 2021.1

#74
post #73
post #63

Earlier quoted context omitted.

Apparently they couldn't be bothered to provide an AppCDS archive in modern JVM to go alongside InteliJ.

I also have the feeling that's only pjmlp and maybe 100 enterprises around the world that do use some features like these! You always seem to mention them (class sharing, Java AOT compilers, etc), but nobody (for values of somebody < enough) seems to be actually using them :-)

When one does enterprise computing those features are available to anyone that cares.

It is not my fault many developers don't care about their tooling, and settle for worse is better. :)

Re: IntelliJ IDEA 2021.1

#75
post #74
post #73

Earlier quoted context omitted.

I also have the feeling that's only pjmlp and maybe 100 enterprises around the world that do use some features like these! You always seem to mention them (class sharing, Java AOT compilers, etc), but nobody (for values of somebody < enough) seems to be actually using them :-)

When one does enterprise computing those features are available to anyone that cares. It is not my fault many developers don't care about their tooling, and settle for worse is better. :)

So, that's my question then: are those features really mature and available for using in production.

Or is it like some half-done features with several caveats and/or some companies with this or that compiler extension (like Java AOT), that might or might not work well, not have good documentation, or any kind of support, and that some cavalier daredevils opt to use?

I mean, I'm not 100% convinced whether it's devs don't caring, or the tools being niche and "use at your own peril", the reason for that lack of adoption.

GraalVM, for example, probably still has some rough edges, and that's an official Oracle tool.

In your experience which are the maturest alternative Java deployment tools/compilers/options?

Re: IntelliJ IDEA 2021.1

#76
post #57

Earlier quoted context omitted.

I'll have started Doom, opened a project, found my file, edited, saved and closed, while IntelliJ's indexing bar is still at 10%.

What does this indexing buy you time wise later? And what about starting it with an already indexed project?

> What does this indexing buy you time wise later?

For simple projects in Python or JS, nothing. For complex projects in most languages, quite a bit. For anything running in the JVM, a whole lot. That's why I pay for my IntelliJ license every year.

The question here is if it's quicker to open a project and be immediately productive in Doom Emacs, and it is, very much so. This is in contrast with Spacemacs, which I used for a couple of years but had to run Emacs as a daemon to make the startup fast.

If I want to go even faster I'll use Vim, but that's mostly out of habit and proficiency.

> And what about starting it with an already indexed project?

Maybe I'm missing something, but it re-starts indexing every time I open the IDE or the project or when switching branches. Is there any other way?

Re: IntelliJ IDEA 2021.1

#77
post #75
post #74

Earlier quoted context omitted.

When one does enterprise computing those features are available to anyone that cares. It is not my fault many developers don't care about their tooling, and settle for worse is better. :)

So, that's my question then: are those features really mature and available for using in production. Or is it like some half-done features with several caveats and/or some companies with this or that compiler extension (like Java AOT), that might or might not work well, not have good documentation, or any kind of support, and that some cavalier daredevils opt to use? I mean, I'm not 100% convinced whether it's devs d…

GraalVM is mature enough to power Twitter.

AOT compilers for Java exist in production since around 2000, basically all commercial JVMs supported it, specifically those targeted for embedded deployment.

AppCDS in Hotspot is nothing new, basically just like Flight Recorder, proven components from BEA J/Rockit JVM acquired by Oracle, which they eventually decided to make available on Hotspot.

Likewise OpenJ9 AOT and JIT caches, have years of production testing, from IBM J9 deployments in WebSphere Realtime JVM (now discontinued), IBM mainframes, Aix and Linux.

PTC and Sonic have been used for years in military deployments, and factory automation scenarios.

Aicas focus mainly in embedded scenarios.

Excelsior JET was quite good, but for whatever reason they went bankrupt.

Android Runtime, although not Java, has been AOTing since Android 5, starting with Android 7 evolved into a mix of interpreted/JIT/AOT with PGO from JIT, in Android 10 gained the ability to upload PGO profiles to the store so that devices can AOT right away.

Post reply on HN