We Keep Coding

Running a Java Program from a Browser without Plugins

Some weeks ago I wrote a little Java program showing a real time plot chart (i.e. records with tracking of current time), with a modest 25 kbps streaming rate, 20fps framing rate, and no relevant user interaction. Thinking on its eventual deployment as a Mobile App, a Web Server chart or simply as a PC as a program, being Java a perfect selection for me.
Before starting now the Web version of this program, i started to investigate and according the 2016 Oracle White Paper Migrating from Java Applets to Plugin Free Java Technologies:
The deprecated plugin technology will be completely removed from the
Oracle Java Development Kit (JDK) and Java Runtime Environment (JRE) in a
future Java release (TBD). Java Web Start applications do not rely on a
browser plugin and will not be affected by these changes.
And according 2019 OpenWebStart:
Java Web Start (JWS) was deprecated in Java 9, and starting with Java
11, Oracle removed JWS from their JDK distributions
And then I get lost.
Hence, which is the way to go with a Java program like this? Which is the proper sustainable Java way to do this (and not subject to something like what happened to Java Web Start)?.
Or should I simply move to another way to do it, now that the program is in its infancy, considering I am not precisely a fan of Phyton, considering PHP is not precisely the way for programming these kind of numerical things, and considering I am not so willing to give Microsoft technologies a chance?
It is not a problem for me to adapt and rewrite my current code if necessary, but possibly not doing this every 5 years.
Which article would you recommend me to get back to the proper path?
Thanks in advance.

The easiest and highest-performance option is TeaVM, a transpiler that converts Java classes into JavaScript. Your code then runs in the browser natively without any plugin.
Read an introductory article here: https://blogs.oracle.com/javamagazine/java-in-the-browser-with-teavm
TeaVM's main site is here: http://teavm.org/

Thinking on its eventual deployment as a Mobile App, a Web Server
chart or simply as a PC as a program, being Java a perfect selection
for me.
(..)
Hence, which is the way to go with a Java program like this? Which is
the proper sustainable Java way to do this (and not subject to
something like what happened to Java Web Start)?
Two lines of Java
What happened is that our old friend, the Java Standard Edition, split into two lines:
Oracle Java SE ("commercial Java"): needs paid license for commercial use for releases since April 16th, 2019
OpenJDK ("open source Java"): open source (GPLv2 with linking exception), does not contain Oracle's Java Web Start implementation
The Oracle Java SE version keeps Java Web Start and Java FX available and supported only for Java SE 8. Newer Java versions, esp. Java SE 11 do not carry these anymore.
It is not a complete client / desktop technology removal, because Oracle, according to the Java Client Roadmap Update 2018, continues to support AWT and Swing for at least 5 more years on both Java SE 8 and Java SE 11.
You can continue deployment via Java Web Start
Open source Java got a decent implementation of Java Web Start, which is free and available for Java SE 8 and newer Java versions like Java SE 11.
This is Karakun's OpenWebStart based on Red Hat's IcedTea-Web, now beyond version 1.0, which you already found.
Continued support is not guaranteed but seems likely. So you might continue on this track.
Or you might deploy via an app store
Oracle's explanation for dropping Java Web Start was, that they want to change the deployment model to applications with bundled runtime:
As client application development continues to shift from the old
“plugin” world to modern deployment, the need for a standalone Java
Runtime Environment (JRE) that is installed centrally, separately from
Java applications has diminished. Using the ‘jlink’ tool introduced
with JDK 9 will make it even easier for application developers to
package and deploy dedicated runtimes rather than relying on a
pre-installed system JRE.
(Source: Faster and Easier Use and Redistribution of Java SE)
Deployment, according to Oracle, would occur via some app store like the iTunes Store:
No doubt this was true, but the OSes have shifted hard and fast away
from this model. The "app store" model is now it. macOS has been
ratcheting this down hard for several years now. MSFT -- even in the
enterprise market -- has signaled this direction as well. For sure we
need to find options to support the legacy, but the future here is limited.
(Source: OpenJDK discussion mailing list)
Note that Java Start Web Start handled the updating of available new versions of applications on the client machines, and so do typical app stores.
Of course you can serve a version of your app with bundled runtime on your web site, but then you usually have to implement some mechanism to handle updates of your application on the machines of your users yourself.
What to choose?
It is true that the separate JRE installation has disadvantages, e.g. I changed my JRE recently and suddenly the IDE for Java did not work anymore. :-)
Moving deployment from a web site you control to an app store controled by the OS vendor or mighty players like Valve, has its own challenges. E.g. access restrictions, fees, release delays because of the review process, or they might not like your app for some reason and will not publish it.
Then adoption: Personally I have seen private use of app stores mostly on mobile devices and macs, but no use in companies yet. This might be a factor in your decision which road to pursue.

