JSFのConversation Scopedを改めて試してみた

Java EE 7+JSF 2.2に行きたい所は山々なのだが、現在EE 5やら6から逃れられない全国のエンプラ開発現場の方々お疲れ様です。

さてJSF 2.2からはCDIにFlow Scopedという便利なものが付き、開始・終了が自動になったのであるが、現在EE 6の場合、そんなもの使えないのである。しょうがないので、どうしても類似のことがやりたければ、JSF 2.1でも動作するCDI+Conversation Scopedで誤魔化すしか無いのである。

Conversation Scopedは会話(Conversation)の開始・終了を明示的に行わないといけないので、結構めんどくさいということと、どうやれば綺麗に開始・終了できるのかイマイチ成功例がわからなかったのであるが、やっぱり避けられなくなったので改めて何パターンか試してみた。これが一番綺麗かな? というのが見つかったので、メモ代わりに紹介しておく。これが使いこなせれば、継承とアノテーションを駆使してCDI上でViewScopedと似たことがJSF 2.1でも実現できるかも知れない。いやーさすがにこれは無駄な努力かなぁ・・・

※ちなみに本例ではFaceletをJSF 2.2仕様で書いているが、2.1仕様であればjsfc=”h:inputText”とかで書き換える必要がある。

※JSFの基本的な作り方については、先週発表のスライドにまとめてあるので、そっちば参照してはいよ。
http://www.slideshare.net/iwasakihirofumi/java-ee-7-jsf-22

とりあえず、ポイントは一体どこで会話をスタートさせるのか、だ。JSFの場合、Phase Listenerで制御が一応できるので、Pre Render Viewで引っかけて強引に呼ぶ例をWebで見つけた。他にもGetterメソッドを作ってFaceletの先頭で表示させるついでに#{bean.property}で強引に呼び出す方法もあるが、こっちの方がスマートかも知れないし、タイミングは早いから安全ではある。f:eventを書くのめんどくさいけど。

注意点としては、開始と終了の書き方はほとんど固定で、下記のように書くしかなさそう、という点だ。また、間違って2回conversation.start()が呼ばれると、前に格納されていた値は全消去されてしまうので、あくまで最初に1回だけ呼んでやる必要がある。ここを間違えると「?」な挙動になるので注意するべしである。

遷移画面(3画面)

index.xhtml –> confirm.xhtml –> completed.xhtml

Backing Bean (CDI)

[java]
package com.mushagaeshi.jsftest;

import java.io.Serializable;
import javax.enterprise.context.Conversation;
import javax.enterprise.context.ConversationScoped;
import javax.faces.context.FacesContext;
import javax.inject.Inject;
import javax.inject.Named;

@Named
@ConversationScoped
public class ConversationBean implements Serializable {

private static final long serialVersionUID = 5792114893614101597L;

// 会話制御のためのオブジェクトを挿入する
@Inject
private Conversation conversation;

private String id;

private String password;

// 会話の開始メソッド。1頁目の先頭でf:eventにて強制的に呼び出す。
public void initConversation() {
// ポストバックでなくて、且つ、会話が開始されてなかったら開始する。
if (!FacesContext.getCurrentInstance().isPostback()
&& this.conversation.isTransient()) {
this.conversation.begin();
}
}

/**
* Creates a new instance of ConversationBean
*/
public ConversationBean() {
}

// 1画面目でボタンが押された際のメソッド。書かなくても行けるけど念のため。
public String clickNext() {
return "confirm?faces-redirect=true";
}

// 2画面目でボタンが押された際のメソッド。書かなくても行けるけど念のため。
public String clickConfirm() {
return "completed?faces-redirect=true";
}

// 3画面目でボタンが押された際のメソッド。会話を完了させて遷移する。これで状態が消える。
public String clickCompleted() {
// 会話が開始されてたら終了する。
if (!this.conversation.isTransient()) {
this.conversation.end();
}
return "index?faces-redirect=true";
}

public String getId() {
return id;
}

public void setId(String id) {
this.id = id;
}

public String getPassword() {
return password;
}

public void setPassword(String password) {
this.password = password;
}

}
[/java]

1画面目 (index.xhtml)

