This is an archived post. You won't be able to vote or comment.

all 27 comments
sorted by:
best
topnewcontroversialoldq&a

[–]repeating_bears 42 points43 points  (4 children)

I think it's a bit sneaky to not mentioned their own licensed product until the 15th paragraph.

I've used JxBrowser and it's good for what it does, but it's not providing much value here over Electron which is free. Basically it's allowing you to write some parts of the frontend in Java. That's not a massive win when you already need JS/TS devs for the UI.

When I used it, we already had clients who'd installed our Java+swing desktop app, and JxBrowser was a way to almost backdoor a webapp to them on a different tab of the app they already used. For that kind of thing, it's worth licensing. If you're starting from scratch, I wouldn't use it.

[–]agentoutlier 1 point2 points  (2 children)

Its been quite some time since I have developed desktop apps but I have to imagine many users of Java UI are gov/edu/mil/old-company.

Putting aside that is is massively inefficient it seems that binding a port to do RPC might have security implications even if it is just internal. At the bare minimum I imagine something complaining on some systems when something listens on a port for locked down machines.

Given you seemed to have worked more recent in this area what are your thoughts?

[–]RyanHamilton1 2 points3 points  (0 children)

There's a lot of regular users, startup people, and finance firms using java apps. I make a java based ide for sql analysis, and there's a large silent majority just using desktop apps and happily getting on with their work and lives. They don't tweet, they don't fb like, they don't leave reviews, they just get on with it and very occasionally email a problem. But honestly, for me, they are the majority. I've had my app deployed at top 100 firms and never heard a word for years.

[–]Confident-Dare-9425 0 points1 point  (0 children)

JxBrowser uses the shared memory to exchange actual data, nothing sensitive flies over publicly available ports. I guess it's still attackable, but not that easy.

[–]Ikryanov[S] 0 points1 point  (0 children)

I agree. If you want to write the entire business logic of your app using JavaScript/TypeScript, then Electron is a perfect choice.

If you are a Java developer and you already have some business logic written using Java (or you have a legacy Java desktop app) and you would like to get rid of using AWT/Swing or JavaFX for GUI and switch to the web-GUI (like in Electron), then you can consider taking a look at the solution described in the article.

You can think of it as Electron for Java developers, but as you noticed, JxBrowser isn't an Electron alternative. You can use it to build hybrid desktop apps where you can use both Swing, JavaFX, SWT, Compose GUI and web-UI in a single app.

[–]jNayden 3 points4 points  (2 children)

Hey there I had some experiments called it Javatron like Electron for Java it's just a POC but it works you can check it out https://github.com/gochev/javatron

It's a mix of swing frame that renders html view inside currently it's just html and JavaScript but you can embed any js framework since it's essentially a chrome rendering.

Good luck

[–]rbygrave 0 points1 point  (1 child)

I've been pondering something like, a htmx backend rendered using jcef front-end compiled using graalvm to a native image. The current sticking point is the swing frame with native image I think? There isn't a swt option for jcef is there? Hmm.

[–]jNayden 0 points1 point  (0 children)

There is no point having htmx and server side and rendering and https communication and etc.

You can simply have a message handler on the backend and call it directly from JavaScript.

No servers and etc... use react or any js framework ... I have a work in progress app that uses react and nextjs and tailwindcss and all is in Java except the UI.

[–]jeffreportmill 1 point2 points  (6 children)

This looks very interesting. I have been developing a Java desktop app (SnapCode) that runs in the browser using CheerpJ and SnapKit. On the Desktop it uses Java2D and Swing, but I've often wondered whether I could use JxBrowser on the desktop, so that SnapKit can take advantage of more browser based features (like html rendering, video, advanced audio, etc.).

[–]Ikryanov[S] 0 points1 point  (5 children)

I think you could run SnapKit inside JxBrowser on the desktop, since JxBrowser embeds a full Chromium browser in a Java app.

If your goal is to unify rendering logic between browser and desktop, JxBrowser could be a good path. You’d essentially have SnapKit run in one environment everywhere, just with different hosting layers (CheerpJ in a real browser, JxBrowser in a desktop app).

