Comment by MaxBarraclough | Hacker News Reader

Comment by MaxBarraclough | Hacker News Reader

Parent Full thread

> SWT is surely just going through AWT

Not so, SWT uses its own bindings to the OS's native GUI toolkit, using JNI.

> desktop JVM could see a surprising renaissance as a lesser evil

I'm not convinced that a whole new toolkit is the solution, with all the challenges that brings (lots of widgets to create, internationalisation, accessibility, multiple platforms to test on, etc). I figure the better move would be to work on improving JavaFX. As far as I can tell it's a pretty solid GUI toolkit, albeit one with little adoption.

edit Also, I suspect one of the things holding back Java desktop GUIs might be that they're often clumsy to distribute. Expecting the user to install the JVM isn't good enough, the application should bundle a JVM, or use ahead-of-time compilation. The user should never be made aware of what language you built the program in. As I understand it, OpenJDK has been making solid progress on the latter option. (And Excelsior JET no longer exists.)

>Also, I suspect one of the things holding back Java desktop GUIs might be that they're often clumsy to distribute.

I just download Netbeans, this is 10+ years since I touch a Swing / Java apps. And nothing has changed, it still looks Java. It is still heavy, although start up speed are now better. But generally speaking an Electron Apps ( VS Code ) looks and works better than that.

Eclipse is still better look wise, as it was 10+ years ago. That was basically the reason why I choose SWT back then. But it is still not perfect.

So I decide to check out another consumer Desktop App from similar era, Vuze, or used to be called Azureus. And it is the same, Desktop Java Apps. And yes that was the reason why no many were using Consumer Desktop Java Apps. They dont look good, heavy on resources, need JDK etc....

As if nothing has changed in the past 15 years. I remember I was trying to use GCJ and SWT for Desktop Apps then, it was just too hard. I gave up. And it seems no one cares about decent, java desktop apps.

> it still looks Java

I think the Nimbus look is ok. [0]

> It is still heavy, although start up speed are now better.

It's certainly heavy. iirc NetBeans spins up over 20 threads even if you're not doing anything. As for startup times, is this on the same hardware? I imagine SSDs must help with NetBeans startup.

> trying to use GCJ and SWT for Desktop Apps then, it was just too hard.

There was a proprietary payware alternative to GCJ called Excelsior JET but it was discontinued 2 years ago. [1]

[0] http://wiki.netbeans.org/wiki/images/b/b2/Vista_Nimbus_Scree...

[1] https://en.wikipedia.org/wiki/Excelsior_JET

And about your edit, it's true of course, this is an issue. If you bundle the JRE feels wasteful and if you don't it feels uncaring for the less technical. Didn't JavaFX, beside being "Swing 2", consist of some native launcher component that would connect with an installed JRE if available (and sufficiently modern) and guide the user through download/installation if not? Memories are faint.

Many similar approaches have been done, but none became a conveniently dominant go-to solution. Perhaps AOT compilation will finally bring a JRE bootstrapper component that is sufficiently "java" to find a wide footing in the java dev community and sufficiently friendly to end-users to end all "but maybe that other tool is even better" that kept all existing approaches niche.

> Not so, SWT uses its own bindings to the OS's native GUI toolkit, using JNI.

A right, I forgot that, thanks. What's the SWT approach to use cases where you basically want a pixel canvas? Falling back to AWT on a surface allocated from the native API or its own facade for native APIs?

In any case this property of SWT kind of explains the omission, SWT happens on a level that is two layers away from skija in the stack Jetbrains are building for Compose Desktop.

> What's the SWT approach to use cases where you basically want a pixel canvas? Falling back to AWT on a surface allocated from the native API or its own facade for native APIs?

I don't think SWT makes any use of AWT, I believe it does the latter.

> SWT happens on a level that is two layers away from skija in the stack Jetbrains are building for Compose Desktop

The article is making the case for a whole new GUI toolkit for Java, without making a persuasive case against JavaFX (I'm not convinced that its performance is a problem), and without mentioning SWT, the foremost 'unofficial' desktop GUI toolkit for Java. Skija may have its merits as a platform for 2D graphics, but that's not the point.

Incidentally, the article's title is misleading. It's about GUI toolkits, not graphics libraries.

The whole new GUI toolkit in question is Compose Native and that's not entirely new (only the desktop part is). Literally millions of Android devs would already feel more at home with it than with any other desktop UI toolkit.

Maybe it's a bit dishonest to present Skija as if it was made for any other reason than to enable Compose Desktop, but it's very laudable to have the ambition to be more than an enabling component of that.

JavaFX might turn out to be a winner but it's still partly proprietary and is still transitioning from Oracle to the OpenJDK community. There's good reasons for it having little adoption.

Reply on news.ycombinator.com