Posted by & filed under いろいろ.


※本記事は最後まで読まないと誤解されかねない内容を含むため、Web広告に敵愾心を抱いてる方、プライバシやくざの方などは閲覧をご遠慮ください

http://hatenablog.com/js

Hatena.Diary.setupTrackとかHatena.Diary.trackEventNowとかあるのにnavigator.doNotTrackを見てないのが気になりました。

別にこのことを批判したいわけではありません。ぱっと見た感じ表示しているURLやreferrerなどの一般的なサーバーのアクセスログに記録される情報だったり、表示にかかった時間やスクリプトエラーなどのセンシティブでない情報を記録してるだけに見えます。Do Not Trackがこの手のものまで禁止してるかも知りません。

ただ今回の件ではてなブックマークボタンのトラッキングの件にふれてる人が見当たらなかったので一言いっておきたくなりました。minifyやコメント削除をするとこういったことのチェックが難しくなります。まあトラッキングだけなら通信見ればわかるし、minifyされててもClosure CompilerのADVANCEDモードで鍛えられたおかげである程度は読めるけど。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under 開発.


Java8のリリースが近づいています。Java8と言うとラムダ式のほうが有名ですが、多くの人がブログに書きそうなので、地味なDate/Time API(JSR-310)のほうを説明します。
ひとつだけラムダ式について言及しておくと、「ラムダ式は(関数型インターフェースの)オブジェクトを生成する」と説明している文章があったら、その文章は怪しいので疑いの目で読んでください。実際にはラムダ式はオブジェクト生成のコードにはならないからです(InvokeDynamicの呼び出しコードになります)。
後日つっこみを受けました。詳しくは別記事を参照してください。

さて、Date/Time API(JSR-310)の話です。
Javaの新しい日時処理(日付処理および時刻処理)のAPIです。結構、複雑です。過剰設計という批判もあるようです。自分自身、まだそこまでの判断はできません。自分が言えるのは、日時処理はそもそも本質的に複雑だという経験です。ざっと思いつくだけでも日時処理が複雑になる要因として次のような思いつきます。

  • そもそも一貫性がない(月ごとに日数が異なる)
  • 様々な基数(12進数、60進数、7進数?(曜日))
  • 何の法則もない祝日
  • 何の法則もない年号
  • 複雑さに輪をかけるタイムゾーン
  • 複雑さに輪をかけるうるう年
  • 複雑さに輪をかける夏時間

うんざりします。

Date/Time APIというフレームワークに載ってラクができるならそれに越したことはありません。

Date/Time APIの具体例の前に用語定義をします。

基本概念の用語定義

時刻 時間軸上のある瞬間の値。タイムゾーンと関係あり。タイムゾーン非依存の時刻をエポック値と定義(後述)
時間 時刻の差の値。タイムゾーンと無関係
日時 時刻を人間のために年月日時分秒で表現したもの
日付 時刻のうち年月日

可能な演算

時刻と時刻 減算(結果は時間)
時間と時間 加算と減算(結果は時間)
時刻と時間 加算と減算(結果は時刻)

コンピュータのための概念の用語定義

エポック値 エポック時刻(UTC1970年1月1日0時)からの経過時刻。タイムゾーンと無関係

人間のための概念の用語定義

UTC日時 時刻をUTCで表記した日時。エポック値から一意に決まるので相互変換可能
ローカル日時 時刻を特定のタイムゾーンで表記した日時。エポック値とタイムゾーンから決まる
ラベル日 タイムゾーンと無関係な日(例: 12月25日はクリスマス)。厳密には時刻ではないので時刻(UTC日時、ローカル日時)と演算してはいけない
期間 年月日時分秒で表記した時間(例: 1年、3ヶ月)
年号 西暦や和暦などの年表記
タイムゾーン 時差

Date/Time APIに話を戻します。
Date/Time APIでローカル日時を表現しようとすると、LocalDateTime、OffsetDateTime、ZonedDateTimeの3つのクラスの候補があります。どれを使えばいいか迷います。可能か否かで言うとどれでも可能だからです。
まず、LocalDateTimeを使う選択をした場合、別途、タイムゾーンを管理する必要があります。とは言え、普通、国際化したプログラムであれば、利用ユーザのプリファレンスなどでそのユーザのタイムゾーン設定があるはずです。そのタイムゾーン情報をユーザコンテキストで持っていれば、LocalDateTimeで充足します。
一方、OffsetDateTime、ZonedDateTimeのふたつは、それ自体がタイムゾーンを持ちます。OffsetDateTimeは、元々、SQLやXMLなどの外部処理用らしいので、それ限定で良いかと思います。
そうなると、LocalDateTimeとZonedDateTimeのどちらを使うかに話が集約されます。
個人的にはZonedDateTimeを推します。別途ユーザコンテキストなどに持つタイムゾーン情報と冗長管理になりますが、どうせタイムゾーンが一緒でないと意味のないローカル日時であれば一緒のクラスにするほうが安全だと思うからです。

java.timeパッケージのクラスの説明と利用指針

Instant 時刻。UTC日時に使える
Duration 時間
Period 期間
ZoneId タイムゾーン(名前ベース)
ZoneOffset タイムゾーン(値ベース)。あまり使う機会はないかも
LocalDate ラベル日として使える(年号取得やうるう年判定に使える)
LocalTime タイムゾーンを気にしない単なる時刻処理クラスとして使える
LocalDateTime 通常の日時に使うのは危険(タイムゾーンなしの時刻はバグの元)。ラベル時刻(全世界同時刻)のためには使える
ZonedDateTime タイムゾーンありの日時。通常の日時に使う
OffsetTime 簡易版タイムゾーンありの時刻。外部処理用(SQLやXML)
OffsetDateTime 簡易版タイムゾーンありの日時。外部処理用(SQLやXML)

その他パッケージのクラスの説明

TemporalAdjusters 強力な日付演算(月末、直近の日曜日など)ユーティリティ
JapaneseChronology 和暦

現在時刻エポック値の表現と取得方法

数値 System.currentTimeMillis()やSystem.nanoTime()
Instant Instant.now()

実装方針

時刻の扱い

  • データベース上はエポック値を格納(JDBCではjava.sql.Dateを経由。ミリ秒以下が欲しければjava.sql.Timestamp経由)
  • コード上はjava.time.ZonedDataTimeで扱う。ただしUTC日時とローカル日時の区別は開発者の責任

時間の扱い

  • データベース上は数値として格納(JDBCではintを経由)
  • コード上はjava.time.Durationもしくは数値で扱う