I've missed the Java on browser too. Because of curiosity I just developed an "JVM-Server", which precompiles the Java-Classes to native JavaScript and serves them to a WebBrowser.
Look here is a Hello World example application which is running on Browser:
https://github.com/neo-expert/jsjvm_helloworld
There is also a Library which implements WebGL bindings. In the above Example is a WebGL demo included, where a 3D cube will be rendered. The code is written in pure Java.

Is it a swing app? Will have to map that to a web (html) app to make it work on a browser nowadays.
You cannot run any of those programs from a browser directly.
Java used to java applets and java web start - where the browser helped you install a java app on local system but user had to seperately have installed JRE (Java run time) to run it locally.
Now all we have are web apps. basically apps that might have a a session, login, authenticaiton and authorition but in the end the app outputs HTML, Javascript, images and text data (JSON. XML etc) that is rendered on the web page.
Look at J2EE. I'm a java fan. but it takes longer to develop, but i think it runs better. Especially with a good framework like Spring Boot (it includes MVC see https://dzone.com/articles/7-best-java-frameworks-for-2016)
But learning curve is there. Buy a book or do a course online like udemy or similar.youtube has free videos. but not sure of the order/ quality.
If you choose php - many free and cheap servers like x10hosting to start with and learning curve is less too. Good framework - packages like drupal and wordpress.
On the browser HTML, Javacript run. There are frameworks for this too. Like gogole's angular https://angular.io/ this too needs a book/seperate study. Old days we used to use simple Javascript ...
For mobiles - sometimes can get away with using a URL OR there are frameworks that wrap a web page in an 'app' for android, iphone etc OR make a native app - but then will have different code bases.
I know someone who used a game engine to make a mostly single code base (some classes are specific to each platform like android, iphone) but used to render business graphs and a few interaction use cases (about 40). He used https://libgdx.badlogicgames.com/

