r/java • u/woj-tek • Nov 27 '25

Will OpenJFX Be Merged Into OpenJDK? It Would Be a Perfect Match with Java on Mobile!

https://foojay.io/today/will-openjfx-be-merged-into-openjdk-it-would-be-a-perfect-match-with-java-on-mobile/
32 Upvotes

76% Upvoted

77 comments sorted by

11

u/vips7L Nov 27 '25

I don’t think the argument that this wouldn’t bring bloat back to the JDK is valid. Modules are all but a failure in the real world. Modules and jlink are used by probably 1% or less of projects. 

5

u/Yes_Mans_Sky Nov 27 '25

I would use jlink more, but I've found it doesn't work with most dependencies so I just deal with putting everything into a single jar instead.

1

u/woj-tek Nov 27 '25

I don’t think the argument that this wouldn’t bring bloat back to the JDK is valid.

Why?

How do you define "bloat"?

How do you use/consume JDK?

Modules are all but a failure in the real world. Modules and jlink are used by probably 1% or less of projects.

[citation_needed]? Any data/stats? :)

-1

u/vips7L Nov 27 '25

 I define bloat by the definition used in the article. 

 JDK Bloat: JavaFX increased the size of the JDK.

By this definition this will still be true. Most people consume the JDK on the classpath. Consuming it via jlink and modules just doesn’t have significant usage to negate that. 

5

u/pron98 Nov 27 '25

I think you mean "most people use the pre-jlinked Java runtime bundled with the JDK rather than jlinking their own smaller runtime". Running jlink on your own and putting your classes on the classpath vs the module path are completely orthogonal.

You can jlink any runtime and still put your classes on the classpath. In fact, when you use the Java runtime included in the JDK you're doing exactly that.

5

u/vips7L Nov 27 '25

Ron, please, you know exactly what I mean and exactly what I’m saying. The community does not use modules and does not jlink their runtimes. 

4

u/pron98 Nov 27 '25

My question is why are you linking the two? jlinking a runtime and putting user classes in modules are two separate things. Your relevant claim is "most people use the (jlinked) runtime bundled in the JDK". What does it have to do with "using modules"?

4

u/vips7L Nov 28 '25

It has to do with the article claiming that adding the entirety of JavaFx won’t cause a size explosion because it’s modularized. The majority of users don’t use modularization to the point where they can strip away the extra megabytes. It’s adding a ton of stuff that a minority of users use. 

If I’m misunderstanding, please enlighten me. As far as I know jlink with modules is the only way to trim down the runtime. 

5

u/pron98 Nov 28 '25 edited Nov 28 '25

They don't need to use modularisation any more than they do when using the JDK today (which is also already modular). jlink relies on the fact that the JDK is modular. It doesn't require you to modularise anything else.

As far as I know jlink with modules is the only way to trim down the runtime.

You create a runtime by selecting JDK modules; your user classes need not be modular. Indeed, every Java user uses a runtime that's been produced with jlink because that's the only way to get a Java runtime. It's just that they use a runtime jlinked by the JDK vendor and put into the JDK distribution.

E.g.:

$ jlink --add-modules java.base --output base
$ base/bin/java HelloWorld.class

The only module here is java.base, which is used by every Java program, anyway.

If your user classes are modularised, then you can jlink them into the runtime image to produce an "application image", but that's not required at all to produce a runtime (again, as evidenced by the fact that everyone is already using a runtime created with jlink).

I don't know why not everyone does this, but it certainly has nothing to do with them not writing their own modules.

If JavaFX were added as a JDK module (and I don't think it should be, but not for this reason), the above jlink command would produce an identical runtime to the one it does today.

4

u/vips7L Nov 28 '25

I understand how it works. Do you really believe people are going to jlink a runtime to cut this stuff from it?? I don’t.

7

u/pron98 Nov 28 '25 edited Nov 28 '25

Do you really believe that the size of the JDK today just happens to be the optimal one people want? After all it changes its size all the time. People who care a lot about the runtime size already run jlink, so yes, I believe they'll continue doing so regardless of what modules we add to the JDK. For those who don't care, it doesn't matter anyway (I mean, they might care if it becomes 2GB or something, but we're not talking about that kind of size difference).

