R42日記スマートフォン用の表示で見るR42日記この日記は私的なものであり所属会社の見解とは無関係です。takahashikznITmediaに寄稿しました。JDK7に致命的なバグ重要なので先頭に追記しておきますが、JDK7のホットスポットコンパイラに致命的なバグが存在するそうです。http://d.hatena.ne.jp/takahashikzn/20110802JDK7を使用する際はご注意下さい。(Javadocのスタイルもガラっと変わりました!!)http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-418459.htmlJDK7の正式版がリリースされています。興味深い機能やAPIなどが追加されているわけですが、その中でもみんな一番気になるところである、Java言語仕様の変更についてご紹介。あとは、個人的にjava.lang.invokeなんてアヤシゲなパッケージが気になっているのですが...APIを見る限り、動的言語サポート関連のパッケージっぽいですね、コレ。どなたか解説をお願いします(笑)では、順次見ていきましょう。※念のため記載:大半のサンプルコードはリリースノートからの引用(一部、翻訳のために改変)であり、著作権はOracleにあります。0x42;などと書く必要があったわけです。これだと、ビットパターンをイメージしづらい。(脳内に『16進数→2進数』変換ハードウェア回路を焼成済みの方を除く)というわけで、JDK7からはこんな風に書くことが出来るようになりました。0b01000010;byteだけじゃなくて、他の型のバイナリ表現もあります。0b1010000101000101101000010100010110100001010001011010000101000101L;もちろん、配列でも使えます。0b10011000};整数型の定数を使える場所ならどこでも使えます。(アンダースコア入り数値リテラル)数値リテラルに、可読性のためにアンダースコアを入れられるようになりました。123;と同じ意味です。紛らわしいケースでは注意が必要です。123;とは違います。999という意味として解釈されます(これまでどおりの仕様)。(switch文のcaseラベルに文字列を使える)caseラベルに文字列リテラルを使えるようになりました。typeOfDay;}ラベルのマッチングはString#equalsで行われるため、文字列はケース依存です。if...と書くよりは、多少なりとも効率的なコードへとコンパイルしてくれるそうです。(コンストラクタ呼び出し時の型推論)待望の型推論が実装されました。言ってもコンストラクタ呼び出しの時だけですが。List<String>>();こんな風に書くことが出来るようになりました。HashMap<>();ちなみに、コレはダメです。rawタイプ警告が出ます。HashMap();万能ではないので、このようなケースはコンパイルエラーです。(型パラメータの可変長引数におけるコンパイラ警告の改善)型パラメータの可変長引数を使っているところで、コンパイラ警告の発生具合が変わりました。ヒープ汚染とは例えば、このようなコードを書くことが可能です。ClassCastExceptionが発生これは何をしているかというと、要するにこういう事です。ClassCastExceptionが発生これをヒープ汚染と呼びます。ジェネリクスを使って型の安全性を保証しているように見せかけて、爆弾を仕込むことが出来るということです。可変長引数と型パラメータ以下のようなコードを考えてみます。ジェネリクスの配列にヒープ汚染を仕込んでいる例です。}}JDK7からは、コンパイラがArrayBuilder.addToListで以下のような警告を出すようになりました。型パラメータTのヒープ汚染が発生する可能性があります。実際にJDK7のコンパイラでこのコードをコンパイルしてみたわけではないので、コンパイラ警告の和訳は異なるかも)で、この警告を出さないようにするためには、以下のいずれかの手段を使うことになります。}}コンパイル結果は以下のとおりです。(リソース管理用構文の追加)必ずクローズしなければならないリソースを使う場合、try-finally構文を使うのがお約束だったわけですが、ちょっと便利な構文が追加されました。}}複数のリソースを使う場合はこんな感じ。宣言とは逆順にcloseが呼ばれます。}}この構文で指定するリソースは、java.lang.AutoCloseableインタフェースを実装する必要があります。これは、java.io.Closeableのスーパーインタフェースです。Closeableを実装しているクラスは、標準でこの構文を使用可能です。(複数のcatch節、例外の再スローについての改善)複数のcatch節を書くようなケースが改善されました。ex;}こんな風に書けるようになります。結果としてcatch節の中身は同じようなコードになりがちです。この構文があると、冗長なコードを減らすことが出来るわけ。ついでに、コンパイラも専用のコードを生成してくれるようで、catch節を並べて書くよりも処理が効率的になるそうです。例外再スロー時の型推論JDK7から、例外再スロー時に型推論が働くようになりました。}このコード、JDK6までは当然コンパイルエラーですが、JDK7からはコンパイル可能。要するに、try節とそれに対応するcatch節の中身を見て、throws宣言として適切な型を判断してくれるということです。以下のケースでこの型推論が機能します。try節が投げる可能性のある例外は、thorws節で宣言している例外だけである型推論を適用したいcatch節の前に、先に例外をキャッチしてしまうcatch節が無いthrows節で宣言する例外は、catch節で宣言する例外のサブクラスであるへぇ、何だか面白い機能ではありますが。そもそもtry-catchを使わなきゃいいんじゃね?という気がしないでもないです。06:19JDK7正式版の新機能一覧(Java言語仕様に関して)関連記事2016-02-16Tomcat-8.0.32上でRhinoの初期化に失敗する問題を強引に解消するTomcat-8.0.32がリリースされています。instrument"になる件lambda-factoryをOpenJ9で動かすおまじない月別アーカイブスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。