これは、あなたが考えているほどすぐにはわかりません。
まず、 OracleはJava 2013年2月の時点で6 のパブリックサポートを停止していますが、プレミアサポートは2013年12月に、延長サポートは2016年12月に行われます。少し長い尾があり、その上に永遠に続くサステインのサポートがあります。
次のメジャーJavaベンダー、IBM、 Java 6 のサポートの終了も投稿していないようです引き続きサポートJava 5!)
第3に、Appleがいます。2013年6月の最新のパッチでは、 "会社はサポートポリシーを白黒で明記していません" だれかが推測しているようですが、彼らが扱うJava 5は、さらに18か月ほどかかる可能性がある基礎として使用できます... 2014年の終わりのようですか?
最後にOpenJDKがあります...これは Red Hatは今後サポートする予定であると言っています ...
そして、私は 他のJVM実装 を実際に目にするより一般的なものだけを考え始めることすらありません!
だから私が見ることができるものから、これまでのところ、Oracle/IBM/Red Hatに支払うお金がある限り、Java 6バージョンが無期限にサポートされ続けることができます...
たぶん、私たちはこの質問を少しうまく組み立て始めることができ、不明確でない答えのチャンスを得ることができます:
特定のJVMが動作するハードウェア/オペレーティングシステムを購入できない場合、その特定のJVMが引き続きサポートされることは、ちょっとした問題点です。延長サポート契約は、既存のシステムによって既存のニーズが満たされている可能性が高い既存の顧客向けであり、新しい顧客に変更できない場合
Appleハードウェアは5年間サポートされます(カリフォルニアの場合は7))ので、サポートされる唯一のAppleハードウェアはスイッチが 2006年12月に完了したため、x86ベースのハードウェアである(PPC based Apple出荷するハードウェア) 、実際には、PPCで実行されるApple Javaバージョンについて心配する必要はありません。
同様に、おそらくJavaの古いバージョンのWindowsで実行されるバージョンを除外できます。つまり、これは Apr 2014 if JavaインストーラーがWindows 7以降で実行されない場合、Java Windows XPでサポートされているバージョン)を効果的に無視できますか?
私の本当の関心は、開発者ツールがいつ最小バージョンJava=.
Jenkins はしばらくの間、Java 5でサポートを維持していますが、新しい変更は 1.520 + が必要であることを意味しますJava 6以降のマスターとスレーブこれは、レガシーハードウェアなどの一部のビルドスレーブが新しいJVMを実行できない場合に問題を引き起こす可能性があります。
Maven ユニットテストを実行するために、JVMをJ2SE 1.3にフォークできるという長い歴史がありますが、 Surefire 2.15 の時点では、ユニットテストの実行をサポートしています。 Java 5。
javacは1と3に戻ります-source
および-target
...の観点からのポリシーなので、Java 6ソースファイルのサポートがjavacから削除されました... 2年のリリースケイデンスとJava 8は2014年の初めにリリースが予定されています。これは2016年の初めにJDK9を、そして早くにJDK10を意味します。 2018 ...しかし、JDK9はさらに3年間公に維持されて利用可能になるでしょう。つまり、2019年のある時期に、JDK 6ソースコードの互換性が失われる可能性があります。
OSS開発者ツールチェーンがJava 7以前のJVMのサポートを終了できる時期を確立するために使用できる明確な日付はありますか?その日付は何ですか?
OSS開発者は通常、拡張/プレミアム/持続型サポート契約を購入するための資金を持っていないため、OSSの区別は重要であり、多分、あいまいな/メインフレームのハードウェアにアクセスできません。
更新:「Java 7以前のJVMのサポートを削除」して、-target 7
ieを使用してツールチェーン全体をコンパイルしても安全であることを意味しますバイトコードが実行するために必要なことJava 7.
更新2:これは、フレームで示されているように、事実に基づいた回答可能な質問である必要があります。正解は次のいずれかの形式である必要があります
明確な答えはありません。ここに「Java 6)でOSSの人々に無料のアップデートを提供している一部の人々」へのリンクがあります。
または
はい、YYYY-MM-DDの正式な日付があり、ここに証拠があります
OSS開発者ツールチェーンがJava 7以前のJVMのサポートを終了できる時期を確立するために使用できる明確な日付はありますか?その日付は何ですか?
いいえ、そのような日付はありません。
ツールチェーンを開発している人々は、JavaのEOL版のサポートを自由に自由に削除できます。仮に、個人(または企業)が他の企業(顧客など)と一定の期間サポートを提供する契約を結んだ場合、それらの契約は明らかにそれらを制約することになります。ただし、それがプロジェクト全体を制約することはまずありません。
(ただし、実用性としては、古いバージョンのJavaのサポートを維持することは、ますます難しくなることです。開発者は、ツールチェーンコードで新しいJava機能を使用できるようにする必要があります/したがって、ツールチェーンを使用してレガシーJavaのコードを開発できる場合がありますが、最新のJavaでツールチェーンを実行する必要があります。
OSSバージョンのJavaコードベースの場合、あなた(Javaのユーザー)はより良い立場にいます:
これを行うことが商業的に実行可能になる時点をはるかに超えて、ある程度のコミュニティのサポート/開発が行われる可能性があります。
そうでない場合は、ソースコードにアクセスできるので、(理論的には)自分でサポートしたり、誰かに代金を支払ってもらうことができます。
Steve Conollyはコメントしました:
OSSコミュニティはサポート契約を結ぶことはできません。
それは完全に間違っています。
OSSコミュニティの誰もが、OSS製品のサポートを提供する契約を結ぶことができます。これが実際に、一部の開発者が彼らの開発を続けることを可能にするお金を稼ぐ方法です。
さらに、GPLとそのすべてのバリアントを含むすべての主流のOSSライセンスがこれを許可します。
しかし、コストを負担せずにテクノロジーにまったくアクセスできないためにOSSコミュニティが開発者を成長させることができない場合、Java 7より前のサポートは不可能になります。
それも間違っています。
Sun(以前)と現在のOracleは、無料バージョンのJavaのEOL版の無料ダウンロードを提供しています... Java 1.1までさかのぼります。 EOL-ingは可用性を変更しません。実際に、最近発見されたセキュリティの問題やその他のバグに対するJavaの古いバージョンのパッチリリースの可用性についてです。あなたはその代金を払わなければなりません。 (十分に公正です。作業を行うにはOracleの費用がかかります。)
問題は、Java 5以前がソースコード形式で自由に利用できることとそうでないことです。つまり、顧客はJava 5のセキュリティホールを(たとえば)修正するオプションを現実的には持っていません。対照的に、Java 6では彼らはそのオプションを持っています。 OpenJDK 6コードベースがオープンソースとしてリリースされ、そのcannotは取り消されました。さらに、Java 7とJava 8もオープンソースであるため、人々はJava 7と8のセキュリティ修正を追跡して、 OpenJDK 6コードベースの変更...