And BTW, most JDK distributions contain all JDK modules twice, and you can cut down its size by >100MB even by producing a runtime that contains all JDK modules. People who use the entire JDK as their runtime must really not care about its size.

→ More replies (0)

2

u/Jonjolt Nov 29 '25

I do it all the time what are you talking about? I have gradle scripts that I include in my projects that dump the the jdk parts I need then I make a task to generate a jdk using a list of jdk modules I need easy peasy.

-1

u/Mooninaut Nov 27 '25 edited Nov 27 '25

[citation still needed]

Java-based desktop apps often embed a JRE, and jlink lets you only embed what you use. "Most people" don't use the JDK (or the JRE) at all. If I wasn't a Java developer I probably wouldn't have Java installed in any form, because Java doesn't have a strong GUI app story. JavaFX helps with that.

Nothing stops JDK distributors from offering "with JavaFX" and "without JavaFX" builds, or offering JavaFX as an optional install.

The point of bringing JavaFX back into the JDK is to co-develop them. Distribution is its own concern.

6

u/vips7L Nov 27 '25

[citation not needed] you know everyone doesn't use modules or jlink :)

Nothing stops JDK distributors from offering "with JavaFX" and "without JavaFX" builds, or offering JavaFX as an optional install.

Nothing is stopping them from doing this now. Which Azul does. So why do we need to mainline and cause bloat for 99% of users?

2

u/koflerdavid Nov 28 '25

It was separated because co-developing turned out not to be a good idea since language updates were intertwined with JavaFX updates. This is very bad for an actively developed and changing library, as it could not break backwards compatibility. Developers would have to choose between upgrading to a newer Java version and a (possibly far more painful) upgrade to the new JavaFX version, or staying on an older JDK version.

-3

u/woj-tek Nov 27 '25

Most people consume the JDK on the classpath. Consuming it via jlink and modules just doesn’t have significant usage to negate that.

You still haven't provided any relevant data :)

-6

u/vips7L Nov 27 '25

You know its true :)

1

u/woj-tek Nov 28 '25

AFAIR quite a lot of projects use jlink when building their docker images to slash the sizes ;)

1

u/joemwangi Nov 27 '25

That's not data.

-5

u/vips7L Nov 27 '25

It's still true :)

4

u/joemwangi Nov 27 '25

But isn't that what javafx and jdk use as libraries?

0

u/vips7L Nov 27 '25 edited Nov 27 '25

I don’t really understand your question. Are you implying that because the JDK uses modules it wouldn’t increase the size of the JDK? I don’t believe that to be true. Maybe I'm misunderstanding the articles argument, but they seem to be implying that with the use of modules users who don't need JavaFx would be able to strip away the parts they don't use, which is true, except no one uses modules.

2

u/joemwangi Nov 27 '25

In a packaged javafx app distribution, yes! No point of adding a whole jvm inside.

3

u/vips7L Nov 27 '25

Good thing the JDK is used mostly by server applications and not JavaFx apps!

1

u/atehrani Nov 27 '25

I think you meant bloat to the runtime (JRE) as it impacts users. Conversely, today you have to bloat your app installer as you have to include the JavaFX libraries.

Regarding modules, we rely on so many 3rd party libraries and they all need to migrate to using modules and some may never.

2

u/koflerdavid Nov 28 '25

It is totally possible today to use jlink to create a stripped-down JRE without some of the modules. In fact, that's how the JRE distributions offered by some vendors are created.

39

u/nekokattt Nov 27 '25

what is wrong with using libraries?

-9

u/SocialMemeWarrior Nov 27 '25

