Metal for IntelliJ Platform | Hacker News Reader

Metal for IntelliJ Platform

blog.jetbrains.com

109 pointsmarkdog1276 comments

You’d think Apple would just hire someone to do this for them, in Java. There are maybe 10,000 concerns they could pay for to resolve, with clear no nonsense objectives like “Does Java2D run on Metal?” And the crazy thing is they have the money to do it.

Apple has vested interest in users not running Java on their platform.

I've worked at Apple and hundreds if not thousands of their devs use Java

That's interesting - what is Apple building on Java? They're still on Java 6 I think? I thought they deprecated their Java system APIs years ago as well?

I bet most of their Java usage is web services and not Swing client apps.

Their FoundationDB has java Record Layer and in their keynotes they specify that it is used in iCloud and it is basically all icloud is java based

I’m pretty sure I saw the word «webObject» in my url bar while being redirected to their site at some point.

https://en.wikipedia.org/wiki/WebObjects

Been a while since I worked at Apple but it would likely still be:

- Apple ID

- Apple Online Store

- App Store

- Bug Reporter/Radar

- iCloud Apps e.g. Mail.

- iTunes Connect

- iTunes Store

- WWDC

Pretty much all of the internal apps will be in Java unless they are using off the shelf software e.g. discussions. In addition you would have all of the companies they acquired and whatever tech stacks they use e.g. Siri.

Apple have an OSS framework built on Netty (whose lead developer is employed by Apple) named ServiceTalk, and this talk [1] says that almost all back end services are Java-based.

I have no idea where the idea of Java 6 being in use comes from.

[1]: https://youtu.be/Ms8vriZ6ieU

> where the idea of Java 6 being in use comes from

Possibly from confusion with the last time Apple actually shipped a JDK/runtime to the public. They used to produce their own optimized distribution, which had better Cocoa widgets among other things. It was part of the original big push to get decs on OSX, it’s mentioned in Jobs’s keynotes etc. They later deprecated it once they reached critical mass, and discontinued it; if i remember correctly, the last jdk they shipped was a v6.

Not for building apps though, right?

not sure what you mean by "apps" but I am talking back-end mostly

I mean desktop apps, not backends.

I think this is true to a certain extent. They'd rather have developers create UIs with Swift/ObjC, which tend to look and perform better on Mac.

i.e. it's probably more about fostering great UIs for the end customers rather than curbing Java altogether as a platform.

Yes, it’s more likely that an app written with Swift/Obj-C and AppKit/UIKit/SwiftUI will be more tailored to macOS specifically and will better take advantage of platform facilities than apps written with a different language and toolkit (such as Java+ Swing). Apps built with third party tools tend to be more lowest-common-denominator.

Nobody cares, proved by electron and popularity of web apps in general. The only b thing Apple will achieve is to speed up the native going into irrelevance and being replaced with things like electron. Regular people don't care about "looks and feels native" zealots. All the relevant software has distinct, software specific looks. Adobe suite, Fusion, bunch of engineering tools, IDEs.

Regular Mac users _used to_ care. For many years, one of the defining characteristics of Macs was the high quality native apps, all with consistent look, feel and behavior. Mac users would refuse to use apps that weren't sufficiently Mac-like. Developers of Mac apps had a similar passion and perfectionism for good UX and UI.

Somewhere along the way, this part of Apple culture got lost. I think Apple's commercial success is part of the reason. The traditional Mac user base got diluted by lots of newcomers who didn't have the same high expectations and requirements for good and consistent user interfaces. The traditional Mac developers got diluted by programmers from other platforms, who – although not being technically inferior in any way – did not have the same passion or understanding of Apple's UI philosophy, often not even bothering to study the Human Interface Guidelines.

A lot of Mac users still care, as is evidenced by the continued existence of the likes of Panic and OmniGroup.

> Adobe suite, Fusion

Funny thing is that those are both products that many are reaching for alternatives to whenever viable. As powerful as they may be as tools, there's quite a lot that's throughly mediocre or even bad about them.

There are examples of truly great apps that use their own look and feel, but I don't think either of those are among them.

It’s about fostering lock-in and staying in control. Which is why they felt the need to build something like Metal in the first place.

