Groovy 1.8.4 & 2.0-beta-1のリリースと今後のロードマップ（翻訳）
原文: http://docs.codehaus.org/pages/viewpage.action?pageId=227053189
本日、新たなジョイントリリースのお知らせをできることを大変うれしく思います！
Groovy 1.8.3における、Grails webフレームワークやGradleビルド自動化ツールでの問題点の修正や改善を含む、Groovy 1.8.4をリリースしました。
さらに、Groovy 2.0-beta-1のリリースもあわせてお知らせします！
Groovyのバージョン番号体系の変更
そうです、Groovy 2.0ベータです！え？1.9系を進めていたはずだろうって？確かにそうだったのですが、1.9リリースではかなり多くの新機能が盛り込まれるため、この機会に番号体系を改めることにしました。
歴史的には、Groovyの「メジャー」バージョンはずっと「ドット」バージョンでした。これはこの業界ではちょっと異例で、普通はメジャーバージョンは新しいメジャー番号を持つものです。Groovyのバージョン番号体系は、外の人や新たにGroovyを始める人からは少し奇妙に思われてきました。また、マーケティング的観点では、もし1.10バージョンをリリースすることになった場合、辞書的に逆順（数学的にも1.10 < 1.9）になってしまうという問題があります！バージョン番号の大きな変更は初めてのことというわけではありません。Groovyは1.1から1.5になりましたし、最近Grailsも次期メジャーリリースを1.4から2.0に変更しています。
そんなわけで、いつまでも実現しそうにない神話的な "2.0" バージョンではなく、次のメジャーリリースが 2.0 になります。その後は、たぶんいつも通りいくつかの2.xバージョンをリリースするでしょう。そしてメジャーバージョン番号を持つものについても、ほぼ毎年1つのメジャーバージョンをリリースするという、これまでと同じ方針を採用します。したがって、2012年の初期に2.0の最終版がリリースされるとして、その後、2013年にリリースされるであろう後継のメジャーバージョンが 3.0 になります。でも、私たちはGoogle ChromeやMozilla Firefoxのような超高速の番号体系は採用しないのでどうかご心配なく！
2.0の何がそう特別なの？
静的型チェック
私たちはGroovyの静的型チェックのサポートについて作業を進めて来ました。
私たちは、多くのJavaプロジェクトで、GroovyがJava API用のシンプルで強力なスクリプト言語として使われていることに気づきました。Grooovyの動的な特徴は特に活用せず、より良いシンタックスを持つJavaとして使われているのです。この用途では、開発者はメソッドやパラメータ、変数名などのミスタイプや、不正な代入などを防ぐ意味で、より厳格な型チェックを好むことが多いようです。後の実行時ではなく、コンパイル時にコンパイラが問題を検出すれば、この種の誤りに対するフィードバックをより早期に得ることができます。これは、特に変更される可能性があるAPIを使っている場合に役立つでしょう。
静的型チェックについては、これまでGroovyメーリングリストでも議論されてきましたが、その実装方法や振る舞いなどについてのフィードバックは引き続き歓迎しています。ぜひこのトピックについてあなたの考えやアイデアをお聞かせください。
この新しい特徴をカバーしたGEP(Groovy Extension Proposal: Groovy拡張提案)も作成しました：
http://docs.codehaus.org/display/GroovyJSR/GEP+8+-+Static+type+checking
また、SpringSource/VMwareのJochenと私のチームに新たに加わり、この機能を担当しているCédricも現状についてブログに詳しく書いています：
http://www.jroller.com/melix/entry/groovy_static_type_checker_status
上の二つのドキュメントには、Groovy 2.0.0-beta-1での静的型チェックの使い方の具体例なども示されていますので、ぜひ読んでみてください。なお、この機能はまだベータ版であることを忘れないでください。みなさんのフィードバックでAPIが変わったり進化するかもしれません。
静的コンパイル
静的型チェック、型推論機能、フローセンシティブタイピングなどによって、Groovyコンパイラはコードが実際に何をしているのかずっと賢く理解できるようになりました。上述のようなJava APIに対するスクリプティングの場合、コンパイラにGroovyのMOPを経由しない、Java流の直接のメソッドコールを生成させることができ、Javaと同レベルの性能が実現できるかもしれません！
2.0では、賢くなった新コンパイラとその基盤を活かした静的コンパイルを検討中です。初期サポートを盛り込んだ新しいgitブランチを作るので、みなさんもこの方面の進捗を監視することができるでしょう。
Groovy++はどうなったの？
Alex TkachmanとRoshan Dawraniの素晴らしい業績であるGroovy++拡張プロジェクトは、私たちに明確なヒントを与え、Groovyでの静的型チェック・コンパイルのサポートの重要性を確信させてくれました。Groovyのコア部分に関する考え方の違い、例えば、私たちが欲しかったものに比べ広すぎる守備範囲（永続コレクション、新しい演算子、トレイト、新しいマップスタイルのクラスなど）といった理由から、Groovy++をGroovy 2.0に単純に統合することはできませんでした。また、私たちはプリミティブ型の最適化作業や、静的型チェック・コンパイル、invoke dynamicサポートなどにうまく適応できるようにGroovyコンパイラのインフラを進化させたかったのですが、このためにはGroovy++に大幅な改造を加える必要があったのです。とは言え、Groovy++チームと協力し、Groovy++の開発経験から学ばせてもらうことはもちろん大歓迎です。
私たちはコミュニティにも参加し、静的型チェック・型推論のさまざまな側面を議論しました。新たなデータ構造を導入したり、既存の機能（非final変数を持つクロージャのような）を制限したりすることなく、できる限り従来のGroovyセマンティクスに近づけるためです。この結果、静的型チェック・コンパイルの導入はGroovy開発者の負担にならず、追加モードと従来の動的モード間のセマンティクスの違いによるインパクトは最小限です。
2.0以後は？
静的型チェック・コンパイルやinvokeDynamicのサポートによって、このリリースはまさにGroovy 2.0という命名にふさわしいものになったと思います。では次は何でしょう？
2.x / 3.0以降で取り組みたい項目の中では、Groovyの文法をAntlr 2.xからより新しいバージョンに移行させることに興味があります。Antlr 3はしばらく前にリリースされていますが、この夏に行った移行の試みはまだ成果がでていません。しかし、2.0が出た後にもう一度調査し、Antlr 3で行くのか、それともGroovy 3.0をリリースする頃には使えるはずのAntlr 4で行くのかを決めるつもりです。
メタオブジェクトプロトコルの再設計(MOP 2)については過去に何度も言及してきました。Groovy 2.0のinvoke dynamicサポートや、JITのinvoke dynamic性能の調整などの経験に基づき、invoke dynamicの利点をフル活用して、より高性能な動的機構を実現する、MOP再設計のより良いビジョンを持つことができるはずです。
他にも検討したい課題はたくさんありますが、現時点でGroovy 3やそれ以後を語るのは少し時期尚早でしょう。開発者の生産性をさらに向上させるためにGroovyに何を追加するべきか、少し考えてみましょう。みなさんの日々の業務をシンプルにするために将来のGroovyに求めるものをぜひお聞かせください。
今日のGroovyはみなさんのアイデアや貢献の賜物なのです！
重要なリンク
変更点の詳細についてはJIRAの変更履歴をご覧ください：
- Groovy 1.8.4: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10242&version=17852
- Groovy 2.0 beta 1: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10242&version=17925
そしてこれらの新リリースはGroovyサイトのいつものダウンロードエリアから入手できます：
http://groovy.codehaus.org/Download?nc
Groovyに関わるすべての方に改めて感謝するとともに、みなさんからのフィードバックを楽しみにしています！
Groovy開発チーム
