意外と知られていない。SpringBoot のもう一つのPlatformTransactionManager
それは：org.springframework.data.transaction.ChainedTransactionManager　です。

使用するイメージ

    @Bean(name = "chainedTransactionManager")
    public ChainedTransactionManager transactionManager(@Qualifier("primaryDs") PlatformTransactionManager ds1,
                                                    @Qualifier("secondaryDs") PlatformTransactionManager ds2) {
         return new ChainedTransactionManager(ds1, ds2);
    }

@Transactional(value="chainedTransactionManager")
public void updateDb01() {
    Entity01 entity01 = repository01.findOne(1234);
    entity01.setName("Name");
    repository01.save(entity01);

    //Calling method to update DB02
    updateDb02();
}

public void updateDb02() {
    Entity02 entity02 = repository02.findOne(1234);
    entity02.setName("Name");
    repository02.save(entity02);

    //Added this to force a roll back for testing
    TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
}

要するに、DS1とDS2を同時にコミット/ロールバックできることです。
DS1 -> insert -> OK
DS2 -> update -> OK
DS1,DS2 -> commit

DS1 -> insert -> OK
DS2 -> update -> NG
DS1,DS2 -> rollback

参考サイト
https://www.it-swarm-ja.tech/ja/spring/%E8%A4%87%E6%95%B0%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%AB%E3%81%BE%E3%81%9F%E3%81%8C%E3%82%8B%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E4%BC%B4%E3%81%86spring-transactional/837725347/

環境

Spring Boot 2.4.0
java 1.8
thymeleaf 3.0.11
Spring Security 2.4.0
MySQL 8.0.22

現象

MySQLWorkbenchで「いらんなぁ」って思ったレコードを消去しました。
Delete rowでぽんと消しちゃったんですね。

そしたらシステムにログインできなくなりました。

別にしようとしてたログインとは関係ないレコードなんですけどね。

また元に戻せば大丈夫ですが、AutoIncrementがあるので、
1. AutoIncrementを外す
2. idを指定するinsertする
3. AutoIncrementをつける

ってめんどくさいことをしないと戻せない。

前にもやったんですけど、解決策がわからず前に進まなかったので、とりあえずめんどくさいけど上のやり方をしました。

でもまたあとから見て不要だと思ったので削除しようってやったら、「またかよ・・・」

これからもあるかもしれないので、ちょっと調べました。

解決策

https://stackoverflow.com/questions/46612968/hibernate-unable-to-find-entity-with-id
これを参考にしました。

@NotFound(action = NotFoundAction.IGNORE)

どうやらこれを追加すれば良いみたい。

どこに？！

@ManyToOne（の下）

例

@Entity
Supplier {
  // フィールド省略
}

@Entity
Wedding {
  // フィールド省略
  @ManyToOne // ←これが消したレコードを探しにいってるみたい・・・
  private Supplier supplier;
}

変更後

@Entity
Wedding {
  // フィールド省略
  @ManyToOne
  @NotFound(action = NotFoundAction.IGNORE) // ←これのおかげで無視してくれるみたい
  private Supplier supplier;
}

原因

まだわかりません。
どうして消したはずのレコードのIDを探しにいってるの？
てかなんで覚えてるの？
どこに保存されているの？

ということがわかりません。

でもどっかに保存されているのでしょう。
Hibernateってやつですかね？？

そのあたりSpringBootのことをしっかり理解していないですが、使いながら理解していきたい！！

とりあえず同じ様なエラーで前に進まない方の参考になればと思います。

プログラミングのときに使われる「～～～ケース」ってやつを、整理してみます。

キャメルケース

複数の単語をつなぐときに、先頭の単語の頭文字は小文字、2語目以降は頭文字を大文字で書くというルールです。

例

hello world -> helloWorld
programing language -> programingLanguage
osaka city -> osakaCity

利用例

・Javaのメソッド名や変数名

スネークケース

複数の単語をつなぐときに、単語同士を「_（アンダーバー）」でつないで書くというルールです。

例

hello world -> hello_world
programing language -> programing_language
osaka city -> osaka_city

利用例

・リレーショナルデータベースのテーブル名やカラム名

パスカルケース

複数の単語をつなぐときに、単語の頭文字を大文字で書くというルールです。

例

hello world -> HelloWorld
programing language -> ProgramingLanguage
osaka city -> OsakaCity

利用例

・Javaのオブジェクト（クラス）名称

Great explain.

