VMWereって、買収されてたの知ってた？で、Springは今、ブロードコムが扱ってるらしい

２月２日にあった、JSUG勉強会2024その1　
Spring for GraphQL入門、そしてSpring Boot 3へのマイグレーション
の話をYouTubeLiveで聴いたんだけど

 

その話を報告していないので、メモ

---

Spring for GraphQLは、
JavaのフレームワークSpringで、
（DBに依存しないで）データ検索・更新を行うための言語GraphQL
を使うライブラリ。

今回の勉強会では、その概要と書き方（デモ）をやっていたんだけど、
デモ・書き方部分は、メモってない

それと、SpringBootの２系のサポートが終わり、３系になっているので
そのマイグレーションについて。

終わりの方の１０分間で、
以前、Springを扱っていたVM Wareをブロードコムが買収し、
その結果、今ブロードコムがSpringの有償サポートをしていて、
NECと協業していることを説明してた

---

以下、その時のメモ

JavaのSpringフレームワークのアプリを生成AIで作成する話とかをちょこっと聞いた！

１２月１１日、JSUG勉強会の「Spring One報告会」を

YouTubeライブで見たので、そのまとめをシェア

Spring　Oneは、JavaのフレームワークSpring

（NTT　Dataの開発フレームワークTERASOLUNA（テラソルナ） 

　なんかでも採用されている）

Server Framework for Java｜フレームワーク｜TERASOLUNA

のカンファレンス。

ことしは、JDK21対応として、バーチャルスレッドやCRaCのほかに、

Springから生成AIを呼び出すフレームワーク

Intelligent Beans with Spring AI

や、

Springアプリを生成AIで作成する（Spring CLIの１機能である）

Spring AI Add

なんかのお話もあったみたい。

では、以下シェア

Spring AI Addって、これかなあ？

ai add :: Spring Cli

https://docs.spring.io/spring-cli/reference/commands/ai-add.html

Intelligent Beans with Spring AIのSpring Oneでのお話は

↓みたい

 

JJUG CCCで、Jakarta EEをキャッチアップしてきた！

１１月１１日の、JJUG CCCの話つづき。

Java21のあとは、

Jakarta EE 11 キャッチアップ

を聞いてきました。

---

　Jakarta EE とは、Javaでサーバーサイドのアプリケーションプログラムを作成する際のプラットフォーム標準を決めたもので、この実装としてGlassFishやPayaraがある。

　ちなみに、Jakarta EEのほかに、Javaのサーバーサイドのアプリケーションプラットフォームとしては、Springがある（って、今回の講師の人は説明してました。少なくとも私はそう理解した）。

　日本の開発においては、サーバーサイドのプログラム・運用だけでなく、それらを含めて開発全体を統合環境としてSIerごとに提供している。

　たとえば、NTTDataさんの場合は、TERASOLUNA（てらそるな）という統合開発環境があって、この中では、Springフレームワークを採用している

Server Framework for Java｜フレームワーク｜TERASOLUNA

 一方、富士通は、Interstage（いんたーすてーじ）という統合開発環境があって、この中では、GlassFishを基にしたサーバーが提供されている（自分の記憶が正しければ、たしかGlassFishそのものではない）。

　その実装されているJakartaEEのバージョンは、１１ではなく、ネットで見つかったのだと８が最新なのかな・・・そうなのかな？

https://www.fujitsu.com/jp/documents/products/software/middleware/business-middleware/interstage/products/bapserver/catalog/cz3125-7.pdf

　あれ、↑の説明だと、JakartaEE８もサポートしているけど、Springもサポートしているとか。最近、データさんの仕事ばかりで、富士通さんの仕事はしていないので、よくわかりません・・・

---

世間話長くなりすぎました。聞いてきた内容は↓のとおり

Java8からJava21への移行話をJJUG CCCで聞いてきた！

11月11日は、JJUG CCC　Fallを聞きに、

新宿野村ビルに行ってきた！

いままでと会場が変わり、カンファレンスルームA1で聞いてきたんだけど、

ちょっと狭い部屋。始まりだしたところで満席になり、最終的には立ち見

ちらほらでした。

で、まず１つめ。

Java８から２１に移行したときのお話。

時間が短かったので、ポイントを、

・Optional

・Switch式（値を返せるようになった）

・Records

に絞って話してました。

内容は↓の感じ

window.openerでwindowオブジェクトが取れないときの対処法

Javascriptの話。javascriotで、ウィンドウを開いたとき、
開いた元の画面の情報を取りたいときなどに

var w = window.opener;

とか,いう感じでopenerっていうのを使うけど、

（このほかwindow.opener.open()っていうのでも使う）
このopener、ときどき値が入ってこない（nullになってる）
ことがある。

同一ドメイン上にある場合は取得でき、そうでないとブラウザが判断した場合
（実際どうかではなく）、openerはNULLになるみたいで、
セキュリティ上の仕様らしい

---

・・・といわれてもこまるんですよ！
昔のプログラムでは