[html]
<?xml version=’1.0′ encoding=’UTF-8′ ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:jsf="http://xmlns.jcp.org/jsf"
xmlns:f="http://xmlns.jcp.org/jsf/core"
xmlns:h="http://xmlns.jcp.org/jsf/html">
<!– 強制的に会話開始をここで呼び出す –>
<f:event type="preRenderView" listener="#{conversationBean.initConversation()}"/>
<h:head>
<title>Facelet Title</title>
</h:head>
<h:body>
Hello from Facelets
<form jsf:id="form">
<input type="text" jsf:value="#{conversationBean.id}"/>
<input type="password" jsf:value="#{conversationBean.password}"/>
<input type="submit" jsf:action="#{conversationBean.clickNext()}" valuie="submit"/>
</form>
</h:body>
</html>
[/html]

2画面目 (confirm.xhtml)

[html]
<?xml version=’1.0′ encoding=’UTF-8′ ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:jsf="http://xmlns.jcp.org/jsf"
xmlns:h="http://xmlns.jcp.org/jsf/html">
<h:head>
<title>Facelet Title</title>
</h:head>
<h:body>
<h1>Confirm</h1>
<p>#{conversationBean.id}</p>
<p>#{conversationBean.password}</p>
<form jsf:id="form">
<input type="submit" jsf:action="#{conversationBean.clickConfirm()}" value="confirm"/>
</form>
</h:body>
</html>
[/html]

3画面目 (completed.xhtml)

[html]
<?xml version=’1.0′ encoding=’UTF-8′ ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:jsf="http://xmlns.jcp.org/jsf"
xmlns:h="http://xmlns.jcp.org/jsf/html">
<h:head>
<title>Facelet Title</title>
</h:head>
<h:body>
<h1>Completed</h1>
<p>Thank you, #{conversationBean.id}!</p>
<form jsf:id="form">
<input type="submit" jsf:action="#{conversationBean.clickCompleted()}" value="completed"/>
</form>
</h:body>
</html>
[/html]

実行結果

1画面目。入力してみる。
Screen Shot 2013-11-18 at 10.54.04 PM

2画面目。確認画面。ちゃんと入力された値が表示されている。
Screen Shot 2013-11-18 at 10.54.15 PM

3画面目。完了画面。まだ入力された値は生き残ってる。下のボタンを押すと会話が完了し値が消え、1画面目に戻る。
Screen Shot 2013-11-18 at 10.54.26 PM

戻った1画面目。Conversationが再度startされているので、値は消えて再度状態が開始されている(つまり空っぽ)。
Screen Shot 2013-11-18 at 10.54.36 PM

こんな感じですね。これであればBacking BeanJava EE 6でも動くし、EE 7が出てもそのまま持って行ける。ただ、繰り返しになるがHTML friendly style tagsだけは違うので、やっぱりEE 7への移行の際には画面に影響があるのである。返す返すも無念である。

Java EE座談会に出ます

すっかりBlog更新するのを億劫がって放置してしまったのであるが、明日東京のOracleに呼ばれ、Java EE 6の座談会に出ることになった。これで3回目である。福岡より飛行機で行きます。

最新のJavaを3時間で知る!Java解説セミナー (受付終了)
http://www.oracle.com/webapps/events/ns/EventsDetail.jsp?p_eventId=170343&src=7863984&src=7863984&Act=31

この座談会のセミナーは既に受け付け終了してしまっているのだが、講演の様子は後日記事になるらしく、そこで參照していただければと。私も告知を知らなかったので案内出來ませんでしたことよ(×_×)

ちなみに前回・前々回のものは既にWeb記事になっているので、そちらを参照して頂きたい。

「Java EE 6導入を推進するうえでのポイントと導入効果」(前回のもの)
http://builder.japan.zdnet.com/sp_oracle/weblogic_2013/35036674/

なお今回はJavaOne 2013に参加した事や、Java EE 7ネタを入れたので前回と少し違う方向性になるのではと思う。思うだけなのでどうなるかは不明であるのだが、大筋はあまり変わらない予定である。

GlassFishの商用サポートが打ち切られるという衝撃的な発表が先日行われたが、その後に控えている多くのJava EE商用製品のEE 7対応版がいよいよ来年より登場してくると考えている。そろそろ手を付けても罰は当たらない(投資が無駄にならない)頃かなと思っているのだが、どうだろうか。大量なので一朝一夕に追いかけられないため、徐々にキャッチアップしていくのが賢い戦略であろう、と思う次第である。