https://stackoverflow.com/questions/56262240/difference-between-bindascontract-and-bind-in-hk2

環境

Spring Boot 2.4.0
java 1.8
thymeleaf 3.0.11
Spring Security 2.4.0

実現したいこと

ログイン中のユーザーのUSERDETAILSを継承したクラスの情報を取得したい。

いろいろ試してなんとか実現

ほぼ丸一日かかりました。というかちゃんとSpringBootを理解していないのだとは思いますが、いろんなサイトを見て試してみてなんとかうまく行ったので、記録として残しておきます。

USERDETAILSを継承しているクラス

Tenantsクラス
Staffクラス

ログイン認証

MyUserDetailsServiceクラスのloadUserByUsernameメソッドで、返すクラスを分けています。

MyUserDetailsServiceクラス

public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        // 引数がnullなら例外を投げる
    if (Objects.isNull(username)) {
      throw new UsernameNotFoundException("username is empty");
      }
    Tenants tenants = tenantRepository.findByAdminId(username);
    Staff staff = staffRepository.findByEmail(username);
    // nullが返ってきたら例外を投げる
    if(tenants != null) {
        return tenants;
    } else if(staff != null) {
        return staff;
    } else {
        throw new UsernameNotFoundException("Not found username: " + username);
    }

    }

コントローラー

ログイン後のトップ画面を表示するコントローラーで、今どのクラスでログイン認証されているか表示したい

いろいろ試した結果、下の実装で、どのクラスで認証されているか取得できるようになりました。

@GetMapping("/top")
public ModelAndView userTop(eModelAndView mv, Principal principal) {

        // ログイン中のユーザーのUSERDETAILSを継承したクラスを取得する
    Authentication auth = (Authentication) principal;
    String authClass = auth.getPrincipal().getClass().getSimpleName();
    if(authClass.equals("Tenants")) {
        System.out.println("テナントクラスだぜ！！");
        String tenantId = ((Tenants)auth.getPrincipal()).getId().toString();
        httpServletResponse.addCookie(new Cookie("tenantId", tenantId));
    }
    if(authClass.equals("Staff")) {
        System.out.println("スタッフクラスやっちゅうねん！！");
        String tenantId = ((Staff)auth.getPrincipal()).getTenantId().toString();
        httpServletResponse.addCookie(new Cookie("tenantId", tenantId));
    }
}

ハマったところ

PrincipalやAuthenticationなどの使いかたがよくわからなくて、
・引数の渡し方
・@AuthenticationPrincipalアノテーションの使い方
・キャストが必要？
・PrincipalにTenantsクラス入ってるけど、フィールドが取り出せないよ？
・getClass()がコード・アシスタントで出てくるのにエラーが出て実行できないよ？
などなど。。。

どうやらPrincipalにはUserDetailsを継承したクラスの、認証がうまく行ったときのレコードが全部入っているようでした。

しかし、username以外は取り出せないということに。。。

Principalを使えば良いとばかり思っていたけど、どうやら違った。

Authenticationクラスの中にPrincipalクラスが入っていて、Principalの中にUserDetailsクラスが入っているイメージでした。（合っているかわかりません）

ただそのイメージで

// コントローラーの引数に渡しているPrincipalからまずAuthenticationを取得する
Authentication auth = (Authentication) principal;
String authClass = auth.getPrincipal() // Principalを取得
   .getClass() // クラスを取得
   .getSimpleName(); // パッケージ名を除外

この流れでうまくいきました。

最初の
Principal → Authenticationへのキャストが必要なの？？って感じでしたが、これをやらないとうまく行かなかった。

thymeleafでビューで表示する方法

<div sec:authentication="principal"></div>
<div th:text="${#authentication.principal}"></div>

いずれも同じ内容が表示されます。コントローラーで取得するようりも遥かに簡単に取得できます。

そしてちゃんとprincipalにはUserDetailsが入っているのが確認できます。

まとめ

• コントローラー引数に Principal principalを渡す
• Authenticationから.getPrincipal()でPrincipalを取得
• thymeleafでは<div sec:authentication="principal"></div>
• または<div th:text="${#authentication.principal}"></div>

