Good day.In this article I will talk about the “modernization” in the company I work for of such a tool as Java Web Start, or rather, about replacing it with an alternative opensource solution.About myself
My name is Ildar and I work in a German company, which, like many German companies, uses the old technology stack and tries to migrate to a newer stack.Problem
I'll start with a description of the problem. Our company has the most important part of the system, which is a legacy application written in java 6 and partially in java 8. It was launched in java 8. To use this application for production, users download the jnlp file from the site and run it in their home on computers.So the company happily existed for a long time , until Oracle announced that it had stopped supporting version 8 of java, marked Java Web Start technology as deprecated, and decided to cut it out starting with java 11. It meant that there are still more JWS applications, of which there are still many will not receive including security updates. Of course, few can come to terms with this. Also thought enthusiasts from Karakun decided to write their replacement for JWS.In our company, some time ago, they began to rewrite the application using Spring boot for the backend and React for the frontend, but the process is not fast, and there are no updates now.Search for a solution
So the development team faced the question of finding alternative solutions. In general, it is worth recognizing that there is more than one solution to the problem. Initially, architects selected two GetDown solutions and the same OpenWebStart . At the time of the initial decision, the choice fell on the first option, since OpenWebStart was not even released under the first version (there were only some developments and plans).Each of the solutions had its pros and cons, but the company decided not to wait for the release of OpenWebStart and begin to implement proof of concept based on GetDown.After spending a couple of weeks, one of the developers coped with the task and we realized that, in principle, we can implement a complete solution that satisfies our requirements by spending a little more time.In the meantime, other urgent tasks arrived and the development team distracted from the transition from the PoC stage to the full implementation of the Java Web Start replacement.Deadlines
Everyone lived happily until the management realized that it was time to end already and with the replacement of Java Web Start. Until this moment, I was not involved in this project, but here they connected me too.First, I decided to look for information on solutions to our problem again. So let's say get into the solution from scratch. Thus, I discovered the existence of OpenWebStart. I tested it locally, ran into some problems (then we ran into others as well) and solved them. As a result, everyone liked the solution. Needless to say, management especially liked it because it would not have to spend time on development, as is the case with GetDown. But in the end, we spent time getting our system to work with OpenWebStart.Quick Info About OpenWebStart
OpenWebStart is based on another implementation of Java Web Start - IcedTea-Web and the JNLP specification JSR-56 . At the time of writing, the project exists in version 1.1.4 and plans to implement the main features of Java Web Start (progress can be observed here ).I don’t see the point of listing all the possible settings, it can take a very long time.Here are just a few of them:- cache management (size, location ...),
- security settings (allowing users to run an application not signed by certificates, whether or not to show warning popups ...),
- add server addresses to the white list,
- remote debug settings,
- security certificate management
- JRE / JDK version control,
- other
Features of using OpenWebStart and the problems we encountered
Install OpenWebStart
Installing OpenWebStart is quite simple. It is enough to download the installation file for your platform on the website and follow the instructions of the installer.But this is bad luck. In our case, the users are about 10,000 customers, for each of which the support service of our company must install this tool. The solution was found quite quickly: the so-called background installation is available.You need to upload the installation file to each of the computers and run a special command (and for this the company already has a tool):OpenWebStart_windows_Setup.exe -q -varfile response.varfile
, where response.varfile is a file with some settings that can be set in advance by the installer. For example, the folder in which to install OpenWebStart, and some others.Well, we coped with this problem. Further, it would be necessary for all clients to somehow install a specific version of AdoptOpenJDK and link them to OpenWebStart, which is easily done through the user interface, but this is not our case.
We found in the settings that you can specify the URL from which OpenWebStart will take the settings file, in which you can specify the URL to the JRE we need. And the URL itself with the settings file can be specified in the response.varfile mentioned above (that's how complicated it is).The JSON settings file itself with different versions of the JRE is as follows .In the settings, you can also specify the version and vendor of the JRE, in case several JREs are specified in the JSON file. We indicated only one and uploaded the JSON file and archive with the JRE we need on the Amazon S3 bucket.After testing, we found that with the version of JRE that we downloaded, the application does not start ... It turned out that our Java has a slightly different structure in the archive. We whipped up a batch script that rebuilt the structure of the JRE archive.“Well, now everything will work fine,” we thought.When you first start the application, the JRE is automatically loaded, which is used in the future. But, we were waiting for the next surprise.Misfortune never comes alone
But as it usually happens, we were not limited to one problem.Our application has, let's say, one feature. There are actually two of them. One application (one jnlp file) starts a second application (second jnlp). And in this case, the second application did not start. In the logs, you could see that the applications are stuck in the deadlock. From the stealth trace, it became clear that the reason is the OpenWebStart internal logging mechanism.The problem was solved by disabling the internal logging of OpenWebStart. The logs of our applications, of course, remained on.
These settings were also turned off in the response.varfile file, which is used during the background installation.And now, after overcoming these and a few other obstacles (I don’t have to mention everyone), we managed to launch our application, which is currently undergoing testing before being released to the prod. As we tested, the version of OpenWebStart upgraded from 1.1.1 to 1.1.4. Of the notable changes was added the ability to debut remotely.
Perhaps my article will be useful to someone in such a difficult job as support for legacy applications. If you have questions - ask, I will try to answer.PS all images are taken from the official OpenWebStart website .