Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。2.0は、この言語に静的型チェックや静的コンパイルといった重要な静的機能を導入します。7対応の改良も取り入れられ、また、以前に比べよりモジュール化されています。この記事ではこれらの新機能をより詳しく見ていきます。"静的なテーマ"静的型チェックGroovyは生来、そして将来にわたって常に動的な言語です。(冗長な記述が少なく、より強力な機能を持つJava)として使われることがよくあります。実際、多くのJava開発者がより表現力のあるビジネスルールを書いたり、顧客ごとにアプリケーションをカスタマイズするための拡張用言語として、GroovyをJavaアプリケーションの中に組み込んで使っています。いったJava指向のユースケースでは、開発者はこの言語が持つ動的な機能のすべてが必要なわけではありません。開発者はGroovyのコンパイラにも、いつもjavacがくれるようなフィードバックを期待していることが普通です。変数名やメソッド名のタイプミス、間違った型への代入などには、実行時エラーではなくコンパイルエラーが期待されています。2に静的型チェックのサポートを盛り込んだのはこういった理由からです。抽象構文木)変換メカニズムを使って作られています。この仕組みをご存知ない方は、アノテーションをトリガーとして起動されるオプションのコンパイラプラグインだと考えてください。オプション機能ですので不要なら使う必要はありません。静的型チェックを起動するには、チェックを有効にしたい範囲に応じて、対象メソッドまたはクラスに@TypeCheckedアノテーションを付けるだけです。naaammme}test()メソッドに@TypeCheckedアノテーションを付けました。これは、コンパイル時に指定したメソッドの静的型チェックを実行するようGroovyコンパイラに指示します。name変数もタイプミスして出力しようとしています。コンパイラは2つのコンパイルエラーを報告するでしょう。"today"}この例では、int変数にDateは代入できないことや、メソッドシグネーチャで指定されているDate値のかわりにStringは返せないことをコンパイラが指摘します。スクリプトの中ほどのコンパイルエラーにも注目してください。これは間違った代入が検出されるということだけでなく、型推論が行われていることも示しています。型チェッカーは、String配列を処理しているのだから当然letters[0]はString型である、ということを知っているのです。型推論についてもう少し型推論に触れたので、他の事例についても見てみましょう。}}プリミティブ型のint値を返すメソッドを考えます。caseブロックといったさまざまな構造からの戻り値もチェックできます。elseブロックの分岐の一方で、プリミティブのint型ではなくString値を返そうとし、コンパイラがそのことを検出しています。静的型チェッカーは、Groovyがサポートしているある種の自動型変換については文句を言いません。}}name変数はdefで定義されていますが、型チェッカーはそれがString型であることを理解しています。この変数が挿入文字列の中で使われている部分ではStringのtoUpperCase()メソッドを、その次の行ではGDKがStringクラスに追加しているtrim()メソッドを呼べばいいことを知っています。最後に、プリミティブintの配列の要素をイテレートするところでは、この配列の要素がintであることももちろん理解しています。覚えておくべき重要なポイントは、静的型チェックの使用はGroovyで利用可能な機能を制限するということです。コンパイル時に静的に型がチェックできないので、実行時の動的機能の大部分は使えません。したがって、メタクラスを使って実行時に新しいメソッドを追加することはできません。ある特定の動的機能(例えばGroovyのビルダーのような)を使う必要がある場合、静的型チェックを使わないことはあなたの自由です。@TypeCheckedアノテーションは、クラスレベルまたはメソッドレベルで付けることができます。クラス全体で型チェックをしたければクラスにアノテーションを付け、いくつかのメソッドだけで型チェックをしたければそのメソッドだけにアノテーションを付ければよいのです。importしておけば、短く@TypeChecked(SKIP)でも可)を付けることもできます。greeting("Cédric").contains("<div>CÉDRIC</div>")型推論とinstanceofチェック現在の製品版のJavaは一般的な型推論をサポートしていません。そのため、コードが非常に冗長だったり定型的な記述であふれていることもしばしばです。これによってコードの意図が不明確になったり、強力なIDEなしではコーディングが困難になったりしています。instanceofチェックもこの一例です。ifの条件節でinstanceofを使ってある値のクラスを確認した直後のブロックであっても、その値のメソッドを使うためには依然としてキャストが必要なのです。Groovyでは、通常モードでも新しい静的型チェックモードでも、こういったキャストは完全に排除することができます。次のifブロック内ではNumber型であることを知っているのです(キャストは一切不要)。Bound)静的型チェッカーの型推論は、オブジェクトの型についてのきめ細やかな理解という点ではさらにもう一歩先に進んでいます。3.14]}この例ではIntegerとBigDecimalということで、直感通りNumberのリストが返されます。Bound)*訳注」と呼ばれるものを計算し、それはSerializableかつComparableであるNumberのリストになります。Comparable>という感じになるでしょう。*訳注:ここでは型インタフェースの公約数のようなものだと考えるとわかりやすいと思います。フロータイピング良いプラクティスとしておすすめできるものではありませんが、ときどき開発者は型付けしていない変数を使いまわして、異なる型の値を格納することがあります。エラー!varはint型}var変数はintで初期化され、その後Stringが代入されています。「フロータイピング」アルゴリズムはこの代入の流れ(フロー)を追跡し、この変数が現在Stringを格納していることを理解しているので、GroovyがStringに追加したtoInteger()メソッドを呼び出しても静的型チェッカーは何も問題を検出しません。次に、var変数に再び数値が代入されます。その後toUpperCase()が呼ばれると、IntegerにはtoUpperCase()メソッドがないので、型チェッカーがコンパイルエラーを出力します。フロータイピングアルゴリズムにはいくつか特別なケースがあります。変数がクロージャと共有される場合です。コンパイルエラー!}varローカル変数にはStringが代入されています。その後、乱数の値によってはvarにDateが代入されるかもしれません。通常、このクロージャ内のif文の条件が満たされるかどうかは実行時にしかわかりません。したがってコンパイルの時点で、varが今Stringを格納しているのかDateを格納しているのかをコンパイラが知るすべはありません。これがコンパイラがtoUpperCase()の呼び出しに文句を言う理由です。変数がStringを格納しているかどうかを推論できないのです。var.foo()}上のtest()メソッドでは、varにまずAのインスタンスが代入され、次に(後で呼ばれる)クロージャ内でBのインスタンスが代入されています。そこで、varは少なくともA型であると推論できます。Groovyコンパイラに追加されたこれらのチェックはすべてコンパイル時に行われるものです。生成されるバイトコードは以前の動的なコードとまったく同じです。その振る舞いは一切変わっていません。コンパイラがプログラムの型情報についてより詳しくなったことで、面白い可能性も広がります:この型チェックされたコードを静的にコンパイルしたらどうでしょう?明らかな利点は、生成されるバイトコードをjavacコンパイラが生成するバイトコードに近づけることで、静的にコンパイルされたGroovyコードをJava並みの速さにできることでしょう。次の節では、Groovyの静的コンパイルについて見ていきます。JVM命令および関連APIをサポートします。これはJavaプラットフォーム上での動的言語の開発を助けるもので、Groovyの動的呼び出しのパフォーマンスをさらに改善します。7は実業務ではまだそう広く使われているとは言えません。誰もが最新版を使う機会があるわけではないのです。2.0では大した変化は見られないかもしれません。幸運にも、Groovy開発チームはこういった開発者も興味深いパフォーマンスの改善を得られるように、型チェックされたコードを静的にコンパイルできるようにしました。生成されるバイトコードはjavacが生成するバイトコードのようになり、高速に実行されます。@CompileStaticは@TypeCheckedアノテーションのようにクラスとメソッドに付けることができます。@CompileStatic(SKIP)を使えば、クラスが@CompileStaticでマークされていても特定のメソッドの静的コンパイルをバイパスすることができます。Java風のバイトコード生成のもう1つの利点は、アノテートしたメソッドのバイトコードサイズが、通常、動的メソッドのためにGroovyが生成するバイトコードより小さくなることです。これは、動的なケースのバイトコードには、Groovyの動的機能をサポートするためのGroovyランタイムシステムを呼び出す余分な命令が含まれるからです。その悪影響を避けるために使うこともできます。Groovyのような言語で利用できる動的機能は、開発者にとてつもないパワーと柔軟性を与えます。注意を怠ればこれが意図しない結果をもたらすこともあります。これが「モンキーパッチ」と呼ばれていることもおそらくご存知でしょう。あなたをモンキーパッチの影響から守ってくれます。静的コンパイルされたコードはGroovyの動的ランタイムシステムを経由しないからです。通常のAST変換メカニズムはすべて今まで通り使用可能です。大部分のAST変換はコンパイル時に処理されるからです。パフォーマンスについて言えば、Groovyの静的コンパイルされたコードは通常、javacのものとほぼ同程度の速さです。開発チームが使ったいくつかのマイクロベンチマークでは、多くのケースでJavaと完全に同等なパフォーマンスを示し、ときどき少し遅いことがある程度でした。これまでは、パフォーマンスをさらに上げたい場合には、ホットスポット部分をJavaで書き直すよう開発者にアドバイスしてきました(JavaとGroovyが透過的かつシームレスに統合されているおかげです)。静的コンパイルオプションを得た今、これはもう当てはまりません。プロジェクト全体をGroovyで開発したいと願っている人たちは、実際にそれが可能なのです。7関連テーマGroovy言語の文法はJavaの文法がベースになっています。Groovyは気の利いたショートカットを追加して開発者の生産性を高めています。Javaとのシンタックスの類似性は、その学習の容易さから常にGroovyのセールスポイントであり、幅広い採用の原動力にもなっています。Coin"で追加されたシンタックスの改良の恩恵を受けることも期待しているでしょう。dynamic"という久しぶりの新バイトコード命令なども導入されています。開発当初から(2003年からです!)GroovyはJavaを拡張したシンタックスや機能を持っていました。7ではStringだけが追加で使えるようになりました)。Coinのシンタックス拡張のいくつかは、Groovyにはすでに備わっていたわけです。2はこれらもサポートします。Kitの豊かなAPIを通してすでにさまざまな代替手段が提供されています。6以前では、数値は10進か8進、または16進で表記しました(Groovyでも同じ)。41285数値リテラル中のアンダースコア長い数値リテラルを書く場合、数字のグルーピング(3桁ごと、ワード単位など)がわかりにくくなります。0b11010010_01101001_10010100_10010010マルチキャッチブロック例外をキャッチするとき、複数の例外を同じように処理したければcatchブロックを複製することになります。この回避策としては、共通処理を別メソッドに切り出すか、あるいはExceptionや最悪Throwableといったレベルで全部まとめてキャッチする、というより醜い方法をとることになります。呼ばれる新しいバイトコード命令がその関連APIとともに導入されました。この狙いは、動的言語の実装者たちがJavaプラットフォーム上に彼らの言語を構築する仕事を助けることです。定義することで、動的メソッド呼び出しを簡潔に書くことができるのです。パフォーマンス改善に将来有望ではあるものの、まだJVM内で完全には最適化されていないということです。現時点では、必ずしも常に最高のパフォーマンスをもたらしてくれるわけではないのです。今後アップデートを重ねれば、最適化は確実に進むでしょう。siteキャッシュ」によってメソッドの選択と起動を高速化したり、メタクラスレジストリによってメタクラス(動的実行時におけるクラスに相当)を管理したり、Java並の速さでネイティブのプリミティブ演算を実行したり、といったさまざまな独自の実装テクニックが導入されてきました。登場により、パフォーマンスの向上やコードベースをシンプルにするために、Groovyの実装をこのJVMバイトコード命令とAPIの上に構築し直すことができるようになりました。Groovyの一連のJARファイルの新バージョンを使うことができます。付いているので簡単に識別できます。付きのJARを使うだけでは不十分です。コマンドを使うとき、--indyフラグを指定する必要があります。5や6をコンパイルターゲットにできるということも意味しています。2.0に対応していませんが、近日中には対応する予定です。dynamicサポートを有効にするフラグはまだ存在していません。先ほどと同様、GMavenもすぐにアップデートされるでしょう。エッジケースの最適化のために余計なバイトコードを生成するプリミティブ最適化機能をオフにすることも必要です。改良されたJITを持つでしょう。dynamicサポートを使わない方が速いプログラムもあることがわかりました。JVM自体の調整がまだ不十分なため、完全な最適化にはまだ長い道のりがあることに気づいています。7のアップデート(特にアップデート8)にはさっそくこういった改良が含まれるはずなので、状況は良くなる一方です。さらなる改良が確実に期待できます。2.0の新機能の旅を終わりたいと思います。Javaと同じように、Groovyも単なる言語ではありません。UI構築、Antスクリプト、JMX統合、SQLアクセス、Servletなどなど、さまざまな用途のAPIの集合体でもあります。Groovyの配布形態は、こういったすべての機能とAPIを1つの大きなJARに同梱していました。すべてのアプリケーションがこのすべての機能を常に必要としているわけではありません。Webアプリケーションを書いているときはテンプレートエンジンとServletに興味があるかもしれませんが、デスクトップクライアントプログラムを開発しているときはSwingビルダーしか必要ないのかもしれないのです。Groovyモジュールこのリリースでのモジュール化に関する最初の目標は、従来のGroovyのJARを、より小さなモジュール、より小さなJARに分割することです。2では、すべてをクラスパスに入れるのではなく、必要なモジュールだけを選んで使うことができます。JARもまだ提供しています。サポート付きでコンパイルされたJARも提供しています。拡張モジュールGroovyのモジュール化を進める作業は、拡張モジュールという面白い新機能も生み出しました。Groovyをより小さなモジュールに分割していく過程で、モジュールで拡張メソッドを追加する仕組みが作られたのです。これによって拡張モジュールは、JDKやサードパーティのものを含む他のクラスにインスタンスメソッドやstaticメソッドを提供できます。GroovyはJDKのクラスを拡張するのにこの仕組みを使い、StringやFile、各種ストリームなどのクラスに便利なメソッドを追加しています。getで取得できます。このモジュールによる拡張メソッドは、静的型チェッカーやコンパイラにも認識されることに注目してください。既存の型に新しいメソッドを追加する方法を見ていきましょう。既存の型に新しいメソッドを追加するためには、まずそのメソッドを含んだヘルパークラスを作る必要があります。ヘルパークラスの中のすべての拡張メソッドは、public(Groovyではデフォルトですが、Javaで実装する場合は明示が必要)、かつstatic(利用されるのは対象クラスのインスタンスですが)にします。これらのメソッドは必ず1個以上のパラメータをとり、最初の1つは実際にメソッドが呼ばれる対象のインスタンスです。続くパラメータは、そのメソッドが呼ばれるときに実際に渡されるパラメータになります。これはGroovyのカテゴリと同じ規約です。Stringに、パラメータで指定した人に挨拶するgreets()メソッドを追加したいとします。}}staticメソッドの追加staticな拡張メソッドの場合も仕組みや規約は同じです。Randomに、2つの値の間をとるランダムな整数を得る、新しいstaticメソッドを追加してみます。4)拡張モジュールディスクリプタ拡張メソッドを含んだヘルパークラス(GroovyでもJavaでもよい)を書き終えたら、次にモジュールのディスクリプタを作る必要があります。モジュールアーカイブのMETA-INF/servicesディレクトリの中にorg.codehaus.groovy.runtime.ExtensionModuleという名前のファイルを作ります。モジュールの名前、バージョン、拡張メソッドを持つヘルパークラスの名前をカンマ区切りで並べたリスト(インスタンスメソッド分とstaticメソッド分)、以上4種類の必須フィールドをGroovyランタイムに伝えるために定義できます。importなどの手続き一切なしで自分のコード内で拡張メソッドを使うことができるようになります。CentralのようなMavenリポジトリから依存モジュールを取得できます。@GrabResolverアノテーションを追加して、モジュール探索のための独自ロケーションを指定することも可能です。する場合、拡張メソッドのインストールも自動的に行われます。id、versionと一致しているべきです。まとめGroovyはJava開発者の間でとても人気があり、アプリケーションのニーズにこたえて成熟したプラットフォームとエコシステムを提供しています。Javaプラットフォームでの開発効率をさらに向上させるべく、Groovy開発チームは言語やAPIの改良を休みなく続けています。5以降を使うすべての開発者に静的コンパイルを提供。動的機能の一部をあきらめれば「モンキーパッチ」の影響を防いだり、Javaと同レベルのスピードを得ることも可能に。Coin拡張のサポートにより、これまで通りGroovyとJavaのシンタックス類似性を維持。静的型チェッカーにより、GroovyをJava用スクリプト言語として使う開発者にjavacと同レベルのフィードバックと型安全性を提供。新しいレベルのモジュール性により、より小さな配布形態を実現。APIの成長と進化、そしてユーザによる既存の型への拡張メソッドの追加などが可能に。Laforge氏はGroovyの公式なプロジェクトマネージャであり、CodehausでのGroovy動的言語プロジェクトを指揮しています。Engine用のGroovyアプリケーション開発のための軽量ツールキット、Gaelykプロジェクトも立ち上げました。Language)といったテーマで数多くのプレゼンテーションを行っています。GuillaumeはフランスのJava/OSS/ITポッドキャスト、LesCastCodeursの創立メンバの一人でもあります。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。