Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The decline and fall of Java on the desktop

jdeploy.substack.com

Post reply on HN
Print view View original

141–150 of 362 posts

Re: The decline and fall of Java on the desktop

#141

Post by rowls66 »

nray wrote: post #58
mjevans wrote: post #33

IMO the real decline was Oracle. Java used to be a slowly rising language and set of platforms with benevolent oversight from SUN and at least the outlook that it was one of a few things you might want to add after Microsoft's Windows or Apple's OS (Macintosh or later OSX). Then Oracle bought SUN and everyone knew all of the good would eventually be strangled out by the lawyers and models that sought to dominate and…

The JRE security horrorshow might have started before the Oracle aquisition, and we wanted rid of java on the desktop for the same reason we wanted rid of flash. Apple used to advertise that only Windows suffered from viruses until their own unpatched JRE was exploited widely. Oracle contributed by making updates burdensome to download, and now unavailable without a support agreement, but what stopped java GUI apps f…

My understanding is that most of security defects in the JRE were related to the browser integration. The core Java sandbox was secure.

Re: The decline and fall of Java on the desktop

#142

Post by mdaniel »

dimgl wrote: post #119
shiado wrote: post #29

On the other hand Minecraft is the best-selling PC video game of all time and it was originally written in Java and the Java client is the definitive experience of the game.

There's also Project Zomboid. Which doesn't really come close to Minecraft, but it's also developed in Java with a Lua engine on top. Why? Well, I have absolutely no clue...

Heh, thanks for bringing that to my attention; based on the video alone, I think that'd be right up my alley (linky-linky: https://www.gog.com/game/project_zomboid and it's on Steam, too, if you're into that)

> Why?

From the GOG page:

Works on: Windows (10, 11), Linux (Ubuntu 16.04, Ubuntu 18.04), Mac OS X (10.9.0+)

is almost certainly "why," and I'd guess the lua part is because it seems to be the lingua franca of game modding, so meet folks where they are

Re: The decline and fall of Java on the desktop

#143

Post by leftbit »

shannah78 wrote: post #113
leftbit wrote: post #106

I've been coding Java since 1.2, mainly UI. 20 years we built a really complex control system visualizing thousands of graphical states on six monitors on a Pentium, quietly ticking away at 20% CPU usage... all in Swing. Which I still find very impressive. Swing suffered from two central weaknesses: the tutorials provided by Oracle were... often insufficient. And you could pick up some bad habits by following them. A…

"Swing suffered from two central weaknesses: the tutorials provided by Oracle were... often insufficient. And you could pick up some bad habits by following them. And then there were the UI builders where anybody could draw up something mediocre." Agreed. Also, the IDEs would typically give you too much rope - enough for a novice to hang himself. When you create a new project with Xcode, you get a default project wit…

Oh, yes, the details are critical.

Once inherited a 2D graphic editor... so slow it was totally useless. After tinkering a bit I noticed coordinates were sometimes 'long', sometimes 'Long'... gazillions of automatic boxing and unboxing operations resulted in a severe performance penalty. But the original developer didn't figure this out, tried to fix the problem by adding some multithreading on top... and of course botching it.

Introduced some sensible data types, got rid of the multithreading and it really got smooth...

Re: The decline and fall of Java on the desktop

#144

Post by leftbit »

thrashh wrote: post #56

IMO the real reason why Java never took off on the desktop is because making a cross platform Java app is pretty easy but distributing a cross Java platform app is super hard. There’s all these situations that you have to account for, there’s no de facto way of doing anything, and you’re basically on your own finding a solution that fits your app. On top of that, you have to distribute the JVM and licensing for that…

Now we've got jlink to bundle your application with the neccessary runtime modules into one custom runtime image... a bit late to the game, but still...

Re: The decline and fall of Java on the desktop

#145

Post by panick21_ »

throw7 wrote: post #77

The issue with java was users don't care about write once/run anywhere. They care about the program running perfectly on their OS of choice i.e. the java program better look and perform just like a native program (and who can blame them?!). I run tuxguitar once in awhile and it still gets multiple monitors wrong which makes reading music sheets awful by default. (the "fix" is to hard code a resolution in a startup co…

I don't think so. In reality people don't care about native feel, they care about it looking good, working well and doing what they want.

Re: The decline and fall of Java on the desktop

#146

Post by cgrealy »

