谷本 心 in せろ部屋 このページをアンテナに追加 RSSフィード

2017-01-11

TT-BA09で、テレビの音声をBluetoothで無線化してみた(成功編)

BABYMETALのライブが放送される時期だけWOWOWを契約する、ちょっとWOWOWにとっては迷惑気味なメイトのCERO-METALデス!


さて、普段ヘッドホンで音楽を聴くようになってから、テレビでもライブなどを観る時にはテレビのスピーカーでは物足りなくなり、ヘッドホンで聴くようになりました。ただ3mぐらいのケーブルを使ってもテレビまで近いですし、キッチンで料理や洗い物をしながらテレビを観る時になんかには使えません。

そんな背景から、テレビの音声をワイヤレスにしてヘッドホンで聴きたいなーと思っていました。


ちょうどWOWOWBABYMETAL東京ドームライブが放送される年末年始のこのタイミングで、テレビの音声をBluetoothで飛ばして、ヘッドホンで聴ける環境を作ることにしました。


何がいるの?

そもそも、テレビの音声をBluetoothで飛ばすには何が必要か、という整理からです。接続の流れはこんな感じになります。


テレビ → Bluetoothトランスミッター → Blueotoothレシーバー → ヘッドホン


テレビからの音声入力を受けてBluetoothで飛ばすものを「トランスミッター」と呼び、Bluetoothで受信をする方を「レシーバー」と呼びます。ITエンジニアの皆様方にも分かりやすく説明すると、トランスミッターがWi-Fiルーターに相当し、レシーバーWi-Fi子機に相当します。

またレシーバーとヘッドホンをケーブルで繋ぐものもあれば、ヘッドホン自体がレシーバーになるワイヤレスヘッドホンなどもあります。


製品の選び方

Bluetoothトランスミッターやレシーバーを選ぶ際の観点になるのが、次の2つです。

  • 音声入力の方式(ヘッドホンジャック、赤と白のRCAピンプラグ、光デジタルなど)
  • 対応コーデックSBCAACapt-X、LDACなど)

音声入力の方式はまぁ分かるので割愛するとして、よく分からないのがコーデックです。

ざっくり調べた感じ、次のような違いがあるようです。

  • SBC: ほとんどの機器が対応するけど、音質が悪い。
  • AAC: 主にApple製品で使われる。SBCより音質が良い。
  • apt-X: Androidや多くの機器で使われる。AACより遅延が少ない。
  • apt-X HD: apt-Xをさらに高音質にしたもの。まだ対応製品が少ない。
  • LDAC: ハイレゾ音源に対応するもの。音質は一番良いがソニー製品でしか採用されていない。

対応製品が多いapt-Xが、現在ではほぼスタンダードになってるようです。apt-Xに対応したトランスミッターはいくつかあるのですが、AACやLDACに対応した単体のトランスミッターというのは、ちょっと見つけられませんでした。


実際に買った製品

それで今回用意したのは、次の製品です。

この組み合わせで、ばっちりワイヤレスで視聴できる環境が整いました。


TT-BA09

音声のトランスミッター、レシーバーの両方に使える製品です。TaoTronics社からは似たような製品がいくつか出ているのですが、このTT-BA09は光音声入力があったので、これを選びました。ちなみにTT-BA09には音量を調整する機能がありません。


TT-BA08

上の製品と同じく音声のトランスミッター、レシーバーの両方に使える製品です。TT-BA09よりも一回り小さな製品です。

こちらはレシーバーとして使う際に音量の調整ができるようになっています。通常、光音声入力では出力側での音量調整ができず、レシーバーで音量調整する必要があるため、これを選びました。


それで、繋いでみると。

さすがは同じメーカーの同一シリーズの製品でしょうか、全く何の問題もなく接続できました。

接続はこんな流れです。


テレビ → (光音声出力) → TT-BA09 → (Bluetooth/apt-X) → TT-BA08 → (ケーブル) → ヘッドホン


Bluetoothを切断/再接続をしても、全く問題なく音声を聞くことができます。

また、テレビの音量を変えてもヘッドホンから聞こえる音量は変わらないため、テレビは消音にし、音量をTT-BA08で調整するような使い方になります。音量を調整できないレシーバーだと、こういう事ができないんですよね。


遅延とか音質は?

Bluetoothでよく言われるのが音声の遅延。

apt-Xでは40msほどの遅延があると言われており、口と声がズレるのを気にする僕としては、遅延があるのははっきり分かります。遅延があまり分からない人でも、テレビとヘッドホンの音を両方出せば、はっきりとズレていることは分かるでしょう。

