OSSライブラリで複数のJavaバージョンをサポート
私は、オープンソースハードウェアコミュニティが公正/中程度に利用する最初のOSS Java lib（GitHub/Maven）を立ち上げる過程にあります。
私はこのライブラリをJava 8で作成し、Gradle2.4でビルドを管理しています。今年後半にJava 9が解き放たれ、積極的に保守したいと思います。いくつかの理由から、ライブラリの個別のバージョン（JVMバージョンごとに1つ）。
- Java 9の機能と言語をサポートすると、パフォーマンスとAPIの改善につながる可能性があります
- しかし、ライブラリを強制的にrequire Java 9は、ライブラリにアップグレードする準備ができていない大規模なアプリケーションに過度の困難をもたらします
- したがって、両方を並行してサポートする（つまり、定期的なリリースを継続する）ことで、全員が幸せになります
これらのGradleサブプロジェクトを同じリポジトリの下に作成するか、独自のトップレベルプロジェクトに配置するかで悩んでいます。そう：
- 単一の
myawesomelibトップレベルプロジェクトとJava8/およびJava9/その下のサブプロジェクト;または - 2つの別々の
myawesomelib-Java8およびmyawesomelib-Java9トップレベルのプロジェクト。または - 他に何かありますか？
私の傾斜はCIの目的で2つの別々のトップレベルプロジェクトを使用することです（一方にコミットしても他方へのビルドがトリガーされないようにするため）が、これまでこの問題に対処する必要はありませんでした。
ですから、これはすべて、OSSライブラリで複数のJVMバージョンのサポートを管理するための一般的な手法と、これらの手法の実装に役立つGradleの機能は何ですか？
現在のJava-8バージョンに比べてJava-9にはどのような利点がありますか？
私はあなたの図書館を利用している人を意味します。
同じライブラリの2つの同時バージョンをデプロイすることには、多くの欠点があります。 2つの間でAPIの互換性を維持する必要がありますか？また、コードを2回保守し、バグを2回修正する必要があります。これは、必然的にコードに多少の違いが生じるためです。何もない場合は、V8でリリースするだけで、V9でも同様に機能しますのでご安心ください。
一般に、独自のプロジェクトよりも大規模に使用するライブラリを作成する場合、ライブラリは非常に保守的で、可能な限り低いバージョンのJavaをサポートする傾向があります。クロージャが必要ですか？NIOを使用しますか？いいえ？おそらくv6に固執し、より多くのユーザーにリーチするのが最善でしょう。
これについての私の個人的な見解は、JDKの可能な限り低いバージョンでリリースされた単一のコードベースを試してみて、それをそのままにしておくことです。 Java 6 under Java 8で構築されたライブラリを使用すると、正常に機能します。Java 9が登場しても、引き続き機能します。問題なく。
ライブラリをプロジェクト外で使用しない場合は、プロジェクトで使用するJDKのバージョンを使用できます。繰り返しになりますが、2つの別々のバージョンを維持しないでください。これは、2倍の作業であり、メリットはほとんどありません。
複数のバージョンをサポートする必要がある場合は、2つのバージョンを分岐してこのように維持することをお勧めします。これは、サポートする一般的なVCSツール（git、svnなど）に自然に適合します。複数のコンパイル環境をサポートしたり、ビルドスクリプトで回避して何をいつコンパイルするかを確認したりする、維持するファンキーなプロジェクトレイアウトはありません。それでも、私が考えるには、メリットはかなり大きくなければならないでしょう。