// コントローラー
// 引数に Principal principalを渡す
public ModelAndView userTop(eModelAndView mv, Principal principal) {
// コントローラー
// 引数に Principal principalを渡す
Authentication auth = (Authentication) principal;
// AuthenticationからPrincipalを取得
String authClass = auth.getPrincipal()
   .getClass()
   .getSimpleName();

*ポエムです。

Software Development Trends in 2021 - ソフトウェア開発トレンド予測記事をせっかく頑張って読んだので、他にも2021年版的な某かをまとめた。

Developer Roadmaps
https://roadmap.sh/
The 2021 Web Developer Roadmap
2021年版に更新されているようだ。

What are your plans to read/learn in 2021?
に記載されている以下は便利かもしれない。無料ツール・リソース50。
50 free tools and resources

こちらは本。
Eight must-read books for developers in 2021

で、JSer.info 10周年: JavaScript情報の集め方、書き方、まとめ方 これも頑張って読みたいと思った。

そしてふと気づく。
JS界隈と対象的に最近のJavaって何が話題なのかぼんやりしている。
いや、新しい記事はたくさんあります。

Java 15新機能まとめ なんてのもあるし
Javaアドベントカレンダー2020 にも書かれている。
Gc, チューニング等。

試しに Java 2021 トレンド で検索！

【2021年最新】Javaフレームワークのトレンドを紹介！案件・求人情報も！ がトップ。

2021年に最も勢いのあるJavaフレームワークのトレンドはこれから紹介する以下2つです。
それぞれのフレームワークの中身について紹介をしていきたいと思います。

Spring Framework
Apache Struts

知ってる。。SpringもStrutsも。。ていうかStruts多分2000年代からあったわ

Top 10 In-Demand programming languages to learn in 2020 (2020年、学ぶべき言語トップ10) はどうだ。

引用：

In recent years, Java has lost some of its markets to highly developer-friendly modern languages and the rise of other languages, especially Python, JavaScript. Also, JVM is not quite Cloud friendly because of its bulky size. Oracle has recently introduced hefty licensing fees for JDK, which will dent Java’s popularity further.
Fortunately, Java is working on its shortcomings and making Java fit for Cloud via the GraalVM initiative. Also, in OpenJDK, there is a free alternative to the proprietary Oracle JDK.
Java is still the number one programming language for enterprises.

近年、Javaは開発者フレンドリーな現代言語や、Python、JavaScriptを中心とした他の言語の台頭により、市場の一部を失っています。また、JVMはそのかさばるサイズのため、クラウドとの親和性はあまり高くありません。オラクルは最近、JDKに高額なライセンス料を導入したため、Javaの人気はさらに落ち込むことになるでしょう。
幸いなことに、Javaはその欠点を改善し、GraalVMを通じてJavaをクラウドに適合させている。また、OpenJDKでは、プロプライエタリなOracle JDKに代わる無料の代替品がある。
Javaは今でも企業向けのプログラミング言語としてはナンバーワンだ。

はい。なんだかんだでお仕事で一番今読んで書いている言語はJavaです。

GraalVM は調べる価値あるのかな。ほかディストリビューションがわけわからんのでこれももっと追及して調べたい気持ちはある。
OpenJDKと各種JDKディストリビューションの情報源まとめ #minjava
JDK、Oracle JDK、OpenJDK、Java SEってなに？

しかし
Java屋さんの私がPythonをはじめる理由
を読んでしまうとむしろPythonをはじめたいなんて思ったり。

ふとQiitaトップページを見たら

Javaという枠ではもう週間、月間ベスト10には入らない。全体でかろうじて9位。

このままゆるゆるとCOBOL化してしまうのだろうか。。。

追記: この記事が【Java】Qiita 週間 LGTM 数ランキング【自動更新】 に載った通知を頂いた！ありがとうございます。感動の、単独首位。。。。

追記2: およそ同じ内容を dev.to でつぶやいてみたらコメントを頂けた！
https://dev.to/siy/comment/1aibj

All those articles you mention as well as TIOBE index and other stuff, has nothing to do with real usage of any language. I think that Java now in the position when it above all hypes or trends. It's enough to take a look at any job site and realize that demand for Java is high and growing.

「あなたが引用している記事は、TIOBEのインデックスや他と同様、その言語の実際の使われかたとは何の関係もありません。私は、Javaは今、それがすべてのトレンド予測より上に位置していると思います。求人サイトを見たら、Javaの需要は高く、成長していることを認識するのには十分。」
ですよね。。。転職には困らないと思います。。

追記3:

The next release of Java may include project Loom, which brings with it lightweight threads (similar to kotlin's coroutines). That will be a game-changer for Java web development, I think.

「次のリリースには、(kotlinのコルーチンに似た)軽量スレッドをもたらすLoomプロジェクトが含まれているかもしれません。これはゲームチェンジャーになると思います。」

そうなんですね！期待したい。。

line-bot-sdk-javaを使用した、自社サービスの既存ユーザーアカウントとLINEユーザーのアカウントの連携手順についてメモ。
※記事内のソースは例外処理等記述してないので、注意。

サンプルソースコード

アカウント連携のシーケンスで、アカウントを連携する手順についてドキュメントが用意されています。
ここを確認しながら実装する。

以下モジュールを使用しました。

<dependency>
    <groupId>com.linecorp.bot</groupId>
    <artifactId>line-bot-servlet</artifactId>
    <version>4.3.0</version>
</dependency>
<dependency>
    <groupId>com.linecorp.bot</groupId>
    <artifactId>line-bot-model</artifactId>
    <version>4.3.0</version>
</dependency>
<dependency>
    <groupId>com.linecorp.bot</groupId>
    <artifactId>line-bot-parser</artifactId>
    <version>4.3.0</version>
</dependency>

フォーローイベントを受け取ったら、連携用のメッセージを返す形で進める。

1 Call API to issue link token
2 Return link token
フォローイベントを受け取ったら、LINEのユーザーIDを元にリンクトークンを取得します。

LineMessagingClient client = LineMessagingClient.builder("yourAccessToken").build();
// アカウント連携用トークン取得
IssueLinkTokenResponse linkTokenRes = client.issueLinkToken(event.getSource().getUserId()).get();
String lineLinkToken = linkTokenRes.getLinkToken();

3 Call API to send linking URL
自社サービスのログインフォームが表示できるようユーザーへTemplateMessageを返します。
ログインフォームへリンクトークンをパラメーターで渡します。
※連携解除について
※ユーザーがアカウントを連携するときに、連携解除機能があることを通知すること

// 自社サービスのユーザー認証画面を表示するボタン付きのメッセージを返す
List<Action> actions = Arrays.asList(new URIAction("連携する",
            URI.create("https://yourdomain/loginform?linkToken=" + lineLinkToken), null));
String botResponseText = "LINEと連携するアカウント情報をフォームに入力してください。";
TemplateMessage templateMessage = new TemplateMessage("アカウント連携",
                    new ButtonsTemplate(null, "アカウント連携", botResponseText, actions));

TextMessage textMessage = new TextMessage("連携はいつでも解除可能です。");

ReplyMessage rep = new ReplyMessage(event.getReplyToken(), Arrays.asList(templateMessage, textMessage));

// TODO reply message

4 Send linking URL
LINEユーザーが、3で送信したTemplateMessageを受け取ります。

5 Access linking URL
6 Show login form
LINEユーザーが、4で受け取ったメッセージのアカウント連携ボタンをクリックして、自社サービスのログインフォームを表示します。

7 Enter credentials
8 Get user ID and generate nonce
自社サービスのユーザー認証処理を通し、Nonceを生成します。

9 Redirect to account link endpoint
10 Access account link endpoint
8でリクエストを処理したら、以下URLへリダイレクトするようレスポンスを返却します。

https://access.line.me/dialog/bot/accountLink?linkToken=[2で受け取ったlink token]&nonce=[8で生成したNonce]

11 Send webhook event
12 Link accounts
アカウント連携イベントを受け取ったら、8で生成したNonceから自社サービスのユーザーを判定しLINEユーザーIDと紐づけます。
※連携解除について
※ユーザーに連携解除機能を必ず提供すること

LinkContent linkContent = event.getLink();

if (linkContent.getResult() == Result.OK) {

    String nonce = linkContent.getNonce();

    // TODO 自社サービスで生成したNonceでユーザー判定

    // TODO 自社サービスのユーザーIDとラインユーザーIDをセットで保存する

    TextMessage textMessage = new TextMessage("LINE連携が完了しました。");

    List<Action> actions = Arrays
            .asList(new PostbackAction("解除する", "unlinkAccount"));

    TemplateMessage templateMessage = new TemplateMessage("アカウント連携解除",
            new ButtonsTemplate(null, "アカウント連携解除", "アカウントの連携を解除する場合は、以下ボタンをクリックしてください。", actions));

    ReplyMessage rep = new ReplyMessage(event.getReplyToken(), Arrays.asList(textMessage, templateMessage));

    // TODO reply message

}

TextMessage textMessage = new TextMessage("連携失敗");
ReplyMessage rep = new ReplyMessage(event.getReplyToken(), Arrays.asList(textMessage));

// TODO reply message

これで、自社サービスユーザーとLINEユーザーのアカウント連携が完了。
公式のドキュメントが詳細に記述されていて、わかりやすい。

What's？

Red Hat Enterprise Linuxでは、システムの暗号化ポリシーを設定できます。

システム全体の暗号化ポリシーの使用

この内容で、Javaのセキュリティ設定も変わりますよ、という話です。

環境

CentOS 8で確認してみます。

$ cat /etc/redhat-release 
CentOS Linux release 8.3.2011

使用するJavaは、OpenJDK 8とします。

$ java -version
openjdk version "1.8.0_275"
OpenJDK Runtime Environment (build 1.8.0_275-b01)
OpenJDK 64-Bit Server VM (build 25.275-b01, mixed mode)

確認

たとえば、jdk.tls.disabledAlgorithmsという暗号化において無効化するアルゴリズムを指定するプロパティがあります。

Java Secure Socket Extension (JSSE)リファレンス・ガイド

Java暗号化アーキテクチャOracleプロバイダのドキュメント(JDK 8用)

こちらを出力するプログラムを書いてみます。

App.java

import java.security.Security;

public class App {
    public static void main(String... args) {
        System.out.printf("jdk.tls.disabledAlgorithms = %s%n", Security.getProperty("jdk.tls.disabledAlgorithms"));
    }
}

ここで、java.securityの設定を見てみます。

$ grep ^jdk.tls.disabledAlgorithms -A 2 /usr/lib/jvm/java-1.8.0-openjdk/jre/lib/security/java.security
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
    EC keySize < 224, 3DES_EDE_CBC, anon, NULL

作成したプログラムを実行してみます。

$ javac App.java

…まったく異なる値が得られました。

$ java App
jdk.tls.disabledAlgorithms = DH keySize < 2048, SSLv2, SSLv3, TLSv1, TLSv1.1, DHE_DSS, RSA_EXPORT, DHE_DSS_EXPORT, DHE_RSA_EXPORT, DH_DSS_EXPORT, DH_RSA_EXPORT, DH_anon, ECDH_anon, DH_RSA, DH_DSS, ECDH, 3DES_EDE_CBC, DES_CBC, RC4_40, RC4_128, DES40_CBC, RC2, HmacMD5

ここで、現在の暗号化ポリシーの設定を見てみます。DEFAULTとなっています。

$ update-crypto-policies --show
DEFAULT

暗号化ポリシーには、DEFAULT、LEGACY、FUTURE、FIPSの4つのプロファイルがあります。

システム全体の暗号化ポリシーの使用

ここで、/usr/share/crypto-policiesディレクトリを確認してみます。

各プロファイルごとの設定が配置されているのですが、この中でDEFAULTプロファイルのJava用の設定を見てみます。

$ grep ^jdk.tls.disabledAlgorithms /usr/share/crypto-policies/DEFAULT/java.txt 
jdk.tls.disabledAlgorithms=DH keySize < 2048, SSLv2, SSLv3, TLSv1, TLSv1.1, DHE_DSS, RSA_EXPORT, DHE_DSS_EXPORT, DHE_RSA_EXPORT, DH_DSS_EXPORT, DH_RSA_EXPORT, DH_anon, ECDH_anon, DH_RSA, DH_DSS, ECDH, 3DES_EDE_CBC, DES_CBC, RC4_40, RC4_128, DES40_CBC, RC2, HmacMD5

これ、先ほどのプログラムの出力結果と一致します。

ここで、暗号化ポリシーのプロファイルをLEGACYに変えてみます。

$ sudo update-crypto-policies --set LEGACY
Setting system policy to LEGACY
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.

変更したらOSを再起動。

$ sudo reboot

暗号化ポリシーのプロファイルが変わったことが確認できました。

$ update-crypto-policies --show
LEGACY

先ほどのプログラムを再度実行してみます。

$ java App 
jdk.tls.disabledAlgorithms = DH keySize < 1023, SSLv2, SSLv3, RSA_EXPORT, DHE_DSS_EXPORT, DHE_RSA_EXPORT, DH_DSS_EXPORT, DH_RSA_EXPORT, DH_anon, ECDH_anon, DH_RSA, DH_DSS, ECDH, DES_CBC, RC4_40, DES40_CBC, RC2, HmacMD5

$JAVA_HOME/jre/lib/security/java.securityファイルは変更していないのに、設定が変わりました。

ここで、LEGACYプロファイルのJavaの設定を見てみます。java.txtというファイルです。

$ grep ^jdk.tls.disabledAlgorithms /usr/share/crypto-policies/LEGACY/java.txt 
jdk.tls.disabledAlgorithms=DH keySize < 1023, SSLv2, SSLv3, RSA_EXPORT, DHE_DSS_EXPORT, DHE_RSA_EXPORT, DH_DSS_EXPORT, DH_RSA_EXPORT, DH_anon, ECDH_anon, DH_RSA, DH_DSS, ECDH, DES_CBC, RC4_40, DES40_CBC, RC2, HmacMD5

この値と同じになっていますね。

どうやって反映しているのかはわかりませんでしたが、これは知らなかったです…。

プロファイルを選択したり、カスタマイズもできるようですが、LEGACYは選ぶべきではないでしょうね。RHEL 5互換に近づくということらしいですが。

最後に、各プロファイルのJavaの設定を見てみましょう。

DEFAULT

/usr/share/crypto-policies/DEFAULT/java.txt

jdk.tls.ephemeralDHKeySize=2048
jdk.certpath.disabledAlgorithms=MD2, MD5, DSA, RSA keySize < 2048
jdk.tls.disabledAlgorithms=DH keySize < 2048, SSLv2, SSLv3, TLSv1, TLSv1.1, DHE_DSS, RSA_EXPORT, DHE_DSS_EXPORT, DHE_RSA_EXPORT, DH_DSS_EXPORT, DH_RSA_EXPORT, DH_anon, ECDH_anon, DH_RSA, DH_DSS, ECDH, 3DES_EDE_CBC, DES_CBC, RC4_40, RC4_128, DES40_CBC, RC2, HmacMD5
jdk.tls.legacyAlgorithms=

FUTURE

/usr/share/crypto-policies/FUTURE/java.txt

jdk.tls.ephemeralDHKeySize=3072
jdk.certpath.disabledAlgorithms=MD2, SHA224, SHA1, MD5, DSA, RSA keySize < 3072
jdk.tls.disabledAlgorithms=DH keySize < 3072, SSLv2, SSLv3, TLSv1, TLSv1.1, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_GCM_SHA256, DHE_DSS, RSA_EXPORT, DHE_DSS_EXPORT, DHE_RSA_EXPORT, DH_DSS_EXPORT, DH_RSA_EXPORT, DH_anon, ECDH_anon, DH_RSA, DH_DSS, ECDH, AES_128_GCM, AES_128_CCM, AES_256_CBC, AES_128_CBC, 3DES_EDE_CBC, DES_CBC, RC4_40, RC4_128, DES40_CBC, RC2, HmacSHA1, HmacMD5
jdk.tls.legacyAlgorithms=

FIPS

/usr/share/crypto-policies/FIPS/java.txt

jdk.tls.ephemeralDHKeySize=2048
jdk.certpath.disabledAlgorithms=MD2, SHA1, MD5, DSA, RSA keySize < 2048
jdk.tls.disabledAlgorithms=DH keySize < 2048, SSLv2, SSLv3, TLSv1, TLSv1.1, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_GCM_SHA256, DHE_DSS, RSA_EXPORT, DHE_DSS_EXPORT, DHE_RSA_EXPORT, DH_DSS_EXPORT, DH_RSA_EXPORT, DH_anon, ECDH_anon, DH_RSA, DH_DSS, ECDH, 3DES_EDE_CBC, DES_CBC, RC4_40, RC4_128, DES40_CBC, RC2, HmacMD5
jdk.tls.legacyAlgorithms=

LEGACY

/usr/share/crypto-policies/LEGACY/java.txt

jdk.tls.ephemeralDHKeySize=1023
jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1023
jdk.tls.disabledAlgorithms=DH keySize < 1023, SSLv2, SSLv3, RSA_EXPORT, DHE_DSS_EXPORT, DHE_RSA_EXPORT, DH_DSS_EXPORT, DH_RSA_EXPORT, DH_anon, ECDH_anon, DH_RSA, DH_DSS, ECDH, DES_CBC, RC4_40, DES40_CBC, RC2, HmacMD5
jdk.tls.legacyAlgorithms=3DES_EDE_CBC, RC4_128

項目数からして、$JAVA_HOME/jre/lib/security/java.securityとの差分な気がするので、このファイルとOS側の暗号化ポリシーの両方を見た方が良さそうですね。

参考

システム全体の暗号強度設定を統合するcrypto-policiesのカスタマイズ

RHEL8のシステム全体の暗号化ポリシー