Using Java Web Start with JavaFX's Native Bundles - java

I have developed a JavaFX app and I am going to distribute it as a Native Package to avoid headaches with users having a Java version lower than 7 (and thus, without JavaFX) or having no Java at all.
However, I also want to be able to deliver updates of my application. One solution is for the app to call home (its already communicating with the backend via XMLRPC), fetch a JAR and self-update. I can see potential problems with the actual update process though (would need to build a separate updater program, but how do you update the updater?).
I know about and would love to use Java Web Start. However, I have no idea if this will work with the Native Package thing. If the user already has Java installed, it will disregard my bundled JRE. If he has no Java... well, he can't use Java Web Start, right?
How can I solve this problem in an elegant way that will not have a detrimental effect on user experience? (and preferably won't be very long to implement)
note: I am using e(fx)clipse as build tool.

If he has no Java... well, he can't use Java Web Start, right?
True, but as mentioned in the JWS tag Wiki:
Java Rich Internet Applications Deployment Advice. Describes the deployJava.js
script designed to ensure a suitable minimum version of Java is installed before
providing a link to a
JWS app.
or launching an
applet.
Note that JWS also offers fine grained versioning as detailed in Java Web Start - Runtime Versioning.
Saying that, JWS can allow you to support earlier systems by adding the JavaFX 2 API selectively to those earlier systems. That is achieved using a version based resources section in the launch file.
So, JWS combined with deployJava.js would actually be 'the alternative' to the Native Package that page discusses.

Related

How to deploy Java Swing Application on Web Browser?

I've found exactly the same question I just made but it is 7 years old; so I'd like to have an "updated" answer if it is possible. Thanks.
Old days
As commented by TrogDor, there were previously two ways to deploy a Swing app through the web:
Java Applet technologyYour app would appear within a rectangle on the web page, within the browser.
Java Web Start technologyClicking a link on a web page would download a copy of your Swing app to the user’s local machine, where your app would then be launched locally using a locally-installed JVM. So your app runs separate from the web browser. This click-to-download-and-run process is defined by Java Network Launching Protocol (JNLP).
Both of these are being phased out.
➥ For details, see the white paper Java Client Roadmap Update published by Oracle, updated 2020-05-11.
Nowadays
The modern approach is to build a Swing and/or JavaFX app, then deploy by using a packaging tool to include a JVM. You end up with a complete self-contained self-launchable application.
This means you need multiple builds, one app for each platform your users may deploy on (macOS, Linux, BSD, Windows, and so on). While that is an additional burden to you, the flip-side is that you control exactly what version of Java is being used to run your app.
Because of the Java Platform Module System (JSR 376) in Java 9 and later, you can now strip down the bundled JVM and libraries to include only the parts actually used by your particular app.
The build tools for packaging your app have been rapidly evolving in recent years. So be sure to do your research to find the most robust and modern tooling.
Alternatives
You might consider any of these alternatives:
Remote execution
OpenWebStart A re-implementation of Java Web Start
GraalVM Ahead-of-time native-code compilation of your Java app
Vaadin Flow Using Java to build desktop-style apps delivered as web apps
Remote executions
Some vendors may offer a product or service to execute your Swing app remotely while displaying the user-interface within a web browser.
One such company is WEBSWING Ltd. with their Webswing product.
OpenWebStart
You might be interested in a separate implementation of Java Web Start technology.
While Oracle is phasing out Java Web Start, there is an open-source implementation of JSR 56: Java Network Launching Protocol and API called OpenWebStart. See GitHub. This project is currently maintained by the company Karakun, based on the IcedTea-Web core functionality developed at Adoptium (née AdoptOpenJDK).
GraalVM
A cutting-edge alternative is to build an entirely native-code ahead-of-time compiled version of your app using GraalVM.
Vaadin Flow
An entirely different way to build a web app by using Java is the Vaadin Flow framework.
You specify your user-interface layouts with widgets in a manner quite similar to Swing, specifying an arrangement of widgets (buttons, fields, labels, etc.). You can do so using your choice of straight Java code, an XML-based description language, or a visual design tool.
At run-time, Vaadin automatically automatically generates the HTML, CSS, and JavaScript necessary to render your app remotely on the client user’s machine within a web browser. So, you have pure Java on the server-side, and no Java on the client-side, just Web standards technologies built into all modern browsers.
More info
All of this has been covered many times already on Stack Overflow. So search to learn more.
For tips on obtaining a JVM to bundle with your app, see How to get java 11 run-time environment working since there is no more jre 11 for download?.
Nowadays you can run Swing app on server with UI in the browser. You can find example here: https://github.com/JetBrains/projector-demo.
Update: JetBrains ceased development of Projector as a separate product. See their notice. They have incorporated the technology for their own use in their Gateway product for remote execution of their IDE products.

Migrating to Java Web Start - Will Applet-Desc be deprecated?

I'm working on research to move an existing applet (extends Applet) to Java Web Start due to the deprecation in Java 9. However, it seems like most of Oracle's migration docs instruct the dev to use the "applet-desc" tag to create a new JNLP and migrate. Does this mean that launching applets outside of the browser will not be deprecated?
If not, then what is the recommended approach? Saying "rewrite your applet" doesn't help... that's what everyone says. Doesn't really give me the "how".
What are possible solutions and examples/tutorials of migration? I can't seem to find much newer documentation out there, I see a lot of stuff between 2001 and 2011. It seems like most websites that provide examples no longer host the applications, or they aren't properly signed.
EDIT
My most important part of the question is: Is Oracle deprecating the Applet class when deprecating the browser plugin? Or, can we still use classes extending Applet within the tag in a JNLP, without a deprecation warning?
My applet requires user authentication and session cookies that are dynamically generated in our JSP. I've seen online that this is possible. This JWS application is not to be used offline, and is meant to be launched from an HREF. Is this still valid?
The thing that is deprecated is done by the browser manufacturers (though Oracle, realising the situation now advises not to develop them). So Oracle has not 'deprecated' the applet tag(1) in the same way that it has deprecated other classes, methods or attributes as occasionally mentioned in the Java Docs.
As to launching the applet using JWS, yes that should still 'work'. But note that whereas (for example) Chrome used to pass a JNLP direct to the program registered as a consumer of that file type (wherein it would be passed to the Java Web Start Client included in the JRE), it now causes the user to first download the JNLP, then explicitly choose to launch that file.
Update: Oracle may not have deprecated the applet tag, but they'll do effectively the same thing come Java 9. From JDK 9 and the Java Plugin:
By late 2015, many browser vendors have either removed or announced timelines for the removal of standards based plugin support, eliminating the ability to embed Silverlight, Java, Flash and other standards-based plugin technologies.
Oracle plans to deprecate the Java browser plugin in Java Standard Edition Development Kit 9 (JDK 9). Deprecation is a warning for developers to stop using this technology. JRE 9 will continue to provide the Java Plugin and support launching applets on browsers that still offer standard plugin support. This browser plugin will be removed from the Oracle JDK and JRE in a future Java SE release. Developers and users who want to learn more about this planned change can find out more in this blog post.

Implementing a JavaFX application auto update feature

I'm about to write a new cross platform application, and I choosed JavaFX, mainly because of its rich UI libraries (both standard and third party) and it native data binding feature. My application will be deployed via native packaging, both because the lack of PPAPI Java plugin (Chrome will discontinue NPAPI in Chrome 42, which is in beta now) that would prevent an user with Chrome to use WebStart, and because a more "classic" user experience, so WebStart and automatic updates are off the table.
The scenario would be the following:
Application starts and checks for updates
If updates are found, download them and put them in a temporary folder
At application shutdown, write the newly downloaded JAR files over the old ones
Automatically restart the updated application
However, a few question arises in my mind (initially these two, but I could be updating this question as soon as I have more):
Is it safe to do so? Am I risking that somehow the JVM gets crazy if I overwrite some of the JARs already used in the application lifecycle?
I'm struggling to find a way to automatically restart my JavaFX application. Is it even possible?
Thanks everyone for your help.
Take a look at GetDown or UpdateFX. It implements a bootstrap downloader that checks for updates, downloads them and starts your Application as soon it is updated
I've recently created update4j which works with Java 9's module system and meets your requirements.
Perhaps you can try install4j though it's paid. The main feature here that I love the most is the auto update and the way you can configure the installer in an easy way (create Linux - deb,rpm installer, Mac and window installer) and can even package the required jdk version to run your app (this means your users do not need to have that java version installed first before using your app)
Though, it might seem a bit overkill foe your needs

Java Desktop application

This is a single question, but with a couple of sub questions. I am planning a Desktop application using Java and I am using NetBeans as the IDE. Questions:
Why are there so many versions of Java? Java, Java SE, Java EE, Java Me
I want the application to store data locally, what is best Java DB or SQLite?
Do I need anything extra to create a setup file for my clients to install the application?
Is it there a Java solution similar to .Net OneClick to keep the clients updated to the latest version of the application?
I have plan to run the application in Windows, but if I have to ported to Mac or Linux how hard can it be?
There are different java libraries for different purposes. Java ME for instance, is designed for cell phones / mobile devices. You'll probably be fine with java SE, unless you need some of the features from EE.
Depending on how complex your data storage is going to be, you may not even need a "database." In java, any object which implements the "serializable" interface can be written directly to a file. So, if you're just trying to store things such as user settings, etc, you can create an object to store them, implement Serialiazable, and write it to disc.
Only if your application links to code libraries which you don't want packaged in the same directory. You can package it as a self-executing JAR from netbeans, it'll be similar in function to an .exe
(Shrug.)
If you are careful not to use operating system specific paths, a self-executing jar will work immediately on any operating system with the JVM installed. There may be a couple other quirks, but Java is built to be extremely portable.
Because you don't really need everything everywhere. For example you don't really need to use GPRS or SMS from you computer, or ORM from you phone. Each edition is targeted to a specific environment. This way you can have a lighter environment for mobiles, and a lot more components for enterprise applications (which you don't really need of a standard application).
I would advise you to use JavaDB (or Derby) but it really depends on you
Not really, you could offer a nice solution to install your application, but it's not necessary.
There is (I don't remember, but other answers will certainly help)
It's really easy, in particular for unix application, the executable creation will basically be a .sh file launched directly (you could of course have a real executable on UNIX, but it's really common and easyier to maintain to have .sh files) (you could also use .bat file on windows, but let's say that's just less common)
I re-read the question and might have not really answered the last point (I was still on .exe creation) so here is a second shot :
5.It's the main goal of java, to be ported everywhere. As long as your code doesn't use specificity of your system (or it's protected with ifs) your code will work everywhere. Of course you have to use the same java edition (edition, not version) and the same libraries or you could have problems.
Why so many Javas? Java, Java SE, Java EE, Java Me
So many environments. The first two are desktop, EE is server side, ME is phones.
..3. Do I need anything extra to create a setup file for my clients to install the application?
Use Java Web Start.
That also covers 4. & 5.
I have no opinion on which is the 'best' DB, but note that for small amounts of data, JWS provides mechanisms where even sand-boxed apps. can store and retrieve information, alternately the installer-desc element can be included in the launch file to install/set up the DB.

Migrating Delphi App to Java or to Web App

We want to migrate UI rich application from delphi to java or Web Application.
Reason is that we want application to be portable on all Operating Systems.
Current Components and Modules of Application in Delphi :
In Delphi we are utilizing TWebBrowser component to display HTML content
We are playing mp3 that is extracted from FileStream on clicks in HTML.
All resources for HTML are retrieved from Embeded Database Firebird/Ms Access.
To sync some content we are doing HTTP post to PHP scripts to centralize the data on webserver.
Deployment:
- Application has to be deployed on CD and installed on Desktop computer on Mac OS, Linux, Windows.
I need your help how to approach this migration. Is better to go with Java UI or Web App that will be deployed with WAMP/XAMP and appropriate distributions on Linux and Mac's.
EDIT:
I have some specific requirements for audio functionality. Audio files are separate files distributed on CD or USB. Audio files are one solid file compiled from mp3's inside. Application will have to have ability to extract the mp3 based on offset and size of mp3 stored in index file and to play in real time... How this affects idea of Web App using this approach.
Why don't you give FreePascal a try? It uses the same language as Delphi, and can compile to a native application on Windows / Linux / Mac. Since you already have your app in Delphi, converting it shouldn't be too difficult.
Have a look at the freepascal website
If I had to deploy on a CD, I'd probably go with Adobe's AIR. It is really fulfilling the promise Java made 10 years ago in a reasonable way. It isn't perfect, but it does a pretty good job.
I've heard this internet thing is really taking off.
For all of the reasons that applications have gone online over the past 10 years, there really isn't much discussion to be had.
While Java is reliable, distributing and rolling out subsequent updates to those applications is heavy and time consuming.
I did Delphi development for over 9 years. I resisted the idea of distributing real applications over the web for quite some time. Today, I can't believe anyone would choose to continue in this way.
One nice thing, you can probably reuse some of your Delphi logic on the backend if you get creative. (I would only recommend this for the short term)
But, this answer doesn't really address your issue as you are saying that you must distribute it via CD.
The Java 6u10 release allows for distributing Java WebStart applications on media instead of from a Webserver, which might be exactly what you are looking for. You can also put the JRE installer for Windows on the CD too, if needed.
What exactly are your requirements crossplatformwise?
If most of the application is HTML-based, why not make it a full web application, using Ajax and Java?
I recommend NetBeans, and ICEFaces, which is a Java Server Faces implementation with Ajax support, including concurrent updates - if one user edits a record, all other users will see an update in their web page.
It is possible to package the whole application in a single jar file, including the servlet container (Jetty for example), so a simple java -jar myapp.jar will run the application.
NetBeans allows visual editing of the ICEFaces web pages, and even visual editing of the page relationships. The tutorials on NetBeans.org are excellent, and with tools like Maven, Hudson and others, code quality and development process can reach a very high level.
If you have some Delphi application using Datasnap : you can also re use your server made in Delphi with Datasnap in Delphi Prism and make Silverlight application.
And the same is true for DataAbstract

Categories

Resources