We Keep Coding

How do I upgrade to jlink (JDK 9+) from Java Web Start (JDK 8) for an auto-updating application?

Java 8 and prior versions have Java Web Start, which auto-updates the application when we change it. Oracle has recommended that users migrate to jlink, as that is the new Oracle technology. So far, this sounds good. This comes with a host of benefits:
Native code on Windows, Mac and Linux
Modularization of the code (although Proguard does this as well)
The use of new, supported technology.
The problem: I can't find the canonical Java solution to auto-update with jlink.
One would think that Java Web Start could continue to be used, especially if one casually reads this document. Notice the fact that Java Web Start continues to be prominently listed. But there's a fly in the ointment: Oracle is deprecating Java Web Start. It's slated for removal in JDK 11. So, what's the official path forward. Failing that, is there a standard way that people proceed?
For the purposes of this question the following are out of scope:
Paying huge amounts of money yearly to someone with an feature-packed enterprise solution. The application to be distributed is already packaged into a single jar that is smaller than 50MB.
Forcing users to run an InstallShield style app to reinstall the new version, and then manually uninstall the old version every time an update is pushed. That's sooo 1990's.
Porting the entire app to be a webapp, rewriting the UI and client side logic to fit in a browser and dealing with all the incompatibilities that entails. The authors of the application worked on GWT and know exactly what web browsers are capable of. Unfortunately, they also know the level of effort required.
Allowing users to continue to run old versions of the application. That, too, is sooo 1980's. Modern apps update quickly, and supporting every version of the application ever released is not tenable. That's what my father's COBOL application had to deal with, and he didn't enjoy it. I'm hoping technology has progressed.
Continuing to use Java Web Start. Until/unless Oracle changes its mind, Java Web Start is a doomed technology.

In May 2019 commented to watch the OpenWebStart project.
Now (October 2019) it is time to give OpenWebStart serious consideration. While not yet feature complete, a alpha beta release of OpenWebStart is now available for download under a "GPL with Classpath exception" license.
The OpenWebStart Technical Details page states:
OpenWebStart is based on Iced-Tea-Web and the JNLP-specification defined in JSR-56. It will implement the most commonly used features of Java Web Start and it will be able to handle any typical JWS-based application. We plan to support all future versions of Java, starting with Java 11. In addition to Java 11, the first release of OpenWebStart will also support Java 8.
The page goes on to state that OpenWebStart will support interactive installers with auto-update, and non-interactive installers. Some JNLP features will be supported, and it will include a replacement for the Java Control Panel. A more comprehensive list of planned features1 and their implementation status is provided in the feature table.
1 - If you have a requirement that is not on their feature list (e.g. jlink support), you could contact the OpenWebStart team, and offer a suitable incentive (e.g. money to pay developers) to implement the feature for you. They also offer commercial versions of the software for paying customers.
Disclaimer: I have no connection with the OpenWebStart project, the company (Karakun) or the project sponsors. This is not a recommendation.

I had a similar problem in a past project. We needed to migrate from Webstart to another technology.
The first approach was to install IcedTea. It is directly bundled with the AdoptOpenJDK Project.
But as far as I understood the problem, Java wasn't meant to be installed on the Client side like this anymore and we didn't want problems with all of our customers.
Our solution was then building an own specific Executable, which connects to the server, ask for enviroment settings from the server side, and then download and extracts the JLink Java. So we could use the old technologies and just wrapped it in an Executable.
Last thing done then was redirecting to the download location of the Executable when calling the jnlp-URL.