ただ、そうは言っても40msですから、ズレを検出しようとしない限りは、さほど気にならない程度でした。


そして気になる音質ですが、これはとても良いです。

ショボいテレビのスピーカーに比べれば音声はクリアに聞こえ、特に海外映画などの英語もだいぶ聞き取りやすくなりました。音楽番組などもしっかり低音が聞こえるのは、さすがヘッドホンですね。

音楽番組を流しっぱなしにしながらリビングキッチンでウロウロしても、ヘッドホンで聴けるのは最高です。


・・・ということで、特にトラブルも起きることないつまらない話になったのですが、実はこの前に、別メーカーの製品との組み合わせでトラブルがありました。せっかくなので、それについては、また改めて書きたいと思います。


See you!

2016-01-01

[]AWS LambdaでJavaNode.jsとGoの簡易ベンチマークをしてみた。

あけましておめでとうございます!

現場でいつも締め切りに追われデスマーチ化している皆様方におかれましては、年賀状デスマーチ化していたのではないかと憂慮しておりますが、いかがお過ごしですか。

エンジニアの鑑みたいな僕としましては、年始の挨拶はSNSでサクッと済ませ、年末年始は紅白など見ながらAWS Lambdaのソースコードを書いていました。


ということで、Lambda。

Lambdaを書く時に最初に悩むのは、どの言語を選択するか、なのです。


まず手を出すのは、サクッと書けるNode.js

ただNode.jsの非同期なプログラミングになかなか馴染めず、わからん殺しをされてうんざりしていました。みんなどうしているのよとtwitterで問いかけたところ @ からPromiseを使うべしと教わり、なるほど確かにこれは便利ですナと思いつつも、これが標準で使えないぐらいLambdaのNode.jsが古いところにまたうんざりしました。


では手に馴染んでるJavaを使ってみたらどうかと思ったら、メモリイーターだし、なんとなくパフォーマンスが悪い感じでした。詳しいことは後ほどベンチマーク結果で明らかになるわけですが。


それなら消去法で残ったPythonなのですが、僕マジPython触ったことないレベルであり、これは若者たちに任せることにしているので、Pythonも選択肢から消えて。


本来、Lambdaみたいな用途にはGoが向いているはずなのだけど、いつ使えるようになるんだろうなぁなどと思って調べてみたら、Node.jsからGoを呼び出すというテクを見つけて、こりゃいいやとなりました。

http://blog.0x82.com/2014/11/24/aws-lambda-functions-in-go/


ただGoを呼ぶにしてもNode.jsを経由するためのオーバーヘッドはあるわけで、じゃぁ実際にどれぐらいパフォーマンス影響があるのか、調べてみることにしました。


処理の中身

簡単に試したいだけだったので、数行で済む程度のごく簡単な処理を書いてベンチマークすることにしました。


1. 引数で渡されたJSONパースして、中身を表示する

2. DynamoDBから1件のデータを取得する


当初は1だけだったのですが、あまり性能に差が出なかったので2を追加した感じです。そんな経緯のベンチマークなので、実装も雑ですが、とりあえずソースをGitHubに置いておきました。

https://github.com/cero-t/lambda-benchmark


実行結果
回数Java(1)Java(2)Node.jsGo
1回目218006700900600
2回目13007300800500
3回目19000500200500
4回目10001300200400
5回目500200400500
6回目400100200500
7回目400300400500

時間はいずれもミリ秒のBilled duration。


Java(1) : メモリ192MB。処理中にAmazonDynamoDBClientを初期化

Java(2) : メモリ192MB。処理前に(コンストラクタで)AmazonDynamoDBClientを初期化

Node.js : メモリ128MB

Go : メモリ128MB


メモリの実使用量は

Java : 68MB

Node.js : 29MB

Go : 15MB

でした。


考察など

正味の話、Lambdaで行っている処理などほとんどないので、性能的には大差ないかと思っていたのですが、思ったより特性が出ました。これは処理時間というよりは、関連ライブラリのロード時間な気がしますね。


Javaは最初の数回が20秒、実装を改善しても7秒とかなり遅かったのですが、ウォーミングアップが終わった後は200msぐらいまで早くなりました。呼ばれる頻度が高い処理であれば良いのでしょうけど、たまに呼ばれるような処理では、この特性はネックになる気がします。