bruce343434 wrote: post #110
cgrealy wrote: post #67

Earlier quoted context omitted.

not really a desktop app though, is it? And Minecraft is also a notable outlier. Outside of mobile, there are very few games written in java on PC or consoles.

Minecraft is an app lication which runs on the desktop... I don't see what you mean.

It's a game. It's UI is full screen and completely divorced from "standard" UI elements (WIMP, etc).

You can call it a desktop app, and you'd be correct in the most pedantic sense, but then every web app is also a desktop app since you run it on a desktop.

Re: The decline and fall of Java on the desktop

#147

Post by leftbit »

adrian_b wrote: post #63
cosmotic wrote: post #4

Java Swing still lets you make native-looking-and-feeling apps (with some care). I don't know of any new GUI frameworks that let you do the same. I consider this a killer-feature of the framework. It's also very fast, backed by OpenGL and DirectX. It also ships with source code and isn't declarative, so it's trivial to step into as a means to debug why your code isn't working.

I do not know whether the Java GUIs that I encounter from time to time are made with Swing or with other frameworks. What I know is that since the beginning of Java and until now, on every occasion when I use for the first time some program and I am surprised that its GUI is ugly, slow and impossible to customize, then, without exception, I always discover that the GUI is written in Java. Since around 8 years I use o…

Yes, that's totally annoying since it really isn't very hard to get right... Swings layout managers are just made to deal with this stuff.

Re: The decline and fall of Java on the desktop

#148

Post by kaba0 »

Cthulhu_ wrote: post #132
tombert wrote: post #93

Earlier quoted context omitted.

Haven't used Lombox, RxJava is great, but it just feel like bandaids on a language that wasn't really designed for it. There's no accounting for taste, but I'll take either Scala or Clojure on the JVM any day of the week. Scala's monads don't feel like a library feature, they feel baked into the language...because they are.

Lombok is indeed a band-aid that replaces IDE-autogenerated code, which in turn is a band-aid for language design choices on the one hand (e.g. equals and hashcode), and accepted Best Practices in Java world like setters/getters everywhere; for the latter, you can either do public final fields, just use public fields until you need an accessor method (java's refactorings are great), or on the other hand add language…

Java designers chose the public method with the same name as the corresponding field policy as the preferred one (as per record’s design), this combined with the coming syntax for “copy the object but changing these fields” will make java quite good to use imo.

Re: The decline and fall of Java on the desktop

#149

Post by kaba0 »

babypuncher wrote: post #136
michaelt wrote: post #85

Earlier quoted context omitted.

Oracle certainly wasn't good for Java. But Java-on-the-desktop had been struggling for years before that. You either bundled a complete JVM with your application (fine if you're making a 500MB IDE, not so good for anything smaller) or you had the embarrassment of directing your users to an installer that bundled the Ask toolbar. They might even end up with the security-hole-riddled java browser plugin. And even once…

The hassle involved with needing multiple versions of Java on one system also impacts its viability on the desktop. Not a problem if you run your Java-based services in containers that can use their own JRE, but a huge annoyance for kids and budding hobbyists who try to run Spigot and god knows what else on the same computer.

There is not even a JRE anymore, current best practice is to create a platform-specific lean package with jpackage that will only contain the modules that is actually used (decreasing binary size as well startup time). So the current direction is very much away from the old ways.

Re: The decline and fall of Java on the desktop

#150

Post by hermitdev »

sebazzz wrote: post #10

As a C# developer I remember the first time I developed a GUI java application. In C# you have a code-behind file with your own code and event handlers, and a "designer file" with the generated code to set-up the GUI itself. Then I used Netbeans for a Java app, and the code file contained weird sections of artificially not editable code, and event handlers were so much more complex and cumbersome - with inner classes…

Early C# didn't have partial classes and had the generated code in the same file as all of the rest of your code, as well. They put it in regions that VS would automatically collapse for you, but it was still directly there. I think it was C# 2.0 that added partial class support and they started moving the designer generated code into separate files which was truly helpful.

I don't think C# was ever as bad as MFC was with true magic generated code that you had better not change lest you inadvertently broke everything beyond repair (unless you really understood cryptic C++ error messages & preprocessor usage). MFC of the same era was not beginner friendly, even C# 1.0 was.

I've never had the (dis)pleasure of doing java UI work, though, so I can't really comment on the state of things there.

Post reply on HN