祝! Java EE 7リリース

Java EE 7が遂に出た。実に目出度い話である。

EEとはEnterprise Editionである。つまり「企業版」である。企業システムに携わらない方にはなんのこっちゃら分からん話の可能性大である。

Screen Shot 2013-06-12 at 21.33.18

Java EEの歴史は混乱の歴史でもあるが、出てもう13年にもなるのでさすがに記憶が曖昧になってきた。忘れないうちに憶えている分だけメモっておきたい。

EE以前はWeb側がApache JServのServletとかNetscape Application Server (NAS)、サーバーサイドはWebLogic のEJB (一時期Tengahって名前だった)が主流ぽいけど、結局なんかよくわからん仕様がゴロゴロ出てきて、MicrosoftもIISでJava動かす荒技(もはや名前すら覚えていない)とかまあ、今のNoSQLみたいな状況であった。移植性? ゼロに決まってるじゃん、という。これはさすがに嫌だった。正直嫌だった。

最初のJava EE、当時はリリース直前に”Java 2 Platform”とかトチ狂った事を言い始めたどこぞのSunという会社がそれの企業版、ということで”Java 2 Platform, Enterprise Edition”つまりJ2EEという、Core 2 Duoみたいな醜い名前で登場した。しかもバージョン1.2。Java 2の2じゃないのかよ、という突っ込みは至る所で誰もが言っていた。このちょい前にJ2EEがProjectナンチャラって名前の頃、呉越同舟の同盟関係だったはずのMicrosoftを訴訟で追い出すというアホな事もしでかして、ついでに100% Pure Javaとかオレンジジュースみたいな宣伝までやってた、今思うと、自分自身の反省も含めて滑稽だなと思う次第である。

