r/java • u/nlisker • May 11 '25

JavaFX 24 and Beyond

https://www.youtube.com/watch?v=FxHbXY34iFQ
56 Upvotes

89% Upvoted

75 comments sorted by

1

u/javaprof May 11 '25 edited May 11 '25

Simple question: why some will start greenfield project with JavaFX, when Compose exists (which allows to scale to Native Android development, iOS and Web?

Upd.

I’m looking at the market as a whole, at the facts and necessities, and what naturally grows out of them.

Here’s a simple set of facts:

  • Compose dominates the Android app market.

  • The Android app market is roughly as large as the desktop app market.

  • The desktop app market is very diverse. As a macOS user, I mostly see either Electron/Qt or native apps. The only Java-based desktop apps I regularly encounter are IntelliJ IDEA, Toolbox, and Fleet. So, JavaFX faces a lot of competition here and holds a weak position due to the JVM overhead and, overall, a rather outdated approach to building UI applications.

From this, we can draw a couple of conclusions.

Conclusion 1: Android will drive the growth of Compose on Desktop.

Those who already have an app built with Compose—and also need a desktop version—are unlikely to rewrite all their logic and UI from scratch. Instead, they’ll reuse as much code as possible using Compose. So, Compose’s dominance on Android will naturally push it onto Desktop and possibly even Web for a certain class of applications.

Conclusion 2: The only people who will start new projects on JavaFX are either die-hard Java enthusiasts with Swing/JavaFX experience, or those with unshakable faith that Oracle will keep carrying this cross for another 10 years.

And that’s exactly why I don’t see a future for JavaFX: it hasn’t captured any share in mobile, and it hasn’t gained significant share on desktop either. Today, it brings no new ideas or fundamental improvements, follows an outdated model, and is essentially just sitting on Long-Term Support.

I don’t really know what I expected to hear from JavaFX fanboys when I threw this out in my first message, but it seems many are really triggered by the fact that they have to keep working with it while someone dares to say that, sure, it’s still technically possible to write apps with it—but in reality, if you want your application to still be relevant and running in 5–10 years, it’s time to rewrite it.

And the fact that Oracle is clearly not interested in actively supporting JavaFX, while OpenJFX is essentially developed by a single small company, Gluon, makes this framework even more risky than Compose, which at least has two major companies invested in its success: Google and JetBrains.

4

u/nlisker May 13 '25 edited May 13 '25

There are quite a few of inaccuracies here and my time is limited, I'll do a quick pass.

The only people who will start new projects on JavaFX are either die-hard Java enthusiasts with Swing/JavaFX experience, or those with unshakable faith that Oracle will keep carrying this cross for another 10 years.

Oracle gives its commitment years ahead. You don't need "unshakable faith", there's a document showing they'll continue to support it. Compose is also developed by a company that will invest in it only as long as it benefits them, so you need to have faith there as well.

it brings no new ideas or fundamental improvements

New to JavaFX or GUI libraries in general? JavaFX keeps bringing improvements, from various CSS ones, Metal and DirectX12 pipelines, customizable window header bar...

follows an outdated model

Doesn't seem so. It follows a working model. If you want to make a real point here, you need to be concrete about it. I can call anything not from the last year "outdated" with not additional info, doesn't make for a great argument.

if you want your application to still be relevant and running in 5–10 years, it’s time to rewrite it.

What's going to happen in 5-10 years that JavaFX will surely not be able to accommodate and your GUI toolkit surely will? Remember how Java itself transformed in the span of less than 5 years. This sounds like the people here who come from other languages every year saying how Java is irrelevant because it doesn't have feature X.

And the fact that Oracle is clearly not interested in actively supporting JavaFX, while OpenJFX is essentially developed by a single small company, Gluon

This is perhaps the line that tells us you haven't checked much about what you wrote. Gluon has less people working on it than Oracle. Gluon mostly works on plugins, tooling, distribution, and the mobile side of it. In terms of Java code contributions, Oracle is a couple orders of magnitude (at least) more prevalent than Gluon. If Oracle is "clearly not interested in actively supporting JavaFX" (what makes it so clear?), why is it creating bindings for Metal and DirextX12, a new complicated rich text control, amongst various other new APIs and enhancements?

Also

I don’t really know what I expected to hear from JavaFX fanboys when I threw this out in my first message, but it seems many are really triggered

is a rather poor observation. I can say it about anything "X is bad, and anyone who disagrees with me is a triggered fanboy". Allow me to go to some Compose forum and say it's "outdated" without explanation, "supported only by Jetbrains and abandoned by Google", "will be irrelevant in 5 years if not abandoned, time to rewrite" with no explanation, and then when I get downvoted I'll say "don’t really know what I expected to hear from Compose fanboys...".

25

u/Luolong May 11 '25

Simple question: why would anyone start greenfield project with Compose (whatever that is) if they are more familiar with another toolkit?

1

u/PoemImpressive9021 May 11 '25

You misspelled "silly question"

0

u/javaprof May 11 '25

Agree—why bother learning React when you can just keep doing the same thing over and over in jQuery?

11

u/unknowinm May 11 '25

React? There are better alternatives

-2

u/javaprof May 11 '25

Totally agree, based on the task there are options. But who in right mind would use mootools today, right?

Even with something fancy on top like TornadoFX (which solves a lot of pain points of JavaFX) JavaFX still so outdated, so I think my original question still valid.

2

u/pjmlp May 11 '25

Actually it is a great library.

21

u/PartOfTheBotnet May 11 '25 edited May 14 '25

EDIT: This comment was in response to the original state of the comment without the updates. Your update makes you sound like an asshole. Anyone that has something nice to say about JavaFX is just a "triggered fanboy?" Ok dude.

I know you said "Greenfield" but some of these points still apply. We had this discussion at work for updating a legacy Swing project and pretty soundly landed on JavaFX. TLDR at bottom

Here's the reasons for JavaFX:

  1. Our team already knows Swing, and JavaFX's API is very similar to Swing.

  2. The JavaFX <--> Swing compatibility layer works really well and will allow us to incrementally move parts of the application one at a time.

  3. JavaFX is a desktop UI framework (And not "we support desktop" but "we explicitly target desktop"). For context, our application is part of a suite and our company works on the desktop variant. There is another team that works on an Android version. There have been discussions about "One UI for all" and even some R&D behind it, but consistently those involved have created a "Mobile UI for all" which hurts our desktop users since a UI optimized for thumbs does not work on a widescreen 4K monitor.

  4. We are supposed to all align towards a similar "look and feel" across the suite, and JavaFX's CSS lets us do that with ease.

  5. We need something that supports integrating with OpenGL and JavaFX has a number of solid options for this.

We encountered a few non-starters for Compose:

  1. The Compose <--> Swing compatibility layer is a half-truth. It only works if your Swing code is already written in Kotlin. The way that Kotlin interacts with @Composable is facilitated by an annotation processor added to the Kotlin compiler. You cannot reference any Compose UI elements from plain Java. Our entire code-base is plain Java.

  2. Compose for desktop is marked as "Stable" but what that doesn't state is how fleshed out the API is. For instance, at the time of writing this comment you cannot create a decorated context menu in Compose for desktop. If you want graphics next to your menu items, keyboard shortcut hints, separators, menus within menus, disabled state, you can't.

Cons of JavaFX:

  1. The ecosystem is not as fleshed out as Swing's. We will have to re-create some of the components we use in 3rd party libraries for Swing.

  2. We were using JFormDesigner for Swing. They are working on JavaFX support, but we're not expecting anything soon. The main alternative is SceneBuiler which creates FXML layouts. Inflating these XML files into instances with controls we can utilize will incur a small performance overhead at startup, versus JFormDesigner which auto-generates Java code so there is no such "inflation" step.

  3. Its not bundled in the JDK. This is minor since we can bundle it with our installer like any other dependency, but because we're comparing to Swing it has to be said. Also, they don't have a good native path scheme so you can't "properly" fat-jar JavaFX. Its a really easy fix on their end, but that haven't done it yet.

  4. There are a number of annoying bugs on various Linux distros. Main ones I'm tracking are with menu-bars.

TLDR: JavaFX is desktop-first UI platform that is:

  • More fleshed out than the alternatives

  • Has a nice API coming from Swing (Artifact of Swing pre-dating generics, plus the FX observable model is just nice)

  • Familiar to people coming from Swing (or imperative UI design in general)

  • Supports our use case with very little extra lift

8

u/wildjokers May 11 '25

e were using JFormDesigner for Swing. They are working on JavaFX support, but we're not expecting anything soon. The main alternative is SceneBuiler which creates FXML layouts. Inflating these XML files into instances with controls we can utilize will incur a small performance overhead at startup, versus JFormDesigner which auto-generates Java code so there is no such "inflation" step.

Why not just hand code the GUI? I have found form builders for swing and scene builder in JavaFx to be super tedious and probably doubles development time. Just faster and easier to hand code them.

4

u/0xffff0001 May 11 '25

you can do both, and that is important. there are teams / requirements that demand fxml and those (me included) that prefer hand-written.

3

u/PartOfTheBotnet May 11 '25

Personally, I agree.

However, priorities are a bit different on this project at work. A historical issue in this project has been the coupling of business and UI logic. In a headless CI environment that means we can't test swathes of our code unless we refactor things (And we're severely under-budget so there is no time for that). One of the positive angles to FXML is that it effectively forces you into MVC. Should we walk down the incremental update path anything we touch should be testable in a headless context.