As your research already revealed, Java is not a relevant web frontend technology anymore. Prefer Javascript and CSS for browser frontends, instead. Feed the frontend code with data served by Java backend services. The Java Servlet Specification is still the base for server-side Java. Many frameworks (like Spring or Jersey, to name a few) are build on top of it. Either chose one of these frameworks, or - for really simple use-cases - build an application only with plain servlets. Any servlet needs to be deployed in a servlet container (e.g. Apache Tomcat).
Your Java code needs probably some refactoring in order to provide an API for the web. As you are asking for near-realtime communication, you should have a look at the WebSockets standard which is designed for bidirectional and fast client-server-communication on the Internet and supported by all modern browsers (nice intro explaining the difference to WebRTC and arguing why WebSockets are often the better choice). To plot your data in a browser with Javascript and SVG, have a look on the D3.js library. A quick search brings you to demos like this one: D3 Real Time Chart. Also, there are other libraries that are built on top of D3, for example plotly.js.
Summary:
Java is fine for web backend services.
Your code needs refactoring to serve a backend API, preferably WebSockets. (introduction on how to start in Java at https://www.baeldung.com/java-websockets)
Get familiar with a Javascript browser plot library, such as D3.js.

Javafx in webpage? [duplicate]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have done some research on JavaFX over the last year, and even built some basic desktop apps with it.
It's described as being used to create RIAs (Rich Internet Application).
http://en.wikipedia.org/wiki/Javafx
But can it really be deployed by a web browser? I have only deployed it via an executable JAR file.
How easy is it to deploy via web browser? Does it work? Does anyone have experience with this?
http://docs.oracle.com/javafx/2/deployment/deployment_toolkit.htm

Update for the March 2018 Java Client Roadmap
I encourage readers interested in this question to review the following Oracle Whitepaper:
Java Client Roadmap Update
The above paper outlines the official Oracle position on related technologies (JavaFX/Swing/AWT/Applets/WebStart), the dates until which it intends to support those technologies and which of those technologies it intends to transition to open source development projects separate from the JDK and JRE.
Update for Java 9, Oct 2017
According to the Java 9 release notes:
Java Applet and WebStart functionality, including the Applet API, The Java plug-in, the Java Applet Viewer, JNLP and Java Web Start including the javaws tool are all deprecated in JDK 9 and will be removed in a future release.
So, for Java 9+, deployment of JavaFX in a browser using a Java plug-in will only be possible using deprecated technology. Oracle notes in another part of the Java 9 release notes:
Deprecates the Java Plug-in and associated applet technologies in Oracle's JDK 9 builds. While still available in JDK 9, these technologies will be considered for removal from the Oracle JDK and JRE in a future release. Applets and JavaFX applications embedded in a web page require the Java Plug-in to run. Consider rewriting these types of applications as Java Web Start or self-contained applications.
Note: Java Web Start isn't really an alternative as that is also deprecated (anyway, it's different from an application embedded and rendered within a browser page). Also note for those who wish to use Web Start, even though it has now been removed from Oracle JDK 11+, it is available as open source, info on this is at OpenWebStart.
As an alternative which offers similar functionality, consider something like jpro, which deploys JavaFX applications in a browser without a Java plugin (jpro is currently only in closed beta, so it is not a viable solution as of October 2017, but maybe someday in the future...).
For now, I would recommend that the best way to deploy JavaFX applications is as self-contained applications, running outside a browser.
Previous answer for Java 7 and 8
JavaFx - can it really be deployed in a browser?
Yes, JavaFX applications can be deployed so that they run inside a web browser hosted html web page.
The technology which allows this to occur is the Java Plugin. This plugin is currently a NPAPI based browser plugin solution. The Java Plugin is shipped with the Oracle Java 7 Runtime Standard Environment.
Not all browsers are supported, only those listed on the JavaFX Supported Configurations page.
How easy is it to deploy via web browser?
The easiest way to deploy a JavaFX project in a web browser is:
Create a new JavaFX project in NetBeans.
Develop a simple HelloWorld App.
Follow the instructions for Deploying your first JavaFX Application.
This is not difficult (in my opinion).
Alternatively, follow instructions on the detailed reference for Deploying JavaFX Applications (or use 3rd party tools). For many projects, using a tool other than the NetBeans IDE to perform packaging is a better approach. However, it is generally easier to let the NetBeans IDE handle deployment packaging tasks for you.
What follows is not related to answering the original question, but provides some opinions and information requested in comments on this answer.
Some Advice
There are pitfalls to deploying Java in a browser. I encourage you to do your own Google research on the subject.
In my mind, based upon the current JavaFX 2.x deployment model, for most application types that require a browser as the primary runtime container, using JavaFX is not an appropriate solution.
Examine the deployment and runtime requirements for your application. Based on your requirements, and knowledge of the JavaFX browser based execution model, decide if a browser based deployment using JavaFX technology is the correct mechanism for your application.
A couple of potential difficulties for browser embedded JavaFX applications
Some important browsers (e.g. Internet Explorer 10, iOS Safari and soon Desktop Chrome) don't permit execution of plugins using the NPAPI currently used by the Java browser plugin => some of your target users may be unable to use your application.
With a browser embedded application, you don't have complete control over the runtime on which your application executes (browser + Java runtime + plugin interface) => an application which was working when first installed may stop functioning as expected after an update to these runtime components.
Deployment Alternatives
If a browser based deployment model is not appropriate for your application, there are other ways to deploy JavaFX applications (e.g. WebStart, stand-alone jars and self-contained applications).

JavaFX - can it really be deployed in a browser?
No, not any more.
The answer used to be yes, as given in this answer, although even in 2013 when that was written the writing was on the wall. However, here in 2016 the answer is no, it cannot. Modern browsers essentially don't support NPAPI any longer (Firefox does for Java, but only until the end of the year), and NPAPI is required for the Java plugin.

As of 2016 you can use jpro without any browser plugin. And it even runs on mobiles.
Edit 1: The project is free for non-commercial or open source projects. A "hello world" can be found here

I found solution by chance here.
what was missing in my web project.
I must add this to web.xml file :
<mime-mapping>
<extension>jnlp</extension>
<mime-type>application/x-java-jnlp-file</mime-type>
</mime-mapping>

Java single code base for desktop and mobile