(その後MicrosoftはJavaのコピーをC#として出すことになるのだが、まあお互いコピーしまくってるからそれはそれってことで)

さて当時だが、J2EEの実行環境がSunのWebサイト(JavaSoftではもう無くなってた)で1999年の12月だったかに出た。当時としてはえらくサイズがでかかったのでよく憶えている。ダウンロードはしたものの、さてどうやって作ればいいのかさっぱり分からんという悲しい状況であったことは良い想い出である。程なくして、それはWebLogicと同類のものである、と判明するわけであるが、その統一規格であると見切るまでは暫く時間が必要だった。なんせ日本語の情報がほぼゼロだったからである。あったのかもしれんが、少なくともペーペーの私の所には届かなかった。

それからすぐ、今は亡きDBマガジンという雑誌に、たぶん国内初のJ2EE特集記事を書く千載一遇のチャンスが訪れ、その後にJavaOneに參加して生ジョブズをMac OS XのJava Swing対応のプレゼンテーションを見たり、Sunの本社とAppleの本社とをハシゴする等々、なかなかゴージャスな経験をさせてもらいながら、J2EEが実は企業アプリケーションの統一規格であることを体験しながら理解していかせてもらったりしていた。

そこで理解したのは「統一規格、いいじゃん!!」なのである。移植性担保ってかなり重要なのだ。ISO/IEC 12207 Software Lifecycle Processに非機能要件として入ってるでしょ、と。なので、それ以降今に至るまで、私のEEに対する理解は「統一規格」がベースなのである。

ちなみに、であるが、当時からCORBA分散モデルを忠実に移植しただけのEJB Entity Beanはゴミ扱いなので、まともな技術者は誰ひとり使っていなかった。これは事実である。私を含め、みんなオリジナルのDAOを作って使っていた。それを知らない連中が真面目にEntity Beanを使って「裏切られた!!」と吠えまくるのであるが、ご愁傷様、としか言い様がないのである。

その後、やはり今は亡き「JavaWorld」に寄稿しつつ、その間に登場する事になるJ2EE 1.3、1.4とおつきあいすることになるのだが・・・ちなみに私はEntity Bean=ゴミ理論当時からJavaWorldの連載で散々書いていた記憶があるので、贖罪の意識はない。

J2EE 1.3の目玉はJSPがやっとまともに使えるようになった(JSTLが追加された)、とかMessage-Driven Beanが使えるようになった(初期はEvent-Driven Beanとか言っていた)とか、あんまり良い想い出がないというか、1.2とあんまり変わらんのである。

J2EE 1.4は、これまたあんまり変わらんが、JAXPが付いたとかJAX-RPCが付いたとかあるけど、でかいのがゴミのようなJSFが突っ込まれて大ブーイングを喰らった記念すべきバージョンである。ここで分かったような分かってないような連中がやれSpringだ何だと大騒ぎしてグチャグチャになる訳であるのだが、いま思い返せば只の「第二のJ2EE」を作り出しただけであり、今や作り替えるにも難易度が高すぎる壮大なレガシー(≒死に逝く旧システム)そのものになっていることは、見知らぬ後輩のためにも記しておかねばなるまい。

さて、私はここでJ2EEに見切りを付け、さっさと.NET Frameworkのプロモーション等に携わったりと、まあ要するに1.0、1.1、2.0辺りとC#およびVB.NETを駆使していろいろ作っていた。何故なら、J2EEは暫くダメだろうと直感したからである。Javaプログラマーの単価がナイアガラのように急降下したのもこの辺だ。昔はJavaできるってだけで引っ張りだこだったのだが・・・

お陰で食いっぱぐれることもなく今に至れるのであるが、その代償として、この時期のJ2EEが良くわからんのである。SpringもStruts 2も真面目にシステムを作ったことがない。そんなもん使うより、ASP.NETとADO.NETを駆使してエレガントにVisual Studio使った方が100倍マシだと思っていた。今でも思う。

Visual Studioが出てきたので記しておきたいが、JavaのIDE(昔はRADと言っていた)は長らく定番が無く、非常に困り果てた歴史でもある。私自身もViVi -> WinCafe -> JBuilder 1.0 -> Visual J++ -> ForteForJava -> VisualAge for Java -> JBuilder 3.5~6.0 -> Eclipse 1.0~2.0 -> NetBeans(今)という流浪の歴史である。細かいところは忘れた。なんかWebLogicとかOracleのもあったような気がする。今はNetBeansで満足しているため、他に移るつもりは今のところ無い。

対してVisual Studioは選択肢がこれしかないし、出来も恐ろしく良いので考える必要がない。Javaメインだった頃は実に羨ましかった。実際やってみて、納得した。良い。

さて、そろそろJavaに話を戻そう。そして現職になりコンサルティングする立場からコンサルティングを受ける立場になり、そしてJavaが戻ってきた。いや、戻したというのが正しいかもしれない。それは頭が割れそうになるくらい散々考えた末である。

そして戻ってきたときにはJ2EEはいつの間にかJava EEになっていた。5である。1.が抜けた。5だよ5。そしてテストとしていろいろ作ってみた。特にJSF -> EJB -> JPAの流れであれやこれや頑張ったのであるが、結論としては「これは厳しい」である。それまで使い込んできた.NETに比べて、圧倒的な力不足感と、半端ない「考えてなさ」感。JSFはだいぶマトモになった。が、ベースがJSPであることの恐ろしい制約がもうダメだと思った次第である。

そしてその5の末期であった。ダメだと思ったとたん、Java EE 6が出た。GlassFish 3.0も一緒に。

そのときの直感は「やっと標準機能だけで作れるようになったか!!」だ。

長らくEE仕様は1.2から1.3、1.4、5に至るまで、どれひとつとして標準機能だけでは満足にシステムを作れなかった。Web系フレームワークではStrutsが必須であった。他のでも良かったが、みんなStrutsを使っていた。あとはApache Jakarta Commons。今となっては無用な制約でしかなく狂ったような依存関係になる元凶としか見なせない対象だったりもするが、当時は救世主でもあった。

が、EE 6ではJSFのベースがFaceletになり、JAX-WSも付き、EJBにCDIが入り、JPAも良くなった。何より良かったのがNetBeansである。こいつとGlassFish 3とMavenとの連携はまさにVisual Studioに匹敵するか、もしくは部分的に凌駕しているものであった。いや過去形ではなく現在形である。

で、EE 6から本格的に復活した。昔のようにアホみたいに作りまくる生活に戻ったのである。違うのは、余所様のを作るのか、自社システムを作るのか、だけ。大きな違いではある。JavaOneにも10年振りに復帰した。今年も行く予定である。

ここでEE 7の登場である。中身を見ると、JSFの改善が著しい。というか最初からこれを出しておいてよ!! と絶叫しそうなくらい、改善が凄い。案の定文献が無い状況であるが、最初のJ2EE 1.2も同じ状況であったので、毎度の話である。むしろ現地JavaOneで昨年、事前に情報が得られただけ10倍マシである。Batch Frameworkとか謎仕様がてんこ盛りであるが、実際の企業システム構築で使えるようになるまで暫く時間があるため、その間に樣々試そうと思う次第である。

さて、NetBeans 7.3.1と一緒にダウンロードすることにしよう。プロジェクト作成の時には「Mavenプロジェクト > WAR」の一択であるため、そこだけ間違えなければ素敵なEE 7ライフが待っているはずである。

※画像のリンクがGlassFishになってなかったので修正しました。けど、NetBeansをダウンロードしたら一緒にインストールできるので、開発用途としてはまずNetBeansをダウンロードする方が賢いと思いますよ。

 

Javaは常に最新版で使いましょう

Javaのセキュリティ更新が出た。今回はJava 7u11である。

Java 7 (JRE)
http://java.com

Java Development Kit 7 (JDK)
http://www.oracle.com/technetwork/java/javase/downloads/index-jsp-138363.html

さてここからが本筋。上記で分かるとおり、Javaは開発キット(JDK)と実行環境(JRE)の二種構成である。これは確かJDK 1.1の頃から分岐したんじゃないかなと思う(確かJDK 1.0の頃は一緒だった)。JDKにはJREが含まれており、JDKのインストール時にJREが一緒にインストールされる、という構成になっている (Mac OS X版はインストールオプションが無いが)。

Javaというとひとくくりに上記ふたつが混在して認識されていると思うが、一般に悪さを引き起こすことが多いのがJRE側である。こいつはJava Appletをブラウザーで動作させるためのJava Plug-Inが入っているので、セキュリティホールが発見された場合、ここ経由で攻撃を食らう可能性が在る。Java Appletは他のプラグインに比較しても高機能であるため、これがデフォルトインストールでONになっているというのもどうよ、と思わなくもない (7u10辺りからOFFにする機能が追加されたが、それ以前だと標準でOFFにする機能すらなかった)。

JDK側は主に開発時およびサーバー側で使われていることが多い。仕様上、Java EE仕様サーバー(WebLogic, WebSphere, GlassFish, JBoss, Interstage, Tomcat等々、順不同)にはJREではなくJDKが必要(各種自動生成のためのコンパイル動作が必要であるため)なのだ。JDKはプラグインを持たないため直接の被害を受けにくいのであるが、当然ながら各種侵入攻撃を食らうような穴がたまに見つかることが多く、定期的な更新は必須である。

で、OracleはJavaのセキュリティホールが見つかるたびに定期的に修正版を出しているのであるが、遂にJava 6は2013年2月(今年2月)にEOL、つまりサポート切れである。恐らく最後に1回更新版が出てお仕舞い、になるだろうけど、とにかく更新されなくなる。つまり只で使いつづけたい場合、7に乗り換えないと行けないのだ。使いつづけたい場合はお金を払って延長サポートを受けることはできるのだが、たぶん高額である。(WebLogic等商用サーバーを買った場合は自動的に更新権が付いてくることが多いので要チェック)

当然ながら新規開発系はもとより、現在6以前で動いているシステムは7に変える必要がある。これは大変なことであるが、それは他の技術でも同じ話なので省略。

問題は新規開発系である。初学者が学習するJavaの本が7対応のものであればいいのだが、6以前のものを馬鹿正直に見て学ぶ場合、JDKがふるいものを自分のマシンにインストールして学習開始、することが多いのではないか。書籍側が「最新版入れてね」とか「そのうちサポート切れるからその場合は新しいのを入れてね」と気を利かせて書いてくれている場合はいいのだが、そんな気の利いたものはほとんど見たことが無い。クレームを恐れて「このバージョンで動作確認したから同じバージョンを当然ながらインストールしてね、察してね」みたいな感じで押しつけてはないだろうか。(全部を見た訳ではないのでアレではあるのだが)

この場合、納品物の完成度を担保するバージョンと、学習者が利用すべきバージョンは明らかに別物である。

Javaの場合、メジャーバージョン内の互換性は基本的に担保されている(そうじゃない場合(JDK 6u10)もたまにあるが)ので、そのバージョンの最新リビジョン「のみ」を原則として使うべきである。これはJDKもJREも同じ。特にJREなんぞは複数バージョン入れていてもいいことは基本的にない。常に最新版を使うべきである。

これが企業内システムの場合、特定バージョンで「寝かせる」事もこれまで恒常的に行われてきたのだが、JREの場合ブラウザーのプラグインにも結びついている関係上、当たり前の話だが更新しない訳にはいかないのである(OFFにできる機能が付いたのはついこないだ)。

これまでこのような当たり前の事実に目をつぶり、危険性を放置してきた文化が日本の暗黙文脈として容認されてきたんじゃないかと思う節が各所に見受けられたのだが、もっと厳密にバージョン管理したほうがいいんじゃないか、と思う次第である。

まあ、私はもはやコンサルでも何でもないので、単なるいち技術者からの提案である。とにかくJavaは常に最新版で使うべし。

※Java商用延長サポートを前提とした特殊な場合を除き、今からJDK 1.6(6), 1.5, 1.4, 1.3, 1.2, 1.1, 1.0の開発を始めるなんてのは以ての外である。JDK 7を使いましょう。

Oracle WebLogic Server 12c Forumキーパーソン座談会

さて先月の話になってしまうのだが、Oracleに呼ばれて久々に表舞台に出てみた。Java EE 6に(ようやく)対応してきたWebLogic 12cのリリースを記念してフォーラムがあったのだが、その最後にキーパーソン座談会と称して、斉藤さんと新野さん、お二方とOralceの伊藤さんで、Java EEが現場でどのように使われているのかを中心に会話してみた。詳しくは下記にいろいろ記載されているため、そちらをご覧頂きたい。

Java EE 6は企業システム開発の課題への “解”となるか? キーパーソン座談会【前編】
http://www.oracle.co.jp/campaign/weblogic/columns/column01/column17/java_ee_6.html

Java EE 6で変わる企業システム開発のパラダイムと開発者の役割 キーパーソン座談会【後編】
――「Oracle WebLogic Server 12c Forum」レポート
http://www.oracle.co.jp/campaign/weblogic/columns/column01/column17/java_ee_6_oracle_weblogic_server_12c_forum.html

私自身はWebLogic 3.5くらいの時期からずーっと使い続けているため「やっと対応かすげー遅いぞWebLogic」としか思わないのであるが、ここ十数年で市場はだいぶ変化し、WebLogic以外のJava EEサーバーがいろいろ出ては消え、を繰り返し、下馬評通りのラインナップとなって現在に至る、みたいな状況である事は間違いなかろう。

Java EEによるオープン化、というキーワードでSI会社が儲けられた時代は遙か7-8年くらい前に終了して、あとはどう効率的に使えるかどうか、という所に焦点が当たって久しい。特にEEのターゲットであるエンタープライズシステムにとっては、いかに効率的に単純にCRUDシステムが構築できるか、どう保守性を上げていくか、辺りがキーポイントであることは、現場にいる人間であればほぼ誰もが思っている事であろう。

それに対してSI会社側からは、そんな地味な内容では食いっぱぐれるだろボケ、と云わんばかりに、やれアスペクト指向だ、やれDIだインジェクションだ、やれEJBを外せだと本道から外れたところで主張し始め、Java EEが本来の姿とちょっと違う視点から攻撃されまくり、一方サーバーベンダーからはやれSOAだやれBPELだと、これまたちょいと焦点のぼけた製品を売りさばこうとして失敗し、という悲しい状況が続いた、というのがここ5年くらいの市場動向だろうか。

それに対してWebLogic 12cがようやく対応したJava EE 6仕様は、うまいことDI系の仕様を組み入れた上で、シンプルにすげー複雑なトランザクション処理をやり遂げる、という本来の旧J2EE仕様が目指してきたところに着地してきているものである。もはやStrutsもSpring FrameworkもAXIS2もHibernateもお払い箱でOKという、全方位フルラインナップがそろったのがEE6であり、EE5よりも徹底されている所が非常に好感が持てるような仕様となっている。

・・・というような事を喋った記憶があるのだが、どこまで伝わっているかは神のみぞ知る所である。相変わらず写真写りが悪いとか早口すぎて訳分からんとか云われそうであるが、それで商売してるわけでもない単なる現場の人間であるのでご容赦頂きたい。まあ、とにかくJava EE 6いいよ、現場で使いまくってるよ、という事が伝えたかったのである。