　window.opener.open(なんとかかんとか・・・

とか、opener散々使ってて、それをいまさら、使えないとは・・・

・・・といって、途方に暮れていている、あなたに贈る対処法

---

【対処法１】window.open('',画面名）でwindowオブジェクトを取得する

window.openして、画面を生成するとき、window.openの第二引数に、
（_blankなんかを指定しているかもしれないけど、ここに）
画面名（任意。なんでもいい）を振っておくと、

w = window.open('',画面名）

で,wにその画面名のwindowオブジェクトがはいってくる


つまり、window.openは、
　第一引数にURLが指定されている場合は、そのURLの内容で画面をひらき、
　　その画面のwindowオブジェクトを返す
　　また、第二引数が_で始まるような一般的なものでない場合、
　　　　画面名として、wiodon.nameに設定される

　第一引数が''（空文字）だったら、
　　　　第二引数を画面名として、既存のwindowオブジェクトを参照して、
　　　　第二引数を画面名と既存のwindowオブジェクトのwindow.nameが
　　　　　一致したら、そのwindowオブジェクトを返す
　　　→結果として、画面名でwindowオブジェクトを検索できる

よって、openerに指定する画面名がわかれば、
window.open('',openerの画面名)で
windowオブジェクトが取得できる

・・・という仕様があったが、使えない場合もある（使える場合もある）

---

【対処法２】lacalStorageにwindowオブジェクトを保存する

　window.openerに該当するwindowオブジェクトを
　　どこかで、localStorage.setItem()で保存しておいて、

　window.openerしたいときに、localStorege.getItem()で
　　取得する

という方法。localStorageは普通使えるから、こっちのほうがいいのかもしれない

---

【使い分け】
・ブラウザのバージョン変更がありそうなときは、localStorageのほうが
　無難だけど、
・localstorageのほうは、開く元画面（親ウィンドウ）側で、
　localStorageに格納するコードを書かないといけない。
　ソース修正の権限で、親ウィンドウ側のソースコードは参照できても
　自分が修正できる立場にないときは、対処法１しかできない

JavaをWindowsにインストール（最新版のLTSを）

ORACLEのJDKは、以下にある


https://www.oracle.com/java/technologies/downloads/


最新版はJava２０だけど、これは2023年９月（Java21）までのサポートなので
2024年９月まで利用できる最新版のLTSであるJava17を入れてみる。


Windows版Java17は
https://www.oracle.com/java/technologies/downloads/#jdk17-windows
にある。


x64 Compressed Archive
x64 Installer
x64 MSI Installer


の３つがある。下の２つはどっちでもいいけど、
せっかくだから一番下のx64 MSI Installerをダウンロード
（URLリンクをクリックする）


ダウンロードすると、jdk-17_windows-x64_bin.msiっていうファイルが
できているので、それをダブルクリック


NEXTをクリックし続けて（２回かな？）でOKだけど、
途中、なにも動かなくなったら、裏で
「許可しますか」というダイアログがでているはず。
そしたら許可するほうのボタンをクリック。先に進む


Successfully Installedというのが１行目に出ていて、
下にcloseボタン、ちょっと左上にNext Stepsという
ボタンが出たダイアログになったら、正常にできているので
closeボタンを押してもいいし
Next Stepsボタンをおしてもいい。


Next Stepsボタンをクリックした場合、
https://docs.oracle.com/en/java/javase/17/index.html
というページが開く。
ってことで、その場合でも、
まあ結局「close」ボタンをクリックするんだけどね（＾＾；）
（上記ドキュメントページは
「スタート」→「Java Development Kit」→「参照ドキュメント」
　で開けるので、上記「ページが開く」で開いたページをクローズしても
　大丈夫）

「Visual Studio Codeを利用したJava開発環境の構築方法について」のありか

昨日(1/27)のJJUGナイトセミナー「開発環境の最前線」
の前半戦、寺田さんの

「VS CodeでJavaのアプリ開発ができるってご存じですか？」

のセミナー、「動画でやります！」ってことで、動画を流したけど、その動画

「Visual Studio Codeを利用したJava開発環境の構築方法について」

は、これ

（ありかはhttps://www.youtube.com/watch?v=YWzlCWSrKJ8）

ちなみに、動画内容はこんなかんじ

・JDKインストール
　Microsoft BuildのOpenJDK（プレビュー版）
       Visual Studio Codeでやるには、JDK11以上

・Visual Studio Codeを入れる
　　　→Cording Pack for javaを使う

　エクステンション
　日本語対応
　各種エクステンションインストール
　　Spring Boot関係、
　　マイクロプロファイル
　　チェックスタイル

・プロジェクト作成
　ソース作成
　ターミナル表示
　構築

　Quarkusの場合

　リファクタリング

　デバッグ
　→Quarkusアプリをデバッグモードで

・Azureへデプロイ

       Mavenプラグイン

   　azコマンド

       Advanceツール

・Git hubにプッシュ

【クラウドでの開発】
・Codespaceについて

JAVAの最近のLTS（Java17）とそれ以降の話も聞いてきた！

昨日は１７までだったけど、１７以降の話も

１１月２１日のJJUG CCC

「Head toward Java 17 and Java 18」

で、話を聞いてきたので、以下メモメモ

---

●自己紹介

●メインはJava17
　2021/9/14リリース。３年ぶりのLTS

●LTS
　長期サポートバージョン
　OpenJDKコミュニティ：半年ごとにバージョン上げる
　３年ごとにLTS
　（ただしOpenJDKはバイナリを作っていない）
　２年ごとに変更する提案あり
　→Oracleはそうする予定

　CSR：日互換性をともなう変更のあるレビュー

　NEW API since Java 11 というのがある

・用語
　インキュベーター：試験機能

●Java17の機能
【追加機能　１０個】
・内部APIの隠蔽強制的になる→使えない
　所属しているクラス　jdepsコマンドで確認
・MacOS（Apple Sillicon）対応
・Java2DAPIのMacOS対応
・疑似乱数生成（PRNG)の改善、新ＡＰＩ提供(java.util.random)
・Ｊａｖａ９のデシリアライズのフィルター
　filter factory経緯で指定できる
・メモリＡＰＩの提供（使いやすいＪＮＩ）　細かいＡＰＩ変更有
・ＶｅｃｔｏｒＡＰＩ
・浮動小数点の計算が厳密になる
・パターンマッチングがswitch文で（プレビュー）ガードパターン、カッコつきも
・シールクラス標準に昇格（継承、インターフェースを制限できる）

【削除・非推奨　４つ】
・AppletAPI非推奨
・セキュリティマネージャー非推奨
・RMI　Activation削除（RMIそのものは非推奨でも削除でもない）
・一部のコンパイラ削除

【その他】
・ロギングの非同期出力
・TLS1.3デフォルト（いままでは１．２標準）
・Unsafe一部削除
・JDKフライトレコーダーに新しいイベントなど

・GCの性能改善
　ZGC
　G1GC

●Java18
・Java APIのcharsetがUTF-8デフォルト
・Simple Web Serverの提供
・JavaDocでコードスニペット対応
・VectorAPI

JAVAの前のLTS（JAVA１１）から、今度のLTS（JAVA17）までの差分話を聞いてきた！

ちょっと前だけど、

１１月２１日にあった、JJUG CCCの

「最新 LTS Java 17 でプログラムが書きやすくなるという話」

で、JAVAの前のLTS（JAVA１１）から、今度のLTS（JAVA17）までの差分話を聞いてきたので、以下（下線から）、メモメモ

---

・Java11以降で入ったものの話をします

　レコードクラス等

・自己紹介・会社紹介

・LTSってなあに
２０２１年９月１４日にLTSのJava17
（前のLTSはJava11）
LTS:長期サポートが行われる
３年に１度のペース（２年に１度を検討）

サンプルソースコード、資料
https://bit.ly//3GYJ4n5

●レコードクラス　Java１６～
　JEP 395
　レコードクラスの宣言　
　public record User(long ld,String name){
}

レコードヘッダ(long ld,String name)
レコードコンポーネントリストlong ld,String name
レコードコンポーネントlong ld
finalなフィールド
大量のボイラーテンプレートを排除
明示的に継承はできない。implimentsはできる
デフォルトコンストラクタは宣言されないが、初期化が暗黙的に
→明示的にコンストラクタをつくることはできる
コンパクトコンストラクタ
メソッド;equalsmhashCode,toStringが暗黙的に→オーバーライドできる
finalなので、フィールドは書き換えられない
エンティティに使うべきではない
　→エンティティは変更可能なことが前提
DTOにするのは、問題ない
JSON変換にはJackson使う
Thymeleaf:SPEｌ式：レコードでもそのままでＯＫ

●新しいswitchステートメント
→を書くと（switch rule）break文不要
yieldで値を返せる（｛｝とyield省略可能）：returnでないこと注意

●Instanceofによるパターンマッチング

●switchによるパターンマッチング　Java17プレビュー

●テキストブロック
　文字列の連結を使わずに書ける
　"""で始まり、終わり

●シールクラス
　JEP 409
　利用できる場面、それほど多くない
　APIで提供するとき、間違って作成しないために
　enumでも似たことはできるが、柔軟にできる

JAVA15の変更点を聴いてきた！

そうそう、メモメモといえば、この前（9/28(月) ）

【オンライン】 JJUGナイトセミナー「Java 15 リリース記念イベント」
https://jjug.doorkeeper.jp/events/111440?utm_campaign=event_111440_134638

を聴いて、最近出たJAVA１５の変更点を聴いたのでメモメモ
（https://www.youtube.com/watch?v=c_tyFmgb1lYで見れる
　初めのほうの話でJAVA１５の変更点について触れている）

---

■JAVA１５の変更点
（１）削除・非推奨になったところ：４つ
（２）新機能：６つ
（３）プレビュー、インキュベーションなど：４つ

（１）削除・非推奨になったところ：４つ
・Nashorn（Javascriptエンジン）
・バイアスロック
・solaris/SPARCポート
・RMIアクチベーション（非推奨：RMIのアクチベーションのみ非推奨）

（２）新機能：６つ
・EdDSA(エドワーズ曲線デジタル署名アルゴリズム）
・Hidden Class
・UDPの新しい実装（バーチャルスレッド対応。TCPはJava13で対応済み）
・ZGC
・テキストブロック
・Shenandoah(RedHatのGC)

（３）プレビュー、インキュベーションなど：４つ
・パターンマッチング（instanceofによる）
・Records
・シールドクラス
・フォーリンメモリーアクセス：ヒープ外のメモリアクセス

Java 14がリリースされて、Javaのバージョンアップの向き合い方を聴いてみた

この前の、オンライン版？JJUGナイトセミナー

Javaのバージョンアップとの現実的な向き合い方 - Java 14リリース記念
https://www.youtube.com/watch?v=QMUV4h7YbUg

が上記の通りYouTubeにあがっていたので、メモメモ

---

・自己紹介
・Java14　注目の新機能
　レコード
　JFR（JDKフライトレコーダー）イベントストリーム
　フォーリンメモリーアクセスエリアの話
　Javaパッケージ
　・・・おいといて、いろんな人たちがコミット
　他にも文法的改善、面白そうな機能

・使いますか
　Java14→LTSではない
　　知見をためる
　　次１７？

・追従は？６か月、３年、しない？
　本心は最新版→使いたいバージョン使えば
　アプリケーションサーバー、下まわり、フレームワークに縛られる
　テストしておく
　Dockerイメージに入っているものになる
　求人のため
　フレームワークのバージョンアップのほうがつらい（Spring)
　ラムダ、モジュール→Java6,7,8使っている人は、いつやるの？
　正論ではやったほうがいい

　６か月：耐えられる証明としてやる

・保守開発でバージョンアップすべき
　脆弱性に対応するのが保守開発
　　→正論は置いといて
　ほそぼそとやっている場合（０．５人月）
　　→Springはむり
　体制と予算

　サーバーサイドJavaではそんなに・・・
　　→だからJavaがはいる

　請負に対する考え方
　　→時代的に作って終わりでなくなってきている

・バージョンアップに追従するためにやっておくべきことは
　サイドカーサービス→ルーティング、ロードバランシングなどを担う
　　インフラとフレームワークの境界線をうまく切りたい
　　ビジネスロジックはサイドカーにHTTP通信する
　　→バージョンアップしやすくなる
　Javaとインフラのバージョンアップを別のタイミングにできる
　　→ライフサイクルの違うものを分離できる
　横断的関心事を減らしたい

　コンテナがやってくれる

　テスト大事、CI大事。ほかに？
　　ろんぼっくはややこしくなるから・・・

　やろうという気、スタンス

　流れが読めない→ビジネスロジックとの分離

　フレームワーク：依存しちゃうと抜けられない

　関数型で書けば？

【質問】追従するとしたら手順は？
　自動テストから
　フレームワーク、ライブラリを上げてからランタイムを上げる
　戻せること→ビジネスロジックが更新してたら？
　　→ブランチをきって、両方にロジックを入れる
　Dockerイメージ：戻せる→データ構成変わったら？
　DBを先にあげる？ケースバイケース

・ディストリビューションどれが一押し
　みんなのJava読んでください
　https://www.amazon.co.jp/dp/4297111993

　システムの事情で決まる（システムデフォルト）
　　→標準を決める理由がない

　複数言語だとPython,RubyよりJavascriptかも

　組織標準いらない
　　→どうしたらいいかわからない

　ディストリビューションのイメージ
　　Linux：ちがう　そんなかんじではない

　迷うのは決まらないケース：趣味とか

・Java８で稼働中のシステム、これからどうすべき？
　７，６なら：しおずけ？
　９以上にもっていけるか、ビジネス的に価値があるか？
　とりあえずクラウド
　むかしのような大きいサーバーがいる環境では今はない
　　→今はコンテナ
　Java11世代のAP　変わりやすい
　　jakarta EE はまだまだ
　モノリス、マイクロサービス：やりかた

　Java8の人、変わらないと思って採用した
　　→９以降、話が変わった

　ネイティブイメージとそうでないのの共存

　デスクトップアプリ

　２０２６年までは選択肢を持たせている

　モノリスからマイクロサービスだけではなく、
　システムをリフレッシュしたい

（このへんいろいろはなしてたけど
　はっきりしないのでしょうりゃく）

　１５，１６で入りそうな機能　→１７で？
　
　お金のバランス
　セキュリティー　WAFとか手前に
　塩づけ→脆弱性のコスト：それならあげちゃったほうが
　戦略的に塩づけはない？

　OSのアップデートとおなじこと。

　エンジニアが調達できないから、塩漬けする

　コンテナ対応；バックポートされてるけど

　アップデートしたくない理由：
　　新規案件８でやりたい人（APサーバーは置いといて）
　　８を選んだら１１にあげられる気がしない
　Spring Boot　Java8で新規案件はないよね

　８に下げてくれと言われた
　　→無償で使える8、足並みを合わせる
　ふっと８を入れてしまう
　　→CENT OSでインストールしてて。。。
　Oracle JDKからOpenJDKになって、人は不安になる
　　→誤解だけど、向き合わないと
　　→Python,RubyのSIerが、そこを攻めてくる

　正しい情報で正しく判断するのは難しい
　　２０００年代　かれているほうがいい
　　今　　　　　　新しいもののほうが安全
　　　→攻撃のスピードが上がったから
　　昔の判断になってしまう
　　→Javaはあぶない、Pythonかな？

　Android最近どう？
　　あっちから上げる気はない

　正しい：ポジショントーク
　営業さんも混乱する

・他言語に比べ、最近のJava
　ここがだめというのが、減ってきている
　　→これから攻めに転じる？
　コード互換性：今書いたソースが１０年後動くか

・まとめ：最後にひとこと
　周りの環境大切
　塩漬け：脆弱性きけん
　ダウンロードして使って、コミュニティで使ってる感
　１４も通過点
　オンラインイベント、どうだった？→ポジティブな意見

P.Sちなみに、次の動画は
いかにJavaのバージョンアップと付き合うべきか 谷本 心
https://www.youtube.com/watch?v=DTzoPkdicJY

「Javaが有償化されたと思っている方いないですよね？」ってことで、OpenJDKの話を聞いてきた！

７月２５日に
JJUGナイトセミナー「JCP 20周年記念 / OpenJDKテイスティング」
https://jjug.doorkeeper.jp/events/94344
に行ってきた！時のメモ

---

■JCP２０周年記念！　浜本さん
・２０周年記念のデュークくんもいるよ
Twitter : @jcp_org #JCP20Years

・Javaは成長している
　１２００万の開発者
・Javaのフィロソフィー
・オープンな改革
　１９９５　Javaを開発
　１９９８　JCPが生まれる
　２００６　JavaSE,EEをオープン化
　２０１０　オラクル　SUNを買収
　２０１７　オープンJDKリリースサイクル短縮、JavaEEがEclipseへ
　→南極以外は７大陸使ってる

・JCPメンバー
　世界各国いろんな方々
　営利団体
　非営利団体＆オープンソース
　JUG→８０以上
　個人

・Oracle Code One→Java OneがOracle Code Oneになった
　JCPも参加：コミュニティーパーティ

・らっふるチケット

■これからのJDK/JVM　何を選ぶ？どう選ぶ？
　-Tasting OpenSDK Distribution
・諸注意
　ネットにアップしちゃいけないところあるよ
・自己紹介
・免責事項
・なぜマルチプラットフォーム対応のJDKに着目するか
　開発環境とテスト、本番環境でのJDK種類・バージョンによる差異を極力なくす
　リリース早い
　Linux distroに含まれるOpenJDK　古いかも→改元対応、Mystery meat

・その前に：Javaが有償化されたと思っている方いないですよね？
　Java自由化
　現在の主流はOpenJDK with HotSpot
　Java is Still Free

・OpenJDKの歴史
　JDK8まで　Oracle JDK　一強

・時代の変化
　８から１１で何が起こったのか
　　リリースモデルの変更：LTSとnon-LTS
　　共有ランタイムではなく、カスタムJREをアプリに組み込むことを推奨
　　　→まだ過渡期JDK14で配布やりやすくなる
　JDK８までとOpenJDKの違い
　　JavaFX→OpenJFX
　　モジュールシステム

　１１以降は
　　OpenJDKとOracleJDKが一緒になった
　　グラフィック→フォントが変わってる
　　→いろんなJDKがでてくる

・誰がOpenJDKをつくっているか
　Oracleさん（RedHatさんの存在感も出てきてるけど・・）
　アップデートはRedHatさん（OpenJDK）

・改元対応
　１３に入れて、そこから前のバージョンにバックポートしていく

・LTSリリースはOracle JDKとRedHat主導のOpenJDKで差異あり
　CPUとPSUがある
　
・OpenJDKProjectの動向把握用の基礎情報源
　JEP：JSRをけん引
　JBS：

・Oracle JDK
　Oracle Open JDK　LTSなし
　Redhat OpenJDK
　Azul zulu(ずーる）
　SAP machine
　BellSoft Liberica JDK
　Adopt Open JDK
　Amazon Corretto
　GraalVM
→Oracle OpenJDKを選ぶ人が多いが。LTSないよ

・判断軸
　サポート
　使いやすさ
　どこで運用するか

・コストをどう考えるか
　商用技術サポートは有料
　ITライフサイクルを通じて考える
　
（ここから２まい、SNS禁止）

・JDKディストリビューションにどう接していくか
　開発
　　複数のJDKの特徴を把握
　　新しい機能リリース

・Java/JVMエコシステムはこれまでと変わらず重要

・ブログ書くまでが勉強会

■OpenJDKカジュアルトーク
・OpenJDKを選ぶときの注意点を教えて！
１．独自機能が多いJDKを利用すべき
２．開発環境と運用環境で同じJDK
３．OS/ミドル・JDK
４．政治

１．独自機能が多いJDKを利用すべき
　利便性VSロックイン
　Java8でJFR？
　標準化される機能を使うのはあり

２．開発環境と運用環境で同じJDK
　グループ内で合わせたほうが、トラブル少ない
　RHEL→Mac版は？
　証明書：デフォルトのルートCAの違いとか

３．OS/ミドル・JDKの組み合わせ
　OS標準のJDK？
　違いは認識

４．政治的なことを気にすべき
　　AWS
　　民法の改正：動作保証

・とにかく、どのOpenJDKを選べば教えて
　REHL→RedhatのOpenJDK
　Amazon→Corretto
　Azure→Zulu
　バックポートではいってくる
　LTSが主流になっていくのかな？

■連絡
・来月は、OpenJDK作ってる人
・JJUG CCC Fall　１１月２３日
　　Call For Paper ８月２０日

JDK8でビルドできたものがJDK11だとできないとか、Open JDKの８に移行する話

OracleのJDKのリリースとサポートがあんなことになってしまい、
傷心モードになっているJavaのエンジニアの心の傷に、てらだよしおさんが、
塩を塗るようなデモをみてきた・・・

９月１９日、日本 GlassFish ユーザー会の

【JDK 11 リリース直前】各ベンダーのJDKリリースモデル特集！
https://glassfish.doorkeeper.jp/events/78762


を聞いてきたのでメモメモ

なお、表題の件、寺田さんのデモは最後のほうにでてくる。

---

■Azul System Your Long Term Java Partner
・会社紹介
・Zing：ガベージコネクション　レスポンスいいJVM
・Zulu：エンタープライズ、エンベディッド ARMに対応
・JavaSEアップデート＆ロードマップ
　６か月ごとにアップデート：
　Java8の公開アップデート収量は２０１９年１月
　非LTSリリースを使用するとJDK12から潜在的なリスクが生じる

・Zing　ヒープ８TBまでサポート
　ファルコンLLVMに基づく

・ユースケース

Q&A
・ZuluとZuluエンタープライズの違い
　　Zulu　ダウンロードはできる。それをしただけでは、サポート対象外
　　Zuluエンタープライズ　会社で使う場合
　　Zuluエンベディッド　なにかに組み込んで使う場合。契約が違う


■オープンソースで提供される第二のＪＶＭ
　ＯｐｅｎＪ９　ＶＭとＩＢＭ　Ｊａｖａについて

・ＯｐｅｎＪＤＫ／ＯｒａｃｌｅＪＤＫ

・ＩＢＭ　ＳＤＫ　ｆｏｒ　Ｊａｖａ　Ｔｅｃｈｎｏｒｏｇｙ
　Ｊ９ＶＭ
　サーバーでの使用に特化している
　　　クライアント、組み込みは対象外
　２０１７年までは単独提供なし
　２０１８年以降は、オープンソース提供

・ＩＢＭ　Ｊ９　ＶＭ
　ＩＢＭ内でクリーンルーム開発（Ｏｒａｃｌｅのライセンスに縛られない）
　Ｐｏｗｅｒ，大型汎用機でも使えるように開発

・特徴
　先進的な機能を率先
　　　クラス共有
　　　参照圧縮：６４ビット→ヒープが増える：３２ビットに圧縮（アラインメント８バイト→３ビット切り捨てられる）
　　　メトロノームＧＣ

　多彩な問題判別機能
　　　Ｊａｖａ　ＤＵＭＰ（Ｊａｖａｃｏｒｅ）

・ＯｐｅｎＪ９
　オープンソースに
　２段階
　　コアの部分　Ｅｃｌｉｐｓｅ　ＯＭＲ　Ｊａｖａだけでない汎用環境（ＣＯＢＯＬ，ＰＬ／Ｉ、Ｒｕｂｙ）
　　ＯＭＲの上にＪ９ＶＭをＯＳＳとして公開
　ＥＰＬとＡＰＬのデュアルライセンス

・２０１８年以降のＩＢＭ
　ＯｐｅｎＪＤＫが正になっている

　ＯｐｅｎＪＤＫ＋ＯｐｅｎＪ９
　ＩＢＭ　ＳＤＫ　ｆｏｒＪａｖａ

・ＯｐｅｎＪＤＫ＋ＯｐｅｎＪ９
　無償（ＯＳＳ）
　　入手方法（１）
　　　　Ａｄｏｐｔ　ＯｐｅｎＪＤＫ　https://adoptopenjdk.net

　　入手方法（２）　Ｄｏｃｋｅｒ　Ｈｕｂから
　　　　https://hub.docker.com/u/adoptopenjdk

・サポートも提供
　　ＩＢＭ　Ｓｕｐｐｏｒｔ　ｆｏｒ　Ｒｕｎｔｉｍｅ
　　　　年間５４８００円
　　→Ｏｒａｃｌｅ：クラウド環境の場合割高になるケースも
　障害サポート

・ＩＢＭ　ＳＤＫ　ｆｏｒ　Ｊａｖａ　Ｔｅｃｈｎｏｌｏｇｙ
　　ＡＳ４００にも対応、ＩＢＭ　ＪＣＥ（暗号化ライブラリ）
　　ソフトウェア同梱（Ｄｏｃｋｅｒ環境のみ単独も）
　　ＬＴＳを適用

・Dockerイメージの入手方法
　https://hub.docker.com/_/ibmjava/
　ライセンスＩＬＡＮ
　ＩＢＭの多くの製品がＤｏｃｋｅｒ環境→ＤＢ２とかも
　ＩＫＳ　ＩＢＭ　くーばねーてぃす　サービス
　プライベート、ベアメタル
　　ＩＣＰ

・ＯｐｅｎＪＤＫ　８　２０２２年までサポート
　Ｊａｖａ１１も終わり決定していないけど、長期間サポート

・ＩＢＭ　ＪａｖａＥＥ　アプリケーションサーバー
　ＷｅｂＳｐｈｅｒｅ：　Ｌｉｂｅｒｔｙランタイムは軽い
　　月額５５２４円
　Ｏｐｅｎ　Ｌｉｂｅｒｔｙというのがでている。

　Ｏｒａｃｌｅさんからパッチ提供を受けている

■”マイクロソフトの”寺田さんからのお話
・Ｊａｖａ１１のリリースを控えて
・自己紹介
・今後のＪａｖａに関して
　　今まで３年に１回
　　それがなぜ半年に変わったか？
　　　　ＩＴ業界：３年はすごく長い→価値のないものに変わっていった
　→Ｊａｖａの開発・提供もアジャイル的に
　Windows１０　１０の中でもアップデート
　　今の時代に合わせた話
・ＪＤＫ１０よりＤｏｃｋｅｒコンテナの対応強化
　　　ヒープメモリの割り当てを調整可能
・ＪＤＫ１１が今月正式リリース
　　ぜひ、早めに触って→結構大変！
　でも：
　　ＪＤＫ８だと動くけどＪＤＫ１１→エクセプションが出て落ちる
　今まで動いていたアプリが１１だと動かなくなる可能性がある
　あげていただきたいんです！
　早めにどっちの問題か、（製品側の問題か、自分たちの問題か）

・ＪＤＫ１１から削除されるパッケージ
　　ＸＭＬ系、CORBAが取り除かれる！
　自分が作ったアプリなら→依存関係を追加する

・なぜ１１へ　
　カスタムのスモールＪＤＫの作成：小さいオブジェクトのものが作れる
　　　→Ｄｏｃｋｅｒに組み込んで

■お知らせ
・ＲｅｄＨａｔのＯｐｅｎＪＤＫのサポート
　→ブログを読め
　タグで検索すれば、みつかるはずだ！

---

【所感】

表題の件は、１１になると、XML系などのライブラリが削除されるから。
寺田さんは１１にあげてくださいっていうけど、
これじゃ、怖くて上げられない。
OpenJDKに移行して、延命する？

Spring5の変更店などを聞いてきた！

５月２６日、JJUG CCC 2018 Springに行ってきた！ので、その内容をメモメモ

次に

Pivotal認定講師が解説！ReactiveだけじゃないSpring5&SpringBoot2新機能解説

をメモメモ

---

・このセッションについて
　リアクティブは対象外

・自己紹介

・会社紹介（これはスポンサーセッション）
　Core Spring(4日間）　８００ページ
　　ハンズオン　６月２８日

・１Coreの新機能
　　８ベース、
　　　９，１０，１１でも使える
　　ロギング

　８ベース
　　７未満では動かない
　JDK9,10でも動く（Tomcatはエラー出たけど）
　　開発プロセスでは９，１０でビルドして確認
　　モジュールシステム対応
　　Springの各jarは自動モジュール

　モジュールシステム対応
　　module-info.javaにrequireする必要あり

・JDKアップグレードの考慮天
　モジュールパスでなく、クラスパス
　バイトコードレベルはJava8
　　ASM5が９以上拒否
　　Spring5.0はJDK11でも動く予定

・ロギングがより便利に
　　spring-jcl
　　　commons Logging Bridge
　　　ログバック追加するだけ

　ビルド時のコンポーネントインデックス作成
　　spring-context-indexse
　　　コンポーネントスキャンの遅さを解消
　　　ビルド時のannotation Processer
　　ビルドすると。・・
　　　コンポーネントしないで
　　　インデックス利用の注意点：大きなプロジェクトでないと、意味ない
　　　　　→小さいと、コンポーネントのほうが早い

　@NonNull/@Nullableがつけられる→IDEで検知できる

・２Web
　HTTP2対応（サーブレット４．０）
　Bean Validation 2.0対応
　イミュータブルなフォーム

　Http2対応
　　Servlet4.0対応
　　　push Builderをコントローラーメソッドの引数で取得可能
　　　サーバーのHTTP2対応も必要：Tomcat

　　BeanValidation2.0
　　　新アノテーション追加
　　　DateTimeAPI
　　　コレクション要素の検証

　WebMvcConfigurerAdapterの非推奨

　イミュータブルなフォーム
　　　入力を変えられない→Setterいらないはず
　　　javacの-parametersもしくはデバッグ情報の有効化必要
　　　SpringBoot2.0+Mavenだとデフォルト
　　　　→まともに動かない。夏か秋の５．１に期待

　例外処理の便利機能

３．Data：破壊的変更有
　APIの変更
　SpringDataJDBC
　　　Optionalの利用
　　　メソッド名の変更
　→互換性ない

　SpringData JDBC（ベータ版）
　　JdbcTemplateを利用したSpringData
　　いくつかブログ出てる

４．セキュリティ
　OAuth2.0対応
　　従来はSoringSecurity OAuth2→ほかのライブラリにもあった
　　→本体で再実装
　OAuth2には、
　　　クライアント
　　　リソースサーバー
　　　認可サーバー
　の３つのサーバーがいるが、いまのところクライアントだけ
　　OpenID Connectにも対応
　リソースサーバは５．１→現時点ではSpring Security OAuth2.0
　認可サーバーはそのあと


　Delegating Password Encoder
　　パスワードエンコーダー：ハッシュ化する
　　じゅうらいは、平文ではいってしまう。
　→デフォルトが入るようになった
　　　　パスワードのプリフィックスを読んで、適切なパスワードエンコーダに処理を委譲する

５．テスト
　JUnit5対応
　　SpringEtention DI機能が使えるようになる
　　ParameterResolverを実装→テストメソッド引数でもDI可能

　便利なアノテーション
　　　Spring JUnit Config,webconfig

６．Boot
　２．０→５．０対応→Java8以上
　　　Date and Time API使える

　セキュリティの簡素化
　　　設定をJavaConfigに一本化
　　　ベーシック、フォーム認証が基本

　アクチュエーターの改良
　　デフォルトでURLぷれふぃっぅす　
　　デフォルトではindex,helpのみ公開

　エンドポイントの公開設定
　　有効かつ公開するとき

・その他；プロパティのリネーム
　spring boot properties migratorという便利ツール出ている
　　→ただし、ずっと使うものではない

Variable Handlesって、何？

５月２６日、JJUG CCC 2018 Springに行ってきた！ので、その内容をメモメモ

こんどは

■Java 9 Variable Handlesのイロハ（JavaSE基調講演）

をメモメモ

---

VarHandles

・自己紹介
・今日の内容
　　あちこち適当に
　　Javaのメモリモデル
　　MethodHandles
　　ごきぶりほいほい

・valhalla
　　ばはら＝天国に行って支配→ばりゅーたいぷすと発音似てるから
　　　Project ぱなま　Javaとねいてぃぶつなぐ・・

　　Value Types
　　ジェネリックの特殊化
　　VarHandles→これは出ている

・余談その1　まいこん
　PEEK　POKE　任意のメモリのアドレス値を取得・設定
　　→アセンブラ
　sun.misc.Unsafe
　　JDKの内部機能を直接呼び出す内部インターフェース
　　これを使ってメモリを操作できる

　　リフレクション、シリアライゼーションの利用から、CPUの使用率を見るため・・・まで
　　Sun以外の利用は想定外
　　RTじゃないとだめにした→破る方法見つかる

・Unsafe Demo!
　　Java10だとできない
　　すぐクラッシュする

・JDK→９からアクセスできなくなる
　　　メモリ管理　　　　valhalla
　　　メモリレイアウト panama
　　　メモリアクセス　　Arrays2.0
　
　　細かいメモリモデル　varHandles

。varHandles
　３つクリアすればいい
　　C11/C++11のメモリモデルに合わせる
　　j.u.cのatomicのような変数の変更もできる
　　sun.misc.UnsafeのメモリアクセスのAPIをリプレース

・C++メモリモデル
　Happenes-Before
Atomicメモリアクセス

　従来のJavaのメモリモデルより細かい
　　　データの単位ではなく、アクセスの単位で決める
　　　ほかの言語などで導入されている傾向がある

・Atomicのような変数
　　C++→３つのステージ　よみこみ　たして　書き出し
　　　→syncronizedを使う：重くなる

　　　ごきぶりほいほいはロックと似ている
　　　　　一回入ったら、もうでない

　　Atomicクラスを使う→オーバーヘッド高い
　　　　２つのオブジェクトになる：オーバーヘッド

　　unsafeを使う：Java9ではできない

・varHandle
　　methodHandleの知識は不可欠


・method Handle→ダビンチ　マシン　プロジェクト
　　メソッドハンドル→関数ポインタ
　　　　リフレクションよりパワフル
　　　　　　コールサイト：Javaレベルのリンキング

　　リフレクションAPIより効率的：代わりに呼ぶ
　　フィールドのアクセスができる（単なる関数ポインタではない）

　　MethodHandleの魅力
　　　　生成時のアクセスチェック：
　　　　シグニチャ・ポリフォーフィズム
　　　　　invokeExact
　　　　　javacで使うときに生成

　　varHandleで作る
　　　　　compareAndSet,読み込むにはget

・Atomic以外
　必要な時だけvolatileとしてアクセスできる

・まとめ
　varHandleは普段使わない
　methodHandleは役に立つ
unSafe使うな

＜HR>

【所感】

で、Variable Handlesって何？