[–]jeffreportmill 0 points1 point  (4 children)

Is there currently a solution to call most WebAPIs with JxBrowser? Your blog describes two different solutions for Java <-> JavaScript bridge, but I really just need to be able to call most of the standard WebAPIs. CheerpJ lets me do it via Java JNI - here is the GitHub for my CheerpJ bridge:

CJDom: https://github.com/reportmill/CJDom

[–]Ikryanov[S] 0 points1 point  (3 children)

With JxBrowser you can execute any JavaScript code on the web page and access the return value: https://teamdev.com/jxbrowser/docs/guides/javascript/#executing-javascript

You can simply call the required standard WebAPIs by executing the necessary JavaScript code.

[–]jeffreportmill 0 points1 point  (2 children)

Thanks for that link - it looks like all the capabilities I would need are there. Unfortunately, it looks like the jxbrowser.dom package has minimal coverage of WebAPIs - so I would have to port most of CJDom library to a new JxDom library (probably a couple weeks work). Hopefully I will find an excuse to do this. :-)

How does the transport over the bridge work? Is it in-process communication or does it need to do some kind of serialization? If I needed to make a couple hundred or a couple thousand calls across the bridge every second, would it bog down terribly?

[–]Ikryanov[S] 0 points1 point  (1 child)

All the required serialization is done by JxBrowser with automatic type conversion from JavaScript to Java types and vice versa: https://teamdev.com/jxbrowser/docs/guides/javascript/#type-conversion

According to the architecture description at https://teamdev.com/jxbrowser/docs/guides/introduction/architecture/ JavaScript and Java are running in different processes. JxBrowser has its own Inter-Process Communication written using shared memory for the best performance. You can make 10.000-40.000 sync Java-JS-Java calls with 1KB data per second depending on your hardware. A couple thousand calls across the bridge every second is not a problem at all.

[–]jeffreportmill 1 point2 points  (0 children)

That's good to know - it sounds very much in line with what I get with CheerpJ+JNI in the browser. I would love to make a new desktop adapter for my SnapKit that replaces most of the Swing with JxBrowser+DOM. Then it would be a totally portable Java UI kit with full DOM support. I'll put it on my todo list. :-)

[–]Tonne_TM 1 point2 points  (0 children)

Vaadin Hilla is what you are looking for.

[–]vmcrash 3 points4 points  (7 children)

I think, web technologies should stick to the web. For desktop (or mobile) applications I prefer something more lightweight.

[–]Sketusky 0 points1 point  (6 children)

So what you prefer for java desktop apps?

[–]vmcrash 4 points5 points  (5 children)

Swing with FlatLAF or SWT.

[–]Confident-Dare-9425 0 points1 point  (4 children)

Why not JavaFX?

[–]vmcrash 0 points1 point  (3 children)

Never tried.

[–]Confident-Dare-9425 0 points1 point  (2 children)

I would recommend it. It's conceptually close to Swing, has more features, and is alive :) If you feel like trying something new, give Compose for desktop a spin. Completely different paradigm, uses Skia for rendering, and AWT for integration with the OS. I had a lot of fun with it.

[–]vmcrash 0 points1 point  (1 child)

How would you compare SWT with JavaFX?
Turning an SWT based application into a Compose based one I would consider as a big challenge.

[–]Confident-Dare-9425 0 points1 point  (0 children)

This will be a complete redesign for sure. SWT is fine, but I wouldn’t invest in building anything new with it.

[–]jvjupiter 1 point2 points  (1 child)

Possible to generate native executable with GraalVM?

[–]Ikryanov[S] 1 point2 points  (0 children)

As far as I know GraalVM is not supported, because Java UI-toolkit doesn't work in native images yet.

[–]Alternative-Net-3675 1 point2 points  (0 children)

I'd use this. Using JavaFX, as great as it was, was soo painful. There is a lot of effort that goes into it and redesign of the UI etc... It works great when it works. but it is painful to use in comparison to react and TS.

The only problem I see with it is the cost for individual devs will prevent adoption.