I had a nice long talk today with the guys from Sandec (sandec.de). They were showing me their product called “Centralized Java (CJ)”. With this solution it is actually possible to run a JavaFX application in a browser (for now it works best with Chrome).
The website javafx-samples.com shows several demos that are using this technology. The demos include the JavaFX SceneBuilder, the game 2048, the JavaFX Ensemble demo suite. It is amazing how much of these applications is supported by CJ. There are still a few gaps but the folks at Sandec are planning to close them soon.
CalendarFX running inside Chrome
CJ hosts the application on the server and serializes the JavaFX scene graph. The graph is then sent to the browser and recreated by JavaScript. So you basically end up with a JavaScript rendering engine for JavaFX. Very cool!
CJ even supports a mode called “MultiView”. With this it is possible to share a session with several people, very similar to (for example) TeamViewer.
CJ is one step more for fulfilling the vision that the same code base can be used for any client.
Edit: I have uploaded a video to YouTube showing CalendarFX running in Chrome.
This could be good. Really good… Depending on performance.
Questions you may be able to answer:
Do they support streams?
Do they support lambdas?
Is a beta (paid or otherwise) available?
This definitely sounds very cool! Thanks for posting! Any info on if Sandec’s CJ will eventually support JavaFX 3D?
Nice. Hope to see more of it. 🙂
Things like this existed in Swing and never took off. I used Echo2 back in the day which had a similar architecture and it just never worked well. I tried the website and its nice to open ensemble like that but even now the inherent problems are visible.
If you lose server connection things start to get flaky, customizing the components in any way becomes a hassle and the underlying JavaScript is unreachable. So effectively you have something that provides no real advantage over desktop programming and brings a lot of baggage into the web…
We actually did a proper JavaScript port of Codename One using TeaVM which is an amazing JavaScript AOT VM for Java that even supports java.lang.Thread! We then implemented CodenameOne entirely on top of Canvas and that allows it to run embedded in the browser without a server e.g. check out our solitaire demo in the demos section of the site.
I don’t think something like this can be done in JavaFX because of the level of complexity inherent in to it. When I worked at Sun we tried to Map the FX scene graph to SVG (so we can work on mobile devices that support SVG) but that was pretty insane and I don’t see that happening.
@Sean the application is running on the server with full Java 8 support, including streams and lambdas.
@Sean please contact the guys directly and ask them for a beta (license).
@John regarding 3D. We talked about it but I am not sure what the status is. Currently AFAIK it does not support 3D.
@Shai maybe a little less promoting your own product 🙂 Just saying…
BTW, sometimes you even get more features than JavaFX. The media player of JavaFX for example will be replaced by the media player of the browser when run with CJ. And the media player of the browser supports more media types than the one of JavaFX 🙂
FYI: due to high demand the server (just one) seems to be a little bit overwhelmed sometimes. 🙂 If that is the case for you then please be patient and maybe try the demos on another day.
I have uploaded a video of CalendarFX running in Chrome. You can see it here: https://youtu.be/IM1vzdICnVs
@Shai
CJ is still in Beta. But, we thought it would be interesting for lots of engineers to see, that the community is working hard and actively coming up with new innovative and surprising solutions. Therefore, we decided to make it public already at this stage.
In fact, your blog about JavaFX made a significant contribution to our decision; to publish CJ now, allthough not yet complete. We wanted to show, that things might look better, than you described in your blog. (Btw, my contribution to your blog 2 days ago was removed for some reason, which I found a bit surprising (?) )
Yes, many of us have made experiences with similar approaches in the past, many of them not working quite according to the expectations. But, as far as I am aware, they were all significantly different to the approach we have now chosen. For instance, to create for Swing what we here did for JavaFX would have had no chance. Our approach here is substantially different from what you referred to using Swing.
And, I need to say, it seems like you make some wrong assumptions, “… underlying JavaScript is unreachable”. You will be able to add your own JavaScript code to it.
“ … map the FX scene graph to SVG … is pretty insane … ”. Well, fact is, we have done this, and the result is pretty successful.
@John
JavaFX3D is not available, yet. Actually, we have not yet decided exactly which route to take. Should we pick a 3D-Library working for SVG, or should we go straight to the more ambitious route, supporting WebGL, with all its great possibilities. Currently, we are evaluating, but no doubt, our current favorite is the latter; because we would then actually be able to create really great 3D apps using JavaFX (with an extended Scene Graph).
@Hans-Henry
Thanks so much for the info! Great work on bringing JavaFX to the browser! For JavaFX 3D, if possible, the WebGL route for supporting JavaFX 3D in the browser is also my favorite as well, even if it takes longer. This would open up a lot of exciting possibilities, I think.
Great Demo! The main goal before releasing CJ should be better performance…
Go go CJ;!!
This is an amazing demo – I hope Sandec posts more information soon, including what others can do to help. One of the things that really shocks me is the launch time of these demos: almost instant, all the way over here in Texas. I think this approach is fine – this approach is already common for demanding tasks, like Webex and Twitch. And much of this work could be leveraged to run these apps 100% on the client when we have something like TeaVM or Doppio running in WebAssembly.
@Jeff
Thank you for the positive comment. We will definitely come with some official infos relatively soon. But, until launching, please ask questions here or/and contact us on email (info@sandec.de) and we will answer as good as we can. We could probably also share some written material with you etc.
For the next couple of weeks, we need to focus on stability, performance and some gaps in functionality. The last days we had a pretty overwhelming amount of users on the page. And, obviously at this stage we had some server downtimes. Those issues have the highest priority for us right now.
As you also state, already today, performance is really good on LANs. And, if you have a “normal” internet-connection, it works pretty well. The first realistic benchmark tests of the server-load also look promising. But, we have some optimizations on the way, which we believe will bring a lot. So, we would like to complete those before launching. And, yes, startup-time of a Java-Application for instance is much faster this way than it is when they start from the desktop.
The obvious feature-gaps we need to fill are such as the WebView (a bit funny that this one is missing 🙂 ), MediaPlayer (not complete, yet), Cut & Paste / Drag & Drop and our “Virtual Disk”, which will enable for persistency on a “Personal, virtually local” disk on our server. 3D will need to come later.
Apart from this, we will share with you some features we have created for “MultiView’ing” of applications (similar to the TeamViewer, but for the app instead of the entire screen).
And, we are working on a standard “App-Container”, which will offer some general standard features, which is then available for any published App (like features for MultiView’ing, Chatting, Zooming/Resizing, Statistics regarding server-usage etc.)
Yes, any JavaFX-application can run as a CJ-App. So, there is no CJ-motivated “correction” to it required if you decide to run it in a different environment later on. There should be no CJ-motivated either-or decision required later.
Why is Shai almog always pessimistic about everything posted here?
Good question! 🙂
Looks really promising!
Btw, For those of you who are interested in a similar solution for Swing, have a look at this open source project webswing. It basically allows you to deploy your Swing application on a webserver and has a very good performance!
http://webswing.org
regards,
Christiaan
@ any JavaFX-application
will this support CDI and event bus like Weld http://weld.cdi-spec.org/ I use this all the time, I use CDI events to update the GUI thread off the main thread, I run into a lot of concurrency issues that CDI events help me work around
@nigel please contact the Sandec guys directly.
@nigel
this is a particularly interesting question when it comes to which environment and scenarios we should support for our server/cloud infrastructure (the structure which hosts the app-instances). Today, we do not use any application server for this purpose, but, we have come up with several arguments for doing so. You here might have come up with another one. Nevertheless, CJ should not hinder you from embedding whatever features Java gives you (even server features) into your app. I am not an expert on Weld, but I cannot see why CJ should hinder you from triggering UI-updates in the javafx application thread, nor using CDI in general. Although with different mechanisms, we have often used similar patterns with no difficulties.
non of the samples work
WebSocket connection to ‘ws://apps.java4browser.com/app/ensemble’ failed: Error during WebSocket handshake: Unexpected response code: 400
@walec51 works fine for me. Please try again, maybe the server was restarted. Also make sure to use Chrome as this is currently the only fully supported browser (this will of course change in the new year).
I’m trying since yesterday, both on Chrome 46.0.2490.86 (64-bit) and FF.
I always get this error.
@walec51
That’s interesting.
Maybe you are behind a proxy, which doesn’t support websockets?
Does this webpage work for you? http://www.websocket.org/echo.html
You could try out another internet-connection or another device.
Please tell us, if you can solve the problem!
Blog doesn’t send out updates so didn’t see those.
@dlemmermann we work in this space and I have a sample that’s relevant. I don’t see that as promoting.
@Hans perhaps I miss phrased. Echo2 also allowed access to the underlying JavaScript. It ended up as a failure because people used it to avoid JavaScript and had a hard time associating the underlying JavaScript and Java layer so basic tricks that you could do in JavaScript became increasingly hard.
The approach today with JavaScript frameworks is “single page” which means the app is local and disconnects/reconnects dynamically. This provides a level of experience that can’t be achieved with a statefull server architecture. I think the TeaVM/DukeScript approach is pretty much the only viable way to get Java back into the browser, but for this size is crucial and FX is just too big.
I mapped FX Script and graphics to SVG when I was at Sun as part of our work to get it into low end mobile devices. The devil is in the details when it comes to these things and FX was engineered in a way that is very “detail sensitive”.
FYI The only case in which we don’t accept blog post comments is if you use a link. If you post without a link it won’t even reach the moderation queue and will be published instantly.
@Shai
Thank you for the useful hints and infos. Our goal is to offer jvm-developers the ability to create one piece of source-code which truly runs “everywhere”, including all “standard” browsers. In addition to that, we offer some optional architectural patterns to choose from. One of them is what we show here, to let the App run centrally. Of course, like with most solutions, there are scenarios in which it’s architecture is not the best one. Environments with unstable or weak net-connections should not go for this architecture, this is surely the case. And, let’s hope, we will see the teaVM/Dukescruipt approach becoming a great alternative for filling this gap. Btw, we might be able to contribute, when it comes to finding a solution to the JavaFX being too large, like you mentioned.
But, there are many other environments in which our tests show excellent results, intranets obviously being the top one. And, with our MultiView feature (which we have not made public, yet), you will have a great tool when it comes to dealing with a group of people interested to easily see the current version of an App – whether it is targeted for a browser, desktop or mobile does not really matter – be it for demo, training or meeting purposes. The scenebuilder is an excellent candidate for such scenenarios.
Whether we will reach a perfect map of javafx to the browsers is something which the nearest time will show. We can only try to convince the viewers to stay on – the solution is still being updated in background almost weekly. And, I guess we all aim for the same – a better and more fun technology to work with!
Looks very cool, but is there still progress in Centralized Java? I can barely find any other resources than the sites you mentioned here…
@MannikJ
thank you for your interest. Yes, there is definitely lots of progress taking place. We currently use CJ in two commercial projects, which are in the phase of implementation. Those we will post about as soon as we have them finalized. We hope, that at the latest from then on, everyone will have to agree, that you can write powerful JavaFX biz-applications which work greatly in plugin-free browsers.
Beautiful ! Very beautiful ! ! ! I just started learning javafx. I like the technology but been very disappointed by the desktop only limitation. I would like to see it available on web browser (no plugin) and mobile. Any timelines when this will be available for production. I would like to create a javafx version of my web app as soon as possible.
Shai I greatly admire the work you have done with code name one. However I think it’s fair to be open to the possibility that some new guy we succeed where you were not able to. Sandec should be commended for their efforts.