javafx on client side - java

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.

Related

Java applet doesn't run in AdoptOpenJDK

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.

How we can deploy Desktop application to clients, for Java 11?

Previously, this is how we deploy legacy desktop application (https://jstock.org, written in Swing and JavaFX) to clients.
Developed in Swing and JavaFX
Use NetBeans as IDE
Use Java 8
Use Oracle JDK
Use Launch4J to create EXE
Use NSIS to create installer, will help user automatically download JRE from http://javadl.oracle.com/webapps/download/AutoDL?BundleId=216434
Due to the complex licensing requirement introduced by Oracle, we want to move away from Oracle, and go for Amazon Corretto or AdoptOpenJDK or Azul or whatever is free.
We want to take this opportunity to migrate to Java 11. But, we notice that there are no JRE for Java 11.
After some research, we though we might need "Self-Contained Application Packaging" technology, to deploy our Desktop app solution to clients, if we were to use
Developed in Swing and JavaFX
Use NetBeans as IDE
Use Java 11
Use Amazon Corretto or AdoptOpenJDK or whatever is free
The information we came across is https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html#A1307236 . But, it is pretty brief, and we still don't know how we can apply "Self-Contained Application Packaging" for our case?
Do you come across any good tutorial resource, to deploy Java 11 desktop app?

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.

Java applet tag for IE: require java 6, install java 8

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.

Using Java Web Start with JavaFX's Native Bundles

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.

Categories

Resources