Java7がダウンロードできなくて困った話
久しぶりにJavaをやったら、色々困ったので覚書です。
Java7がない!
仕事でちょっとJavaを書かなければならなくて、普通に書いて現行バージョンの JDKでコンパイルして渡したときに「本番はまだJava7なんです」と言われました。
まぁ、ちょっと驚愕ですが、Java7でコンパイルするかと Oracleのサイトを 確認したところ……
ありません。Java7がないんです。
ちょっと調べたところ、随分と前にサポート切れて公開していないようです。
Java 7ダウンロードはどこから入手できますか。 2015年7月: Java 7のアップデートは一般に提供されなくなりました。 オラクル社では、Javaサポートを購入したユーザー、またはJava 7が必要なOracle製品を所有するユーザーのみにJava 7のアップデートを提供しています。
参りました。
仕方がないので、OpenJDKのZuluで代替することにします。 Homebrewでインストール できました。
Javaの環境を切り替える
Java7が入手できたのはよいのですが、こんな旧いJDKがインストールされている のも気持ち悪いので確実に、かつお手軽に環境を切り替えるために jenv を インストールします。 Rubyの rbenv に当たるものですね。
また、 .bash_profile か .bashrc に以下を追加します。
#jEnv export JENV_ROOT="$HOME/.jenv" if [ -d "${JENV_ROOT}" ]; then export PATH="$JENV_ROOT/bin:$PATH" eval "$(jenv init -)" fi
次に、jenvの設定を行います。まず、Javaのバージョンを収めるフォルダを作成します。
そして、jenvに登録するためにインストールされているJavaのバージョンを確認します。 確認したら、地道に jevn に登録していきます。
$ /usr/libexec/java_home -V Matching Java Virtual Machines (7): 1.8.0_151, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home 1.8.0_144, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home 1.8.0_131, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home 1.8.0_121, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home 1.8.0_112, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home 1.7.0_181-zulu-7.23.0.1, x86_64: "Zulu 7" /Library/Java/JavaVirtualMachines/zulu-7.jdk/Contents/Home 1.7.0_181-zulu-7.23.0.1, x86_64: "Zulu 7" /Library/Java/JavaVirtualMachines/zulu1.7.0_181.jdk/Contents/Home $ jenv add /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk.Contents/Home $ jenv add /Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home (以下、省略)
すると、 jenv に登録されます。
$ jenv versions * system (set by /Users/hogehoge/.jenv/version) 1.7 1.7.0.181 1.8 1.8.9.151 openjdk64-1.7.0.181 oracle64-1.8.0.151
これで準備が完了です。
Java7の検証をしたいプロジェクトのためにフォルダを掘って、そのフォルダ内だけ Java7の環境となるように設定します。
$ mkdir java7-test && cd java7-test $ jenv local oracle64-1.7.0.181 $ jenv versions system 1.7 1.7.0.181 1.8 1.8.9.151 openjdk64-1.7.0.181 (set by /Users/hogehoge/java7-test/.java-version) oracle64-1.8.0.151
上記でプロジェクトフォルダの環境が切り替わるので、あとソースをコンパイルして テストしていきます。ここで、ちゃんと指定したバージョンが使用されているか 不安なので、コンパイルしたクラスコードを確認します。
以下のコマンドでクラスコードが一体どのJavaのバージョンでコンパイルされたか 確認できます。
$ javap -v TestClass Classfile /Users/hogehoge/java7-test/class/TestClass.class Last modified Aug 20, 2018; size 2181 bytes MD5 checksum 9dd5bbe9909efe0a00b04918234a Compiled from "TestClass.java" public class TestClass SourceFile "TestClas.java" minor version: 0 major version: 51 flags: ACC_PUBLIC, ACC_SUPER Constant pool: (以下、省略)
上記のmajor versionを確認します。Javaとmajor versionの対比は以下の通りです。
Javaのバージョン |
major version |
---|---|
1.4 |
48 |
1.5 |
49 |
1.6 |
50 |
1.7 |
51 |
1.8 |
52 |
9 |
53 |
10 |
54 |
今回確認できたmajor versionは 51でしたから、しっかりとJava7でコンパイルされて いることを確認できました。
Javaのバージョンをめぐるゴニョゴニョ
ここ数年でJavaから遠ざかっていましたが、昨年くらいからJavaの移行プロジェクト でレビューを依頼されたりすることが多くなりました。どこでも移行は大変なのだな と思っていたのです
今回は別にJavaの移行を依頼されている訳ではないのですが、 「大体このプロジェクトなんで今時Java 7使ってんだ」とか色々気になったので Javaを取り巻く状況をまとめておきます。
Oracle Java 7が2015年4月に無償サポートが終了しました。
Oracle Java 8は2019年1月に無償サポートが終了します。
Oracle Java 9は既に2018年3月をもってサポートが無くなっています。
Oracle Java 10は2018年3月にリリースされたばかりですが、2018年9月にサポート切れます。
Oracle Java 11については、無償版はリリースさえされません。 その代わりにこのバージョンから有償のLTS(長期サポート)が提供され、3年間はサポートが保証されます。
つまり、金を出さないとJavaという言語でサポートのあるシステムは組めないということです。
Oracleの考えていることもわかります。
Javaという言語は、少なくとも日本ではメインフレームと呼ばれる大型機の後を受けて ミッションクリティカルなWebシステムの基盤として採用されてきました。特に金融機関では そうだと思います。企業からの要求も高く、言語自体やその周辺のライブラリをどんどん肥大化し しています。
その機能を維持するのは大変だと思います。オープンソースではありますが、Oracleは それなりのリソースをつぎ込んでいるはず。ここで、「もうやってられるか!」と マネタイズに取り組み始めたのかもしれません。
これはよく考えると、大きな転換点かもしれません。
日本ではSIerと呼ばれる企業のプロジェクトではJavaはまだまだ中心的なプラットフォーム です。多くはアプリケーションサーバーとしてJavaでシステムが記述されています。 この言語の部分が有償となるのです。
これは、業界に2つの影響を及ぼしそうです。
大企業はともかく中小でJavaを採用していた企業からは着いてこれない企業が出てくるでしょう。
OpenJDKはあるものの、安定して無償でJDKが提供されないならばJavaを習得しようというエンジニアが減っていくでしょう
さらに現在は LAMPと呼ばれるPythonやPHPで組んだWebシステムがSIer以外のITの世界では 一般的になりつつあります。クラウドやIoT、AIなど最新のIT環境になじんだエンジニアは こういったものを使う傾向にありますし、さらに上記の2点はエンジニアのその傾向を強め そこにビジネスを更に生む可能性があります。
何年かしたら、Javaは一昔前のCOBOLのような扱いになっていくのでしょうか?
確かに今更Javaでシステムを書く気持ちにはなれませんね。