ラベル日の扱い

  • データベース上は数値(20140101のような数値)として格納(JDBCではStringもしくはintを経由。タイムゾーン非依存にするため)
  • コード上はjava.time.LocalDateで扱う

JDBCまわりの対応は未整備です。java.sql.ResultSetもjava.sql.PreparedStatementもDate/Time APIにまだ対応していません。Object型でカラム値を読み書きするメソッドは追加されていますが、気持ち悪い上に動くのか不明(JDBCドライバ次第)なので、現状は旧来のjava.util.Dateを経由して変換する必要がありそうです。

以下にサンプルコードを載せます。コメントの想定例を見ながら読んでください。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under いろいろ.


アリエルってJavaの会社だよね。でもね、Javaだけの会社じゃないんだよ。大部分のコードはJavaで書かれているのは事実だけど、それだけじゃないんだよ。ツールとか製品の周辺部分はRubyだったり、Pythonだったりするんだよ。まだ、一部Perlが残っているんだけど、Perlはだんだん駆逐されていっているんだよ。テスト関係のコードは、とってもRubyで書かれているんだよ。

昔からあるプロダクトはJavaなんだけど、新し目の製品は実はJavaじゃないんだよ。Goなんだよ。なんでGoにしたのかは、

  1. 1.1がでて、安定していそうだから
  2. コンパイルが速いのでコードを書いてデバッグするまでのサイクルが短くできるから
  3. それでいて実行速度が速いから
  4. 最低限必要そうなライブラリは揃っているから
  5. 文法的なところとか、その割り切りが、一部の人にフィットしたから
  6. マイナー路線
  7. 並列性とか、なんとか

無理やり7つも上げてみたよ。でも、横から聞いていると、大谷さんが「Javaは飽きたので、Go好きだから製品で使ってみたいからGoにして!」って言っていたような…。結局、好き嫌いで決まっちゃったみたいだよ。

 

面白そうだからという理由だけでGoで始めちゃったので、Goを書きたい人は来てね。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under いろいろ.


Server-Sent Eventsを使うとサーバーからクライアントにデータをPUSHすることができます。使い方はこの辺を参考にしてください。

node.js + expressでサーバー側を実装するとこんな感じになると思います。

この+ data +部分、data変数が任意の文字列の場合簡単にインジェクションができてしまいます。では安全にdata変数を出力するにはどうすればいいかを考えてみました。

改行をなんとかする

CRLFがterminatorなのでdata変数に改行があると当然おかしくなります。

