どうすんのJava EE

はじめに

これはJava EE Advent Calendar 2016の11日目の記事です。

@kikutaro_さんがアドベントカレンダーをみんなに書いてもらえるよう頑張ってたのがチラッと見えたので、
まぁ僕も協力したいなぁという次第です。

突貫で雑に書いてしまったので変なところがあるかもしれませんがツッコミを入れて下さい。。

今回はConcurrency Utilities for Java EEというのを使ってみたネタにしようかと思ったのですが頓挫しました。NamimgExceptionでて…あぁって。

こんな風に出来るよ、みたいな話にしかならなかっただろうし。まぁ良いですよね。

@Dependent
public class EntryPointBean {

    @Inject
    ConcurrentBean concurrentBean;

    @Resource
    ManagedExecutorService executorService;

    public void exec() throws InterruptedException {
        FutureTask<Boolean> task = new FutureTask<>(() -> concurrentBean.listen());
        executorService.submit(task);
        executorService.awaitTermination(60L, TimeUnit.SECONDS);
    }
}

Payara Micro的なものを使ってるんですが
きっとこんな風にすれば解決はする風ですが。

public class EmbeddedPayara {

    public static void main(String[] args) throws BootstrapException {
        PayaraMicro.getInstance()
                .setAlternateDomainXML(new File("domain.xml"))  // ←ここでExecutorServiceを認識させてあげればきっと大丈夫
                .addDeployment("build/libs/Sandbox.war").bootStrap();
    }
}

参考

※去年も一昨年も書いてあったみたいだし良いですよね、テヘペロ

Java EEとSpringでも比較してJava EEの好きなところとか雑に書こうと思います。

Java EEのめんどくささ

JNDI

いつも思うのはJNDIがめんどうです。
@EJBとかが入った後はその面倒臭さもなくなっていったのだと認識していますが、
それ以前だとコンテナの境界ではJNDIを意識する必要があり、大体うまく行ってないと実行時例外になっていた。
(javax.naming.NamingException)
※って書くと主語がでかすぎる感もありますが

今は大体JNDIとおさらばですよね？おそらく。

多すぎ問題

あと、色々大杉漣ってことですよね。
間違えました、多すぎるかなぁと。

アノテーションの多さ

コレはJava EEに限った話じゃなく、Springでも言えることだと思います。
ただ、なんだかJava EEの方がゴチャゴチャしている感じはします。

CDI、EJB、JNDI、JSFあたりですかねぇ。僕もそれぞれの境界を考えると未だにスッキリと理解できていない感があります。

JAX-RSだけはなんか独立していてアノテーション部分も理解しやすい印象があります。
なんでなんだろう。

CDIは色んなコンテナを統一的に、
というかシームレスに使えるというのを目的にしてたと
昔JSR読んだ時の記憶だと認識してますが、たしかに便利になったけどごちゃ混ぜ感が増した感じもします。

実装コストは減ったけど、結局はCDIなりEJBなりJSFなりそれぞれ把握しておく必要なあるなぁみたいな感じです。

エンドポイントの実装方法の多さ

表現として適切かはわからないですが、
言いたいのは、
さぁ「Java EEを始めよう」となった時に何を選ぶか迷うなぁということです。
Servlet、JAX-RS、JSF、CDIとか、、、？(Servletはイマドキあんまり使いたくないですけど)

Springだと、僕が詳しくないってのもあると思うんですけどSpring MVCを使おうって割とスッとなるんですよね。

かといって、Java EEのMVCはJava EE 8から外すかもってなっててなんだか微妙な感じになってますね。

Java EEの良いところ

Javaの標準であること

JSRもあるし。RIもあるし。

使いこなせると便利

こういうのとか
http://d.hatena.ne.jp/nowokay/20131213

それぞれの機能が独立している感じがあるところ

逆に言うとバラバラということでもある気はしますけど、
好きな機能だけを選んで利用することが出来ることは良いかなぁと思います。

そこをフルスタックにJava EE使おうとかするから面倒になるんじゃないかみたいな。

案件ごとに自分の好きなもの組み合わせて最適解出すのが一番ですよね。

そういう意味ではMicro Profileの方針とかは自分の感覚にはあっているので好感持ています。
ただ、あの組織がどこまで頑張ってくれるかみたいなところはありますが。

Java EEサーバーには大体標準的に機能が入っているところ

でも実装依存とかハマっちゃうとめんどいですけどね。

Java EE はなんだかんだ好き

僕のJavaのサーバーサイドの開発はSpring系の案件はなくてJava EEばかりだったので、
面倒なところもいっぱい書きましたが、思い入れは強いです。

よく考えると、Springのつらみとかに出会ってないのでSpringがよく見える側面もあるし、
Java EEが辛く思える側面があるんだと思います。

Java EEに期待するのは早いリリースとマイルストーンリリースとかEAPとかですかねぇ。
一式揃えてドン！リリース！ってやんなくてもいいのになぁとは思います。

なので、Java EE GuardiansもMicro Profileも応援します。

O社の方々も応援しています。

参考
Java EE Guardians に対する現時点での最新情報の共有

Java EE を使うみなさんも応援しています。

まとめ

なんでこんなにアドベントカレンダーの登録少ないの！

Java EEは悪くないけど、使われ方と広め方とリリースサイクルが勿体無い気がします。
もっとゆるく組み合わせてサクッとJava EEで開発していきたい！

プログラマのはしくれダイアリー

cssmenu

2016/12/11