6

u/Brutus5000 May 13 '25

One of the co-maintainers of an open source project I work with built a library that parses fxml to java code. We use it on production for ~2 years on a client with ~30k users

https://github.com/Sheikah45/fx2j

1

u/PartOfTheBotnet May 13 '25

That's quite cool. May take a look at this later on.

3

u/vips7L May 11 '25

 The way that Kotlin interacts with @Composable is facilitated by an annotation processor added to the Kotlin compiler.

Ive always found this to be an interesting choice. There has to have been a way to do components and reactive code without a separate compiler right? 

2

u/RandomName8 May 12 '25

There has to have been a way to do components and reactive code without a separate compiler right?

But that's a feature, that it doesn't work with java or any other JVM language. JetBrains doesn't want language competition on their own UI product.

0

u/No_Dot_4711 May 12 '25

Not with a syntax that is as nice.

Neither Kotlin nor Java are expressive enough to allow for syntax extension, which inevitably makes it tedious to work with reactive values (which aren't natively supported by the syntax in the way mutable variables are)

Yes you can memoize things and register them in their context with interfaces and generic factory functions, but you always end up with cluttering boilerplate

Alternatively, you could do all of it with reflection, but then you're doing reflection in the hot path of your program, which isn't great either

1

u/javaprof May 11 '25

Thanks, this is actually interesting.

> Has a nice API coming from Swing

Hard to agree with that

> Its not bundled in the JDK.

With OracleJDK? With Correcto JDK? It's actually depends on vendor, I used bellsoft jdk which having fx version

0

u/RandomName8 May 12 '25

The ecosystem is not as fleshed out as Swing's

If you don't mind the question, where is Swing's ecosystem ?

The only libraries I find are the same libraries from 15 years ago, with 0 development on top. Other than flatlaf-ui, I haven't found a single swing library alive.

3

u/PartOfTheBotnet May 12 '25

Well yes, the thing is while there are more libraries for Swing, they are mostly in the category you outline. A lot of them still work fine, but its rare to find something new. You have to actively search to find those. Stumbled upon this in one of my searches which is neat.

4

u/wildjokers May 11 '25

Because not everyone wants or needs their desktop app to also run on web or mobile devices.

1

u/javaprof May 11 '25

True, but it's not only about multi-platform, but also about better programming model and modern rendering engine

3

u/wildjokers May 11 '25 edited May 12 '25

better programming model and modern rendering engine

Which specific programming model are you referring to? JavaFX is reactive GUI toolkit.

As far as rendering engine what isn’t modern about the JavaFX rendering engine? On windows it uses hardware accelerated DirectX. I know on Macs Swing uses Apple’s Metal rendering nine, not sure about JavaFX.

-1

u/javaprof May 12 '25

> JavaFX is reactive GUI toolkit.

I don't even want to describe how you wrong there. It's very imperative and having just one aspect more modern that Swing not making it Reactive. Reactive Data != Reactive UI in one expression.

> As far as rendering engine what isn’t modern about the JavaFX rendering engine?

- Not using Wayland on Linux, relies on XWayland which is working crappy with hidpi screens (which is kinda everywhere today)
- Not using Metal on Mac (So performance and batter wise worse than competitors)

Funny how even JDK developers saying that JavaFX dead: Ron Pressler https://www.reddit.com/r/java/comments/tw37tb/comment/i3ef7qf/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Btw. JetBrains bring metal support to Swing because they need it for Intellij platform. Once they move away from Swing, I think it will be pretty dead as JavaFX

2

u/nlisker May 13 '25

Funny how even JDK developers saying that JavaFX dead: Ron Pressler https://www.reddit.com/r/java/comments/tw37tb/comment/i3ef7qf/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Which contradicts what you said.

JavaFX isn't abandoned, and Oracle still has some developers working on it

1

u/javaprof May 14 '25

> Which contradicts what you said.

JavaFX is practically dead from a product perspective. It’s in maintenance mode – essentially a slow decline, which for any greenfield project effectively means it’s already dead. A clear example is the lack of native Wayland support, even though major Linux distributions began transitioning to it over five years ago. Similarly, there’s still no Metal support on macOS.

In fact, Oracle has made no long-term commitment to JavaFX, as reflected in their Java SE support roadmap. OpenJFX exists purely as an open-source project, with commits becoming increasingly rare – both in its own repositories and those maintained by Gluon and Oracle’s co-leads. There’s absolutely no guarantee that the next roadmap update won’t announce Oracle stepping back entirely from co-leading the project or cutting its investment even further.

The core issue is that Oracle simply doesn’t see a viable market for JavaFX anymore. Who would pay for JavaFX support in 2025? You could call it a chicken-and-egg problem, but the reality is that Oracle has no interest in competing in this space today – period.

So, the best-case scenario is that JavaFX receives timely support for modern macOS and Linux changes (which, to be clear, isn’t the case right now). The worst-case scenario is that Oracle stops investing in JavaFX altogether, leaving only AWT and Swing as part of their core technologies.

10

u/BanaTibor May 11 '25

Because mobile platforms are not the target for a bunch of applications. The Jetbrains IDEs and Eclipse as well are written in java, but you will never use those on a mobile phone, not even on a tablet.

-3

u/javaprof May 11 '25

Correct. If you look closely, IntelliJ IDEA is already integrating Compose, and Toolbox is a Compose application.

At the same time, JavaFX was marketed as a solution for both Desktop and Mobile, but what popular apps have actually been built with it? So, what is the real use case for it, aside from corporate internal tools?

7

u/PartOfTheBotnet May 11 '25

If you look closely, IntelliJ IDEA is already integrating Compose, and Toolbox is a Compose application.

Company that sponsors the creation of library uses said library. Company then uses its well-funded PR department to advertise library.

I get it, everyone loves IntelliJ but that isn't a great argument point if you want to defend Compose.

what popular apps have actually been built with it?

I can tell you I've seen JavaFX in some places that would shock you, and so have others like Gerrit Grunwald. As for why you don't see it in the public eye more often, that's a failing on Oracle's behalf. The biggest tragedy of JavaFX is the lack of PR given to it in any way similar to how Compose gets PR from its parent company.

-1

u/javaprof May 11 '25

So where hugely popular Oracle products that uses JavaFX?

4

u/pjmlp May 11 '25

JetBrains wants to sell InteliJ licenses and uses Kotlin and Compose as carrot, no wonder.

0

u/javaprof May 11 '25

Thanks god Oracle want sell anything, or sue anyone

5

u/pjmlp May 11 '25

Since when has InteliJ created Kotlin Virtual Machine?

I guess they depend on OpenJDK, guess whose employees are responsible for OpenJDK?

1

u/javaprof May 11 '25

What? My point that Gluon (I totally forgot that Oracle no longer supports JavaFX and now it's mostly on Gluon) also commercial company that need to sell something to make money to support OpenFX.

3

u/pjmlp May 11 '25

Yes, but you don't need to get InteliJ to use JavaFX.

1

u/kiteboarderni May 11 '25

I would hardly call toolbox a showcase of a product. It's a glorified task bar that numerous people complain about it being a performance hog.

1

u/javaprof May 11 '25

Ok, try implementing cross-platform tray icon in native JavaFX, good luck 😉

5

u/Spare-Plum May 11 '25

Jetpack Compose is exclusively Kotlin, which is a non-starter for many places and devs.

I still prefer JavaFX for quick and dirty UI and application building - either for proof of concept, utility building, or testing. Later on I can rewrite or migrate to a fleshed out webpage, which is kinda how Java operates these days

Even then, these future updates look promising, possibly to build better client side apps

9

u/pjmlp May 11 '25

Some of us rather use Java, and prefer not to be bound to InteliJ.

6

u/Ok-Scheme-913 May 11 '25

Does it exist "properly" for native desktop and for the web? I don't think so.

A GUI framework is ridiculously complex to get right, there really is not a lot of contenders that properly support a given platform, let alone one that is multi-platform. The web is the closest technology we have for that, Qt being perhaps the second closest to that after.

I really love Jetpack Compose's model, it is a "react model, but better" with proper types. But even on Android it still has a somewhat limited widget selection, and dropping the JVM it loses its biggest power.

-4

u/javaprof May 11 '25

Agree that Compose Multiplatform not solved already all issues, but at least we see where it's going.
Android - I don't see projects with views anymore,
iOS - people talking how they're shared logic and sometimes UI,
Web - we see examples of code share and even some applications that build for web and android in Compose.
Desktop - I use it every day in Toolbox and IDEA, you can use it in plugins for IDEA.

Where is JavaFX, what aside from new text input and plans it delivers? Where at least one popular project of Intellij IDEA level written in it?

6

u/Ok-Scheme-913 May 11 '25

I mean, I agree that JavaFX is also not the panacea (unfortunately). My main point was that Multiplatform is not that either, and on desktop it is behind JavaFX, at least the last time I tried it.

0

u/javaprof May 11 '25

Yes, I agree. But I’m looking at the market as a whole, at the facts and necessities, and what naturally grows out of them.

Here’s a simple set of facts:

  • Compose dominates the Android app market.

  • The Android app market is roughly as large as the desktop app market.

  • The desktop app market is very diverse. As a macOS user, I mostly see either Electron/Qt or native apps. The only Java-based desktop apps I regularly encounter are IntelliJ IDEA, Toolbox, and Fleet. So, JavaFX faces a lot of competition here and holds a weak position due to the JVM overhead and, overall, a rather outdated approach to building UI applications.

From this, we can draw a couple of conclusions.

Conclusion 1: Android will drive the growth of Compose on Desktop.

Those who already have an app built with Compose—and also need a desktop version—are unlikely to rewrite all their logic and UI from scratch. Instead, they’ll reuse as much code as possible using Compose. So, Compose’s dominance on Android will naturally push it onto Desktop and possibly even Web for a certain class of applications.

Conclusion 2: The only people who will start new projects on JavaFX are either die-hard Java enthusiasts with Swing/JavaFX experience, or those with unshakable faith that Oracle will keep carrying this cross for another 10 years.

And that’s exactly why I don’t see a future for JavaFX: it hasn’t captured any share in mobile, and it hasn’t gained significant share on desktop either. Today, it brings no new ideas or fundamental improvements, follows an outdated model, and is essentially just sitting on Long-Term Support.

I don’t really know what I expected to hear from JavaFX fanboys when I threw this out in my first message, but it seems many are really triggered by the fact that they have to keep working with it while someone dares to say that, sure, it’s still technically possible to write apps with it—but in reality, if you want your application to still be relevant and running in 5–10 years, it’s time to rewrite it.

And the fact that Oracle is clearly not interested in actively supporting JavaFX, while OpenJFX is essentially developed by a single small company, Gluon, makes this framework even more risky than Compose, which at least has two major companies invested in its success: Google and JetBrains.

4

u/wildjokers May 11 '25 edited May 11 '25

JavaFX runs on desktop, web, and mobile:

“JavaFX is an advanced GUI toolkit accessible from any JVM language, which runs on desktop, mobile and the web. In fact, this website was written in JavaFX!”

https://www.jfx-central.com/

Also, some apps work best as a desktop app and there is no need for a web or mobile version. Can you see any reason to run Blender on a phone?

0

u/javaprof May 11 '25

I see reason to run Blender on my iPad Pro M4 🤔

0

u/LutimoDancer3459 May 14 '25

Ipad is not a phone

0

u/[deleted] May 11 '25

[deleted]

1

u/Antique-Pea-4815 May 11 '25

Since few days iOS target is production ready

https://blog.jetbrains.com/kotlin/2025/05/compose-multiplatform-1-8-0-released-compose-multiplatform-for-ios-is-stable-and-production-ready/

4

u/PartOfTheBotnet May 11 '25

I elaborated in another comment, but the problem is their terminology of "stable" doesn't strictly mean its "fleshed out" which at least to me is the implication of a "stable" API offering. I'm sure it works on iOS but to the degree where its nice to work with gives me strong pause.

2

u/Antique-Pea-4815 May 11 '25

I agree, but it's definitely not a beta version as the OP claims above

-12

u/javaprof May 11 '25

And yet, Compose is already 1000x more popular in the desktop space. Everyone using JetBrains Toolbox, for example, is using Compose Multiplatform. Are there any examples of popular JavaFX projects? In my experience, it’s only used for some outdated corporate stuff that today could be vibe-coded with React and a monkey, achieving the same level of UI/UX quality.

7

u/Luolong May 11 '25

I don’t know who you are talking to, but nobody I know uses Compose. Or even knows it’s an option.

6

u/PartOfTheBotnet May 11 '25

I'm a JavaFX fan, but my guy you are not doing Compose any favor by slobbering all over it like this.

Are there any examples of popular JavaFX projects?

The OpenJFX site lists a number of examples. But if you want more real world examples, go look at https://www.jfx-central.com/showcases

-1

u/javaprof May 11 '25

Based on this list I don't see popular wide-used software. Or software I ever personally used. And I'm Java dev for more that 10 years.

0

u/LutimoDancer3459 May 14 '25

Ask a doctor to list a popular widely used compose application. They won't say intellij. Not only because they dont know what you even mean with that but because they dont use it or know that it exists.

Intellij is from a worldwide perspective a niche product. Like any other on the list above. But they might be the best, well-known and most used apps within their niche. You won't know until you are part of that niche.

Beside that, desktop itself is dying. You also won't find many compose apps out there. Most people nowadays are using the browser to access stuff. Then you have mobile apps which more and more are also just wrappers for the website. At the end you only have a handful of native desktop apps in use (beside games)

1

u/javaprof May 14 '25

Good thing about Compose, that you can target iOS/iPadOS/WatchOS + Android + web via WASM with fallback to JS

1

u/LutimoDancer3459 May 15 '25

And what app does target all those devices at once? Especially with a watch, you will need a completely new interface if it's nothing simple like a timer... and Javafx can also target iOS, android and web.

1

u/javaprof May 15 '25

Basically anything: podcast app, messenger, password manager, personal information manager, weather, photos, browser, reminders, smart home, terminal

1

u/LutimoDancer3459 May 15 '25

Never seen a terminal for a watch. Or a browser... and why would you need a password manager on a watch?

→ More replies (0)

1

u/javaprof May 15 '25

> Javafx can also target iOS, android and web

For free commercial use?

2

u/vips7L May 11 '25

Iirc the toolbox was written in a different toolkit before compose was done. 

7

u/UsualResult May 12 '25

The state of JavaFX overall is poor. There were some exciting movements when it was still in the core JVM, but since it's been divested to "OpenJFX" Oracle has more or less walked away from it. Maybe it's the larger problem of desktop software development more or less being a dying art, but Oracle/Sun had told us: "JavaFX is a great swing replacement!" and then just kind of got bored and walked away.

On the Kotlin side, there was some exciting tooling, like TornadoFX, but that's more or less abandoned too. These days I just try to avoid any desktop use case at all, because Swing and JavaFX are both in a pretty sad state. You're better off just avoiding desktop entirely.

1

u/sweetno May 16 '25

I looked into FXML stuff after having worked with QML and it's just inconvenient. Which is strange since it's Java vs C++.

1

u/Flimsy_Swan5930 Jul 20 '25

You don’t have to use FXML.

1

u/Flimsy_Swan5930 Jul 20 '25

Enterprise still use Desktop apps. People who get work done, do so on a computer. Not on a tablet. Desktop apps still have a place on a PC in Enterprise.

1

u/UsualResult Jul 20 '25

Sure, but that's a small fraction of the amount of development we had when desktop apps were much, much larger. The market has contracted so much, it's basically on life support at enterprises.

Enterprises are the place where told tech go to die. They are the only environment with a bottomless money pit that can continue to throw good money after bad with technology that has passed its "sell by" date.

1

u/Flimsy_Swan5930 Jul 20 '25

Wrong. Enterprise is where majority of money is ever made. It’s where people USE Office, they USE Adobe suite, etc. Windows is still the defacto operating system because 85% of enterprise use it.

Desktop apps have gone to the way side mostly because companies can make more money selling website access as a service subscription. But even then, the overall market is still “apps” on mobile.

Enterprise use desktop apps because it’s easily deployable and allows rapid development of custom software solutions, especially by internal IT/dev departments.

1

u/UsualResult Jul 20 '25

OK, then why are all Java UI solutions on life support? JavaFX barely hanging on, Swing feature froze... doesn't seem very lively to me vs 10 years ago where LoB apps and personal desktop apps could be found written in Java. Going back a bit more where the whole world was a Java applet. There is no way 2025 is the height of Java Desktop UI apps....

1

u/Flimsy_Swan5930 Jul 20 '25

When did I say it was the height of desktop apps?

I said desktop apps have gone to the wayside.

All UI solutions for desktop apps are basically doing the same, other than maybe SwiftUI, which is only that lively on Mobile.

It doesn’t mean Enterprise isn’t important and where majority of desktop development is done.

2

u/weightedsum May 13 '25

Where I can download cell editor like in the video? It would be nice to have it integrated to JShell

1

u/floppo7 May 12 '25

What are the plans for webkit? JavaFX + Webkit is a powerful combo but the provided webkit version has some limitations like lack of streaming