Do you use maven?
I've resolved my similar problem with maven (I need to update an EAR).
My main app (the ear package) has a pom.xml with listed the dependencies and repositories.
The dependencies have the <version> tag with a range (documentation) as in this example
<version>[1.0.0,)</version>
That means : get version 1.0.0 or newer of the dependency. (You can put also an upper bound to the version, [1.0.0, 2.0.0) so if you develope a new version, it is not used in old app)
In the repository section I added my personal repository.
Now, in the remote machine I need only to rebuild my ear package with maven : the compiler download the newer version of my jar and put it together.
You need a system to check if there are newer dependencies version and warn the user to update the app and also lock its work (you can't work if you don't update). Maybe you need a little app to make users do the rebuild process easily. It's 1990's but a lot of desktop-app works in this way
PRO
This schema can be used in a lot of different projects.
CONTRO
You need to build the app in the remote machine, so the client must have a JDK and access to your repository (like artifactory);
You must write code in different jars and add them like dependencies in the main archive.
You must change JAR version each time and publish on the repository (this could be a good practice)

What stability guarantees are given for WildFly configuration?

An important part of the JavaEE platform is backwards compatibility, but I'm curious what that entails for configurations. I'm especially interested in the standalone.xml configuration for WildFly; can I expect the options in it to be stable across versions of WildFly? Or maybe just parts of it?

The WildFly team tries to keep the configuration compatible or offer a migration tooling (for example when moving from jboss-web to undertow). If you're concerned about long term stability then maybe you should use Red Hat JBoss EAP which is a productized version of WildFly.

I think so, but you need to be up to date on each version, with the new releases. The standalone.xml file is updated with a lower frequency than the own server implementations, its base is practically the same since our old JBOSS. I've been using wildfly since its early versions and never had backward compatibilite issues.
What I see happening a lot is that most of the developers do not know the dependencies that the server implements and end up having problems in deploy, jar hell and problems in rutime due to lack of knowledge of the dependencies.
In my opinion widfly is the best server full JavaEE, but there are things I think are bad, one of them is the use of CXF in webservices. Do not worry about standalone.xml, I have not seen to add any feature to cause compatibility issues.

Applying security updates to dependencies installed with Maven

We have a web application that is implemented in Java. It uses Maven to install various dependencies such as JavaMail, Gson, and so on.
Unfortunately, deploying and maintaining the project is a nuisance. We need to be aware that any of those dependencies might issue a security update, which means checking regularly for new versions. To make matters worse, we can't see any way that Maven can distinguish security fixes from other new releases. This means that we end up doing needless updates, which is a waste of time and could break something.
The server itself runs Ubuntu, and the situation there is far better. Apt installs urgent updates, but everything else waits until the next Ubuntu release. That's ideal because it gives us a stable but secure platform that we can build on.
Is there any way of making Maven more like Apt, so we can install security fixes but nothing else? If not, I'd be interested to know what strategies other people use for updating deployed web applications.
(We know about the maven-dependency-plugin. This plugin helps, because it can automatically find and update any dependencies which have newer versions. Unfortunately it can't distinguish security updates from normal feature releases, so we end up updating when we don't strictly need to.)

I did come up with a partial solution to this problem, but it doesn't use Maven directly. I implemented a script which scans the NVD database for new security exposures relating to products we are using. Every morning I get any new ones emailed to me, and I can decide whether they justify an update to our web application.
The downside of this approach is that smaller projects don't always issue CVE numbers for their vulnerabilities. We have to restrict ourselves to products that have a significant following, are backed by a large vendor, or have previously demonstrated a willingness to take part in the CVE process.

Your security settings have blocked an application from running with an out-of-date or expired version of Java

Greetings .
I've encountered a Java Error ,which is actually giving me a nightmare .
It says :
" Application Blocked by Security Settings "
" Your security settings have blocked an application from running with an out-of-date or expired version of Java "
Java Version : 1.7_25 ( Recommended for my work and not an old one i believe)
Workaround i have performed (which did not work) :
Lowered Security Level to Medium.
Cleared Browser Cache and Cookies.
Checked a few settings in the Advanced Tab of the Java Control Panel like :
General : Allow user to grant permissions to signed content.
Java Cache was also cleared.
Even after performing the above workarounds, one after other, the issue doesn't go and there is no exceptions site list in the security tab either(just for information).
Majority of the issues related to the error would go after the security level is lowered to medium. But mine doesn't.
Hope some one could help me out.
Shall be ever grateful.
Thank you !
AK

