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.
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'm using java applet on my site. I want to provide correct applet tags which will work in modern browsers and in old IE versions (8+). As far as I understand, modern browsers use <embed> tag and <object> tag provides best experience for Internet Explorer. Internet Explorer even performs automatically silent Java installation, if user does not have installed Java without browser restart. That's very nice.
Now the problem is, most of the documentation regarding <object> tag is outdated. My applet compiles with Java 1.6 and works fine with it, but obviously I want users to install the latest Java. I can't find official documentation about silent installation for Java 8. If I specify classid="clsid:CAFEEFAC-0016-0000-FFFF-ABCDEFFEDCBA", probably that will install Java 1.6 and that's bad. I've found some urls for downloading .cab files and there are no urls for Java 8. Did Oracle remove that convenient method for Java 8?
What is the best approach to use for embedding Java Applets with modern Java with Internet Explorer?
See the Java Rich Internet Applications Deployment Advice for details of the deployment toolkit script. It should write whatever applet tags are recommended for that user agent.
If I specify classid="clsid:CAFEEFAC-0016-0000-FFFF-ABCDEFFEDCBA", probably that will install Java 1.6..
Not anymore. Oracle has dropped support for loading/using an older JRE. Apparently they have become sick of supporting older JREs with potential security bugs.
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.
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.
Question: embed a portable web browser without cache into a java app? Using Java SE.
Can this be done? Are there any JNI supports for e.g. Chrome or Firefox?
Maybe Qt? QtJambi would allow interfacing with the Webbrowser? From what I understand QtJambi is now maintained by the community and LPGL, is QtWebbrowser embeddable for this purpose in the same licence?
Examining the available documentation and over the past few days this is what has emerged:
The open source browsers are Webkit (which is used for e.g. Safari), and the Mozilla flavoured Firefox. There is also Chromium which is the open source version of the Google flavoured Chrome which uses a lesser javascript engine (squirrel as opposed to v8) and does not have the multi-separate-thread modularisation of Google Chrome.
Additional information on Firefox: Mozilla Firefox is based on an application called xulrunner which uses xml and javascript to provide the additional functionality of firefox (other than the 'not so basic' browser - such things as the html parser, css renderer and javascript parser). Xulrunner is the implementation of the browser.
Firefox implements its own private xulrunner, however additionally there is xulrunner as a standalone install.
Xulrunner can be used to create standalone applications, that are based on a web-browser, and has support for javascript. Xulrunner is also used to create the plugins for firefox providing additional functionality.
In order to connect the front end to something a bit more sustained and powerful than javascript (which has improved in leaps and bounds in recent years), but is still not the strongest sustained engine, there is a C-library called xpcom.
Xulrunner uses xpcom (written in C) to expose the javascript variables and parse the dom, and link javascript variables, and do other 'browsery' things like read headers etc. More on Xulrunner and xpcom in a moment.
If you want a browser that is recent and functional (html 4 or 5, good support for css2 at least, and some css3, and solid rendering of javascript), your best bet other than compiling and embedding one of these open source browsers is to use SWT.
SWT is a gui interface, similar to swing, except that it implements a webbrowser type interface, and can be used to implement a browser. SWT also has some developed interfaces to interact both with the dom and the like. SWT was developed by IBM and is actively maintained.
What SWT does is implement the OS system browser, and has support for every major os. On the upside, this means that there is no need to embed your own browser, on the downside you are stuck with whatever browser / parsers exist on the operating systems, at whichever version. The default behaviour on a windows os for SWT is to use Internet Explorer.
It is also possible to implement non-os linked browsers like firefox by installing xulrunner, but this is an additional 20mb (not extensive but something to note), as the more recent versions of firefox are not recognised.
It is a requirement to have javaxpcom support and xulrunner to implement a firefox style browser in SWT. The easiest way to go about getting the last version supported by Firefox (xulrunner 1.9.) for javaxpcom is to download an application called prism. Prism uses xulrunner as its base to create browsers that are standalone to specific urls. There is a known hacked xulrunner 1.9. which has some issues - see wikipedia for information on this, if you aim to download xulrunner 1.9.* compiled already from source.
Xulrunner is developed alongside each and every new edition of the Firefox browser. Until v 1.9.* (firefox 3.* if I am not mistaken), there was additional support for a function called javaxpcom which was an interface written to link the c library Xpcom's functions to java.
Firefox's initial announcement of how easy and simple it was to embed and style your own flavour of xulrunner, and that it was easy to port to many different languages (support for C, initially support for Java, Python amongst others), but obviously there is some overhead to accessing and adding libraries.
Xulrunner is being promoted as a potential software solution to compete in the same playing field as java, but suffers the same limitations of javascript / html applications. Within those parameters it functions.
Since version 2 of xulrunner, support for javaxpcom has withered, as there is no active maintainer of that code. It is open source solution so presumably interest from someone with requisite skills might pick that up. Xulrunner is now recently in version 6 at the time of writing this answer. Xpcom however is still going strong. Presumably there was insufficient interest / activity in the community, amongst other potential issues.
Since javaxpcom has been reported to have broken, and requires someone to maintain an interest in the code; that work would have to come from someone who has a vested understanding of Xulrunners xpcom, or at least a collaboration from someone who has an understanding of changes made in xpcom. Comments from what I have read suggest that documentation on xulrunner may not be a detailed as it could be, nor on javaxpcom, but I am not in a position to evaluate these comments.
I had hoped that the basic core functionality could simply have been maintained, keeping the hard work involved in recent browser improvements in functionality 'embeddable'. Firefox's amendments have resulted in extensions breaking in newer versions, a function of keeping up with the times.
A non-open source solution that embeds a web-browser and the like is called webrenderer.com. It is maintained, but there is a price tag attached, which is not insignificant.
Another possible route to implement a web-browser in a java application is to go the route of a cross platform development platform called Qt. QtJambi is a LPGL licensed (previously commercial) webbrowser that has extensive documentation and support for Java implementation. There is obviously learning curve attached to using any new platform. Reasons for the move from commercial to LPGL? Presumably viability and commercial demand for java supported browsers has .... waned? A function of the times we live in no doubt.
GWT is the java / webbrowser google solution. GWT works by allowing developers to write java solutions, and then ports and converts this solution into a stable javascript that can be obfuscated. However GWT is not suited to developing a desktop type application, in the sense that it requires a 'server' implementation for the backend. In this sense it is most suited or similar to a PHP or ASP style client / server solution.
Whilst it is not impossible to write GWT as a desktop application, presumably you would have to implement Apache Derby, or Jetty or similar as an in-house server to do all the to-ing and fro-ing. Its not neat, elegant or specifically designed for this, but madder solutions have been tried. There have been php style desktop applications.
For a number of political and financially motivated reasons it appears that support for porting / embedding java and open source browsers is not on the up and up, a trend which began with apple's lack of interest in supporting java applications. Mind you, the browsers are open source and presumably with enough time and energy, javaxpcom etc. could be sustained, but who is going to do this for free, I do not know.
Java promised a java browser implementation but this was not released with the Java 7, and requires like most other things, an amount of work. Perhaps in 8? It is unclear even there if it will be ready by then, I can't quite work out if its currently on the roadmap or not, and doesn't appear to be their highest priority include.
SWT requires some additional libraries and installation to work on various platforms.
Some other open source solutions which do at least in part appear to work, but the maintenance, support and current interest in appears mixed to none, include JRex, MozSwing. Rhino is a javascript engine, flying saucer an html4 renderer.
If you are talking about Java SE based application I would highly recommend swt 'Browser' component. I have used it myself within Eclipse RCP based app and it works like a charm (flash, javascript support)