We have tricky situation with out Java Web start project where I need restrict it running on IBM JRE. Otherwise it will not connect back to my cloud application. There are various reason we are restricting to IBM JRE, one of them is cryptographic features.
Having said that, I have tried following things.
Added following tag in my jnlp
<j2se version="1.7.0_72+" href="http://9.182.74.244:8080/jreInstaller/download"/>
where /jreinstaller/download URI served by a servlet.
I have followed exactly how it was mentioned by unofficial web start project.
http://lopica.sourceforge.net/services/index.html
With Oracle Java I am getting below behavior. Instead calling my servlet which it is prompting below popup and running whatever available.
This application would like to use a version of Java (1.7.0_71+) that is not installed on your system. We recommend running the application with latest version of Java on your computer.
Am I missing something, how was unofficial web start services were working previously. Something changed with latest Java?
Oracle removed the JRE auto-download feature from Web Start in 2013: openjdk bug 8006701. Web Start now often (but not always) silently ignores the version specification.
Related
I read here that it's possible to deploy a JavaFX application into a Web Browser:
embed-a-javafx-application-in-a-html-webpage
Now I got stuck at the beginning when he talks about using the java packager to create an executable .jar file. I'm using Maven which uses JavaFX 18, so I followed this tutorial on how to package a java project
java-packager-with-jdk11
Here I got confused with the tools he uses. I downloaded the listed tools and moved the jpackager files into the according directories. Still in cmd it gives me an "Error during initialization of boot layer": jdk.packager not found.
It's pretty worth it knowing how to create a Package from a Java Project, but is this the proper way?
tl;dr
No, not realistic.
You have a choice of alternatives.
Legacy technologies
That page uses legacy technologies, Java Web Start and Java applets.
Java applets have been phased out by all web browser makers, so Oracle consequently decided to phase out the technology. Java applets were first deprecated in Java 9, and later deprecated for removal in Java 17.
Oracle no longer expects end-users to have a standalone JRE or JDK installed on their computer. So Java Web Start is no longer available by default for the consumer market. Java Web Start is no longer included in Java 11+.
However, an open-source implementation continues in the OpenWebStart project. For some environments, such as corporations or schools where the installed base of computers is centrally managed, OpenWebStart may be a useful way to distribute apps.
Ship your app with JVM bundled
Oracle now expects desktop apps and mobile apps to bundle a JVM within their product. This does mean the app must be built in editions, one edition for each supported chip architecture and OS, but also allows the app to be tested with the same JVM that will eventually run the app.
For more info, see the Oracle white paper (PDF format), Java Client Roadmap Update of 2020-05.
New tooling is available to support this JVM-within-app packaging:
Java Platform Module System (JPMS) in Java 9+.
jlink in Java 9+.
jpackage in Java 16+.
Search Stack Overflow to learn more about packaging JavaFX/OpenJFX apps for distribution. Many Questions and Answers have already been posted on the topic. The topic is rapidly evolving, including cutting-edge approaches such as using GraalVM for ahead-of-time compilation to run native.
Vaadin Flow
If you want to build a single-page web app written in pure Java without you needing to learn HTTP, HTML, CSS, JavaScript, WebSockets, Push, etc., consider using Vaadin Flow. This open-source framework is based on venerable Jakarta Servlet technology.
You write Java code similar to that in JavaFX, defining forms by specifying widgets arranged with layout managers. Vaadin Flow then auto-generates the needed HTML+CSS+JavaScript to render the user interface remotely in the web browser while maintaining the state of your app on the server. Pure Java on server, no Java on client.
I have built a web application in JDK 8. Now I want to run that application in JDK 11. So is it possible to run a JDK 8 web application in JDK 11?
In my application, I have used servlets and JSP and database connectivity with MySQL.
So is it possible to run a JDK 8 web application in JDK 11?
For a normal application, the answer is simply yes.
For a web application, you don't run the app directly on a JDK or JRE. You actually run it in a web container that runs on the JDK or JRE. For example Tomcat, Jetty, Glassfish and so on. (For a webapp that uses just servlets and JDBC, you don't need a full J2EE container.)
However different webcontainers have different functionality and different ways of doing things that may be an impediment to a specific webapp.
So my advice is to find out what web containers are recommended for the webapp you are trying to run, and use one of those. Choose a version of the container that that is advertised as supporting Java 11.
Application Blocked by Deployment Rule Set
For security, applications must now meet the requirements for the High or Very High security settings, or be part of the Exception Site List, to be allowed to run.
More:
https://java.com/de/download/help/jcp_security.xml
Deployment Rule Set required Java version 1.8.0_60 is not available or incompatible with version 1.8+ requested by the Application.
Questions:
How can I add deployment rule set properly to allow starting JWS properly? Updating version attribute cannot help
I can still start downloaded app from cache. The standard tool to manage locally installed apps looks sporadically. Is there advanced alternatives?
Looking for C#/Java librarian code to manage/start JWS apps from cache
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.
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.