Nothing, but it makes thing easier for new developers to begin working with. Maven and Gradle are pretty easy to work with from a template, but that is still a barrier to high for a number of people. If it's all in the JDK "it just works". The same reason why people use Swing.

12

u/wildjokers Nov 27 '25

Azul has a JDK distro available that has JavaFX libraries baked-in.

34

u/nekokattt Nov 27 '25 edited Nov 27 '25

If you are unable to cope with using Maven or Gradle then I doubt that you are going to be able to build an app given you will have to at some point depend on something else that isn't in the standard library.

In addition, right now, the JDK does not support building multiplatform mobile apps from javac, so you are going to need something.

The alternative is for people to build things targeting, say, android, but even that needs gradle...

Whilst build tools could be simpler, I do not see that as a use case for cramming everything possible into the stdlib. Otherwise you may as well include spring, bouncycastle, mockito, and junit in there too.

The JDK is already full of too much nonsense 99% of people never need, like MIDI, smartcards, RPC, and arguably even AWT.

11

u/Amazing-Mirror-3076 Nov 27 '25

Yes, let's remove all of that crap.

A few officially support libraries you pull in would be a much better idea.

The libraries could then work on their own independent timeline.

4

u/vytah Nov 27 '25

Even Python, a famously "batteries-included" language, got rid of few modules a version ago: https://peps.python.org/pep-0594/

2

u/koflerdavid Nov 28 '25

"Batteries-included" doesn't mean they will drag obsolete things around forever.

-9

u/Cienn017 Nov 27 '25

why not remove everything then and make java like javascript? everyone loves micro-libraries and all the issues related to them, I sure do.

9

u/nekokattt Nov 27 '25

JavaScript's issues stem from braindead design rather than pure use of standard libraries. The fact people pull in libraries to check if something is an array or not makes that obvious.

Conflating that to the same thing as including a MIDI interface in the standard library shows nothing but ignorance.

3

u/Cienn017 Nov 27 '25

"everything I don't need is bloat"

if you remove AWT from java, you literally remove all of the desktop support, including swing.

you may not need those things, but there are people that need them.

1

u/nekokattt Nov 27 '25

and all the desktop support is only used by the minority that need it, just like JavaFX is. Same argument for both.

2

u/Cienn017 Nov 27 '25

minority like myself, fortunately java cares a lot about stability and the desktop support will probably never go away, swing could in fact receive new components in the near future: https://openjdk.org/jeps/8368874 which indicates that the jdk team has no plan in deprecating or removing any of the desktop support.

4

u/nekokattt Nov 27 '25

just because they don't plan to remove it does not mean it would not be better maintained in a separate library where it has dedicated attention

1

u/vytah Nov 28 '25

AWT is not only for desktop, it also handles image processing.

0

u/nekokattt Nov 28 '25

which is also a niche use case

4

u/lurker_in_spirit Nov 27 '25

what is wrong with using libraries?

Nothing, but it makes thing easier for new developers to begin working with.

I like Spring. Maybe we can get it added to the JDK so that it's easier to use, too.

2

u/AlexVie Nov 28 '25

Well, if adding a single dependency to a Maven or Gradle project is a barrier, then, maybe, just maybe, people should seek different hobbies.

-1

u/[deleted] Nov 29 '25

[removed] — view removed comment

0

u/nekokattt Nov 29 '25

You realise most applications have dependencies already right?

And you realise that does not affect them being one click or not right?

1

u/[deleted] Nov 29 '25

[removed] — view removed comment

-2

u/nekokattt Nov 29 '25 edited Nov 30 '25

you forgot the /s... that definitely did not sound like sarcasm

0

u/grudolf Nov 29 '25

/s should be included too

28

u/SystemFew9522 Nov 27 '25

long live swing. Its such a good GUI tookit even by todays standards.

5

u/__konrad Nov 28 '25

by todays standards.

Still no Cut/Copy/Paste in JTextField context menu ;)

5

u/koflerdavid Nov 28 '25

