For a long time now America has treated strong crypto as akin to munitions; a deadly weapon that must not be allowed to fall into the wrong hands. For the background to this, see the wikipedia page at https://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States
The wikipedia page indicates that this attitude was significantly lessened in 1992 but the sad fact is that is persisted well beyond that for java. The Oracle release notes for JDK8 at https://www.oracle.com/java/technologies/javase/8all-relnotes.html say that the restricton was removed in January 2018, in update 161. The change was also backported to JDK7 in update 171.
This means that java projects using JDK8 had better move to at least this update version if they have not already. Of course, users of OpenJDK probably never had a problem and certainly don't now.
The way I ran into this problem was during work on a trade feed that uses the FIX protocol. The FIX session was secured with TLS1.2. everything was fine until one day the remote side changed from a weak crypto algorithm to a strong one. Our side failed with a mysterious SSL handshake error. This came from the mina package, as used by quickfixj. Mina which doesn't seem to handle this situation well at all. We had to turn on packet level logging via the JVM option -Djavax.net.debug=all to see what was happening. The log showed that the remote side wanted to use a strong algorithm but that many algorithms on our side were disabled. At the time the latest JDK8 update from Oracle was update 251. I switched to that and then all those messages about unknown algorithms disappeared and the algorithm preferred by the remote side was accepted. Everything started working again.