Is there one or several java based technology that can help me write an application code base once (including Logic-Views-Controllers) and then compile and run it for
all platforms including main desktop and mobile operating systems as well as
in the browser. It must work and save in offline mode too so that it could sync with remote server as soon as it is connected to the internet. To me, it seems there must be a way if I use some sort of html/css/js technology to handle my views for such an application since I don't need fancy operating system dependent view technologies, and java for Logic and controllers. So far I have found Oracle ADF Mobile which seems to be commercial, eclipse RAP, eclipse scout .... But I look for something that covers Desktop as well. In addition if I can make the application run only in web browser, in case it would run and save in offline mode, it would be fine enough for me.

You could use Eclipse Scout for this with the following setup/limitations:
Since June 2016 Scout only supports web UIs (until 2015 Scout also had support for Swing/SWT, but this is gone now)
You would need to run the Scout frontend model part in a local Tomcat
or similar
You would need to add the sync code for connecting the Scout frontend
model with the Scout backend (that would sync data once a client installation gets online)
Asking for a mobile solution in combination with Java will most likely put you in a messy situation, especially with the discontinuation of RoboVM
Hint: The Scout team has started working on JS offline capability of the Scout UI. However, this is effort is still many months away from production quality (many parts/concepts still missing, not all parts open source, no documentation, etc.)
Addition: You will have the same limitations with Eclipse RAP (needs a frontend server, only web based, hint: styling rap apps is hard).

Looking for the silver bullet... Beware that "not caring about something" (the OS) will make you care a lot about a framework that does the "dirty work".
Leaving opinions aside, in 2016 you will reach your goal quicker with JavaScript, it has become the only thing supported everywhere.
It may be a good deal if you're OK with JS, and living on the bleeding edge with heterogeneous / less mature tooling (see NPM gate).
Java in the browser (applets) is dying soon due to its well documented security issues. One could argue it's been dead for a long time.
If you do want to code in Java only, GWT is still alive. It compiles your Java code into highly efficient JavaScript.
However, ever since Google reduced its involvement by giving away the project to a steering committee, the developments have slowed down drastically, and I'm not even sure they are up to date with JDK 8 yet.
Google still uses GWT in projects like inbox, for what it's worth.

I would go with GWT.
Google also uses this for projects like the inbox webapp, and the inbox android app. Using GWT a lot of code between the two apps can be shared.
It is also possible to compile as a windows desktop application.

How does java run its applets in the browser?

Well, we are long past the days of ActiveX controls running in Internet Explorer so my question is how does java manipulate the browser into displaying the applet on the web page?

how does java manipulate the browser into displaying the applet on the web page?
It doesn't. The user installs an NPAPI (Netscape Plugin API) plugin which tells the browser it can run Java applets. Then, when the browser sees a Java applet, it fires up the plugin.
It's worth noting that Chrome no longer supports the NPAPI on Linux, and they're scheduled to stop supporting it on Windows in September. As far as I know, officially Mozilla calls NPAPI plugins a "legacy" feature and recommends using other options, but is continuing to support them via click-to-play (at least for now)..