ちなみにJavaだけは192MBで計測しましたが、最初にメモリ128MBで試したところ、30秒ぐらいで処理が強制的に中断されたり、60秒でタイムアウトするなど、計測になりませんでした。こういう所を見ても、Javaを使う時にはメモリを多め(CPU性能はメモリと比例して向上)にしなくてはいけない感じでした。


Node.jsも少しはウォーミングアップで性能が変わりますが、最初から性能は良い感じです。


Goを使った場合は性能が安定しており、ウォーミングアップしても性能が変わりません。メモリ使用量が少ないのも良いですね。Node.jsから呼び出す際のオーバーヘッドがあるせいか、性能的にはウォーミングアップ後のJavaNode.jsに一歩劣る感じでした。


なお、Pythonの実装をしてくれる人がいらっしゃれば、プルリクしていただければ、データを追加したいと思います。


結論

繰り返しになりますが、雑なベンチマークなので特性の一部しか掴んでないと思います。

そもそもJavaだけメモリが1.5倍になっている(=CPU性能も1.5倍になっている)ので公平ではないですし。


ただ「たまに行う処理」を「少ないリソース」で行うという観点では、Goで実装するのが良さそうです。GoはそのうちLambdaでも正式サポートされそうですしね。

きちんとしたベンチマークは、また別の機会にじっくり行ってみたいと思います。


ということで、Goを使う大義名分ができたベンチマークでした!

See you!

2011-12-10

[]xUnit成熟度モデル 〜あなたの組織はどのレベル?

本エントリーは、Software Test & Quality Advent Calendar 2011の10日目です。

http://atnd.org/events/22833


前の9日目は @m_seko さんの

「負荷テスト対象のWebアプリがこういう非機能要件(+α)を備えていたらいいのにという願望」です。

http://d.hatena.ne.jp/sekom/20111209


普段、品質やテストなどには興味なさそう(?)にしている私ですが、

たまには、エンジニア視点から、テストについて語ってみましょう。

xUnit成熟度モデルって?

xUnit成熟度モデルとは、

組織がxUnitをより適切に利用できるようになることを目的として

遵守するべき指針を体系化したものである。


あわせて読みたい : 能力成熟度モデル統合 (CMMI) - Wikipedia


正味の話で言うと、僕がJUnitに初めて出会ってから今に至るまで、

どのようにJUnitを使い、失敗し、改善して行ったのかを、段階ごとに振り返った軌跡です。

レベル1 : 初期

xUnitを利用しているが、記述粒度、記述方針や、利用プロセスなどを決めておらず

それぞれのエンジニアが、自分の裁量でテストコードを書いている。


このレベルの典型的な問題

  • assert文がなく、目視で結果を確認するテストコードが多い。
  • テスト実施前に手動準備が必要である。しかし、その手順がどこにも記載されていない。
  • なぜかxUnitを使っていないテストコードもある。
  • テストコードがバージョン管理されていない。
  • テストコードをバージョン管理しているが、ほぼエビエンス代わりであり、まず再テストは通らない。

次のレベルに向けた活動

  • xUnitの利用方法について、組織内・プロジェクト内での勉強会を行ない、レベル感を合わせる。
  • 組織、プロジェクトとして、どの工程でどのようにxUnitを利用するかを、事前に決める。

レベル2 : 過剰に書かれた

開発プロセスにてxUnitの利用方法を規定している。

ただし、過剰にテストしてしまったり、テストデータ量を爆発させたり、

xUnitが向いてないテストまで無理にxUnit化するなどするため、テスト工数がこれまでよりも掛かっている。


このレベルの典型的な問題

  • 手動でテストしていた時に比べて、テスト工数が2倍以上に増えている。
  • テストコードが、本体コードと同程度〜2倍程度の規模にまで膨らんでいる。
  • Excel形式の投入データ、検証データが大量にあって、レビューも修正もできない。
  • カバレッジ100%を達成するべく、特に最後の10%のためにテスト工数の半分を消費している。
  • テストコードをバージョン管理しているが、膨大すぎてメンテナンスできず、再テストが通らない。

これらは、xUnitを始めた者が、一度は必ず陥る暗黒面だと言える。


次のレベルに向けた活動

  • 小さな部分を、小さくテストする文化を浸透させる。
  • 設計時や実装時に、テスト容易性を考慮した設計を行う。
  • モックを利用したテストを取り入れる。

レベル3 : モック化された

過剰なテストへの対策として、「小さな範囲を小さくテストし、積み重ねる」ために、モックを利用している。


モックを実現する方法として、設計・実装を工夫する(protectedメソッドの活用など)か

