ソーシャルネットワーク事業部の、jyukutyoこと阪田です。JDK6で開発し、現在も運用しているプロジェクトをJDK8へ移行させました。lifeとなっていることです。エンジニア的には8が使いたくてしょうがないという気持ちもあります。8のすごさについての説明はすばらしいサイトがたくさんありますので、他へお譲りするとしまして、ここでは僕たちがちょっとハマった、JDK8導入でのTipsをお届けします。djUnitが...このプロジェクトでは、ユニットテストにdjUnit(2011年10月からもうバージョンアップはありませんね...)を利用しています。JDKを変えてユニットテストを実行すると、次のようなエラー(テスト失敗ではなく)が発生しました。java.lang.Class.forName(Class.java:340)</code>java.lang.VerifyErrorJDK6で導入されたclassファイルの検証方式変更(JSR-202)がJDK7からは有効となっており、VerifyErrorが発生しました。そのため、このエラーはJDK7でユニットテストを実行したときも発生します。検索エンジンで調べると「-XX:-UseSplitVerifier」オプションをつけるとよいという情報がたくさん出てきます。このオプションをつけて実行すると、次のようになりました。8.0</code>表記のとおりです。JDK8ではこのオプションはサポートされていないので、無視されました。attributes」に関するオプションであり、それにマイナスをつける(-UseSplitVerifier)とその機能をオフにします。checkerをオフにすれば動作しそうです。このチェックというのは、classファイル(バイトコード)の検証です。そこでJVMのオプションを調べると「noverify」がありました。クラスがバイトコードの検証なしにロードされます。セキュリティの問題など、さすがにプロダクトコードには使用したくないオプションですが、ユニットテストの実行くらいなら問題ないと考えました。「-noverify」オプションをつけてユニットテストを実行します。------------------------------------------------------------------------</code>成功しました!そもそもの原因djUnitは、モックの実現のためにバイトコードを書き換えています。デフォルトではASMを利用しています。このASMのバージョンが古いと、新しいclassファイルの検証方式に対応しておらず、エラーとなってしまいます。そのためASMのバージョンを最新にすれば、テストが成功するのでは!と考えて試してみました。ASMもメジャーバージョンアップしていますので、djUnitの方が対応しておらず、エラーとなりました。