Eclipse財団とゴールドマン・サックスは、共同のプロジェクトとして、人気のオープンソースフレームワークであるGS Collectionsの開発をEclipse財団へ移行することを発表した。この移行は、com.gs.collections のクローンがブランド名称を変えてorg.eclipse.collections eclipse-collections-apiとしてMaven Centralに現れた2015年12月下旬からすでに期待されていたものである。
InfoQはGS Collectionsの創作者であるDonald Raabにこの新しい関係について聞いた。
InfoQ: Eclipse財団への移行を決めた要因は何ですか？
Raab: 過去数年で、GS Collectionsの採用が安定して増えてきている事を確認しました。GS CollectionsがGitHubにリリースされてから、フレームワークへの貢献を受け入れているかという質問を何度となく受けましたが、これまでの我々の回答は「いいえ」でした。Eclipse Collectionsでは同じ質問に対して確実に「はい」と答えることができます。Eclipse Collectionsに貢献したい開発者のための、 明確なプロセスがあるからです。このEclipse財団への移行についてはJavaOne 2015の直前に当社の gs.com/engineeringサイトにて発表しました。Eclipse財団と提携することで、Eclipse Collectionsプロジェクト周辺にコントリビューターとコミッターによる活気あるオープンなコミュニティを育てていきたいと考えています。Eclipse財団にはその実現の助けとなる成熟したプロセスやツールがあります。
InfoQ: 移行までの道のりを詳しく教えていただけますか？
Raab: 2015年10月、ゴールドマンサックスはEclipse財団の戦略メンバーに参加し、Eclipse Collectionsのプロジェクト案を提出しました。2015年12月にGS CollectionsのEclipse財団への移行が完了し、Eclipse Collectionsにブランド名称を変更しました。パッケージ名はcom.gs.collectionsからorg.eclipse.collectionsへと変更されましたがバージョンはそのままで、GS Collections 7.0からEclipse Collections 7.0への移行となります。
InfoQ: これらは全く一緒のものですか？
Raab: はい、GS Collections 7.0とEclipse Collections 7.0は機能的に同一のものとなります（訳注：上記にあるようにパッケージ名は異なります。）。
InfoQ: コレクションについて教えてください。Eclipse Collectionsはjava.util Collections、Google GuavaやApache Commons Collectionsなど他の広く使われているコレクションフレームワークと何が違うのでしょうか？
Raab: Eclipse Collections は例に挙げられたフレームワークが各々持っている機能をすでに備えています。それに加えて、他のどのフレームワークにもない機能もあります。このスコープの広さと完全性が Eclipse Collectionsの特徴です。
Eclipse Collections はSmalltalk のコレクションプロトコルに影響を受けた豊富な関数型APIを含んでいます。Eclipse Collections内のほとんどの型が継承するRichIterableインターフェースには、100を超えるメソッドが備わっています。
Eclipse Collectionsには、標準のJDKコレクションのクラスであるArrayList、HashSet、HashMapよりも効率がよい代替実装があります。豊富な関数型API に加えて、メモリ効率とパフォーマンスがより良いクラスが欲しかったのです。さらに、メモリ効率の良いイミュータブルなコレクションとプリミティブコレクションも必要でした。Eclipse Collections 7.0はJavaバージョン5以降をサポートしているので、（訳注：Java 5 - 7のバージョンを使っているユーザーであっても）Eclipse Collectionsは今すぐ使い始められ、後にJava IDEのリファクタリング機能を活用してJava 8にアップグレードできますよ。
InfoQ: Eclipse Collectionsの中でも特に興味深いコレクションと機能の例を挙げてください。
- Map、Set、Bag（順序のないListの一種）、Multimapsはメモリ効率が良い実装になっています。
- コレクション上で直接扱える豊富な即時実行API（ハンバーガーのﾊﾞﾝｽﾞのようにstream()とcollect()ではさむ必要はありません！（訳注：意訳かつ原文で省略されているStream APIのメソッド名を追加しています））。
- 豊富なAPIを扱えるプリミティブコレクション。
- 最適化された遅延実行、即時実行可能なparallel API。
- インターフェース上で契約としてイミュータブルなコレクション（可変なメソッドを持たない）。
- すべてのコレクション型に対して完結で一貫性のあるファクトリが利用可能。
- 再利用可能な遅延Iterable。
- 繰り返し練習することで技を研く、武道の型を模したkata チュートリアル。
すべてのコレクションはjava.util Collectionインターフェースを実装しているので、もちろんStream APIを使うこともできます。Eclipse Collectionsはコミュニティからの貢献を受け付けています。
InfoQ: GSCはいつからあるのですか？
Raab: GS Collectionsは2004年にCaramelという名のフレームワークとしてゴールドマン・サックス社内で開発が始まりました。
InfoQ: いつ社外に公開したのですか？
Raab: GS Collectionsは2012年1月にGitHubに公開されました。 Eclipse CollectionsとしてGitHubに公開されたのは2015年12月です。
InfoQ: このフレームワークの開発には何人のゴールドマン・サックスの開発者が携わってきたのでしょうか？
Raab: 長い年月を経て約40人のゴールドマン・サックス開発者がCaramelとGS Collectionsの開発に携わってきました。
InfoQ: この共同はGS Collectionsの未来にどういう影響をもたらしますか？
Raab: バージョン7.0がGS Collectionsの最後の機能リリースになりますが、ゴールドマン・サックスのGitHubとMaven Central上にApache 2.0ライセンスで提供し続けます。GS Collectionsにはバグ修正のみが適用されます。今後の機能開発はEclipse財団のGitHubでEclipse Collectionsに対してのみ行われます。今ではEclipse財団への移行が完了し、すべての開発はGitHub上でオープンに行われます。開発計画や今後のEclipse Collectionsリリースのロードマップなどが提供されてプロジェクトの透明度も増すでしょう。Eclipse Collections 8.0のリリースではJava 8の機能をライブラリ内で直接利用し始めます。Eclipse Collectionsの7.xリリースがJava 5 - 7をサポートする最後のリリースになります。
InfoQ: 使用統計を教えていただけますか？
Raab: ゴールドマン・サックス社内ではかなり多く使用されています。当社には3千～4千のJava開発者がいます。ゴールドマン・サックス社内ではバージョン7.0がMaven Centralに12月末にリリースされて以来すでにEclipse Collectionsへの移行を開始しています。
社外では使用数を計るのは難しいですが、現在GS CollectionsのGitHubリポジトリには1,430を超えるスターがついており、Maven Centralでは毎月2万のダウンロード数を記録しています。