javacでヒープ汚染せずに代入文だけでクラッシュ - しげるメモ
寝ようと思ったら思いついた。 public class Main { public static void main(String...args) { Comparable<?>[] c = method(1, 1L); } static <T> T[] method(T...ts) { return ts; } } これ、javacで警告でないけど実行するとClassCastException発生。言語仕様違反です。 おそらく、new T[ ]するときにreifiableな型の配列作ろうとしてイレイジャ変換かけている(erase(lub(Integer, Long)) = erase(Number & Comparable＜...＞) = Number としている)のに、戻り値にそれ伝播させてなくてT[ ]のまま使ってる。 明日まとめなおす予定。
SunのコンパイラとEclipse JDTで動きが違う(4) - しげるメモ
型推論の正解が分からない - しげるメモからの派生。 型推論で出現する無限型の取り扱いについて、SunのjavacとEclipseのJDTで微妙に動きが違う。 先ほどのエントリで、 method(T, T)にInteger, Longを渡すと、TはR = Number & Comparable＜? extends R＞となるような型Rに推論されると予測してます。それを踏まえて、現行のコンパイラがどうやって無限型を取り扱ってるのかなーと調査中。 void test() { Integer a = 1; Long b = 1L; bound0(a, b); bound1(a, b); bound2(a, b); bound3(a, b); infinite(a, b); } <T> void bound0(T a, T b) {} // 境界なし <T extends Number & Com
型推論の正解が分からない - しげるメモ
自分めも。だけどわかる人教えてください。 public static void main(String...args) { Integer a = 1; Long b = 2; Object result = method(a, b); // resultの型は？ } static <T> T method(T a, T b) { return null; } このmethod(a, b)の型推論で、Tはどのような型に算出されるかという問題。 15.12.2.8 Inferring Unresolved Type Argumentsを追いかけながら進んでいく感じ。ただし、型推論の後半部分だけ。 おさらいしておくと、Integer, Long はそれぞれ下記のような宣言。 class Integer extends Number implements Comparable<Integer>
代入変換とメソッド起動変換 - しげるメモ
ここでよく取り扱ってるんで、まとめがてらちゃんと解説。 Java言語仕様第3版のCHAPTER 5: Conversions and Promotionsを簡単にまとめたものだと思ってください。 式の変換 式の変換が適用されるケースは5通りあります。 代入変換 式の結果を変数に格納 例: Integer i = 1 メソッド起動変換 式の結果を実引数としたメソッド/コンストラクタを実行 例: s.equals("Hello") キャスト変換 キャストによる変換 例: (String) obj.clone() 文字列変換 文字列連結演算のオペランドをString型へと変換 例: "Hello" + 256 数値の格上げ 算術演算のオペランドを共通の型へと変換 例: 1 + 0.5 今回は、その中でも代入変換とメソッド起動変換を。 代入変換 「変数に値を代入するには、変数と同じ型かそのサブタイ
Javaの例外処理 - K.Maebashi's はてなブログ
Diksamに例外処理をつけるため、Javaの仕様を参考にしようとしているんですが。 try catchのfinally節は、「何があっても通る」ところなので、たとえば以下のようなソースでは、 for (;;) { try { … break; } catch (Exception e) { … return; } finally { … } }try節の中のbreakやcatch節の中のreturnでfor文やメソッドを抜ける際でもfinallyの中は通らなければなりません。しかも、finally実行後に行うことはbreakだったりreturnだったりと異なるので、これは単にジャンプ命令で引き回すだけでは実現が難しそうです。 そのためにjsr(jump subroutine)という、関数内のサブルーチンコールのインストラクションがJVMにはあるのだと私は理解してました。 JVMの仕様書を
SunのコンパイラとEclipse JDTで動きが違う(2) - しげるメモ
SunのコンパイラとEclipse JDTで動きが違う - しげるメモでも言及してますが、SunのjavacとEclipseのJDTでは微妙に内部クラス周りの動作に差異がある模様。 java.lang.Class.getCanonicalName()の動作を確認してる最中で、また微妙に動きが違うものを発見。 とりあえず、 package com.example.reify; public class Generic<T> { class Inner {} static class Applied extends Generic<String> {} public static void main(String[] args) { Class<?> aInner = Applied.Inner.class; Class<?> gInner = Generic.Inner.class; Sys
SunのコンパイラとEclipse JDTで動きが違う - しげるメモ
HudsonがEclipseでコンパイルできなかったという話題が1か月前くらいにあって、その調査をしているときにjavacとJDTで微妙に動作が違う点を見つけました。 class Hoge<T> { void h() { class Foo { T t; } Foo o = new Foo(); boolean b = (o instanceof Foo); // JDTでエラー T t = o.t; // javacでエラー } } これはどうもローカルクラスの扱いがjavacとJDTで違うようです。 JDT まず、(o instanceof Foo)でエラーになるJDTを見てみると、次のようなエラーメッセージが出ていました。 Cannot perform instanceof check against parameterized type Foo. Use instead its r
コンパイルエラー - 変換できない型。 - 量産メモ帳
例えばこんなソースを Eclipse で作成してみる。 package org.aeug.rms099; public class IncompatibleTypesError> implements Comparable { @Override public int compareTo(T o) { if (o instanceof String) { String string = (String) o; } return 0; } } Eclipse 上では何の問題もなくコンパイルされる。 しかし javac コマンドを直接叩いてコンパイルしようとすると、「変換できない型」などというエラーメッセージが出力される。 Eclipse のコンパイラがバグってるのかどうかは分からないが、Sun のコンパイラほど厳格じゃないみたいだ。 以下、似たような問題。 Bug 121369 – [1.5
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
