投稿

投稿日:

Jakarta EE 10 時代到来か？ WildFly 27, GlassFish 7, Payara 6

WildFly 27

WildFly 27 がリリースされた。

WildFly 27 では、JakartaEE 10 のみの対応となるので、今後は本格的に JakartaEE 10 の時代となりそう。

気になる JakartaEE 9.1 → 10 に伴う仕様の変更は、ざっくりいうと以下の図のような感じ。

CDI 関連が大幅変更。CDI Lite 4.0 （橙色）が新規に追加され、従来の CDI も 4.0 にアップデートされた。
ここらへんはわかりにくいところなので、『CDI と weld の関係』にまとめる予定。

他の仕様もかなりの部分がアップデート（青色）されている。

Servlet が 6.0 になっているのに恐怖を感じるが（笑）、そろそろ移行作業を開始しましょうかね。

GlassFish 7

GlassFish も JakartaEE 10 に対応した GlassFish 7 をリリースしている。

JakartaEE 10 環境、整ってきました。

ただし、

NOTE: The latest milestone version doesn’t provide Admin Console (GUI for administering the server). This will be fixed in the final version of GlassFish 7.

ということなので、現在配布されているバージョン（M8）はウェブアプリを GUI コンソール画面からデプロイすることはできない。

実際、起動後 loalhost:4848 にアクセスしても以下の画面から進まない。

どうしても使いたい場合は、github リポジトリからソースを取ってきて自力でビルドするしかないだろう。

ただし、ビルド産物は M7 で、これが本当に JakartaEE 10 に対応しているかどうかは不明。

Payara 6

Payara 6 はコミュニティ版も Jakarta EE 10 に対応しているらしい。

payara は気にはなっていたのだが、触ったのは今回が初めて。

しかし、GlassFish とまるっきり一緒だと思っていたのだが、コンソール画面も微妙にカスタマイズ入ってますね。

ブログの記事なども充実しており、乗り換えてもいいかも。

まとめ

JakartaEE 10 対応のアプリケーションサーバーも出揃ってきた。

特に payara に好印象を持った。

今回は、アプリケーションサーバーの紹介程度になってしまったので、JakartaEE 10 の仕様・使い方に関しては順次別記事にまとめていく予定。

 

 

 

投稿日:

M1/M2 Mac で eclipse を使う

M1 Mac で Java 開発用に eclipse を導入しようとあちこち調べたのだが、なんか筋悪の指南が多いのでメモ的にまとめ。

筋悪というのは、「eclipse の日本語版は Intel Mac 向けしかないので、それを使いましょう」的なものがほぼ全てだったから。

そんなに日本語化って重要？

多くのユーザーがいると思われる Pleiades All in One （いわゆる eclipse の日本語版）は、確かに現時点（2022/11）では Intel Mac 向けのバージョンしか上がってないのだが、公式サイトには既に M1/M2 向けのコンパイル済み eclipse がダウンロード可能になっているから。

ここで Download AArch64 を選べば、apple シリコン向けの eclipse のダウンロードが始まります。

思うに、Pleiades のは、ちょっとやり過ぎているところがあって、例えばマルチユーザー環境でこのバージョンを使うとたぶんアプリ自体が落ちます（少なくとも私の環境では落ちた）。

一方、こちらのバージョンは、JRE のバージョンやインストール先の指定もできるので、自分のホームにインストールしておけば、他のユーザーに迷惑をかけずに使えます。しかも arm ネイティブで。

Hello, eclipse

インストールが済んだら、まずはハロワ的なやつ。

今回は maven プロジェクトをチョイス。

今回は pom.xml の中身は手動で設定したが、多分、もっと上手いやり方もあるんだろう。

いつものコードを実装して run 。

コンソール出力に

Hello, eclipse

と出て、まずは一安心。

 

（続く）

 

投稿日:

Java 8 → 11, 17 あたりへの移行（migration）

以前に JavaEE → JakartaEE の移行に関する記事を書いたが、この手の情報が必要な人はおそらく Java8 → Java11 and/or Java17 の移行に関する情報も必要なんでは？と思う。

「Java8 migration」あたりで検索するとそれこそ山のように移行案内系の記事は出てくる。

なのだが、

Java 8 から Java 11 にコードを移行するための万能のソリューションはありません

『Java 8 から Java 11 への移行』

とあるように、移行作業は機械的にできるものではなさそう。

マイクロソフトの中の人が言うくらいだから、まあ、そういうことなんでしょう。

ここは「急がば回れ」式でいった方がいいところでしょうか。

ということで、Java8 以降で起こった Java 文法上の主要な変化。

module

Java9 から package の上位概念として module が導入された。

（続く）

 

投稿日:

JakartaEE 10 に備えよ -まずは 9.1 に移行しておくのが吉-

最近は、ウェブアプリの類は、意識して JakartaEE のお作法で書くようにしている。

といっても JavaEE の頃と大した違いがあるわけではない。

アイキャッチにあるように、これまで

javax.***

としていたところを

Jakarta.***

としているだけ。

これは、JakartaEE 9.1 では JavaEE の名前空間を変えただけ程度の変更に留まっているから。

だから、既存の JavaEE プロジェクトでも IDE などを使って javax → jakarta と「置換」すれば、ほぼ移行作業は完了する。

「ほぼ」と書いたのは、もちろん例外もあるから。

ここでハマったという人が多いようだが、

javax.sql.Datasource

は、このままでいい。

このパッケージは EE の仕様ではなくて SE の仕様なので、Jakarta に変更する必要はないから。

言われてみれば当たり前なのだが、脳死状態で移行していると気が付きにくいですね。

私も、小一時間ハマりましたw

JakartaEE 10 では、新機能も追加されるだろうから、今くらいの時期（ちなみにこれ書いているのは 2022/11）から移行しておいた方がいいでしょう。

JavaEE → JakartaEE 10 の移行は、一気にステージが二段階上がるようなものだから、まずはここで手がかりを作っておくのが吉、という読みです。

（参考）JakartaEE の XML ファイルのスキーマは、ここ参照。
9.1 → 10 で変化するところはけっこうある。
例えば web-app は 5.0 → 6.0 。

（追記）理屈の上では、現在（2022/12）使うべきは JakartaEE 10 なのだろうが、いくつかのアプリケーションサーバを試してみたが、hibernate 経由で clob を扱う際に不具合が出やすいという印象がある。
ちょっと慣れておく、アタリをつける程度の使用にとどめておいた方がいいかもしれない。

 

投稿日:

Java/Jakarta EE 対応サーバとは？

正式には、このページをご参照ください。

WildFly, GlassFish といった有名どころのほか、最近では中華系のアプリケーションサーバも Java/JkartaEE に対応しているようだ。

最近では payara （パイアラと読むらしいです。GlassFish の派生版）の話をたまに聞く。

ところで、たまに「特定の環境でビルドした war ファイルはどのアプリケーションサーバでも動くか？」という質問をうけるんですが、ほとんどの場合（特にシステムが複雑になればなるほど）、手直しなしでそのまま動くことはないです。

簡単なウェブアプリであっても設定などを微妙に変えないといけない場合がほとんどです。
『Mac で GlassFish を動かす』あたりをご参照ください。

また、各アプリケーションサーバによって Java/JakartaEE のモジュールの実装が違うため（例えば、JAX-RS の実装は GlassFish では jersey、WildFly では resteasy がデフォルト）、この場合は、結構な量の手直しが必要です。