モックライブラリ(djUnit、Mockitoなど)を利用するかは問わない。


いずれの方法を使っていても、モックを使う事でテストをスリム化することができ、

テスト工数や、メンテナンスコストを削減することができている。


このぐらいのレベルから、テストの事前準備自体をテストコード内で記述しているため、

リポジトリからソースを取得してビルドするだけで、すぐにテストを実行できるようになっている。


このレベルの典型的な問題

  • モックライブラリの罠に陥っている
    • カバレッジ計測ツールの相性が悪く、期待するカバレッジ結果を算出できない。
    • 逆に可読性の低いコードになってしまい、他の開発者がメンテナンスできない。
  • 本体にバグがあっても、テスト自体がうっかり通ってしまっていて、問題に気付けない。
  • 気がついたら、モック自体をテストしている。

次のレベルに向けた活動

  • モックライブラリを使わずともモック化しやすいような設計・実装を浸透させる。
    • 継承ではなく委譲
    • メンバ変数よりも引数
    • ステートレス化
    • protectedメンバ、protectedメソッドの活用

レベル4:継続的に実施された

CIツールなどを導入して、ビルドとxUnitを定期的に実施している。


CIツールを導入することで、テストコードのメンテナンスを行う習慣が浸透するほか、

テスト環境に依存しない、テスト環境を壊さないようなテストコードを作成するようになっている。


このレベルの典型的な問題

CIツールに対して過剰な安心感を持ってしまい、これまで気付けた問題に気付けなくなる。


たとえば、テスト全体ではなく、一部のテストのみを定期的に実行している場合で

「CIしているから大丈夫」と考えて、動作確認を疎かにしてしまいバグを埋め込んでしまう。


CIツールは「安心」のための「シートベルト」に例えられることがあるが、

シートベルトをしていれば時速200kmで峠を攻めても良い、というわけではない。

レベル5 : 最適化している

テストコードを書くポイントや、分量などのバランスが分かり、

最適なテストコードを書くようになる。

もちろん、組織やプロジェクトの性質によって「最適」の定義、観点は異なっている。


参考までに、観点や選択肢を、いくつか列挙しておく。

  • テスト工程の考え方 / CIの考え方
    • 単体テスト全体をxUnit化する
    • 単体テストだけでなく、結合テストの一部までをxUnit化する
    • 単体テストの前工程として「開発テスト」という工程を挟み、より小さい単位でテストする。
  • 単体テスト対象の考え方
    • あくまで単一メソッドのテストを行ない、外部メソッドは全てモック化している
    • 原則としてpublicメソッドをテスト対象と考え、ある程度のまとまりごとに試験する
  • 外部システムとの連携
    • データベースへのデータ投入や外部システム操作を、テストコード内で実施する
    • データベース部分や、外部システム連携箇所は、すべてモック化する

まとめ

  • レベル1:xUnitを使っているが、テスト自体が杜撰である
  • レベル2:テストコードが過剰である
  • レベル3:モックを使っている。
  • レベル4:CIで定期実行している。
  • レベル5:組織として、最適な解を選択している。

割と好き放題に書いてきましたが、いかがでしたか?

また、あなたの組織は、どのレベルでしたか?


もしこのエントリがあなたの組織のxUnitレベルが上がる一助になれば、幸いです!(><)

2010-10-04

[]JavaOne2010まとめ テクニカル編

JavaOne2010が閉幕してから約一週間。

そろそろ落ち着いてきたので、JavaOneまとめを書く。


まずは、技術面で印象的だったことなどから。


Oracleはクラウドに向かう。

これまでの否定的な態度から一転して、

ラリーエリソンはクラウドを雄弁に語っていた。


今までは「クラウドと言うが、ただのWebアプリに過ぎない」と言っていた

否定的な態度は、Salesforceに対してぶつけつつ、

Amazon EC2のようなサービスこそがクラウドであり、

Oracleもそこを目指すと語った。


ところで、Oracle Open WorldのKeynoteで発表されたExalogicだけでなく

Coherenceというキーコンポーネントも元々Oracleは持っており

いつでもクラウドを推進できたはず。


ラリーエリソンの態度を一変させたのは、この時代の流れなのか、

Sunという「ハードウェアベンダ」を手に入れたためなのか、

ちょっと私には分からないんだけど。

HotRockitが今後の主流になる。

「Oracle's Java Virtual Machine Strategy」というセッションが面白かった。

