Several years ago, I wrote a Java applet that runs in the browser, and runs executables (Exceed XStart files) which are hosted on a network share. The users can manually run the XStart files themselves, but it's a hassle they don't need.
Recently, I installed AdoptOpenJDK on my PC (we were using Oracle's JDK), and now the applet no longer runs in the browser. Some quick googling revealed that AdoptOpenJDK apparently doesn't support java applets.
Oracle JDK isn't an option (company is dropping it). Java Web Start or JNLP won't work (AdoptOpenJDK doesn't support them either looks like). IcedTea looked promising, but doesn't work in IE; which is a must as it's the company standard.
Is there a workaround for this? What's the preferred way of accessing local resources inside a browser?
There is no formal workaround to getting a Java applet to work in a browser, because all major browsers have ripped out the NPAPI support needed to have the Java applet work.
Also, the Java applet itself was particularly singled out to the degree that Oracle decided that it wasn't going to pursue applet functionality in Java 9.
The logical way forward would be to find an old browser to run this with, but I would argue that this is worse, since now you're having to straddle old technology with new and existing infrastructure, which may lead to more frustration.
Related
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'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.
Java 7 is my system default JRE. All of my web browsers are configured to invoke JRE7 on a new instance, as default.
Netbeans fires up Java 8 on a new instance, as its 'isolated' default (isolated in terms as from the rest of the system).
Consider scenario: Chrome is up and running fine, then I'm inspired to code and then open Netbeans. When Netbeans loads, Chrome's java gets funky - I can no longer interact with javascript applets (such as chatango handshakes don't happen, scrollbars become non-responsive, any a host of other anomalies occur). I take the step to reinitialize Chrome, and frames either don't load at all, time out, or stack out of the page's "defined" layout.
Keep in mind, I am NOT (purposely) running any java 8 programs outside of Netbeans.
Why does this occur? My suspicion is that JRE8 replaces the pointers for API calls in the system env.. I would have assumed that the JRE sandbox would have extended to that machine version's libraries, but that seems not to be the case. Is this a fundamental incompatibility, or a bug? Must I suffer it until my choice browser developer releases a Java 8+ compatible browser? Am I the only one that even experiences this?
(I appreciate any feedback that is thoughtful, and not around the lines of LMGTFY or other useless quips)
Thanks!
I have seen something similar happen with Firefox. The reason was a faulty graphics card driver.
Both applications, Firefox and a Java application were using 3D acceleration which resulted in a lot of visual artefacts and crashes later on.
You could try the following:
Disabling any acceleration features in Netbeans (Use sun.java2d.noddraw and sun.java2d.d3d)
Disable acceleration features in Chrome.
Update your graphics card driver
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)
Do the clients need something else than a proper jdk and javafx compliant browser to visit javafx applets?
JavaFX is based on download able JARs. I think there are multiple runtimes, but all of them Require JRE 1.6. The JavaFX classes will be loaded by the WebStart or Applet Classloader, so the JRE does not need to provide this extension.
However as there are some new Features of Java 6 Update 10 specifically targeted for rolling out JavaFX applets, it is most likely that this is the best choice. Update 10 has a new Java Plugin with improvements in speed, installation and stability, and it allows quicker initial installation.
The following JNLP Samples with fine with the released Java 6u10:
http://javafx.com/htdocs/samples.html
http://a.stritzinger.googlepages.com/jfxrace
Ok, thanks for this information. All the samples were "standalone" applications that run "outside" the web browser (a new program was launched, you had to download it and accept some signatures/certs). Is it possible to run the applets inside a browser? (more transparency for my client)
JavFX can be run as an applet and the Java plug-in for running applets was rewritten for Java 6ul10 to provide a better experience for everyone for the JavaFX release.
You can see plenty of applet examples at JavaFX.com as well as the samples in the Netbeans 6.5 JavaFX plugin.