I would like to replace Java Applet which currently needs to use client's resources, i.e. external readers, and to communicate with a server via socket.
Reason:
1. I have thousands of client machines using this Java Applet program, and most of them are running out-dated JRE. When the Java Applet program is updated / added new features, all client machines will need updating the latest JRE.
Expected Solution:
The Java Applet program would be expected to be replaced by a web-based application, which allows to compile and run source code at client's side such that the new web-based application could still use client's resources and communicate with server via socket.
Can I use JavaScript to achieve it?
I would very appreciate your help/suggestion for this problem. Thank you!
JavaScript is a scripting language that gets evaluated in the browser.
I would not describe it as compiling and running but yes, it does mean you can run code in the client and is commonly used to create applications that run in the browser.
There's a staggering amount of frameworks that you can use to write your application. Take a look at the TodoMVC site to see the same TODO app created using several different frameworks.
If you come from Java applets, GWT may be interesting to look at.
If you wish to let the JavaScript client listen for messages from the server, take a look at websockets.
The smart card reader is going to be a problem, though!
See Architectures to access Smart Card from a generic browser? Or: How to bridge the gap from browser to PC/SC stack?
By the way:
The real issue with outdated JREs is not that your code will not run on old JREs, you can create perfectly fine applets using java 1.4 or java 5. Any libraries you may need you can deploy alongside your applet. The pain is a security problem. Anything but the latest version Java plugin is getting actively exploited and puts the user at risk. Occasionally, even the latest version is not safe.
try socket.io
I think this is the latest technology you can use to communicate with client browsers. it support the latest browsers and mobile browsers too.
hope this will help you.
Javascript has become very powerful with HTML 5.0. Here is a list of new elements that you can use to access all kinds of resources, including local files, audio, video, GPU rendering (canvas + WebGL) and GPU compute (WebCL). Here are even more things you can do, including database connections and networking. You can even create offline Javascript applications.
jQuery and jQuery layout make robust GUI development a lot easier. Rich tool suites, such as Google Closure offer optimization and a compiler for improving performance and detecting obvious mistakes early in the development process.
W3 offers useful stats for making an informed decision on how many users on average have access to which features. Note that the most annoying guy in that list arguably is IE8 due to it's lack of proper HTML 5.0 support.
In case you want to stick with Java, then one alternative would be to use my http://bck2brwsr.apidesign.org project. It's goal is to create small Java that can run in 100% of modern browsers without any plugin installed.
There are Java bindings to HTML (via knockout - one of the four most popular frameworks for HTML5) and that is why one can code whole business logic in Java and just render it via HTML. Should be enough to replace most of the applet UI.
In addition to that there is an experimental API to render on HTML canvas. People use it to write Java games that run in a pure browser.
There is a simple way to communicate with server via JSON REST API or via WebSockets. A live example is here.
Related
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.
I am trying to develop an application that can be embedded in the HTML code of a website. I looked into using a Java Applet, but I am turned off of this option from the fact that Applets are decreasing in popularity, and that I am not totally comfortable with Java.
I have experience with Visual Studio C# and VB, and I was wondering if there was some sort of option where I could write an embed-able application using Visual Studio, and if they have some sort of equivalent or similar tool to Applets that I could utilize.
Thank you for your responses.
This depends on whether you want the C# code to run on the client or server side.
Server side you will have to use ASP.NET.
If you want to run on the client side (which it sounds like), this is essentially impossible due to security concerns and technological limitations (a .net clr would need to be invoked and the code passed to it for execution).
You could potentially look into using javascript based activex/com objects to invoke the clr.
Embedding C# code was possible in earlier versions of Internet Explorer, but no longer.
I'm making a database for my project (wirtual clinic) which will be a web application, but here is a thing.. I want in order that my app will based on a JavaFX (MVC pattern, where in View segment I could use .fxml files edited in SceneBuilder) is this solution possible?
If you need a web application running in a browser with a backend in a container, then you cannot use JavaFX. But you might try Vaadin. There you can use either Java code or HTML to build your application. They also sell a designer application.
The http://javafx-samples.com/ mentioned in the other answer shows a JavaFX application running as a server process and mirrored thru the network using JavaScript. This is technically admirable and might work reasonably well for your use case but you should keep that in mind when comparing it to client side JavaScript solutions.
It will not work well for flaky internet connections and extending it will have limits since it would require both Java server side code and JavaScript side code.
Such architectures have been used extensively in the past (e.g. Echo2, AjaxSwing etc.) and they all never gained serious traction even when compared to similar architectures such as GWT.
There are now several client side JavaScript based VM's including TeaVM which are pretty amazing and can produce pretty good results entirely on the client e.g. we used this VM in a recent demo.
Of course it is possible, but with the plugin and updates problems.
Some solutions are in progress. You can check this site:
http://javafx-samples.com/
It is promising I think because you don't need plugin.
We're writing a platform for building apps that are able to run on any browser and we were thinking, is there a way to do this with Python? Or should we better go with Java and Java Applets?
I was also wondering, how hard is it to write a custom browser plugin? How long would it take e.g. in man-hours?
Thank you!
The universal API for browser addons is javascript. It is well supported in Firefox, Chromium/Chrome, and Opera at least; it is the only extension API available on the last two. Intersting API subsets are firefox's Fuel, Chromium's trimmed down extension api, and the very portable GreaseMonkey functions.
A second runtime would have its own startup costs, garbage heap, and ffi overhead. It would require special privileges, and would still have to translate its API calls into javascript. That would make it fairly unattractive.
Edit: you were asking about web content with possible plugin or addon support? You also have the option of the NPAPI (also the Pepper project around it). This api is C-level and can render to a rectangular area on its own (using OS APIs), at the cost of very little support from the browser and being a portability nightmare.
There are many RIA frameworks popping up (flex, extjs, gwt to name very few).
If my server is written in Java, why not use java web start?
The benefits I see: I get to program in a language that is easy to debug (compared to javascript), I can use the same code in server and client side (validations, model objects). With SWT I get nice looking GUI.
Even if it means requiring a plugin in the browser (or using a cli tool), if my application is an enterprise application, does it matter?
For webstart you need Java installed on the client. For Flex Flash. For Silverlight .Net. For other RIA platforms a JavaScript enabled browser. It is a lot of product politic in that question.
And Java is very intenting, because "all seems to be a nail". Of course one of the great advantages of Java: same language, same knowledge, same code on every platform or environment (server/client/middleware).
For enterprise internal use, no it does'nt matter at all. If your biz is on the internet the decison is much more complicated (or even you have to offer the same functionality in diferent platforms).
The only contra argument is that in a lot of cases it's impossible to force the clients of your rich client app to have Java runtime installed on their machines. Everything else is a matter of taste, already existing knowledge and experience.
I think that until now the perfect client technology simply does not exist. We were excited about ajax and then there is another "hot" technology like Adobe Air. What is the difference between these techs and the "old-fashion" client-server apps? My friends we are back to the early 90s!
The AIR for example needs a runtime installed on the client machine, it has access to local system resources and communicates with the server using a binary protocol. On the other hand we are developing "RIA" applications (and very good ones :) using pure java swing clients communicating with the server through the Spring's binary remoting protocol. And i must say, in such a development life-cycle Java-Webstart is the winner. Especially in large-scale projects (and i mean laaaarge-scale, not just e-shops) in the java field i haven't found something more productive and maintainable (ah! maintainence... another big story) than this.
IMO if your users can live with a nice look-and-feel and you don't have to adopt another technology just because it is young and sexy use webstart. Put more work in your business model. After all enterprise apps is about business, not animations. And money is where the business is ;)
Yes I think it does matter, seeing that some big companies still have IE6 as their standard browser and as a requirement for web based applications. And those won't allow you to install any third party plugins into their dinosaur browser.
And you don't make a difference between RIA technologies that use existing browser technologies like JavaScript, CSS and HTML (including GWT which just generates client side JavaScript and ExtJS which is just a JavaScript Component library) and the ones that require an additional runtime environment (Flash, Flex or client side ).
Of course some things are easier to accomplish with proprietary or third party solutions (or you just have more knowledge in one of these platforms), but I still think that there is a huge potential in technologies that are standardized and already implemented in every modern browser (the differences between the browsers are slowly but steadily getting better, too).
If you ship it as a 3rd party application you can define a JRE as a System requirement, anyway but then instead of JavaWeb Start ship it as a normal Java Application as well.