http://d.hatena.ne.jp/cero-t/20100923/1285343999


HotSpot(旧Sun Java)に、

JRockit(旧BEA Java)の機能をマージした

通称「HotRockit」が、来年中に登場する予定。


いまHotSpotを使っている人たちは、

恐らく何の迷いもなく(あるいは気づくことなく)HotRockitに乗り換えるはずで、

今後、HotRockitがトップシェアになっていくはず。


特にJRockit Mission ControlやJRockit Flight Recorderといった

モニタリングツール、トラブルシューティングツールが

HotSpotでも使えるようになる所が最大の見どころ。


この辺りのツールに目がない人は、

今のうちからJRockitのツールを触っておくと良さそう。

Future Java : Yet Another Javaが求められている?

もう一つ面白かったのが

「The Next Big Java Virtual Machine Language」というセッション。

http://d.hatena.ne.jp/cero-t/20100920/1285149540


スピーカーのサイトでも詳細がまとめられていたので、そちらも紹介。

http://www.jroller.com/scolebourne/entry/the_next_big_jvm_language1


セッションも割と人が集まっており、

やはり「Javaの次」を求めている人達が増えてきていると感じる。


上に書いたセッションでは、「Java8(やJava9)がそうなったら、どうだろう」

という締めくくり方であったが、ちょっと僕はそうは思わない。

(どうもスピーカー自身もそうは思ってないみたいだけど)


Oracle自身がJavaのライバル言語を産み出すメリットはないし、

オープンソース戦略に打って出ることも、ちょっと考えにくい。


Next Big JVM Languageを提供するのは、やっぱりGoogleじゃないかな。

あるいは傑出した個人かも知れないけど。

誰かが動き出さなければ、いつまでも絵に描いた餅のままになってしまう。

JavaSE : やっとJava7が登場する。

いよいよ来年、本当に、今度こそ、Java7が登場しそう。

2011年半ばにJava7がリリースされ、2012年後半にJava8がリリースされる。


モジュラリティやクロージャーはJava8に回ったけど

Invoke DynamicなんかはJava7に入ってくる。


Invoke Dynamicは、特に動的言語の性能や、クラスのHotSwap辺りに影響が大きいので

Java7登場後の、周辺プロダクトのリリースが楽しみになる。


ところで、

ここ数年間のJavaの停滞感を、今後Oracleがどう払拭するかは、とても見もの。


たとえば、JCPとの連携をきちんと復活させ、

コミュニティから意見を広く集め直すとか?


悪い方の予想で言えば、(歩みを遅める理由になった)OpenJDKに対して

全くリソースを割かないようにして、事実上ストップさせるとか。

JavaEE : 次が見えてこない。JavaVE観点からの機能追加があるか?

JavaSEと違って、次の姿が見えてこないのがJavaEE。

もっと言えば(いつも言ってるけど)世の中がどれだけJavaEEに

期待しているのか、私にはよく分からない。


次が見えてこないJavaEEだけど、

個人的には、JRockit Virtual Edition(VE)の存在が、

JavaEEに影響するんじゃないかと思ってる。


OS不在で動くVEだからこそ、

「OSありの時にはできたけど、VEになってから出来なくなったこと」

なんてことが出てきて、その一部がJavaEEの機能に対するニーズになるとか。


仮にIBMなどのJVMベンダもVEに追従してきたら、

将来的には「JavaEE = JavaVE」ぐらいのイメージで

語られるようになっても、不思議じゃないかな。

JavaME : 奇策で逆転満塁ホームランを狙う以外ない。

将来が見えないどころか、なくなってしまうんじゃないかと思うのが、JavaME。

iPhone / Androidに対して、Oracle / Javaがどう打って出るのか

という話が聞けることを期待していたんだけど、全く何も出てこなかった。

HTML5周りの話が多少出てたけど、期待できるもんじゃない。


このままでは、iPhoneやAndroidには引き離されるばかりなので

(台数だけで言えば、まだJavaMEの方が相当上回ってるだろうけど)

追いついていくためには、何か奇策が必要。


たとえば、今から規格を統一し直して、

Java搭載ケータイで共通的に使えるアプリストアを構築するとか、

いっそAppleやGoogleに売ってしまうだとか。まぁあり得ないよね。


ただ、なんか大掛かりの手を打たない限りは、

ただガラケーでの既得権益を得るだけの

つまらないビジネスになってしまうんじゃないかな。

2010-09-20 JavaOne Day 2

[]Day-2 : The Next Big Java Virtual Machine Language