Java Applets consists of compiled byte-code, which is executed under
the control of a JVM. Applets may either be untrusted which limits their capabilities or may be trusted which increases their access permissions and allows them to access user data or hardware.
Java applet runs in browser using Java Plug-in technology (hereafter the "Java Plug-in"), which is included in the Java Runtime Environment (JRE), enables Java applets to run in web browsers on the desktop. The Java Plug-in provides powerful capabilities to applets in the web browser. With the Java Plug-in, applets are not run in the JVM inside the browser. Instead, they are executed in a separate process. The same JVM process can be shared between multiple applets, or applets can be placed into different processes depending on whether the existing JVMs match the applet requirements and have enough resources to execute the applet.
A web browser's JavaScript interpreter engine is single thread. The Java Plug-in is capable of managing multiple threads. The Java Plug-in creates a separate worker thread for every applet. Applets themselves may be multi-threaded.
The following figure shows the thread interactions between the JavaScript Interpreter, Java Plug-in, and an applet.
When the JavaScript interpreter is idle, the Java Plug-in executes a JavaScript to Java call on the per applet worker thread (JavaScript Interpreter Not Busy scenario).
When a Java to JavaScript call is in progress and a JavaScript to Java call is made, the latter is executed on the same thread that made the Java to JavaScript call (Round Trip scenario).
When a thread is executing a Java to JavaScript call, another thread wanting to do the same will be blocked till the first thread has received its result and is done (JavaScript Interpreter Busy scenario)
However, Java extension plugin itself is written using NPAPI plugin, the cross-browser API for plugins. Stands for, Netscape Plugin Application Programming Interface. It allowed third-party code in the form of precompiled plugins to be used by the browser to display vendor specific content seamlessly in web pages. Essentially, it lets you call the native binary code from your JavaScript code. But running NPAPI plugin, the code has the full permissions of the current user and has unrestricted access to the local machine. So all in all with NPAPI, security depends on the plugin’s good behaviour and most security considerations
are up to the plugin developer. For example, plugin instances can load
resources from different origins on request of a web page.
Architectural wise, Java needs these privileges to offer the kind of power and control it brings to the table. Java and some versions of Flash and Shockwave still use NPRuntime, and NPAPI needs to be enabled for Java to function correctly in a browser. At the same time many browsers like Chrome consider this (NPAPI plugin) as serious security vulnerability because if the plugin (that uses NPAPI) contains a vulnerability, an attacker might be able to exploit that vulnerability to install malicious software on the user's machine, also sine plugin (java or NPAPI) is exposed directly to web content, making it easier for a malicious web site to manipulate your plugin, which is why it has made it user permission controlled. Another reason why browsers are moving away from this is, NPAPI isn’t supported on mobile devices. Also there are newer problems such as jit spraying http://en.wikipedia.org/wiki/JIT_spraying
Though Chrome has officially stopped NPAPI support, As of Chrome Version 42, an additional configuration step is required to continue using NPAPI plugins. (Could only work till Sept 2015)
In your URL bar, enter:
chrome://flags/#enable-npapi
Click the Enable link for the Enable NPAPI configuration option.
Click the Relaunch button that now appears at the bottom of the configuration page.

How portable is JavaFx 2.0 on the client side of a web application (and is it efficient)?

If I am getting it right from what I am reading, JavaFX 2.0 allows you to code all your logic using Java and design screens with FXML. Then, web apps run as an applet on the client side.
But:
Are all browsers and mobiles devices capable of running applets?
Is it efficient (i.e., nice user experience)?
In other words, how portable are JavaFx 2.0 web applications on the client side? Anyone has experience to share?

From How to run Applets on Android?, it seems like android is not capable of running applets.
So, it seems like JavaFX 2.0 is ok on most browsers, but not for portable devices such as smartphones.

JavaFX produces Java applets. So what I say here applies for Java applets.
Most browsers for desktop machines are Java compatible: IE, Firefox, Chrome, Safari, Opera on Windows, Mac, Linux and Solaris. For smartphones, it seems a lot more complicated. I think it must be a definitive no for iOS, Blackberry and Android. For Windows Phone, it might be possible, but probably too complicated for the mainstream user.
Efficient is a broad idea. It has advantages (performance once started, openess to the rich Java ecosystem) and drawbacks (time to startup, size, all applets running in the same JVM instance). Java 7 improves the experience, as you can read here: http://www.oracle.com/technetwork/articles/java/javaclient-484666.html

JavaFX applications can be packaged in a numerous amount of ways. They can run as applets in a web page, they can be launched through java web start, they can even be distributed as os native applications. So yes, JavaFX is as portable as portable can be. Other people in this thread has already talked about JavaFX applets, which is what governs your question. So I shall not elaborate on that. However, I feel you might have missed the fact that JavaFX clients must not only be distributed as an applet in a browser in order to talk to the back end. Indeed I would not even consider that as an alternative, judging by my own past experience of applets and how ugly they look in the context of a web page.
As an alternative to applets, you can write a JavaFX stand alone application who talks to the back end using a SOAP- or REST based web service. Internet is full of these examples. Moreover, you can have the application be launched through Java Web Start and do dependency injection to get hold of proxy objects to resources on the server. This last part is not talked about by blog posters and Oracle articles. Indeed I haven't found a standardized way of doing that. But if you package a regular Java SE application in a EAR package you can inject resources in this application's Main class and let the thread startup a new JavaFX application and forward those resources. Here is a tutorial I wrote that takes you through the entire process:
http://blog.martinandersson.com/the-enterprise-side-of-javafx-the-missing-part/