This simply is not true.

This specific thing is much more a JetBrains (and their customers) problem than an Apple problem and it looks like they've managed to put together a good solution - do the work and have some assurance it's going to end up in the mainline OpenJDK. They've been selling their tools on macOS for many years, have shipped plenty of custom JDKs before, it's safe to assume they have a decent idea what they're doing.

“Does Java2D run on Metal?” doesn't seem like a top 10,000 question for Apple. It does however seem like a top 10 question for JetBrains. And so here we are.

How do you figure? Making the native graphics api available to popular toolsets seems pretty straightforward OS work.

But Apple wants people to use swift not Java.

That’s not the Apple strategy though is it?

They don’t want to be running around making Swing and SWT and Qt and Gtk work well on macOS. They offer their own and you can take it or leave it. I guess this lets them simplify and focus. It obviously works for them.

I wouldn't think at all. Just like I do not think Microsoft would implement Swift backend for windows.

It looks like much possible than Apple will do.

I would have loved to have seen a Vulkan implementation combined with MoltenVK[1] for Metal compatibility instead of a direct Metal implementation. This means that Java will now have to maintain two separate graphics implementations.

[1] https://github.com/KhronosGroup/MoltenVK

Why is Apple still dead set on having their own special graphics API? Surely it would be better for everyone (even them) if they just adopted Vulkan like literally every other platform?

Metal is used within the OS for all of its rendering.

So it's more a case of they built the API for themselves first and then made it available for developers.

They also have power consumption and mobile performance as being their highest priorities which may not align with Vulkans.

I would be surprised if the graphics API layer had a particularly big impact on power usage. One of the stated goals of Vulkan is also to reduce CPU load when rendering.

Still? What would have caused them to not want to maintain control of their platform?

All it does it make software (especially games) less likely to be ported to iOS/macOS. And they have to maintain a graphics API, which isn't a small task. How is that a good thing for them?

This isn't really something that helps or hinders locking consumers into their ecosystem.

iOS has no shortage of games, so that doesn't seem like a problem. And maintaining their own graphics API lets them fully integrate it into the rest of their hardware and software stack without the baggage that comes with a cross-platform standard.

iOS is a pretty big market, I would argue that they have lots of games despite not supporting open standards, not because. Gaming compatibility on laptop/desktop macOS is pretty piss poor. (Although Blizzard has always been really good at supporting mac).

What does Vulkan brings to the table apart form so called cross platform compatibility? Which is a bit like Cross Platform Apps, they are just never as good as Native Apps.

It is not in any ways better than Metal. And when you design your own Hardware, it makes much sense to own your API design for maximum performance.

I don't think you're right at all. I've read numerous times that Metal has significantly more overhead than Vulkan.

Please provide a citation- apple is doing amazing things with metal - particularly on the M1

> like literally every other platform?

What other platforms? The only ones I see adopting Vulkan are Desktop Linux and some newer Androids. The first effectively doesn't even matter.

Windows, iOS and Android are the most common OSes, only one of which uses Vulkan and not even universally or exclusively.

The games consoles don’t use Vulkan either. It’s a niche API.

There are times like this I feel electron is not bad of a platform. Platform APIs keep on changing but chromium always implement those in early phase(vulkan, metal, ARM mac OS etc). Development almost never have to worry about platform APIs.

Maybe in a couple of years when they get the resource consumption way down. And even web stuff runs better with the "native" implmentation, slack running on safari (really cant find it now, it was posted here a while ago)

I have gone through something similar recently (implementing nanovg on top of Metal). It’s a really good experience and can be achieved with relatively little code.

Who else uses Java Swing these days?

Honestly, I've been looking into starting projects on it because it's mature and I can have some confidence that a jar I compile today will work in ten years.

It consumes less energy? By how much, and was this the main motivation?

The main motivation is OpenGL being removed from macOS at some point.

I'd assume there's other considerations because if that were the only concern why not go with Vulkan, an industry standard?

https://github.com/KhronosGroup/MoltenVK

Battery life might be a good reason

