『サポートが有償になった』とか『Java 11で、パッケージが無くなった』とか、なんやかんやあったので、色々と混乱してしまいました。
当社でも、Javaのコンテンツを公開しているので、Javaが終わってしまっては元も子もありません。
今後どうすれば良さげなのか、簡単にまとめてみたので、参考にしてください。
このコンテンツに書かれている内容は、インターネット上に公開されている情報や、Oracleその他が提供しているライセンス情報を、機械翻訳した結果等を元にしています。
記載内容には注意を払っているつもりですが、正しいことを保証するものではありません。
特にライセンス関係は、違反をすると重大な結果を招く可能性も有るので、充分に注意してください。
まあ最近の流行りというか、どんどんバージョンを上げて、新しい機能を追加していくというのは、様々なプロダクトで取り入れられています。
Linuxのディストロビューションには、ローリング・リリースという考え方が昔からありましたが、スマホのOSやWindowsもこれを取り入れ、新機能をガンガン宣伝できるようになりました。
Javaもこれに乗っかったわけですが、同時にサポートのポリシーも大きく変わってしまいました。
半年ごとに新しいバージョンが出て、サポート期間は次のバージョンが出た月の終わりまでとなります。
但し、3年毎に長期サポート（Long-Term-Support：LTS）リリースが出る予定です。
現状は、Java 8とJava 11・Java 17がLTSで、Java 8は2030年12月、Java 11は2026年9月、Java 17は2029年9月までサポートが受けられます（Extended Support）。
多分こんな感じ。まだ出ていないJava18以降は、単なる予想ですが（Oracle Java SE製品のリリースより）。
LTSは、3年毎と発表されていたと記憶しているのでうが、変わったようです。
いつの間にか、Java 8の無償アップデートが、無期限に提供されるように変わっていました。利用可能終了日を設定する場合は、18ヶ月前に通知されるようです。
うんうん、Javaは終わっていませんよ。
| 2017 | 2018 | 2019 | 2020 | 2021 | 2022 | 2023 | 2024 | 2025 | 2026 | 2027 | 2028 | 2029 | 2030 | 2031 | |||||||||||||||||||||||||||||||||||||||||||||||
| Java 8 | 2014/3 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Java 9 | 2017/9 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Java 10 | 2018/3 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Java 11 | 2018/9 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Java 12 | 2019/3 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Java 13 | 2019/9 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Java 14 | 2020/3 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Java 15 | 2020/9 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Java 16 | 2021/3 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Java 17 | 2021/9 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Java 18 | 2022/3 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Java 19 | 2022/9 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Java 20 | 2023/3 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Java 21 | 2023/9 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Java 8は、2030年12月末まで、個人ユーザ（商用に使用しないユーザ）向けに、アップデートが提供されるようです。商用ユーザ向けの無償サポートは、2019年1月末で終了しています。
Java 11は、そもそも個人ユーザや開発・出版でしか使用できないので、商用には使用できません。
商用のサポートは、全て有償サポートとなります。
Java 9以降は、64ビット版しか提供されません。
まあ、そう言い切ってしまうのもどうかと思いますが...
元々、Oracleが提供しているJDKは、オープンソースコミュニティが開発しているOpenJDKを元にしています。
OpenJDK自体からは、OracleのJDKと同様のサポートしか受けられませんが、OpenJDKを元にしてJDKを提供しているベンダーに対し、セキュリティパッチ等のサポートを行う努力をすることを、Oracleも表明しています（なんとも微妙な言い回しで...）。
RedHatは、いち早く長期サポートを発表していました（そもそもOSが無料ではないので、ただで使えるわけではありませんが）。
筆者はDebianを使用していますが、Oracleのサイトからはダウンロードできないバージョンが既に提供されているので、コミュニティー間の連携は今の所うまくいっているようです。
Debian 9 からアップデートした場合は、インストール済みのopenjdk-8はそのまま使用できます。
sources.listにhttp://security.debian.org/ stretch/updates mainを残しておけば、セキュリティアップデートも受けられます。
但し、Debian 10で未サポートとなったパッケージに対するアップデートが失敗する可能性があります。
また、openjdk-8自身も本当に全ての機能が正しく動作するかは、自己責任で...(^_^;
AdoptOpenJDKが、OpenJDKのバイナリを提供してくれています。
AdoptOpenJDKは、大手のベンダー（IBMやMicrosoft）を含むコミュニティーなので（RedHatもコミュニティの一員ですが、いつの間にかIBMになってしまいました）、まあある程度の影響力は期待できます。
Java 8は2023/9、Java 11は2022/9までサポートしてくれるようです。
Java 8は少なくとも2026/5、Java 11は少なくとも2024/10までサポートしてくれるようです。2020/10/4 追記
また、32ビット版も提供してくれています。macOS版もあります。
AdoptOpenJDKプロジェクトは、Eclipse Foundationに移管され、Eclipse Adoptiumとなりました。これ以降 2021/12/29 追記
JDKのダウンロードは、Adoptium - Open source, prebuilt OpenJDK binariesから可能です。Java 17も、ダウンロードできます。
Java 8 や Java 11 のサポートは、以前と変わらないようです。
Java 17 に関しては、上流サポートが続く限りということのようです。
それは、分かりません。
AdoptOpenJDKのサイトに、以下のようにありました。
As a general philosophy, AdoptOpenJDK will continue to build binaries for LTS releases as long as the corresponding upstream source is actively maintained.
<機械翻訳>
一般的な考え方として、AdoptOpenJDKは対応するアップストリームソースが積極的に維持されている限り、LTSリリース用のバイナリを構築し続けます。
『対応するアップストリームソースが積極的に維持されている限り、』というのは、上流のコミュニティーがうまくいっている限りと読めなくもないので、破綻なくうまくやってくれることを祈るばかりです。
実際のところ、エンドユーザや開発者が離れてしまえば、Oracleも損害を受けるでしょうからね。
C言語、個人的には(^o^)
だめだめプログラマが作ったプログラムは、落っこちてそれ以上悪さしないし。
亡くなりました。無くなりました。
これまでにないくらい、いろいろなものがゴッソリ無くなりました。
Java EEやCORBA関連のパッケージ（モジュール）が、多く削除されました。
特に、javax.xml.bindパッケージは、よく使う機能だったので、結構困ります。
いろいろなプロダクトの、Java 11サポートが遅れていた大きな原因だったようです。
代替策は、該当のライブラリ（jar）を使用することです。
Java PluginとJava WebStartも無くなりました。
代替策には、IcedTea-Webという、オープンソースのプロジェクトがあります。
但し、NPAPI pluginsをサポートするWebブラウザが、2019/4現在ほとんど存在していない。
同梱されなくなりました。
OpenJFXとして、オープンソースのプロジェクトとなりました。
しかし、最近のHTML5などによる、Webアプリケーションの実用性を考えると、本当に必要なのか難しいところです。
OracleからEclipse Foundationに寄贈されて、「Jakarta EE」となりました（ただ、プロジェクト的には「Eclipse EE4J」と呼ばれてます）。
リファレンス実装だった「Glassfis」は「Eclipse Glassfish」として、こちらで公開されています。
この関係で、Mavenのセントラルリポジトリでは、グループIDやアーティファクトIDが変更されているようなので、使っている人は注意が必要です。
はい、どうやら、本当に終わってしまったようです。
なんと、パッケージ名がjavax.xxxxからjakarta.xxxxと変更になります。
Java EE 8と同等のjakarta EE 8は従来のAPIで提供されますが、jakarta EE 9からは新しいAPIとなるので、パッケージ名の変更が必要となります（jakarta EE 9は、2020年リリースの予定です）。
ソースレベルの移行ツールは提供されるようですが、サーバ本体やOSのEOS（End Of Service）でハード更改するようなケースでは、当然ソースからコンパイルなどということは行いません。もし従来のAPIが使えないとなると、デスマーチまっしぐらです。
新旧のAPIが同時に提供されて、新しく追加／変更された機能が必要ない場合、従来のAPIがそのまま使えるといった形でアプリケーションサーバが構成されるとは思いますが、従来のAPI（要するにJava EE 8/jakarta EE 8）がいつまでサポートされるかが、非常に重要となります。
システムによっては、10年20年と運用されるものも珍しくありません。そして、その間に何度もハード更改されますが、ある時「従来のAPIがサポートされなくなりました」となったら、さてどうするのでしょう。
最大の問題は、周りにこの問題を認識している人が誰もいない！ということでしょうか。
今から考えておかないと、10年後に「そんなこと、突然言われても！」「10年前からわかっとたヤロー」なんて、漫才みたいになってしまいます。
コンパイル済みのclassファイルを変更することなく、うまくパッケージ名変更に対応してくれるツールでも作れば、売れるかもしれません。おっ、お金の匂いが...
Java 9以降では、モジュールという考え方が取り入れました。
このおかげで、必要最小限のモジュールで構成されたJREを作ることができるようになりました。
とても解りやすくまとめてくれているサイトがあったので、リンクしておきます。
上記サイトでは、jdkをOracleからダウンロードしていますが、AdoptOpenJDKからダウンロードしたOpenJDKにも、同様のコマンドがあるので実行できます。
ただ、どうやって最新の状態を保つかという問題は残りますが。
そうなんですよ（このコンテンツの内容には、直接関係ないけど）。
Java 11に完全対応した2018-12以降は、64ビット版しかリリースされないようなので、非常に困ってます。
代替策は、OSを64ビットにするしか...
何となく、動いている『Pleiades All in One』のeclipse.iniから、使わないlombokの記述を削除したものをコピーしてきて起動すると、なんの問題もなく動いた。
「おっと、元のeclipse.iniから少しずつ削除していけば、原因わかるじゃん！」と思って、とりあえずeclipse.iniを元に戻して起動したら動いた。
一旦終了して再度起動しても問題なし。OSを再起動しても問題なし。
理由がわからん！？！！
とりあえず解決(^_^;
Linux上の仮想環境だったので、OSの再起動とかしていなかったのですが、再起動したら動かなくなりました。
解決策は、結局Pleiades All in Oneをダウンロードして使用することかと...(^_^;
オリジナルの記述は、正しくありませんでした。理由も分からずじまいです。
========== ここ以降がオリジナル ===========================
理由がわからん！？！！
「Java was started but returned exit code=1」で、例のダイアログが表示される。
当然、eclipse.iniに-vmで、jdkのパスは設定されているし、それが正しいのも確認済み。
コマンドラインで、java -versionが正しくバージョンを表示することも確認済み。
環境変数に、PATHもJAVA_HOMEも設定済み。
いろいろな環境で開発してきたけど、こんなのは初めて。
eclipseもAdoptOpenJDKも、zipをダウンロードして解凍しただけ。
ググってみると、-vmにjvm.dllを指定しろという記述が見受けられる。実際にやってみるとダイアログすら表示されないのだが、この指定で動いている環境があるということは、何らかの方法でeclipseがjavaw.exeの場所を見つけているということ。
実際のところ、Linuxの環境では、eclipse.iniに-vmの指定などしなくても、なんの問題もなく動くし。
で、普通にOracleのJDK（jre）をインストールすると、Windows\system32にjava.exeとjavaw.exeがインストールされることを思い出して、jre\bin配下のjava.exeとjavaw.exeをWindows\system32にコピー。
PATHに%JAVA_HOME%\jre\bin\serverを追加して起動してみると、なんと起動成功。
PATHにserverディレクトリの追加が必要がどうかは確認していないけど、まあ動いているのでそっとしておきましょう。
最初から、msiを落としてきてインストールすればよかったんでしょう。