JVM上で動く、次世代の主流となる言語、

つまりNext Big JVM Language、略して「NBJL」を探るというセッション。


最も面白かったセッションの1つですね。


C、C++、VB、Perl、JavaScript、Javaなどと同じぐらいメジャーになって

シンプルで、オブジェクト指向で、ロバストで、セキュアで、

パフォーマンスが良くて、相互運用性があって・・・みたいな夢物語で

スタートして、どこに着陸するのか、ハラハラするセッションでした。


最初の候補は「Java」。


しかしJavaにも、いくつか問題がある。

Javaは何が悪かったのか、いや、私達は何をJavaから学んだのか、

という観点から、Javaの問題点を7つ列挙する。


1. チェック例外。

理論的には良かったけど、実質的には良くなかったという最たる例。

もみ消しなどされやすく、扱いづらいため、SpringなどのメジャーなOSSでは

ほぼ例外なく、実行時例外を選択している。

→NBJLには不要


2. プリミティブ変数

パフォーマンスは良かったけど、「全てがオブジェクトである」という

思想からは外れた。また、Genericsで使えないなど、少し扱いづらい。

→NBJLには不要


3. 配列

これもプリミティブと同様。

→NBJLには不要


4. 全てのオブジェクトをsynchrnizedのモニタとして使えること

使い方を過って、バグに繋がることが多い。

→NBJLには不要


5. static

並列処理時ができない原因になったり、継承できないから、扱いづらい。

→NBJLではstaticを別の方法で実限したい。


6. オーバーロード

複雑になることが多い。

特に可変長引数とAuto Boxingが導入されてからますます分かりにくくなった。

→NBJLでは避けるか別の方法で実限する


7. Generics

作る側にとっては、非常に分かりづらい。

また、Generics非対応のライブラリを混在させると、警告が出てしまう。

(Commons CollectionsとかCommons IOとか、そうですよね)

→NBJLではもう少し上手いアプローチが必要


また、逆に、NBJPに必要なものは何か?


1. オブジェクト指向と関数型のハイブリッド

関数型は便利だが、とっつきやすい文法ではないので、メインストリームには来ない。

オブジェクト指向と関数型を合わせたものが現実解だろう。


2. Javaよりは動的な型

ひところの動的型付けブームは収束し、静的な型に戻りつつある。

NBJLでは、JavaやScalaよりは動的だが、基本的には静的な型付けが良い。


3. プロパティクラス

setter/getterを作成するのは馬鹿げている。

プロパティクラスを定義できるようにすべきだ。


4. 並列性・・・は過剰には必要ない

そもそもAPサーバで動かしている時点で並列化されており、

アプリ実装者は並列化を過度に考える必要はない。

(確かに、APサーバで動くアプリで「スレッド作成」はバッドパターンですしね)


5. モジュラリティ

これはOSGiなどを使い、言語のコアに取り入れられるべき。


6. ツール、開発環境

これは非常に重要。


7. 拡張性(あるいはオープン性?)

たとえばJavaはOracleのみが修正できる言語となっており、

それ以外の人が修正できる言語ではない。


では、候補は何か?


1. Groovy

動的な言語であり、ニッチ用途で使われても

メインストリームに来るような言語ではない。


2. Scala

関数型言語であり、文法面でJavaからの飛躍が大きい。

これもメインストリームに来ることは考えにくい。


3. Fantom

文法面でJavaからの飛躍は小さいが、型が動的寄りであり、

やはりNBJLにはなり得ない。


では、、、「全く新しいJava」はどうか?


過去との互換性をなくして(ただし移行ツールを提供する)

クロージャー、プロパティ、モジュラリティなども提供する。


、、、仮にそれが「Java8」だったらどうだろう?


という、引き込まれる感じのセッションでした。

確かに「Java8」は「EvolutionではなくRevolution」となるそうです。


ただ、Java8で、過去のバージョンのJavaとの互換性が切ってまで

勝負に出ることは考えにくいですね。

(ちなみにJava7は2011年中盤、Java8は2012年末までにリリース予定)


2年ほど前から、私はJVM上で動く「Dynamic Java」みたいなものが

開発されないかな、と期待しています。


ホットデプロイできて、型がやや動的で、クロージャーもあって、

というような動的言語の特徴が入った、「Java」です。

それこそが、ここで言ってるNBJLに相当するでしょう。


何というか、

Google辺りがサクっと実装しそうだと思ってるんですけどね。

NoopとかGoとかよりも、それをやって欲しいですね。