対応方法として、生文字列を渡したいのであればssl.jsのようにCRLFでsplitしてdataフィールドを複数書けばよいでしょう。またJavaScriptの場合文字列をvalidなJSONとして扱えるため、とりあえずJSONにする手も使えます。(ECMA-262JSONText -> JSONValue -> JSONStringRFC 4627の場合はobjectとarrayのみJSON-text = object / array

HTMLタグをなんとかする

Server-Sent EventsのContent-Typeはtext/event-streamなので、このURLをまともなブラウザで直接表示した場合ファイルダウンロードになるなど、少なくともHTMLとして開かれることはありません。しかし以前からはせがわようすけさんらが警鐘を鳴らしているIEのContent-Type無視によってHTMLとして開かれることがあります。

例えば以下のようなサーバーにIE7で/event/a.htmlを開くとalertが表示されました。

IE8以降であればnosniffでHTMLへの昇格を防げますが、IE7以下の対策をするとしたらJSONにした上で「/」「<」「>」「+」をエスケープするくらいでしょうか。XMLHttpRequestであれば独自のリクエストヘッダをつけたりPOSTで投げたりといった方法もありますが、EventSourceはURLの指定くらいしかできないので使えません。あとscriptタグで読み込んだときにどうなるんでしょう?JSONにしてあれば大した問題にはならなそうですが。

まあServer-Sent Events使うようなサイトをIE7で見るやつなんていねーよ、って言われたらそれまでですが。

検証スクリプト


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under いろいろ.


採用のためのインタビュー記事が@ITに載りました。

兼務しているワークスアプリケーションズのゲストフェローの立場でインタビューを受けましたが、アリエルとしても通用する内容のつもりです。

タイトルの「エンタープライズ領域こそ面白い」は少し過剰な表現で、真意は「エンタープライズ領域も面白い」です。

記事のために敢えて極端に振った表現をしました。エンタープライズという用語が、つまらないものだと思われすぎている気がするからです。実際のところ、サービスが企業向けだろうと一般ユーザ向けだろうと、基盤となる部分できちんと技術的なことができる職場であれば、どちらも同じぐらいに面白く、どちらも同じぐらい良い経験が積めると思います。作った技術の上で提供されるサービスが誰を向いているかは、単純に人それぞれの嗜好や価値観であって、その時々の直感で選べばよいかと思います。

むしろ技術者の経験として大きな違いを生むのは、コードを書き捨てる職場か、コードを資産として残す職場かの違いだと思います。

コードを書き捨てる環境では、抽象層を積み上げるという感覚がなかなか育ちません。この感覚がないと、コードをたくさん書いても、単に誰かの作った抽象層の上で何かした経験、もっと具体的に言うとAPIを覚えて組み合わせで何かする経験が増えるだけしかできません。技術者の初期のキャリアでは意味がありますが、これだけしか経験していないと辛いと思います。もっとも、こういう職場であっても、新しい言語や新しいフレームワークを試す土壌があるなら、筋の良い人は、多くの利用経験から類似性を見つけて抽象化できます。自分なりにオープンソースなどで同じ経験を積んでもいいでしょう。

最悪パターンは、コードを書き捨てる環境で、かつ言語もフレームワークも固定化された環境です。頭の良い人はバッドノウハウの権威になって職場で重宝されます。使っている技術がメインストリームである間は、転職にも苦労しません。しかし、ある技術がメインストリームである期間は誰にも読めません。技術者にとってリスクが高いキャリアの積み方です。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under いろいろ.


川野さんがアリエルをさりました。まあ、彼がどこで何をしようがいいですが、昨日は川野さんの最終出社日。無事、みんなの投票で決まったプレゼント『アジャストパワーウエイトベスト10KG、通称、防弾チョッキ』を渡すことができました。川野さんも喜んでくれたようです。

 

プレゼントを開け、早速着替えてみた川野さん

Photo 2013-11-05 15 23 46

 

そのままトレーニングを始める川野さん

Photo 2013-11-05 15 24 07Photo 2013-11-05 15 24 47

 

ひとしきりトレーニングに励んだ後、川野さんからもプレゼントがありました。まさかりを片手にお菓子を渡そうとするも、怖がられてしまい渡せない川野さん。最終的にとまるんるんに切りかかっていました。

 

感情を爆発させる川野さん

Photo 2013-11-05 15 34 19

 

おまけ

image

 


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under .


Software Design 2013年11月号のEmacs特集が、業界で話題沸騰です。

わずか1ページのコラムですが寄稿しました。

目次は技術評論社のサイトで見られます。

執筆の時間が取れなかったのでコラムでお茶を濁しました。とは言え、今の日本で、Emacs特集にアリエルの寄稿がないと雑誌の売上に影響を与えかねません。なので、社内の若きエース高石さんに記事を書いてもらいました。

まだ献本にまともに目を通していません。雑誌には執筆者全員の.emacs.elの行数が載っているはずです。正直に.emacs.elの行数を申告しましたが、もしかしたら自分が最短行数かもしれません。長ければいいってものではないですが、ひとりだけ極端に短かったら少々恥ずかしいですね。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under 勉強会, 開発.


JavaOne 2013 サンフランシスコ報告会 Tokyoで「Java EE のアップデート」の発表をしてきました。

使った発表資料を公開します。

最近はs5でプレゼンファイルを作るのが常態化しています。Emacsだけで作れて楽だからです。しかしs5の見栄えには満足していません。きれいなテーマを探しましたが見つからなかったので、結局、いつもの見栄えのプレゼンでした。

テキストで書けて、HTMLもしくはPDFで出力できて、それなりに見栄えが良いプレゼン作成ツールがあれば乗り換えたいものです。

ダウンロード版(HTMLファイルをWebブラウザで開いてください):
javaone2013.tar.gz


JavaOne2013 サンフランシスコ報告会 Tokyo

井上誠一郎

アリエルネットワーク CTO

ワークスアプリケーションズ ゲストフェロー

自己紹介

名前

  • 井上誠一郎

主な著書

  • 「パーフェクトJava」
  • 「パーフェクトJavaScript」

ブログ

  • 「ありえるえりあ」

JavaOne参加経験

  • 今年が3度目の参加(2010年、2012年、2013年)
[any material that should appear in print but not on the slide]

今日のお題

  • Java EEのアップデート
[any material that should appear in print but not on the slide]

アジェンダ

  • 予備知識
  • JavaOne2013のJava EE概論
  • Java EEセッションのピックアップ
  • Java EEを取り巻く状況
[any material that should appear in print but not on the slide]

Java EEの認知度?

  • Java EEの最新バージョン?
  • CDI?
  • JPA?
  • JAX-RS?
[any material that should appear in print but not on the slide]

Java EEの最新バージョン

  • 最新バージョンはJava EE 7
  • 目玉
    • WebSocket対応
    • JSON標準API
    • Java Batch
    • Concurrency Utilities
[any material that should appear in print but not on the slide]

CDI

  • CDI: Contexts and Dependency Injection
  • DI(Dependency Injection)の標準規格
  • Java EE 6で登場
  • 今やJava EEの中心規格(主役はEJBからCDIへ)
  • Java EE 7のCDI 1.1で beans.xml が不要に
[any material that should appear in print but not on the slide]

JPA

  • JPA: Java Persistence API
  • ORM(O/Rマッパー)の標準規格
  • Hibernateも今ではJPA実装のひとつ
  • Hibernateはじめ、JPA実装は各々それなりに独自拡張を持つのが実状
  • Java EE 7のJPA 2.1で、SQLのDDL生成やストアドプロシジャに対応
  • NoSQL系への対応は話題のみ
[any material that should appear in print but not on the slide]

JAX-RS

  • RESTfulなURLルーティングやHTTP処理の標準規格
  • アノテーションでURLとクラスやメソッドを対応づける
  • Java EE 7のJAX-RS 2.0で非同期APIとクライアントAPI追加
[any material that should appear in print but not on the slide]

アジェンダ

  • 予備知識
  • JavaOne2013のJava EE概論
  • Java EEセッションのピックアップ
  • Java EEを取り巻く状況
[any material that should appear in print but not on the slide]

JavaOne2013のJava EE: キーノートのトピック

  • Java EE 7リリース(2013年6月)
  • Project Avatarのオープンソース化
  • IBMのJava CTO「IaaS基盤にOpenStack、PaaS基盤にCloud Foundry」
    • 2013年7月のリリース記事: IBMとPivotal社が協業「WebSphere(Liberty) on the Cloud Foundry Platform」
[any material that should appear in print but not on the slide]

JavaOne2013のJava EE: キーノートのトピック(裏)

  • 全体的に盛り上がらず
  • Java EEの扱いが軽い印象
  • Java MEにスポットライト
[any material that should appear in print but not on the slide]

JavaOne2013のJava EEセッション: カテゴリ

  • Client and Embedded Development with JavaFX
  • Core Java Platform
  • Edge Computing with Java in Embedded, Smart Card, and IoT Applications
  • Emerging Languages on the Java Virtual Machine
  • Java Development Tools and Techniques
  • Java EE Web Profile and Platform Technologies
  • Java Web Services and the Cloud
  • Securing Java
[any material that should appear in print but not on the slide]

JavaOne2013のJava EEセッション カテゴリごとのセッション数

  • カテゴリ「Java EE Web Profile and Platform Technologies」: 131セッション
  • カテゴリ「Java Web Services and the Cloud」: 83セッション
[any material that should appear in print but not on the slide]

JavaOneセッション数で勢いを測る(Java EE7の新顔編)

メイントピックのセッションに限定

  • Java API for WebSocket: 6
  • Java Batch: 2
  • Java API for JSON Processing: 6
  • Concurrency Utilities: 2
[any material that should appear in print but not on the slide]

JavaOneセッション数で勢いを測る(Java EE7で大きく変更編)

メイントピックのセッションに限定

  • JAX-RS: 9
  • JTA: 1
  • EL(Expression Language): 2
  • JMS: 4
[any material that should appear in print but not on the slide]

JavaOneセッション数で勢いを測る(定番編)

メイントピックのセッションに限定

  • CDI: 4
  • JPA: 7
  • EJB: 1
  • JSF: 4
[any material that should appear in print but not on the slide]

JavaOneセッション数で勢いを測る(Java EEコンテナ編)

単なる検索結果(メイントピックとは限らない)

  • GlassFish: 16
  • TomEE: 2
  • WebLogic: 4
  • JBoss: 7
  • WildFly: 0
  • WebSphere: 2
[any material that should appear in print but not on the slide]

JavaOneセッション数で勢いを測る(実装編)

単なる検索結果(メイントピックとは限らない)

  • Grizzly: 3
  • Jersey: 7
  • Weld: 0
[any material that should appear in print but not on the slide]

JavaOneセッション数で勢いを測る(JPA実装編)

単なる検索結果(メイントピックとは限らない)

  • Hibernate: 4
  • EclipseLink: 5
  • OpenJPA: 2
[any material that should appear in print but not on the slide]

JavaOneセッション数で勢いを測る(フレームワーク編)

メイントピックのセッションに限定

  • Spring Framework: 3
  • Play Framework: 3
  • Ninja Framework: 0
  • Grails: 3
[any material that should appear in print but not on the slide]

JavaOneセッション数で勢いを測る(NoSQL編)

単なる検索結果(メイントピックとは限らない)

  • MongoDB: 7
  • CouchBase/CouchDB: 2
  • HBase: 2
  • Cassandra: 2
  • Riak: 0
  • Redis: 1
  • Neo4j: 2
[any material that should appear in print but not on the slide]

JavaOneセッション数で勢いを測る(NewSQL編)

単なる検索結果(メイントピックとは限らない)

  • VoltDB: 1
  • NuoDB: 1
[any material that should appear in print but not on the slide]

JavaOneセッション数で勢いを測る(PaaS基盤編)

単なる検索結果(メイントピックとは限らない)

  • Cloud Foundry: 3
  • OpenShift: 1
[any material that should appear in print but not on the slide]

JavaOneセッション数で勢いを測る(PaaS編)

単なる検索結果(メイントピックとは限らない)

  • Google App Engine: 2
  • Amazon Beanstalk: 2
  • Heroku: 1
  • Jelastic: 2
  • CloudBees: 2
  • Windows Azure: 2
[any material that should appear in print but not on the slide]

JavaOneセッション数で勢いを測る(サーチエンジン編)

単なる検索結果(メイントピックとは限らない)

  • Lucene: 1
  • Solr: 1
  • ElasticSearch: 1
[any material that should appear in print but not on the slide]

JavaOneセッション数で勢いを測る(データ連携編)

単なる検索結果(メイントピックとは限らない)

  • Apache Camel: 4
  • Spring Integration: 3
  • Mule: 1
[any material that should appear in print but not on the slide]

アジェンダ

  • 予備知識
  • JavaOne2013のJava EE概論
  • Java EEセッションのピックアップ
  • Java EEを取り巻く状況
[any material that should appear in print but not on the slide]

「Java Caching (JSR 107): The State of the Union [CON10175]」

  • 12年かけてJCacheのスペックがまとまりそう
  • 今年の12月にスペック確定(予定)
  • javax.cacheパッケージのAPI(プログラマブルAPIとアノテーションAPI)
  • アノテーションはJava EE 8とSpring4で採用予定
  • 実装: Ehcache、Oracle Coherence
[any material that should appear in print but not on the slide]

「What’s New in Java Transaction Processing [BOF3433]」

  • JTAが1.1から1.2にバージョンアップ
  • 10年ぶりのバージョンアップ
  • 宣言的トランザクション
  • @Transactional (クラスもしくはメソッドに書ける)
  • CMT(コンテナによるトランザクション管理)がEJBの専売特許でなくなる
  • CDI管理のBeanをCMT可能
  • 要はSpringの@Transactional
  • EJBの立場は? (後述)
[any material that should appear in print but not on the slide]

「JSR 356: Inside the Java WebSocket API [CON3436]」

  • 実装: https://tyrus.java.net
  • プログラマブルAPIとアノテーションAPIの両方あり
  • 同期処理APIと非同期処理APIの両方あり
[any material that should appear in print but not on the slide]

WebSocket プログラマブルAPIコード例

[any material that should appear in print but not on the slide]

WebSocket アノテーションAPIコード例

[any material that should appear in print but not on the slide]

「Jersey 2 MVC in Action [BOF5548]」

  • JerseyはJAX-RS規格の実装
  • JAX-RS自体はMVCフレームワークではない
  • Java EEのMVCフレームワークはJSFなので、JAX-RSがそこに踏み込めない
  • Jerseyは独自拡張でMVCフレームワークを提供
  • Jersey MVCはSpring MVCと同じアーキテクチャ
  • ビュー処理のサポートテンプレートエンジン: JSP、Freemarker、Mustache
[any material that should appear in print but not on the slide]

「Decompose That WAR! Architecting for Adaptability, Scalability, and Deployability [CON2328]」

  • 巨大なwarをどう分割するか
  • 巨大なwarの問題点:
    • 開発速度の低下
    • IDEやコンテナへの高負荷
[any material that should appear in print but not on the slide]

「Decompose That WAR! Architecting for Adaptability, Scalability, and Deployability [CON2328]」(cont.)

  • war分割しすぎの問題点:
    • 実行処理低下
    • 無駄な通信
    • システム全体の理解が困難
    • warにまたがったトランザクション
    • warにまたがる機能
[any material that should appear in print but not on the slide]

「Decompose That WAR! Architecting for Adaptability, Scalability, and Deployability [CON2328]」(cont.)

  • war間の通信: 非同期のメッセージキューを利用
  • Netflix社のAPI Gatewayパターン:
    • 複数RESTサービスの前に配置
    • 後方の各RESTのレスポンスを集約
    • REST呼び出しは並列かつ非同期処理
    • RESTエラー時はキャッシュデータかデフォルトデータで代用
[any material that should appear in print but not on the slide]

[any material that should appear in print but not on the slide]

「The Spring Update [CON2439]」

  • Spring Source社からPivotal社へ
  • http://spring.io
  • ソースコード管理がGitHub
  • Spring 4.0は、Java8およびJava EE 8対応
  • SpringのJdbcTemplateなどはJava8のLambdaと相性が良い
  • WebSocketやJava BatchでJava EEと協力関係
[any material that should appear in print but not on the slide]

「The Spring Update [CON2439]」(cont.)

  • Spring DataでNoSQL(MongoDB、Redis、Neo4j)やSolrに対応
  • Spring for Hadoop
  • Spring XD (ストリームデータ処理)
  • WebSocket上にSTOMP(Simple (or Streaming) Text-Oriented Messaging Protocol)
  • Spring Rooは…?
[any material that should appear in print but not on the slide]

アジェンダ

  • 予備知識
  • JavaOne2013のJava EE概論
  • Java EEセッションのピックアップ
  • Java EEを取り巻く状況
[any material that should appear in print but not on the slide]

Java EEの歴史

[any material that should appear in print but not on the slide]

J2EE

[any material that should appear in print but not on the slide]

Java EE(Web層の進化)

[any material that should appear in print but not on the slide]

Java EE以降のEJB

[any material that should appear in print but not on the slide]

Java EE 7のEJB

[any material that should appear in print but not on the slide]

Java EE 8以降の世界?

[any material that should appear in print but not on the slide]

Java EE 8?

  • Java EE 5は大変革(Java SE 5と同様のrevolution)
  • Java EE 6と7は大きな変革は無し(Java SE 6,7と同様のevolution)
  • Java EE 8は? (Java SE 8はrevolution)
[any material that should appear in print but not on the slide]

まとめ

  • Java EE 7は順調に発展
  • まだJava EE 7対応コンテナがGlassFishのみなので目立つ事例なし
  • Java EE 8の姿は見えない(クラウド対応のキーワードのみ)
  • JSFとEJBが死んだらrevolution
[any material that should appear in print but not on the slide]

関連文書:

  • 関連文書は見つからんがな

Posted by & filed under 勉強会, 開発.


月曜日(2013年9月23日)に聞いた技術セッションのレポートを書きます。

Java Caching (JSR 107): The State of the Union [CON10175]

事前予約していませんでしたが、当日の朝、飛び入りで参加しました。裏番組に人気の”The Road to Lambda”があったせいか、会場はそこそこ空いていました。

スピーカはOracle社の人とTerracotta社のふたりでした。

12年かかって、ようやくJava Caching(JCache)のAPIが標準化されそうです。スペックのリリース予定日は2013年12月12日です。

スペックや参照実装はGitHubから取得できます。JCacheのオープンソース参照実装としてはEhcacheが有名です。

キャッシュはいわば一種のKVSなので、JCacheのAPIは、原則、コレクションフレームワークのMapに似ています。ただ、JCacheはMapとは違う、という点がセッションの冒頭で強調されました。

JCache APIの特徴は次のとおりです(プレゼン資料から抜粋)。

  • java.util.ConcurrentMap like API
  • Atomic Operations
  • Lock-Free
  • Read-Through / Write-Through Integration Support
  • Cache Event Listeners
  • Fully Generic API = type-safety
  • Statistics
  • Annotations (for frameworks and containers)
  • Store-By-Value semantics (optional store-by-reference)

Map風のプログラマブルAPI以外に、JCacheは下記のアノテーションを定義しています。これらのアノテーションは今後のJava EE8とSpring4に含まれる予定です(Spring3は異なるキャッシュアノテーションを既に提供しています)。

  • @CacheResult
  • @CachePut
  • @CacheRemove
  • @CacheRemoveAll

個人的にはキャッシュ制御をアノテーションで宣言的に書けるのか、やや疑問を持っています。と言うのも、多くの場合、キャッシュを破棄してよいタイミングの制御に、条件判定などの業務ロジックがからみそうだからです。

セッションの最後に商用製品のJCache対応予定の話がありました。スピーカふたりの会社、それぞれTerracotta社のBigMemory、Oracle社のCoherenceがJCacheに対応予定ということです。

Jump-starting Lambda Programming [TUT3877]

今回のJavaOneで数多くあったJava8のLambdaのセッションのひとつです。

Oracle社のStuart Marks氏がスピーカでした。JavaOneのLambda関係のセッションで人気のあるのはBrian Goetz氏のセッションです。Goetz氏は著名なのでありがたみがあります。しかし、いかんせんGoetzは早口で英語が聞き取りづらいです。客観的に見て、Lambdaの概要を知りたいなら、Stuart Marks氏のセッションのほうがお勧めだと思います。

全体的な構成は下記のとおりです。この構成は秀逸です。これらを理解すれば、Java8のLambdaを理解したと言えると思います。

  • Lambda
  • Streams API
  • Parallelism
  • Reduction
  • Collectors

一般的なプログラミングにおける抽象化の話から始まりました。

値パラメータによる抽象化、クエリ言語による抽象化、振る舞いのパラメータ化による抽象化と話が進み、振る舞いを簡易に記述できるfunctional interface、つまりJava8で言うところのLambdaに話をつなげます。自分がLambdaを他人に説明するとしても、この順序になるかと思っています。

プログラミングという行為の本質は抽象化だと思います。

とかくLambdaと言うと、関数型プログラミングというパラダイムから話を始めがちです。しかし、その説明の順序は間違いだと思っています。パラダイムや技法より先に、どんな抽象化をするかという見極めが先に立つからです。可変部分と不変部分を見極めた抽象化です。このような抽象化の姿勢を持たず、単に、問題に対して特定のパラダイムや技法を当てはめようとするのは間違いです。個人的に、特定のパラダイム(オブジェクト指向だろうと関数型だろうとメタプログラミングだろうと)に極端に傾倒しすぎた開発者に微妙な不信を感じるのは、こういう理由です。

セッションに話を戻します。

繰り返し処理を、ループとして見る抽象化からパイプライン処理として見る抽象化への変化の説明がありました。コンピュータサイエンスの世界から見れば、特に目新しくない変化ですが、Java的にはパラダイムシフトです。

Java8ではパイプライン処理がStreamsとして抽象化されます。

ただ、Streamとは何か、に対する答えはなかなか面倒です。英語で「Streamとはa multiplicity of valuesだ」と回答していました。値の集まりと意訳してしまうと、コレクションとどう違うのかと突っ込まれそうです。実体としては、コレクションよりはイテレータのほうに似ています。イテレータとStreamの何が違うのかと言われると、イテレータはモノの集まりから要素を取り出す操作の抽象化、Streamはモノの集まりをパイプライン処理に通す操作の抽象化と説明したいと思います。かえって分かりづらかったらごめんなさい。

余談ですが、Streamをストリームと記述すると、従来からあるI/O処理のストリームと混同しそうなので、パイプライン処理のStreamは英語のまま記載します。概念上は、I/O処理のストリームとLambda絡みのStreamは同じなので、結局、同じ名称です。同じ名称つながりで言うと、おっさんは、Unix System VのSTREAMSも思い出すかもしれません。

閑話休題。

Streamパイプラインは、ひとつのソース(Source)、複数の操作(intermediate operations)、ひとつの終端処理(terminal operation)で形成されます。

Java8のStreamパイプライン処理は並列処理の指定もできます。元々、JavaのProject Lambdaは並列処理から始まった背景があります。Lambda相当の言語機能だけを見るとJavaは他言語にだいぶ遅れを取りましたが、並列化に関しては後発の強みかもしれません。

繰り返し処理をパイプライン処理として抽象化する話に続けて、パイプライン処理で要素の加算をする簡単なサンプルに話が移ります。ここでナイーブに書いて失敗する例を示します。パイプライン処理の外側にある変数に += 演算で加算をしようとして失敗します。Lambdaからローカル変数の書き換えはできないからです。理由は、これを許すと並列処理できなくなるからです。なお、AtomicLongを使うと回避できます。しかし、並列処理で競合状態が増えて効率的とは言えません。

この問題はreductionで解決できます。簡単に言えば、パイプライン処理の外側の状態変数を書き換える代わりに、計算結果をパイプラインに流して畳み込んでいきます。

セッションの最後の話題はCollectorです。Collectorとは何か、に対してはMutable Reductionと説明がありました。

Collectorの裏側のマジックはまだ調べ切れていませんが、collectorで可能になることを表層的に説明すると、競合状態を発生させることなく、並列パイプライン処理から結果オブジェクトを生成できます。例としてgroupingBy()などに使われています。

Demystifying Java EE [CON2231]

恥ずかしながらこのセッションで見るまでdemystifyという単語を知りませんでした。mystifyが、対象をmysteriousな状態にする意味の動詞で、demystifyはそれの否定で、謎を解き明かす、と言った意味です。

本セッションは、Java EEのありがちな謎を解き明かすもので、次々にJava EEの混乱しがちなポイントを挙げて、それを解説するスタイルで話が進みました。

内容は悪くないのですが、スピーカが早口すぎます。おまけに、プレゼン資料には混乱ポイントを書くだけで、回答は口頭のみです。回答を聞き取れないと問題はわかるけど答えはわからないストレスがたまります。実に日本人泣かせのセッションでした。

Java EEでの混乱ポイントのひとつに、似たようなアノテーションの存在があります。セッションで、@Inject、@Resource、@EJB、@PersistenceContextの4つをどう使い分けるかの説明がありました。@ResourceはAPサーバにJNDI経由で取得させるリソースの指定、@PersistenceContextはJPAのEntityManager専用、@Injectはその他すべてのDI用です。@EJBはlegacyと断定しました。自分も前からそう思っていましたが、不要と言い切っていいのかまでは自信がありませんでした。@EJBは不要と言い切っていいのだと知って安心しました。もっとも、今年のJavaOneでも、サンプルコードに@EJBを使う人は多数いたので、なかなか消えなさそうです。

他にもJava EEで作るWebアプリはStatelessにすべきかStatefulにすべきかという問いかけがありました。Statelessのほうが流行りで美しいけど、Java EEがターゲットとする業務アプリの大半はStatefulで作るほうがラクなので、べき論で考えすぎなくてもいい、と話していました(たぶん)。

Java Persistence for NoSQL [BOF2887]

JavaOneでは、毎回、NoSQL系のセッションにでています。率直に言って、JavaOneでNoSQL系セッションに出ても、たいした情報は得られません。それでも出る理由は、NoSQL系の動きの熱さを見ておきたいからです。ワールドワイドで見た時、NoSQLはまだ熱いのか、終わりつつあるのか、あるいはどちらでもなく安定期に入りつつあるのか、などの温度を感じたいと思って出ています。ガートナーのハイプサイクル風に言うと、NoSQLの流行期は過ぎたと思っていますが、幻滅期を越えて回復期に入ったかどうかは判断できません。

今回のJavaOneで、NoSQL系のセッションは本BOF2887ともうひとつBOF8022(後述)に出ました。

BOF2887は、JPAの関係者が壇上に座り、NoSQLに関して議論するセッションでした。

結論から言うと会場は大盛り下がりでした。どんどん会場から人が抜けていきました。壇上にはJPAのスペックリードのLindaがいるにも関わらずです。

理由は明白で、壇上のJPA関係者がNoSQLに懐疑的だからです。明確にNoSQLダメとは言いませんが、少なくともJPAのように標準化するには時期尚早との見解を示していました。このため会場のNoSQLファンが何か質問しても、常に議論がすれ違う印象でした。これはこれでNoSQLの現状を見るという目的にはかないましたが。

セッションが始まった最初には会場にだいぶ人がいました。最初に、NoSQLを使っている人?という形で挙手が求められました。NoSQL系のセッションだからかもしれませんが、相当数(70,80%?)の手が挙がっていました。MongoDB?、HBase?、と言う形で問いかけが進みました。この辺がやはりNoSQLで最初に名前が挙がる実装のようです。会場にやたら声の大きいCouchBase派がひとりいたので次にCouchBase、その後、Cassandraという流れでした。NoSQLのどんな実装の名前が挙がるかは、後述するBOF8022で再び取り上げます。

What’s New in Java Transaction Processing [BOF3433]

JTAのセッションです。

Java EE7にはJTA 1.2が含まれています。JTAはなんと10年ぶりのメジャーアップデートです。

JTAと言うと、人によるかもしれませんが、Java EEの中で地味な印象があります。少なくとも、Java EEの簡易的なチュートリアルに普通はJTAが登場しません。理由は簡単です。トランザクション管理はEJBで宣言的に記述可能で、JTAの出る幕がないからです。

@StatelessなどのEJBアノテーションをクラスに付与すると、そのクラスはセッションビーンになります。セッションビーンとだけ名前を聞くと役割が不明ですが、昔のJ2EE時代はともかく、今のJava EEでのセッションビーンの役割は、Webアプリにおいてトランザクション境界の役割と思えば充分です。

セッションビーンを使うと、トランザクションを開始したり、明示的なコミットやロールバックの指示が不要になります。その代わり、セッションビーンのメソッド呼び出しは暗黙にトランザクション開始になり、メソッドを普通に抜けると暗黙にコミット、実行時例外でメソッドを抜けると暗黙にロールバックになります。宣言的な記述には、単に記述が簡易になる以外にも利点があります。分散トランザクションなど、複雑なトランザクションであっても、その実行順序をAPサーバに隠蔽できます。EJBは歴史の中で紆余曲折ありましたが、宣言的トランザクションの機能が今や唯一に近いEJBの存在価値になっています。

JTAもトランザクション管理を行うAPIなので、原理的にEJBと役割がかぶります。JTA 1.2より前は、宣言的にやりたければEJB、プログラマブルつまり普通にAPI呼び出しをしたければJTA、という棲み分けでした。

しかし、今回のJTA 1.2で宣言的にトランザクション管理ができるようになりました。@Transactionalアノテーションです。ちなみに、Springを知っている人にとっては、JTAの@TransactionalはSpringのそれと位置づけはまったく同じです(細かい部分は違います)。

と言うわけで、トランザクション境界を宣言的に書ける手段として、Java EE7の中にEJBのアノテーションとJTAのアノテーションが混在することになりました。当然、どちらを使うべきか、という疑問がでます。多くのJava EE関連のセッションでこの疑問に対する質問があがりました。しかし、全般的に歯切れの悪い回答しか聞けませんでした

後日、他の人に聞いたところ、とあるセッションでは、基本はJTAを使って、EJBの機能(分散オブジェクトとセキュリティ)が使いたい場合のみEJBでトランザクション管理すればよい、という回答をスピーカーがした場面があったようです。

個人的には、EJBの分散オブジェクトとセキュリティはobsoleteな機能だと思っています。今や、EJBのレベルでの分散オブジェクトより、Webサービスでの分散処理やメッセージキューによる分散処理のほうが主流だからです。となると、自分にとってはEJBを使う理由はなくなったと言えます。

公式に、EJBは役目を終えたと言ってしまうほうが、Java EEにとってすっきりすると思います。少なくとも、EJB LiteはなくしてJava EEのWebプロファイル(普通のWebアプリに必要な規格)からEJBは一掃してもよい気がします。

Where Do I Put My Data? Relational, NoSQL, or Other? [BOF8022]

BOF2887に続いて、NoSQL系のセッションに参加しました。

タイトルからすると、RDBMSとNoSQL系DBの使い分けの判断基準などを話しそうですが、単にNoSQL系データベースの紹介だけでした。さらに言うとスピーカがCouchBase社の人なので、その辺を割り引く必要があります。たとえば、MongoDBの扱いが不当に小さかったです。しかし、客観的に見て、MongoDBの存在感はNoSQL系の中で圧倒的です。MongoDB社(旧10gen)はOracle OpenWorldの展示会場で去年より大きく拠点を拡大していました。一方のCouchBaseはこのセッションのスピーカ以外、特に存在感はありませんでした。

上記BOF2887にも書きましたが、NoSQL系セッションに出てもたいした情報は得られません。このセッションでも、相も変わらずのCAP定理の話がありました。整理のために便利なので言及するのが悪いわけではありませんが、個人的には聞き飽きました。

概念の整理は特に目新しくはないので、関心はどの実装が言及されるか、です。これによりNoSQL系の世界のトレンドを追えるからです。

最初に言及があったのはKVS/Cacheの代表格のmemcachedです。まあ妥当ですね。あまりに基本的すぎてmemcachedを飛ばして話を始めるケースも多いですが、NoSQLを最初から話すならmemcachedから、になるでしょう。

その後、KVSより構造化した形の代表として、redisの言及がありました。memcachedの次にredisというのは少し興味深い展開です。

次に、ディスクベースのNoSQLという展開で、membaseの言及がありました。ここはスピーカがCouchBase社の人というのを差し引く必要があります。CouchBase社はCouchDBとmembaseの開発者が一緒になって設立した会社だからです。

その後、Document DBという展開で、MongoDBではなくCouchBaseを取り上げました。ここもスピーカゆえですね。興味深かったのはCouchBaseを、CAP定理でAよりC優先と説明した点です。かつてのCouchDBはCよりA優先でした。マルチマスタ型で、(CouchDBの原型とも言える)Lotus Notesっぽく競合文書ができて、競合文書の解決はアプリに委ねられていました。CouchBaseの事情は追っていませんが、C優先になっているとしたら大きな方針転換です。CouchBaseになり、かつてのLotus NotesっぽいAP型からMongoDBっぽいCP型になったようのかもしれません。

その後、カラムオーバーレイ型の代表としてCassandraの説明がありました。Cassandraはカラムストア型として説明されがちですが、個人的にはデータモデルの説明とデータのストア方式の説明が混在して気持ち悪く感じます。データモデルを説明する用語としてカラムストア型は適切とは思えないからです。本セッションではカラムオーバーレイという用語をデータモデル名として使っていました。この用語が一般的なら倣ってもいいのですが、あまり一般的ではない気がします。

CassandraはCAP定理でAよりC優先と説明がありました。これは前からそうです。

最後にグラフ型として、お馴染みのNeo4jの紹介がありました。グラフデータベースは、NoSQL系のセッションで必ず最後におまけのように扱われます。その時、実装として挙がるのはたいていNeo4jです。日陰っぷりがオブジェクトデータベースやXMLデータベースっぽいですが、もはや誰も言及すらしないふたつに比べるとグラフ型は日が当たる存在です。

最後に、説明なしで一覧に追記されたのが、redisと並んで(Oracle社の)coherence、membaseと並んでriak、CouchBaseと並んでMongoDB、Cassandraと並んでHBaseでした。ここ1,2年での新顔はないですね。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under 勉強会.


JavaOne2013に参加するためサンフランシスコに行ってきました。JavaOne参加は今年で3度目です。そのレポート記事です。

去年のレポートはJavaOne2012@サンフランシスコ レポートを見てください(関連記事もたどれます)。
3年前のレポートはJavaOne/Oracle OpenWorldレポート – ラリーエリソン編 –から関連記事をたどってください。

今年のJavaOneもOracle OpenWorldと同時開催です。同時開催と言うと聞こえはいいですが、実態は、メインとなるOracle OpenWorldの片隅でJavaOneがついでに開催させてもらっている雰囲気です。今年のOracle OpenWorldの登録人数は6万人近いと公式発表がありました。JavaOneの登録人数は公式発表がありません。噂で人数を聞きましたが、信憑性が不明なのでここには書きません。イベントの規模を見ると、Oracle OpenWorldが世界最大のITイベントのひとつなので、比較するとJavaOneは悲しくなってきます。

と寂しい話を書きましたが、比較対象のOracle OpenWorldが異常値なだけで、JavaOneは充分に巨大なITイベントです。プログラミング言語を冠にしたイベントで、JavaOne規模の世界的イベントを開催できる言語は他にないはずです。イベント規模だと次点でPythonあたりでしょうか。どうでしょう。

JavaOne以外のサンフランシスコ話を先にします。

サンフランシスコはOracle一色なので、入国が尋常でなく簡単でした。”How long?”の質問に”One week”と答えた後、”Oracle?”と聞かれて”Yes”と答えたら入国時の質問が終わりました。

観光のためJavaOne後に一日サンフランシスコに延滞しました。

せっかくなのでUCB(カリフォルニア大学バークレー校)を見てきました。かつてここにBill JoyがいてBSDを開発していたのだと思うと感慨深いものがありました。コンピュータ演習室を見つけてどんなOSが使われているのか見たかったのですが、残念ながら演習室を見つけられませんでした。ちなみに、15年ほど前にMITを見に行った時は、演習室にあるPCのOSの大半はGNU/Linux(記憶では一部x86 Solarisもあったはず)で、やはりそうかと思ったものです。UCBで演習室が見つけられない代わりに学生が使っているノートPCを観察しましたが、90%の学生がMacを使っていました。カーネルがBSD由来だからでしょうか。使っているテキストエディタは調べていません。UCBの学生なのでvimに違いないと勝手に想像しています。

去年のレポートでユニクロのサンフランシスコ店のオープンの話を書いていますが、一等地にあるユニクロは特に変わりなく、街に馴染んでいました。一方、去年、空港に広告をばんばん載せて、AT&Tパークの近くで窓から海の見下ろす立派なオフィスを構えて飛ぶ鳥を落とす勢いだったGREEですが、あらゆるものが消え失せました。永井さんは元気でしょうか。

JavaOneの話に戻ります。

初日の日曜日(2013年9月22日)の昼12時から基調講演が始まりました。場所はMoscone Northの広いホールです。微妙な時間から開始した理由は、夕方からメインイベントのOracle OpenWorldの基調講演が同じ場所で開催されるからです。

JavaOne基調講演の冒頭、「我々はMosconeに戻ってきたぞ」と会場が盛り上がりました。

この盛り上がりの理由を知るには多少歴史の知識が必要です。SunがOracleに買収される以前のJavaOneはMosconeで開催されていました。SunがOracleに買収されてから冒頭に書いたようにJavaOneはOracle OpenWorldと同時開催になりました。Oracle OpenWorldがMosconeを使うため、JavaOneはMosconeから追い出されて、近くのヒルトンホテル(と他の近隣ホテル)で開催されるようになりました。今回、初日の基調講演だけはMosconeで開催できたので、盛り上がったわけです。

今年のJavaOneの基調講演の一番の盛り上がりはここだったのではないか、と言うぐらい他に盛り上がりはありませんでした。ネタが悪いと言うより、単純に盛り上げるための演出不足の印象です。途中、Project Avatarをオープンソースにする発表もありましたが、あまりにさらっと発表するので、会場も盛り上がるタイミングを逸したという雰囲気でした。個人的にはAvatarのTSA(Thin Server Architecture)がJava EEの標準アーキテクチャになって、はやくJava EEはJSFから訣別すればいいのにと思っています。

基調講演では当然Java8の話がありました。本来の予定であれば今回のJavaOneのタイミングでJava8リリースをして大盛上がりのはずでした。残念ながら、来年の4月にリリースが延びました。今年の基調講演が盛り上がらない最大の戦犯ですが、まあ、良いものがリリースされれば、リリース時期は本質ではありません。とある事情で、個人的にはJava8のリリースが延びて助かっています。

Java8の目玉機能は当然Lambdaです。他にもDate/Time API(JSR310)、Nashorn(Rhinoに代わるJVM上のJavaScript処理系)、Type Annotation、Compact Profile、Securityなどが触れられました。一見地味ですが、Date/Time APIは今回のJavaOneで大きくフィーチャーされていました。もちろん、Lambdaほどではないですが。

基調講演ではJava9の話もありました。Jigsaw、Project Sumatra(GPUを使う機能)、Reification(ジェネリックスの型イレイジャの見直し)、JNI 2.0(ここは少し盛り上がった)、省メモリ対応など挙げていました。コルーチンなどの案も挙がっているようですが詳細は不明です。

去年に引き続き、NetBeansのProject Eazelのデモもありました。

Project EazelはNetBeansを使ってサーバサイドのJavaのみならず、クライアントサイドのJavaScriptも対話的にデバッグできる優れものです。対話的デバッグのため、NetBeansとWebブラウザが内部的にWebSocketで通信すると言っていました。WebSocketと言うと、どうでもいいチャットのサンプルコードばかり取り上げられますが、Project Eazelのような利用は適材適所の印象です。Project Eazelのデモ中に、見事にNetBeansが落ちました。デモが失敗すると会場が大盛上がりでした。思い出してみると、ここが今回のJavaOneの一番の盛り上がりでした。

Project EazelのデモでKnockout.jsを使っているのが印象的でした。他に(聞き取り落としがなければ)Angular.jsとjQueryに言及していました。なお、JavaOne全体のセッションで、Angular.jsへの言及が目立ちました。個人的にJavaScriptライブラリのトレンドが気になるのですが、今回、Angular.jsの躍進が目につきました。

基調講演でJava EE7の紹介もありましたが、遂にリリースしたぞ、という盛り上がりはなく、淡々とJava EE7を紹介をしただけでした。Java EE7は2013年6月のリリースなのでもっと盛り上げてもいいはずなんですが。Java EE7の紹介ではWebSocketの言及に一番時間を割いていました。これは、技術的な重要さと言うより、派手なので言及しやすいだけだと思います。

その後、Raspberry Piベースのタブレット、名づけてDukePadが出てきました。が、ごめんなさい、特に興味ありません。Oracleが本気でタブレットを出すとは思えないので、無意味な余興にしか見えません。好意的に見ればOracle社内のJavaチームに余力があるとも言えます。悪く言うと、会社の中のメインストリームから外れた日陰者に見えてしまいました。斜に構えすぎかもしれません。気にしないでください。

DukePadもそうですが、今回のJavaOne基調講演で妙に力を入れて紹介されていたのが、Java MEでした。Internet of Things(IoT)の時代になってJava MEの重要性が増しているというメッセージを強調していました。家電や車、あるいは今までIT化されていない各種デバイスがインターネットにつながるIoTの時代が来つつあるのは間違いありません。大きな変革であるのも間違いないと思います。

しかし、既に何10億台のデバイスで採用されているJava MEがその中心になる、というメッセージに違和感を感じずにはいられません。と言うのも、その何10億台のデバイスの市場を猛烈な勢いでAndroidに食われているのではないか、と思ってしまうからです。組み込み系の事情に詳しくないので、単に自分の認識不足かもしれません。Androidはしょせんスマートフォンとタブレットだけであって、その他のデバイスの標準は依然としてJava MEなのかもしれません。どうなんでしょうね。

JavaOne最終日のコミュニティ基調講演でも、再びJava MEとIoTが強調されました。Java MEの比較対象は、組み込みでのC/C++開発でした。IoTの時代になった時、組み込みデバイス上のアプリ開発言語の中心がCやC++のまま、というのはさすがに考え辛いので、何か別の言語なんだろうとは思います。それがJavaなのかは別として、です。


関連文書:

  • 関連文書は見つからんがな