2010年の終わりまでJava2SEv1.4を使い続けています。それは本当に厄介ですが、仕方がありません。すでにいくつかの新機能を使用するには、どのようなオプションが必要ですか？私は次のようないくつかの方法を考えることができます
たとえば、 RetrotranslatorまたはRetroweaverを使用してバイトコードを変更します。
ライブラリのバックポート、たとえば同時バックポート。ただし、これはジェネリックには役立ちません。
チェックされたコレクション、ヘルパーメソッドを使用したVarargsなどのJava5機能のエミュレーション。
プリコンパイルによってソースコードを変更し、最終的なコンパイルの前に1.5のものすべてを削除します。たとえば、Declawerを使用するとこれを行うことができます。
私は、Weblogicと「実際の」ものを使用した実稼働環境での非常に前向きな経験に最も興味があります。
回答ありがとうございます。これは、関連するすべての回答と私自身の調査の要約です。
バイトコードの変更: The Retros
これは、「レトロ」ツール ( Retrotranslator、Retroweaver、およびJBossRetro ) によって行われます。Retrotranslator は、それらのツールの中で最も成熟しており、アクティブであるようです。これらのツールはすべてのクラスをスキャンし、バイトコードを変更して Java 5 および 6 の機能を削除します。多くの Java5 機能がサポートされており、サードパーティのバックポート ライブラリを使用するものもあります。このオプションは最も人気があり、ユーザーからいくつかの肯定的なフィードバックがあります。実験では、期待どおりに動作することが示されました。developerworksの簡単な概要を参照してください。
長所: 完全に Java 5 で開発し、モジュールやあらゆる種類の JAR をビルドできます。最終的には、すべてのクラスを Java 1.4 に変換し、EAR をパッケージ化するだけです。これは、Retrotranslator の Maven 統合 ( org.codehaus.mojo:retrotranslator-maven-plugin) を使用して簡単に実行できます。
短所: 保守的な環境では、変更されたバイトコードをデプロイすることはできません。レトロステップの結果は、どのコーダーにも表示されず、承認できません。2 つ目の問題は、恐怖です。不可解な生産上の問題がある可能性があり、その原因としてレトロ コードが別の段階にある可能性があります。アプリケーション サーバー ベンダーは、バイトコードが変更されたため、ヘルプを拒否する場合があります。したがって、誰もそれを本番環境で使用する責任を負いたくありません。これは技術的な問題というよりも政治的な問題であるため、解決策はありません。それは私たちに起こったので、私はさらなるオプションを探していました:-(
Java5 から Java 1.4 へのコンパイル: jsr14 Java5 ソースを有効な Java 1.4 バイトコードにコンパイルする
、サポートされていないオプションがあります。javac -source 1.5 and -target jsr14varargs や拡張 for ループなどのほとんどの機能は、とにかくコンパイラによって変換されます。ジェネリックと注釈は削除されます。列挙型はサポートされておらず、オートボクシングについてはわかりませんvalueOf。メソッドはほとんど Java5 で導入されたものだからです。
短所: バイト コードのみが変換され、ライブラリの使用法は変更されません。そのため、Java5 固有の API を使用しないように注意する必要があります (ただし、バックポートを使用することはできます)。さらに、すべてのモジュールを同時にビルドする必要があります。これは、開発時に一般的な注釈情報を含む Java5 コードが必要になる可能性が高いためです。そのため、Java 1.4 プロダクション用にプロジェクト全体をゼロから構築する必要があります。
ソースをJava 1.4
に戻します: Declawer 生成されたソースは「少しファンキーですが、それほど悪くはありません」。
長所: 生成されたソースが利用可能であり、レビューできます。最悪の場合、このソースで修正を行うことができます。ソースは有効な Java であるため、「魔法」はありません。JAD (Java decompiler) を使用して Java 1.4 ソースを再度入手する人もいます。デバッグ情報を使用してコンパイルし、内部クラスを使用しない場合、Jad readable の出力は読み取り可能です。
短所: と同様に-target jsr14、展開に追加の手順が必要です。ライブラリにも同じ問題があります。
ソースを Java 1.4 に戻す:
手 自動で繰り返されるビルド プロセスの場合、これはもちろん役に立ちませんが、1 回限りの変更の場合は合理的です。可能なことを自動化するだけです。自家製の変換ツールの作成については、Antlr を参照してください。
バックポートされたライブラリ:
問題は、Java5 には古い JRE では利用できない新しいライブラリも含まれていることです。関連する質問を参照してください。幸いなことに、Java5 の一部の機能を提供するバックポートされたライブラリがいくつかありますが、ジェネリックなどの言語機能をシミュレートすることはできません。
Java 1.4 コードで Java5 機能をエミュレートする: Java 1.4
を使い続けながら生活を楽にするためにできることをいくつか考えていました。最も重要な機能は型安全なコレクションです。ここにいくつかのアイデアがあります:
asList引数とその配列を許可するメソッドを追加1,2,...,nします (varargs をシミュレートするため)。1,...,n引数を配列に変換する) のメソッドでありvalueOf、一部のヘルパー クラスに配置できます。ソースコードのプリコンパイル。最終的なコンパイルとデプロイの前に1.5個すべてを削除します。これを行うことができるツールはありますか？
はい。それらはRetrotranslatorまたはRetroweaverと呼ばれます。Generics（とにかくコンパイラのためにのみ存在する）を除いて、単純に「1.5のものを取り除く」ことはできません。列挙型（および場合によっては他のいくつかの機能）は、機能的に同等のコードに置き換える必要があります。これはまさにそれらのツールが行うことです。
Java 1.4 はしばらくの間 EOL であったことに注意してください。Java 5.0 は 2009 年 10 月 8 日に EOL になります。誰かが 2010 年までに Java 5.0 を約束するとしたら、その理由をお尋ねします!