For this sort of thing, adding another layer of indirection (and another dependency, developed elsewhere with potentially different priorities) is much more likely to end up being a 'now you have two problems' kind of scenario.

But they would have both a macOS port and a cross-platform Vulkan port then. "Two birds, one stone" kind of scenario.

And it's hard to imagine Java2D would have more complex requirements for Metal than the games that are already using MoltenVK.

OpenGL is still "fine" on Windows and optimal on Linux (which if their survey is accurate, are both larger platforms for them than Mac https://www.jetbrains.com/lp/devecosystem-2020/ ).

Of course, they could go full dx12 on Windows, Vulcan on Linux and Metal on Mac, but precisely because their needs are not that demanding in the graphics department, I imagine the incentive is to keep it simple

The Vulkan drivers should be at least as available as OpenGL on both Windows and Linux. So it would make sense to target Vulkan and thus benefit from a shared codebase.

And if their Mac client base is not big, it should make even more sense to experiment with MoltenVK (lower risk).

Anyway, they probably have good reasons for that choice. Just wondering what those are. Perhaps Oracle is not big on relying on community projects like MoltenVK?

From what I understand MoltenVK is not super efficient compared to native Vulkan on other platforms.

"Performance on par with OpenGL"

I would have expected a performance increase to be honest

Or maybe they push the limits of POSSIBLE perf because of the JVM, i guess that's why performance gain can't be perceived, no matter what, the JIT and GC has to constantly work..

They're aiming to get off a dead API as quickly as they can. All they have to do is match performance (no regression) and they're happy. They don't need to increase performance. That can be a separate project. Maybe you want to do it?

The OpenGL-based implementation is pretty damn mature, and it’s probably well optimised. The new Metal implementation is an early access release, at a stage in the project where performance concerns are more like “don’t do stupid things” than like “extract every last ounce of performance out of it”.

You are right, i guess

Now I'm curious to what degree the graphics rendering is responsible for IntelliJ's sluggish, battery-hogging experience on macOS. I wouldn't think it's the main cause, but who knows

Sluggishness is caused by the fact that it's Java.

It's not sluggish at all on Windows and Linux. "Java is slow" is a silly meme, it doesn't reflect reality.

I don't find it to be any more sluggish on my Mac compared to my coworkers on Linux. If anything I have a better experience than them due to various random Linux UI glitchiness (which could probably be attributed to the specific hardware they are using, but still).

That's true. It can be a total nightmare trying to configure stable hardware rendering on a lot of linux distro/hardware combos.

It's not a meme. Garbage collected language just can't be used for certain things.

they are great for desktop IDE software though

I've found Jetbrain products to be really bloated and sluggish, at least on my machine.

Because they do a ton of things and are full-featured IDEs. Of course it takes more resource than a vim or vscode instance which are only code editors

The classic example would be real-time applications where hard envelopes in terms of response times are required and GC pauses must _never_ happen. But even in these cases it is possible to do a lot:

- write garbage-free code (reuse objects and byte buffers, allocate memory off the Java heap and store the pointers in `long`s)

- use a GC that doesn't pause and carefully profile the app to ensure the GC can keep up with the rate of memory allocation

- turn off the GC and cross fringers if the app crashing is considered better than not responding

It's just difficult because most software is written using software patterns that require a GC, which is perfectly fine for many domains.

I quite like JetBrains various IDEs, but it would be nicer to have the same functionality built natively on Cocoa or SwiftUI or whatever.

I think that would slow down the development and that's why not being considered

Nicer, not necessarily practical

I have a Hackintosh with an 10980xe and 128GB RAM.

I tried this Metal build and it doesn't make it any faster. Pretty sure it's all of the background indexing and compilation it is doing because there is no app that can push all of my cores to 5GHz like IntelliJ can.

Indexing completly destroys a CPU. Thats why they are pushing shared indices now

Ah, supporting new Platform APIs I see.

It would be nice if they could start working on supporting Wayland and in turn HiDPI on modern desktops.

"Lanai" as a project name is hilarious. It's like begging to Larry Ellison

"Please don't cancel the project! You'll own it all anyway!"

*Lanai is the Hawaiian island that Larry Ellison owns

Reply on news.ycombinator.com