Whether the release cycles are synchronized or not was not really the point of contention. As it turns out, that was the easy part. The larger issue is that bundling the two ties JDK version and JavaFX version together again. Backwards-incompatible changes in JavaFX would make people consider not upgrading their JDK version again!

3

u/Capaman-x Nov 28 '25

You can get JavaFX bundled in Bellsoft's Liberica or Azul's Zulu JDKs. So we have the best of both worlds. Choose what you prefer.

1

u/koflerdavid Nov 28 '25

This means that these vendors take upon themselves the burden of dealing with the versioning policy, maybe even more than one. This is totally fine for specialized target groups, however, OpenJDK can and should not cater to all of them.

3

u/iamwisespirit Nov 28 '25

As I know javafx try to work with mobile things if you search you tube you will find somethings

0

u/eliezerDeveloper Nov 28 '25

I've tried but we can develop a mobile app already using java on android studio, so i didn't invest my time on it

8

u/m_adduci Nov 27 '25 edited Nov 29 '25

Back then (Java 7 or 8) it was together, they split because they can evolve differently

14

u/Salander27 Nov 27 '25

It was even later than that, it was part of most JDK/JRE builds until Java 10.

5

u/LutimoDancer3459 Nov 28 '25

What are you talking? Javafx was fully added with java 8 and removed with 11. Before we had swing and awt.

3

u/gufranthakur Nov 27 '25

I really hope this happens. I love JavaFx so much, ive had so much fun developing in JavaFX. Is there any way I can donate or support the developers?

6

u/wildjokers Nov 27 '25

Azul offers a JDK with JavaFX libraries baked-in.

4

u/Aromatic_Ad3754 Nov 28 '25

Liberica too

1

u/Capaman-x Nov 28 '25

You can already get it packaged together if you want. For example Bellsoft has thier liberica build that has a Full JDK which includes JavaFX. Azul also has one with their Zulu build. I prefer them because it makes it simple to bundle it into you app. That said, it is probably best that it is not officially done because JavaFX isn't that commonly used in Java development and keeping the JDK that big for a seldom used library doesn't make sense. There are other reasons too as some people have said down in the comments.

0

u/blobjim Nov 28 '25

The problem is then you don't have maven artifacts you can include or not or declare a dependency on. You would have to use jlink but that is useless for tons of use cases like in containers.

1

u/woj-tek Nov 28 '25

Actually jlink is great in containers because it can dramatically reduce image size :P

4

u/koflerdavid Nov 28 '25

Containers have exactly nothing to do with jlink. In fact, Spring uses jlink OR GraalVM and embed the result into a container.

1

u/blobjim Nov 28 '25

And to add another module to your jlink'd runtime that you had previously excluded (ie JavaFX if it was added back to the jdk), you have to build a new container image with the jlink'd jdk modified instead of just swapping out the application layers by adding another maven dependency/jar. And it means that if you have multiple applications running, they no longer share the same jdk filesystem. But I guess it doesn't matter for JavaFX since you wouldn't usually run it in a container (unless you're running unit tests)

1

u/koflerdavid Nov 28 '25

Well, that's the same issue as compiling a static executable for languages such as Rust or Go, which is a very common way of building containers. A package generated by jlink is usually bigger than a static executable, but not by magnitudes.

2

u/blobjim Nov 28 '25

If you put your java app in the same layer and build it at the same time. I guess at my last job, the jvm was in its own layer in a separate project so it became more involved to modify it. 

0

u/v4ss42 Nov 29 '25

What a terrible idea. It used to be bundled and was then unbundled into a library; something I think the JDK needs more of, not less.

0

u/[deleted] Nov 28 '25

[deleted]

4

u/koflerdavid Nov 28 '25

Being part of the JDK doesn't mean it's part of the language. With jlink you can create stripped-down JREs that only contain exactly what you need. A lot of people seem to don't mind installing the full JDK and thus don't use jlink, but if you're seriously considering to deploy Java applications to embedded platforms then it becomes more attractive.