"[Java 1.7.0_25 is] recommended for my work and not an old one i believe".
Unfortunately, your belief is incorrect. As of now (when you asked the Question), Java 1.7.0_u25 is over a year old, and there have been 4 security-relevant releases to Java 1.7 since that release.
In fact, you probably don't have any option apart from upgrading ... if you want to use that application via your web browser. The version checks cannot be overridden (AFAIK) for Java applications launched via your web browser and/or using Java Web Start. This is a good thing too.
So how does this jive with your "work recommendation"?
You need to talk to your system admins, or security people, or whoever made that recommendation. Under normal circumstances, it is bad to use an out-of-date version of Java, especially if you enable it in your web browser. It leaves you open to all sorts of security exploits.
It may turn out that there is a sound reason for this "recommendation"; for example a compatibility issue for some other Java-based apps that they need to support. If that is the case, you have a hard choice to make:
You could upgrade to the latest Java 1.7 release and risk not being able to use applications that (really) require an older release of Java.
You could not upgrade, and give up on the idea of using the app that is giving you problems.
You install a second web browser, and configure on to use the latest Java release, and the other to use the older "recommended" release. This could be messy, but (at least) Java is designed to allow you to have multiple JRE or JDK installs on your system simultaneously.
... but my application(on which i am working, unfortunately supports up to this version (i.e. 7_25).
Developing an application that only runs on old versions of Java doesn't seem like a good business strategy.
But assuming there is a good reason, you should be able to install BOTH 1.7.0_25 AND a later version on your system ... and use one for your development work and the other for running web-based applications.
Or if that isn't appealing, then use different virtual machines, or different physical machines for doing the different types of work that you need to do.

"Your security settings have blocked an application from running with an out-of-date or expired version of Java"
Java Version : 1.7_25 ( Recommended for my work and not an old one i believe)
From Java SE Downloads:
Java SE 7u67
This release addresses a regression introduced in the most recent security update. Oracle strongly recommends that all Java SE 7 users upgrade to this release.
You are not on the latest release for version 1.7.
There have been 7 releases since 1.7.25.

Actual problem can be not an outdated Java but applet jar sign/manifest/jnlp.
Workaround:
1.Install latest JRE from Oracle site
2.Uncheck "Enable Java content in browser" in old java/jre (javacpl.exe)
3.Make sure that applet correctly works with latest JRE
4.Uncheck "Enable Java content in browser" in latest JRE and check it in your old JRE

I had same issue, I reduced security level from high to medium and allowed to run the application at risk, it worked for me.

I recommend adding the site URL to the Security Exception Site list without lowering your overall security level.

Using Java Libraries With Incompatible Dependencies

I'm working on a project where I'd like to use Apache Tika and Apache Jena. However, when I try to run the project I get the following exception:
java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String; Ljava/lang/Object;Ljava/lang/Throwable;)V
My understanding is that this is because Apache Tika includes an old version of SLF4J (pre 1.6.0) and Apache Jena includes a newer version (1.6.0 or later), and that there is a breaking change between the two versions of SLF4J.
How do I get around this issue so that I can use both Tika and Jena at the same time?
Some existing posts talk about using Maven to work around this, but a) I don't use Maven and I'm not familiar enough with it to fully understand the solutions and b) I'm working on a development network that isn't connected to the internet.

slf4j is actually fairly compatible across versions for many usages. Jena does not use many features of SLF4j. It does not LocationAwareLogger as far as I'm aware. It may work with pre 1.6.X. While nothing is guaranteed (AKA you have to test it), it's worth a try.
If that fails, you'll need to rebuild one system and tweak what needs to be changed. Both systems are open source with both code and build system is available.

I wouldn't use these 2 libraries until they have the same version unless I'm absolutely have to do that.
If you think so, then a good explanation of the issue is here: java-classpath-classloading-multiple-versions-of-the-same-jar-project

The solution was to change the order of the libraries so that the library with the newer version of SLF4J (Apache Jena) was before the older version(s) on the build path.