The decline and fall of Java on the desktop
jdeploy.substack.com
jdeploy.substack.com
It’s not that bad really. Package size and RAM usage is a bit of an issue, as we bundle it with a jlink’ed (stripped down to what is needed, thanks to Java 9 modules) JDK.
Other options like Electron or native Windows/macOS wrappers around a shared core written in C++ were discussed but ultimately discarded.
Still happy with the choice, although it feels a bit dated and IDE support (IntelliJ) is so so.
It's good enough to where I think that if JavaFX had come out around the same time as Swing, the Java GUI would substantially more popular. As it stands, when I tell people I'm using JavaFX, they either don't know what I'm talking about, or they'll say "isn't that just Swing? Yuck!"
https://github.com/cljfx/cljfx/
I haven't used React, but I think it's very similar. You have a state atom and then a datastructure that represents the GUI and associated callbacks that modify the atom. So it ends up feeling very functional. It doesn't use hiccup, but it's a similar structure. I've got to say it was fantastic. The least painful GUI programming I've ever done. The core architecture isn't opinionated so there is a little boilerplate/plumbing to setup but then it's very smooth sailing. It even has a very handy memoization structure that allows you to seamlessly have intermediary derived states that update automatically. I release an app using it and it was very performant, used some Java CV libs and drew diagrams to the canvas and it was all very snappy.
My only minor complaint was that the final bundle was like 150MB, which given the scope of the app seemed a bit gross - but it's manageable. And as usual, buy default, the JVM gobbles up and doesn't release memory back to the OS which is annoying. But i think it's surmountable and In theory you could trim that all further with GraalVM. Just out of the box it's not the best for little hello-world apps
Lombok, RxJava/Reactor where possible, and monads everywhere. It is beautiful and succinct, though I totally appreciate it may not always be easy to introduce on older frameworks or legacy projects.
If an object is just data, then @Data is all you need. If an object crunches numbers, then @Service with @RequiredArgsConstructor if you don't prefer to @Autowired things individually.
Any other usage of Lombok is possibly indicative of a questionable application design imo
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.
That said, I did hear Java is getting value types soon, or something like that. A bit too little too late maybe, but welcome nevertheless.
If I had the choice I wouldn't use Java again; JVM is fine, but there's better languages for it than plain Java. Kotlin seems alright. Wouldn't use Scala again, that's a language for sadists.
JNA is an awesome piece of technology.
Question is can JavaFx be recommended for a new project, given the uncertainty of its future and lack of popularity.
TornadoFX is only a convenience skin on top of JavaFX to make Kotlin code more concise (but it's heavier also as it adds a lot of code to your application).
Also I tried to get rid of unused classes using Proguard, but there are zero tutorials for non-Android java apps.
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 extract for revenue control.
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 user has java installed, you can't just double-click a jar file to run it. And the performance isn't anything to write home about either, if Eclipse is anything to go by.
Java remains a fine choice for use on the server, of course.
So, while Oracle is for sure not the most sympathetic company, it is good at execution.
Back when Java/Sun were up for grabs:
1) Google by far (they were less evil back then, I think). I mean, they would have saved money and headaches and probably a lot of distracting management meetings.
2) IBM, well ok: they did Eclipse, had their own JDK, and a lot of enterprise customers on locked platforms that could financially support the language and platform and were decent contributors to Linux.
... ....
3) Really? Oracle?
It's a miracle Oracle didn't completely kill Java.
They were one of the first companies to jump into Java, in fact the first conference talk about Java that we had on the campus back in 1996 was sponsored by Oracle.
They also collaborated with Sun on the Network Computer thin clients for Java based computers.
In 1999, all Oracle GUIs for their software were converted into Java applications.
They also own J/Rockit and BEA, whose core technologies now live on OpenJDK (JFR, JIT Cache, GC) as free beer instead of enterprise prices.
IBM already has their own Java, and have done so since forever, including some extensions (AOT is supported since decades), so it is debatable what they would further do, kill OpenJDK and replace it with J9?
Given Dart and Go examples, and Android with outsourced everything (language, IDE, messy updates, forked language), thankfully Google doesn't own Java.
But the bundling of Ask toolbar came about in 2013, so that was definitely Oracles doing.
....the Ask toolbar. Had happily forgotten about that.
shudder
but at least this would let them play Ski Stunt Simulator...
Regardless of what its other branches are doing, Oracle managed to do one of the smoothest language takeovers where the (stellar) core team is virtually unchanged, the language became completely open sourced and it underwent tremendous changes which resulted in huge growths after the slowdown at the end of the Sun era.
Note: I am not working at Oracle and never have.
I don't think it's needless. I'll bash Java as long as it's the language for AP computer science. Imagine a budding young programmer, bright eyed and bushy tailed, eager to get into computer science. They get to class and greet the teacher "Welcome class, let's learn about Java. There's a wide world of computers out there, but your perception of computing will be that Computing <-> Java until maybe the sophomore year of college. Have fun!"
Students come to me their sophomore year of college completely awestruck. "I had not idea! I thought programming was all Java!" they tell me. Imagine that. Close your eyes and picture a world where all of programming is Java programming. How quick did you open them and splash water on your face to wake rid yourself from that nightmare?
Java is singlehandedly responsible for snuffing the dream of so many young programmers. I've seen it in my own research, where kids in elemntary and middle school describe programming as fun, interesting, and challenging. That's because at this age they're using fun languages like Blockly, and they spend their time programming making and playing games.
Then they get to AP computer science and they are introduced to Java. Perceptions of programming fall through the floor, with more students calling it difficult, frustrating, and scary. It's tragic what Java is doing to young people.
Like, I understand we want students to have skills they will use in business, but we can't present programming to them as if all of programming is OOP enterprise development in Java. It's a crying shame.
But I would say Java is as good a first language as python is.
The purpose of first programming language is teaching concepts - functions, structs / classes, abstraction, data structures (importantly lists and maps); And how to solve problems using that.
Python does well in intuitive syntax for lists/maps, handy standard library functions, and having an REPL; But it gives an illusion that types are redundant. The programmer picking up C++ or Java after python sees only ceremony.
You can also learn the modern java without all the OOP shoved in: Basic programs, functions, data types, arrays, using classes to create custom types, using HashMap, ArrayList, HashSet from standard library; then interfaces, inheritance / subtyping, lambda functions. Use jshell to try small snippets;
The problem with teachers teaching java is that they focus too much on inheritance, with mostly superficial examples like "dog extends animal" instead of something in real world. Inheritance is mostly about subtyping, and any CS student with enough math background should not struggle to understand that.
If students get this preconception, I think it's more an issue how they are taught, not an issue with Java itself. I mean the first language I learned and most of my classes were in Java, but that didn't prevent me from knowing there other existing languages and learning about them.
[0]: https://link.springer.com/book/10.1007/978-3-319-99420-8
Not sure how I feel about Python (or Java) as a first language. Something a bit lower like C would be a better foundation, IMO.
Sounds harsh? Not at all.
Programming languages are a letters on a digital paper, they don't steal and rape people on dark corners, or beat them to death.
The fact that the acquisition cast off a bunch of brilliant, distinguished, charismatic engineers who have every reason to further the mythmaking also plays into why we hear so much of it. But to give credit where it's due, it's given us this esteemable gem of a rant:
That said, Oracle's legal machinations certainly didn't help matters once they took over.
Java was never going to be able to keep up a reasonable native UI binding, because OS vendors were at best ambivalent and at worst actively hostile, because there was nothing in making it work that benefited them.
Security without centralized platform control (e.g. Windows Update, AppStore, Play) was likewise an excercise in futility.
The sandbox escapes were made worse by having applets in the browser.
Now that applets are not a consideration any more the sandbox (SecurityManager) isn't used very much anymore and the Java devs are looking at deprecating and removing it, so most of the sandboxing features will go away.
It's because HTML+CSS (without even any JavaScript) is still the fastest, most effective way to build a compelling and coherent UX/UI for any platform right now.
WPF (nee Avalon) was a contender in the mid-2000s, but for some reason Microsoft put it on ice by 2007 leaving the community stuck with incredibly verbose and bloated XAML markup which only made development more tedious than WinForms, which WPF was slated to replace. Microsoft's effective abandonment of *their own desktop developer story* is what enabled Electron to come along and even prompt Microsoft to use Electron for Skype, Teams, Azure Storage, and VS Code - it's utterly bizzaro-land now: almost as if the Microsoft of the mid-1990s made their own website only work in Netscape.
I was at MSFT from 2012 through 2015, my observation was that the C-suite unintentionally kept OSG (Windows, etc) separate from DevDiv (Visual Studio, WPF, and all those nice cushy libraries), which led to OSG and DevDiv having to recreate each other's work and ending up with complete messes like "XAML Windows Store Apps" which turned into UWP, which no-one is took seriously because it was too limited, while Win32 is still the only real way to use Windows' "real" UI widgets. I can't explain the situation: things were dysfunctional like this long before the great layoff of 2014.
I would agree if you mean cross-platform, but other than for the web specifically, basically every platform has a much better way to create an app for it. The web is seriously so lacking on several trivial fronts that it is laughable, layouting being one example, but just creating a slightly modified version of a native widget like calendar require the recreation of the whole thing with quite bad primitives while goddamn WinForms could deal with it through inheritence.
I accidentally spent 4 hours writing a reply to your point here and it ended up being too long for HN's comment length limit, but I posted it to pastebin: https://pastebin.com/n6AGB62L
> The web is seriously so lacking on several trivial fronts that it is laughable
That depends on your project's requirements. Speaking from personal experience, my main beef is that HTML web-forms still lacks a loit of widgets necessary for RAD that native UIs have had for decades, like comboboxes, true hierarchical menus, RTF or Markdown text editing (because `contenteditable` is horrible), and so on.
...however, if you're enthused enough it's very possible and quite straightforward now to create your own controls and widgets from scratch, which is what Electron apps like Slack do. Of course, when you do, you're condemned to having to maintain them for eternity, but that's a cost of doing business.
> layouting being one example
Actually I was going to say that's exactly where CSS outshines platforms like WPF, XAML, even Cocoa (not to mention Swing and AWT - I can't speak for JavaFX as I've never used it).
I agree that for most of the past 20 years CSS has been a pain for so many layout issues ("how do I vertically center a div?" is probably the #1 question repeatedly asked on StackOverflow), but CSS's flexbox and CSS grid have been supported by all major browsers for almost a decade now and I can confidently say that I can build an aesthetic design with a layout that adapts to changing window/screen dimensions and aspect-ratios in a fraction of the time it would take me to do in any native framework.
Consider that 1990s-era frameworks like VB6, WinForms, etc were all fixed-layout and required you to write your own repositioning logic in resize-event-handlers. WinForms didn't get anchored-layout until 2005! Post-2000s frameworks like Swing and WPF added layout containers, but they're far from perfect and don't support radical re-layouting. More modern frameworks that use constraint-based layout or support major relayouting (like SwiftUI and WinUI 3, to an extent) are appealing, but I find offer few real advantages over CSS's layout model.
A major personal win for CSS is the content/behaviour/presentation separation (<div>-itis, not withstanding). Compared to WPF where a single XAML file will mix content, behaviour, and presentation elements, attributes, and controls without any regard for separation-of-concerns or maintainability (WPF does have CSS-esque Styles, but despite the name suggesting they're strictly presentational they're not: they're invariably used to control behaviour (due to XAML's ugly and unusable template and trigger ceremony) and also content (due to how content-based templates are used).
> while goddamn WinForms could deal with it through inheritence.
But that's where the failures of inheritance becomes obvious: consider WinForm's own Checkbox control. Surprisingly, the Checkbox is actually a subclass of Button, and shares no relationship with the intuitively similar Radio control despite their very similar visual appearance and behaviour. WinForms' design (like most other OOP-based frameworks) shoehorn both UX behaviour and visual appearance into a single OOP inheritance tree. This only works up-to-a-point, then things quickly fall-apart.
Plus ca change...
One of the problems in my opinion is that once you went up the chain beyond the developers, it seemed like there were some people that didn't understand what they were doing or didn't care or possibly both. They had targets to meet (or something) and the health of the project was a secondary concern. Part of this could be seen by the messaging saying they were investing in JavaFX, mobile, etc., but most of the commits to the repo were done by a few people. I can't remember what the numbers were, but I remember being shocked and thinking that if one of the top two contributors disappeared the project would be in trouble.
However, the biggest mistake in my opinion was forcing JavaFX into the JDK way too quickly. You can tell that's the type of decision that comes from the top down. They wanted to be able to say the JDK had a next generation GUI toolkit and checking that box was more important than letting the project develop in a healthy manner.
Before JavaFX went into the JDK it was really easy to contribute to the project via the dedicated bug tracker and you could get quick, friendly, helpful feedback directly from the developers. Bugs were fixed and would land in the next release. After it was part of the JDK you had to use bugs.jdk.com and it became much harder to participate. Factor in JavaFX having to adhere to the JDK release schedule rather than iterating quickly like they had been and it was impossible to figure out what Oracle was trying to do. Was having JavaFX on the JDK marketing material really worth stalling the development and ruining any chance it had of becoming more popular? I still can't get my head around it.
The fixation on the browser plugin and applets always confused me too. It was obvious for years they'd eventually get locked out of browsers, so I don't know why they didn't push things like Web Start a lot harder. Web Start was a pretty decent distribution system and if they had improved it to fetch JREs, like OpenWebStart does now, it would have been one of the best options at the time.
To this day I'm convinced that JavaFX was a missed opportunity. I'd love to try to build an app that uses Gluon [1] stuff for direct framebuffer rendering on a Raspberry PI with Mender [2] for distribution. I think you could combine something like that with JxBrowser [3] to build a digital signage system that's much better than anything on the market, but the licensing is a huge pain and too expensive for a hobbyist project.
A univeral GUI (e.g. Swing) was wrong-headed. I don't actually know what happened after people moved away from Swing. But even in the time range TFA discusses, Intellij IDEA, an IDE written in Java, was a success. It has always been multi-platform, and never had worse than acceptable performance in my experience. It has grown into a large suite of products, and I think it is widely considered to be the best IDE, for pretty much any language you can name, by a wide margin.
Java has become the new COBOL -- the language for business applications, which means backend development. But the continuing success and improvement, and broadening of the JetBrains products pretty much demolishes the argument that Java has declined and fallen on the desktop. JetBrains is an existence proof that it is a very capable platform for anyone who chooses to use it there.
- JBuilder was performant (and as I recall, for GUI development, awesome). Not sure if it was Swing-based, but it was a counterpoint to the idea that you couldn't build performant Java GUI apps.
- Applets were stifled by Microsoft refusing to include a contemporary Java runtime in IE, which was still dominant around 2000. My recollection is a bit vague now, but I seem to recall that Java applets in IE were stuck on a 1.0 JVM when Java 1.2 was contemporary.
It's worth noting that I was developing on Linux and Windows. The author's experience would have been coloured by his use of the Mac platform. Up until quite recently, Macs were stuck on Java 6 while the rest of us were using Java 8, at least. I can't help but wonder if Apple considered Java to be a second class citizen.
Your counterpoint doesn't apply to the article because the author's use of "decline & fall" is about market share and dev mindshare and not about any declining technical capabilities. (Notice that the author already agreed with you about Java's capable platform when he wrote: "Despite the ominous tone of this article’s title, I believe that Java is a compelling platform for modern desktop applications.")
Jetbrains releasing new products doesn't change the fact Java lost popularity as a tool for desktop apps in comparison to its 1995 hype. Even during Java's late 1990s peak hype cycle, its usage for desktop apps was never adopted by programmers to the same degree as Electron/Javascript is today.
Jetbrains IDE's prove the fact that no matter how much you engineer, a java based desktop application will always be slow and eat huge amounts of resources.
This piece covers the state of the technology at that time. In the early 2000's Java was slow. I wasn't familiar with IntelliJ at that time, so can't comment on their performance then. I wouldn't expect it to be dramatically better than other Java apps on the market at that time.
Moore's law has steadily changed the landscape. So have improvements in JIT technology.
It’s ridiculous that I have to modify Java VM arguments so IntelliJ can use more ram and actually index my projects.
The IDE is great, but Java undoubtedly makes it worse.
The JVM is a beast, why do you think a good deal of all serious web applications run on top of it?
When I run a Java app-server I'm happy to, in fact it's unwise not to, allocate it the maximum possible RAM the underlying server has. That's because I know for sure JVM is the only thing that's going to be running on a server.
On a desktop it's a totally different story. IntelliJ has to compete with other applications for RAM because I'm constantly multi-tasking between browser tabs, Apple Music, Slack app and what not. So allocating RAM to JVM apps on desktop is a world of pain because I, as a desktop user, just don't (want to) know how to fine-tune hardware resources for different apps. I don't allocate heap to Safari, why should it be the case with IntelliJ? Why can't they figure out? Or maybe there should be a desktop version/mode of JVM that'll figure out ideal RAM size and work with it and expand/shrink as needed?
The JVM sacrifices latency for throughput, which is good for servers but not for desktops.
In its success it shows how badly Java has failed.
Before 2004, there was a much wider perception that web applications were fundamentally limited by their latency, and if you wanted a really rich, interactive user experience, like Winamp or Outlook, you had to make a desktop application.
Then Gmail launched in 2004 and Google Maps launched in 2005. At that point, if you wanted to make a web-enabled experience with a high-quality user interface, it became more and more clear that you should build the client side in HTML + JavaScript and the server side in whatever you wanted, possibly Java.
Webapps over dialup was a complete non-starter, so you had to have desktop apps.
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 etc. Felt really like a step back.
Being years late to the party and basically creating a (back then) Windows-only copy of Java, it's quite normal that they managed to do a few things better.
Regarding UI editors: back in the days IntelliJ was already amazing and allowed to hide all that boilerplate Java code. This boilerplate code was still there, but hidden by the IDE.
Microsoft brought out Internet Explore (embrace), added ActiveX (extend), and pretty much extinguished Netscape. All websites could run in IE, but not Netscape - and users are going to use the browser that works for all sites.
Sun's lawsuit against Microsoft wasn't quite about adding native GUI features to Java as much as Microsoft breaking Java compatibility. Microsoft removed JNI (Java Native Interface) and replaced it with J/Direct. Microsoft wanted Java programs to be platform-specific with Java being "just the latest, best way to write Windows applications" (according to documents from the trial).
It's not like Microsoft was trying to create MAUI back in 2000 (the new C#/.NET multi-platform app UI). Microsoft was trying to make it so that Java apps wouldn't be cross-platform by both breaking Java programs that used JNI and making sure that new programs would be made with J/Direct and their Windows-only GUI.
Today, we see a much friendlier Microsoft. It's wonderful. They're happy to coexist with lots of people and ecosystems, lots of Microsoft employees use MacBooks, and Azure is one of the largest operator of Linux servers in the world - and they've made a wonderful business out of this coexistence. Back then, Microsoft would kill everything it could find to keep its dominance. There was no friendly help. There was no "oh, we're just trying to make the GUI better." It was "if we make the UX better via a proprietary native UI, we can get developers using our UI toolkit from Java which means that users are still locked into Windows, it means that the Mac will still be starved for applications, and it means that new operating systems like BeOS won't get a library of applications to bootstrap from if they just add Java support."
It can be hard to remember how much Microsoft tried to break your toys - especially when today they seem like the company that's trying to make cool toys for me and make my current toys better. Proprietary Microsoft Office formats to keep people locked in, telling PC makers that if they offered alternative operating systems as an option they'd lose access to Windows, and taking anything that showed promise and adding something to it to break compatibility with cross-platform implementations (Java, the web, etc)
C# got created because Microsoft got locked out of their embrace, extend, extinguish strategy with Java. Their Java license mandated that they maintain compatibility and they didn't - and to be frank, it seems that they didn't break compatibility with good intentions.
> It's not like Microsoft was trying to create MAUI back in 2000
Today, in 2022, Microsoft still tries to uses the MAUI name even though it is directly the name of a pre-existing unrelated GUI toolkit (https://mauikit.org/). Much friendlier my arse.
It didn't take long for JIT compilers to exist for other platforms.
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.
Who are you kidding?
> (with some care)
No. Even if you were to give it more care than required to rewrite the GUI natively in each major platform, you still wouldn't be close.
Look, I get it, there are plenty of applications where a bit of clunk in the GUI is beneath other things on the priority list. That's fine. But the number of java devs who think clobbering together a few native widgets means they have constructed a native experience is... disconcertingly high. There's a whole GUI world out there beyond the lowest-common-denominator, and Swing isn't even the best at that.
Your priorities might still be perfectly rational. I might even make the same decisions under the same constraints. Just... be aware of what you're trading away
At least in Electron textboxes have standard context menu and drag and drop.
It's absolutely a psyop cover for the number of webkit-in-a-box projects that don't even bother with the first step. Normalized deviance.
https://www.amazon.com/Filthy-Rich-Clients-Developing-Applic...
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 only 4k monitors. While on Windows I have encountered some programs which had problems on high-resolution screens, on Linux I never had any problems, except with all professional programs written in Java, which, unlike the native GUI applications, do not honor any system configurations and they do not seem aware of which is the monitor dpi, to adjust their GUI. Moreover, for some reason the programmers who write such Java programs are almost always morons who do not provide any means for changing the fonts which are used by the GUI.
Just a few months ago, I have still encountered some expensive professional programs, which used a Java GUI installer. The Java GUI installer crashed on any computer which used monitors with 10-bit color components. When investigating the problem the conclusion was that it is a well-known Java bug that had not been solved for some years and which causes such Java GUI installers to work only on low-quality monitors with 8-bit color components.
So much for the supposed benefit of Java being able to run anywhere.
Anyone remember this video? https://www.youtube.com/watch?v=UuLaxbFKAcc - Totally Gridbag
As others have said, JavaFX is really pretty good. People who use JavaFX generally seem to be satisfied, it's not often I see a substantive criticism of it, but unfortunately it seems to be widely regarded as too little too late and doesn't get given a chance. The Ada of the GUI toolkit world.
Unfortunately had issues with new version breaking backwards compatibility etc. which killed it.
QT also had similar hype but never took off.
I would. People who use accessibility tools that work best with native controls would as well.
That's the whole raison d'être of the (C++) wxWidgets toolkit. [0] It fully commits to using native GUI widgets, rather than impersonating them. (That is, it wraps various other toolkits.)
As others have pointed out, the other major cross-platform toolkits (Qt, GTK) also do a pretty good job.
I'm sure there are a small group of people who use native apps for everything but the rest of the population is using the browser most of the time.
I don't even understand what you mean by "niche usages like utilities". Utilities aren't "niche".
And I literally don't know anyone who uses a computer and does not use some form of "creative" / authoring apps. Some drawing apps, some music production or maybe just the occasional recording with Audacity, trying to make games, editing ebooks with Calibre, etc. That's what human beings use computers for (and we're here to do things for human beings before anything).
Literally the only obstacle to any language being on the desktop is the lack of someone creating a reliable, well-supported, cross platform, and easily licensed distribution method for that language.
The goal of jDeploy is to sand off as many of these rough edges as possible to make cross-platform distribution as easy as cross-platform development.
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.
Real strength were the lightweight components where you could about change everything in your Look&Feel. Hexagonal radiobuttons? No problem. Want the drop down button of that combobox a bit larger? There you go.
SWT... wouldn't really categorize that as an UI toolkit. SWT is mainly driven by eclipse, not developed independently. All controls commonly used by eclipse run reasonably well. Using anything else, especially cross platform is risky. 2D graphics is especially slow. So it's only a reasonable choice if you want to build something that looks and behaves like eclipse. There's some styling of components via CSS, but it's not complete...
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 with all of the essentials for a native app. The menus, a window, an "About" window. Etc. In most java IDEs you get an empty main() method. Making an app that feels like a first-class citizen requires a lot of work and attention to detail.
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...
Is swing still developed and is there any reason I should pick JavaFX over Swing?
Contrast with the web deployment model:
* Deploy with a free SSL certificate
* Click Once, Run Anywhere (CORA)
Luckily for Java fans, you can make great Java apps for the modern web. Tools like TeaVM (and its Flavour toolkit for SPAs) make it possible. Code in Java, bind to real HTML templates, compose your app out of reusable HTML components, style with CSS. All the benefits of the modern web, with a single strongly-typed language top-to-bottom.
* TeaVM: https://teavm.org
* Real 5-letter word app made with TeaVM/Flavour: https://frequal.com/wordii/
* Migration Guide from Swing to TeaVM: https://frequal.com/TeaVM/migration/MigratingFromSwingToTeaV...
* Java Magazine article on TeaVM: https://blogs.oracle.com/javamagazine/post/java-in-the-brows...
- An Electron (Desktop) app
- An React Native Mobile app (that needs to be delivered through both Google & Apple proprietary channels)
Whether you loved or hated Java the language, it is hard to deny we ended up in a terrible place:
- We lost all freedom on mobile
- We rely way too much on Blink & Webkit
- We traded Java for Javascript
- It's still relatively slow
- We haven't fixed the security problem on desktop
- Devs now have to manage a lot more technologies & moving parts
Why? Well, I have absolutely no clue...
> 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
And Minecraft is also a notable outlier. Outside of mobile, there are very few games written in java on PC or consoles.
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.
Running a server without nogui gets a window also.
Java simply wont go away because it works.
For serverside it's a nobrainer, but also for client if you have a niche consumer base.
Average joes don't understand the overhead of writing native applications and they are paying for it without knowing.
Here is my only contribution to the "desktop" Java eco system: http://move.rupy.se/file/logic.html
It has worked flawlessly on Windows, Linux and Macs for over 15 years.
Mobile, there's Android... or did you not realize that's Java?
As for android, well, let’s just say that android java is not real java.
The JavaFX-based WebView (an HTML rendering component) is lauded, but has no direct API to control the scroll position and is itself a memory hog. Scrolling must be handled through JavaScript, and that indirection is as unwieldy as you can probably imagine. FlyingSaucer is a workable alternative to WebView, but comes with numerous technical issues that rear themselves when embedding a Swing widget inside a JavaFX application---as I discovered during development.
Were I to start from scratch, I would definitely seek out alternative cross-platform programming languages for desktop application development. The JavaFX event-based model is top-notch, but there are too many technical gremlins to make implementation a smooth ride. (Such as improper handling of Alt+Tab, which leaves focus on the menu bar when returning to the application[4].)
[1]: https://github.com/DaveJarvis/keenwrite
[2]: https://github.com/dgiagio/warp
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 config file which is awful ux).
Looking good? The default Swing metal theme was truly awful. It was possible to switch to Windows-like theme, but it was even more awful - it had plenty of visual glitches and things misplaced by a few pixels it couldn't even use the native file selector window.
Working well? Startup times and performance was terrible compared to native apps, and memory usage is still abysmal. And you got occasional GC pauses even in well optimised apps. I still sometimes run into occasional lags in Idea, even though Jetbrains did a lot of great work to polish the user experience.
Doing what they want? That depends on the programmer, but, besides developer utilities like IDEs, I can't think of a Java app that didn't have a better looking and more polished native competition.
Native look has lost its meaning long time ago.
Luckily there seems to be a push for fully native.
Intellij does a shit load of thing, caches your files, constantly monitors for changes, etc. It is not vim written in java.
I've got a desktop machine from around 2010 with 32-bit OS, Core i5 760 (510 / 1611 point in geekbench single/multithreaded) and 4 Gb RAM, runs my current Java code in IntelliJ from those times at blazing speed. Modify a line of code and run in debug, it's up an running in less than a second.
Same code on a 2018-ish laptop, 64-bit OS, 16 Gb RAM, i7 6700 HQ (798 / 3073 in geekbench) and latest IntelliJ takes up to 10 seconds to start.
It's not "Java", it's bloat.
At the scale that something like IntelliJ or your favourite C++ based IDE operate at, Java is not the bottleneck. It’s all down to the system complexity involved in doing all that code crunching in near real time and the integration with various back ends and plugins that causes the lag.
I have used many a native IDE in my time and they’ve all been pretty horrid, and to me Intellij is probably the best of them. At this scale of complexity I think the tightly structured and predictable environment provided by Java actual helps performance as it’s easier to maintain and design a cohesive scalable application.
When trying CLion on the exact same projects everything is just so much slower with no major value-add, like, even opening UI menus feels sluggish. And let's not even talk about typing text, I feel like I'm fighting my keyboard whenever I try to use it. (My computer is an Intel 6900k with 64 GB of RAM to give a point of reference)
Really? I thought there was a push for Electron/Chromium everywhere (which seems comparable or worse than desktop Java...)
Personally I push for either native apps or web apps, to regain at least one of the benefits lost by packaging web apps.
Huh? Two Electron apps that I use are Github Desktop and VSC. Neither is sluggish and both have streamlined automatic updates.
Sure, from the user's perspective. But from the provider's perspective, there is a lot of infrastructure needed to reliably and automatically update on various platforms.
Compiling files per-platform, hosting them securely, checking checksums, binary self-replacement, settings migration for many possible settings...
Compare with deploying the server code, migration only for one data set (the one on the server), and then hitting refresh in a web browser.
I had to write an app in JavaFX for a course project. Compared to most desktop apps written using electron, it was fine. But by default it looks like an old desktop app, for which you'd expect some more performance. It maybe still good for enterprise apps where you have some Java programmers.
Also, startup time; It had some noticeable delay.
I tried flutter recently; If you ignore that apps look like mobile apps, flutter desktop apps feel more responsive.
As for paradigm, recent UI-in-code frameworks like flutter seem superior. In JavaFX you can write Widgets in code or in FXML, but java the language or APIs don't fit into that paradigm like Flutter does.
But yes, for the past few years, the experience latency-wise is garbage.
The development of the described scenario strongly devalued java's most advertised advantage, which was portability.
The apps were typically pretty ugly and Windows had a near monopoly at the time. If either of those were not true, it might have fared better.
This paragraph should really be right in the beginning of the post, instead of in the conclusion.
Not to mention Sun's failure with their java based OS and its own eventual collapse.
https://www.wsj.com/articles/SB891383840659892000
Java is still a major language worth learning, but yeah, it never lived up to its hype. When I was young, I remember asking in one of the forums whether I should learn Java or C#, perl or python. The answers were overwhelmingly java and perl. So java and perl were the first two languages I learned on my own. No regrets, but man the internet at the turn of the century/millenia really got that spectacularly wrong.
Works great, easy to debug, tons of open-source components to plug in when we need, sufficiently performant, thoroughly battle tested.
And these are medium update rate apps, not games, but not static forms either.
It's kind of ironic, because most of our apps are now running in an even slower language with "Java" in the name (JavaScript)
I love the pitch found in https://www.inkandswitch.com/local-first/, but it doesn't seem like it's resonated much in the large - so far, at least.
Apparently, he changed his mind around OSX 10.5 and just removed it.
The unusual syntax of Objective-C was always seen as a hinderance to OpenStep/Cocoa adoption, and Java was seen as the solution to that problem.
But Java wasn't a perfect fit for AppKit development, and once developers wrapped their heads around Objective-C most of them stuck with it rather than deal with Java/Cocoa idiosyncrasies. With few developers, the Java/Cocoa bridge died.
The piece did remind me of the poor Java performance at the turn of the century. If you thought it was bad on a Sun or Wintel, you would have really enjoyed the SGI Irix port I tried to make use of at the time. It was even more unoptimized than the common platforms. :D
I remember typing into a Swing? text field and the keystrokes not registering for a second or three, basically unusable. Made me stick with AWT for a chat client/server I'd created for learning purposes, which was not quite so bad. Shortly after that I found Python, which was a breath of fresh air at the time and didn't write another line of Java for about 15 years, never again for Perl.
Ofc the language at the end doesn't really matters, but I am conviced ( mostly because I only embrace MY learning experience ) that using a language like C helps you get into the programming mindset better.
I mean, you don't need to understand what a smart pointer is, but once you seen that the object you have created in your own implementation of a vector got copied over and over, you will think twice every time you write a function with a return statement in every language for the rest of your life.
From a user perspective, no. Every Swing app I've ever used has been ugly, slow and painful. Now, that might be the fault of the developer, but at some point, you have to wonder if either all Swing devs are terrible or Java UIs are just very difficult to get right.
In Java, when you create a new Swing app, the IDE (by default) just creates an empty main() method for you. You're expected to create your own menus and windows. Trying to make the app "native" requires a significant amount of work.
In addition, Java was ahead of its time, with mid-1990's computing power not up to the job of letting it run smoothly on lower and mid-tier PC's. It also required, for that time, an egregious amount of RAM memory.
Also, I really apologize for nitpicking, but "RAM memory" is a tautology.
The downside is that until .NET Core, C# was a closed shop; by Microsoft, for Windows, and everything needs to be licensed. Whereas Java embraced more of the open source and freedom of choice mentality.
I agree that language-wise, C# is definitely ahead. But just a heads up that I think it is also dangerously going towards the fate of C++ (or even already there) where no one person can hold the whole language in their head, and new but not learnt features might introduce problems down the line. For a language, what gets implemented is an important question but perhaps what doesn’t get is even more important, and Java (after the stagnation at the end of Sun) is a slow-mover but when they do, it is usually the best direction/approach. For an example, C# chose (even created afaik) async which is a good feature, but arguably a runtime language could have got away without any new feature and implement it in the runtime alone, a la project loom in java.
.NET is only open source up to the point that Azure related workloads, and iOS/Android development can be done from non-Windows platforms.
Even for basic stuff like visualizing trace files, you still need to reach out to either Visual Studio proper or Perfview.
If Oracle can't make humongous profits from a product they simply drop it or run it into the ground.
Sure, they do make plenty of money from huge corporations still going with paid support for java 8 (I believe it will be supported till 2030 at least?!), like banks. But it ain’t a crime to ask money for proper services.
Nothing special really, it shines only when compared to other mediocre scripting language we use nowadays.
Performance wise it's still on the heavy side.
As a user I hate both Java e C# desktop app.
A native code compiled, statically linked Java or C# desktop app would be the ultimate C++ killer. It would also lessen the need for languages such as Rust.
Java gets a lot of hate but it's a language I really like. The only real issue I had with it is its memory consumption. As a developer, it still has some warts like the absence of actual generics (autoboxing is an ugly hack), but when I compare it with other languages' warts, they are usually uglier. Although my preferred usage of Java is mostly reduced to mathematical or algorithmic stuff, with little to no external libraries, and it certainly doesn't include Spring or any other annotation-heavy framework.
As a user I also definitely prefer Java to Electron and most modern frameworks. Then again I hate most modern design trends...
- Obviously non-native look and feel. For many years Java apps didn't even use the system font. At a time when everything was on Windows and its UI was actually reasonably coherent, Java apps stood out as out of place and clunky.
- Deployment. Each user needed to first install the Java runtime from Sun. This was a deliberate strategy by Sun to get the runtime in place on as many desktops as possible, but it failed colossally. It would have been better to just bundle the whole thing with each app, as Electron does today.
Hmm... no. Even ms software on windows had different appearance and behavior. Actually, being a mostly proprietary ecosystem, apps tried to be different from one another to get attention. An xp machine running winamp, corel draw, ms office, windows messenger and internet explorer had 5 different themed apps at the same time and it was common at the time; it was the rule.
Consistency on windows was always a problem.
These days web is the new cross platform technology. It works everywhere. And mobile is where people focus for native apps. Windows is an afterthought at best. Mac even more. And Linux oddly is now a main source of open source applications that also work on windows and mac. But it's not a big market.
Unless you consider Android a linux distribution. In that case it's absolutely huge. And Java/Kotlin are the languages of choice on that platform. But they are compiled to native ahead of time so don't require a JVM.
Otherwise, Applet support for browsers died a long time ago so that blocked Java from being useful on the web. The JVM as distributed by Oracle (and other openjdk packagers) only really covers the traditional three desktop platforms. And it's not really native there and kind of heavy weight. That limits the appeal. Java is not really that cross platform anymore. Sun failed to anticipate and survive the move to smartphones. Up until then J2ME was a thing. These days almost no phone comes with Java support. That's the real reason Java usage on the desktop declined. It did not cover new platforms from about 2007 onwards.
Despite this there's a new JVM framework on the block: compose desktop. It uses skia (like flutter) and there's a mobile variant supported by Google called jetpack compose. And a web variant called compose web. IOS support is missing. But that looks like it might be addressed at some point.
Are TV apps really relevant anymore? Chromecast and other similar technologies killed TV apps for me for good.
Could it be the release of Gmail (2004) and Google Maps (2005) showing that you could actually make really great apps written in HTML and JavaScript? For me, these two webapps were turning points in how the web was looked at. As I remember it, things didn't really take off until frameworks like AngularJS were released around 2010.
For the mass consumer market, these apps definitely demonstrated what was possible with web-technologies.
Ironically, Google Maps' dataset is curated in no small part by a powerful Java-based desktop app called Atlas, which was presented at Google I/O 2013:
https://youtu.be/FsbLEtS0uls?t=443
Perhaps today it would be created with web based technologies, but at this point, it's so powerful that it's doubtful it will ever be ported. I suspect there are a lot of powerful internal tools like that across many industries.
On the desktop, Microsoft and C++ were already well established. In the browser, Sun did not offer a browser of their own, so Java depended on support from Netscape, Microsoft and eventually Google. Those companies all had their own technologies for browser development tools, and never tried very hard to support Java. Also Java was a little too much for many 90's era PC's connecting to the internet over dial-up connections, so it was slow.
The story I've heard from people who were in the room is slightly different. Jobs acknowledged that Java had its place on the server, but on the client-side: "Java is a big fat pig."
As everyone is used to fat Electron apps now, Java applications (especially compiled and packed with new JDK features) might be refreshing.
Java is not slow, I use a couple of high quality desktop applications and these will most likely have a future as long as the language is developed. These are not slow apps. Bad developers make bad software regardless of language.
One of the main things that I always struggled with was the IDE of java. Buggy, slow and overly complicated. I saddens me profoundly that java lost its "je ne sais quoi"
And so a deal was struck and the world was lumbered with the dumpster-fire that was J2EE, against which Spring Framework was a logical (maybe even sensible at the time) reaction but which ended up becoming it's very own brand of behemothic monster.
Also, fortunately java really doesn’t have to be written in EnterpriseTM way, hell, the language designers actually agree on this one not making properties and the like native, but instead choosing records.
The fact that it doesn't look exactly like the OS is not I think a big problem for users. Applications like Google Chrome, Discord and Electron apps don't look native and nobody complains about it.
https://dawbench.libsyn.com/episode-10-daw-evolution-iii-bit...
In the time I was playing around with applets (largely after the dates mentioned in this article, mind you), I don't think I came across any site using applets that didn't stick with <applet>. Using <object>/<embed> might have been more "correct," but this is also fervently an era where trying to enforce "correct" HTML usage was at best an attempt to whip the tide into submission.
What is this even referring too? Java is everywhere, especially on the desktop. I wouldn't completely contradict and claim "more than ever", but it sure is not on a decline and/or fall. Applets are gone for good, but that's about it.
For various reasons we moved to Java SWT. It was so much worse it's not even funny.
Part of it was the absurdly overengineered architecture we used. We moved from 2-layer PL/SQL + C++ app to 3-layer PL/SQL + J2EE + SWT but on SWT there were like 5 additional layers and most of the code was XML configuration on the UI side. That's not Java fault.
But part of it was just SWT API being so much worse than Qt. Signals and slots make observers and listeners look like ancient technology. The graphical design tools were so much better in Qt. The layouts in SWT sucked. Everything was worse and took more work.
I remember writing a first SWT app (with embedded JRE) ~2004 and it looked nice and worked fast enough.
I think if Sun/Oracle didn't legally ban JRE trimming, added offical Swing browser widget and added a free cross-platform good-looking and developer/user-friendly installer - the story would've been different.
Jokes aside, the only thing I remember about java on desktop is constantly downloading and installing frmeworks. And lags, lots of lags. Terrible lags. And flickering windows.
Sadly, it only does that when the machine is trying to charge.
A generix UI/UX (OS) model is the most complex and difficult type of software that exists. Games are hard, but not in the sane league. There is no Java OS because the language is insufficient, which is to say, it is suitable enoigh for other things, but I wouldnt say its great.
And I despise supporting or troubleshooting Java applications.
Unfortunately that's my life these days.
From an admin perspective, python, php, hell.. Even ruby. All fine. But Java is a nightmare.
FlightRecorder, single jar deployables, the JDK cli utils to get stacktraces and heap dumps etc are good.
No npm getting a zillion files. Just get some jvm, point it at your jar and done.
If you are talking 2001 servlet container and so on, sure terrible, but if you are running those, switch jobs, thats not java's fault.
Curious about what's so hard about Java.
Er, that’s kind of the point of the Java Virtual Machine… It keeps you from tying your application to a particular system architecture.
I’ve noticed that JVM administration tends to fall into the “no man’s land” between devs and admins: Devs figure that the Admins will take care of it, and Admins are annoyed that they need to use a separate set of tools to admin the Java apps (and are not eager to learn them.)
It is working on one server and then broke on a newly built server apparently due to some network settings which devs/ app admins are not aware of.
However... Minecraft, anyone?
As someone who developed a few Java desktop apps and many more Qt + C++ ones, the difference in performance was huge (memory and startup time).
Reletable
I kinda liked developing Java Swing app but I never saw Swing apps as something very common.
On the other hand Java and the JVM "not on the desktop" kinda made it everywhere.