Java Generics Hell アドベントカレンダー 24日目。 前回(22日目) イレイジャ 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 今回はJavaのジェネリクスでは型変数を用いてnew T()できないけど特に問題ないという話。 コンストラクタの形 コンストラクタは、その内部でthisが使えるしインスタンスフィールドへのアクセスもインスタンスメソッドへのアクセスも出来る。そこからするとインスタンススコープのメソッドのように見えるが、インスタンスに所属しているわけではない。 インスタンスメソッドを呼び出すにはインスタンスを指定するか、自分のインスタンスのメソッド呼び出しでthis.を省略できる、というシチュエーションでなくてはならない。逆に言えば通常のclassのnewはインスタンスなしで呼び出せるわけで、所属としてはclassのstaticに相当する。
Java Generics Hell アドベントカレンダー 22日目。 前回(20日目) ブリッジメソッド 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 メソッドのオーバーロード Javaのジェネリクスのイレイジャについて語るには、まずメソッドのオーバーロードについて語らねばなるまい。 メソッドのオーバーロードとは、同名で引数の型違いのメソッドのことである。 public class Hoge { public void foo() {} public void foo(String s) {} } Javaではなぜ同名のメソッドを宣言することが出来るのであろうか？コンパイラが、あるいはJavaのランタイムであるJavaVMが、メソッドを特定するときに 属するクラスの完全修飾名 メソッド名 引数の型の並び によってどのメソッドを呼ぶか特定しているのである。 これはリ
Java Generics Hell アドベントカレンダー 20日目。 前回(19日目) 内部クラスと型変数のスコープ 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 共変戻り値 Java5以降ではメソッドをオーバーライドするときに、戻り値をより具体的な型としてオーバーライドすることが許されている。 public interface Parent { Number getValue(); } このjava.lang.Number型を返すgetValue()メソッドをChild型でオーバーライドするときにNumberの子であるInteger型にすることができる。 public class Child implements Parent { public Integer getValue() { return 0; } } これが共変戻り値だ。 ジェネリクスを用いている場
Java Generics Hell アドベントカレンダー 19日目。 前回(18日目) ジェネリックな例外 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 Javaでは1ファイルにトップレベルのpublicなclassはひとつしか置けないが、入れ子になったクラスなどを用意することができる。種類がいくつかあるので後に整理するが、内部クラスの場合、外側のインスタンススコープの型変数が内部クラスの内側でも有効となる。 今回はそのあたりを整理してみよう。Javaのクラス宣言の種類については拙稿 Javaのクラス宣言5種+αで以前に取り上げているので参考にされたい。 static 内部クラスの話の前に、そもそも論としてクラスのインスタンススコープの型変数は、staticなメソッドや、フィールドでは用いることは出来ない。なぜなら、インスタンスをスコープとしているからだ。（トート
Java Generics Hell アドベントカレンダー 18日目。 前回(16日目) 型変数のバインド 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 throws E Java のジェネリクスの型変数は例外のthrows宣言でも用いることができる。型変数の宣言時にthrow可能な型であることを型変数の境界で示す必要がある。 public <E extends Exception> void hoge() throws E {} 上記はメソッドスコープの型変数 E を extends Exception としてみた。メソッドスコープの型変数だとthrowsに型変数を用いる意味があまりないが、型システムの挙動を見る分にはコード量が少なくて済むので都合が良い。 バインドの仕方でthrowされうる例外が変わる、例外が変わるのでcatchするべき例外も変わる。 // IO
Java Generics Hell アドベントカレンダー 16日目。 前回(15日目) ワイルドカード落穂ひろい 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 メソッドスコープの型変数 メソッドスコープの型変数へのバインドについては以前も書いたが再掲しておこう。 使用する場合は、通常はバインド型が推論されるのでそのまま呼び出せば済む。 Set<String> set = Collections.singleton("hoge"); 型変数にバインドする型を明示する場合はメソッドの手前に山括弧で指定する。 Set<String> set = Collections.<String>singleton("hoge"); メソッドスコープの型変数については明示的にバインドしなくても概ね型が推論される点は知っておくと良い。これはジェネリクスが導入されたJava5当初からあ
Java Generics Hell アドベントカレンダー 14日目。 前回(13日目) 共変ワイルドカード 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 反変ワイルドカード さて、前回は共変ワイルドカードについてだった。今回は反変ワイルドカードについてである。 反変ワイルドカードは? superを用いて以下のように記述する。 List<A> listA = new ArrayList<A>(); List<? super B> listSuB = listA; // 代入可能 このlistSuBは次のような性質を持っている。 listSuB は B型を格納することが出来る listSuB から取り出した型はObject型となる 前回のList<? extends A>型は、戻り値がA型であることが保証された。代わりに引数でA型オブジェクトを渡すことができなくなった
Java Generics Hell アドベントカレンダー 15日目。 前回(14日目) http://d.hatena.ne.jp/Nagise/20171214/1513260215=反変ワイルドカード 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 共変ワイルドカードと反変ワイルドカードについて書いたので、残りの話題を拾っておこう。 Unbounded Wildcard 共変でも反変でもないただのワイルドカードとして<?>を見たことがあるのではないだろうか。 言語仕様上はUnbounded Wildcardと表現される。適当に訳すと無制限ワイルドカード、だろうか。 何が無制限かというと代入が無制限に行える。 List<?> list; list = new ArrayList<String>(); list = new ArrayList<Integer>();
Java Generics Hell アドベントカレンダー 13日目。 前回(11日目) 型変数の境界 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 変性 パラメタライズドタイプについては以前に書いたが、ワイルドカードについては後回しということにしていた。 <>の内部については非変性であるということは何度か述べてきたが、特定の制限下で共変性、あるいは反変性をもたせることは出来るだろうか？ 共変性 パラメタライズドタイプが共変である場合、何が問題になるのだったか再確認しよう。以下ではclass Aを親とし、class Bが子供という関係とする。パラメタライズドタイプを共変とするとき? extends を用いて以下のように記述する。 List<B> listB = new ArrayList<B>(); List<? exnteds A> listExA = listB
Java Generics Hell アドベントカレンダー 11日目。 前回(8日目) インスタンススコープのジェネリクス 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 週末サボりました。すいません。 型変数の境界 ここまでは話を簡単にするために型変数の境界については触れずにきた。 しかし、型変数の境界についてはそこまで難しい話ではない。その型変数が何かを継承していることを制約としてつけることができる、というだけである。 public class Hoge<T extends Piyo> { } ここで、TはPiyo型かもしくは、Piyo型を継承した何かでなくてはならない。この時、class Hogeの中で型変数T型の変数はPiyoを継承していることが保証されるので、Piyoに定義されるメソッドを呼び出すことができる。これを型変数の境界という。なお、指定できるのはe
Java Generics Hell アドベントカレンダー 7日目。 前回(6日目)ジェネリクスの構文 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 前回、構文の話をしていたが、そのなかでメソッドスコープのジェネリクスをいったんおいていた。 今回はそのあたりを取り上げる。 ジェネリクスとスコープ 前回のおさらいとして、Javaのジェネリクスには2つのスコープがある話をしていた。 メソッドの範囲で有効な型変数 クラスのインスタンスの範囲で有効な型変数 まずジェネリクスのそもそも論になるが、ある処理の塊に型変数という「型」を表す変数を導入し、処理の塊をいろんな型で扱えるようにしよう、ということになる。ここで「処理の塊」としてJavaのジェネリクスでは「メソッド」か「インスタンス」か、ということになる。 メソッドスコープの型変数は インスタンス・メソッド static メ
Java Generics Hell アドベントカレンダー 8日目。 前回(7日目) メソッドスコープのジェネリクス 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 ようやくクラスの型変数の話にたどり着いた。なかなか話題が多くて大変なのである……。 インスタンススコープ ここのところしつこくJavaのジェネリクスの型変数には2種類のスコープがあることを挙げてきた。 メソッドの範囲で有効な型変数 クラスのインスタンスの範囲で有効な型変数 前回、メソッドスコープのジェネリクスについて取り上げた。入門書などではあまり触れられていない構文かもしれないが、機能的にはメソッドスコープのほうが単純だと思うので先にメソッドスコープを取り上げた次第である。 メソッドスコープではメソッドの IN / OUT つまり、引数と戻り値を型変数を用いて関連性を示すことができるということを書いた。
気合が続くか分からない Java Generics Hell アドベントカレンダー 1日目。 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 導入 JavaのジェネリクスはJavaが設計された当初(Javaは1995年に発表されている)から検討はされてはいたものの、実装が追いつかず、導入はJava5(2004年)を待つこととなった。後方互換の都合からいろいろと不便な部分もある。Javaに限らず、ある程度、歴史の長いプログラミング言語は、改定の都合からいろいろと不都合な部分が生じるものである。後方互換性を犠牲にして一新すれば言語仕様もさっぱりするが、非互換の壁でバージョンアップできないという闇を抱えたりとそれはそれで大変だ。 後方互換、つまり、より新しいバージョンは、昔作ったモノも動かせる、ということを前提にした場合、プログラミング言語の仕様というのはどんどん肥大してい
http://aoking.hatenablog.jp/entry/20100427/1272326219での主張は public class Sample { public static void main(String[] args) { List<Integer> list = getList(); System.out.println(list); } public static <T> List<T> getList() { List<T> list = new ArrayList<T>(); list.add((T)"string"); list.add((T)Integer.valueOf(1)); list.add((T)new Object()); return list; } } といったように型変数Tにキャストを行った場合に「このコードはコンパイルエラーは発生しない。
前回から随分と間が開いてしまった。Javaのジェネリクスはイレイジャ方式だけどもクラスにバインドした型の情報が残る場合があるんだよシリーズの第2弾である。 具体的にどういう場合にバインドした型が残るのかという話だが、端的に列挙すると以下のものである。 フィールドにパラメタライズドタイプ(parameterized-type)を用いた場合 メソッド引数や戻り値型にパラメタライズドタイプを用いた場合 コンストラクタにパラメタライズドタイプを用いた場合 継承によるバインドを行った場合 大きく分ければパラメタライズドタイプを使ったメンバのシグネチャか、継承によるバインドの2種類である。 前回、例に挙げたのはパラメタライズドタイプを引数にとるケースだった。 import java.lang.reflect.*; import java.util.List; public class Reflecti
今回のテーマはジェネリクスとリフレクション。Javaのジェネリクスはイレイジャ方式なのでリフレクションでは何も得られないと思ってはいまいか。 public void hoge(List<String> list) {} といったメソッドがあったとして、リフレクションでこのメソッドの情報を得るとしよう。 import java.lang.reflect.*; import java.util.List; public class ReflectionTest { public static void main(String[] args) throws Exception { Method m = ReflectionTest.class.getMethod("hoge", List.class); Type[] types = m.getGenericParameterTypes(); f
再帰ジェネリクスを用いて以下のようなコードを書いたとする。 Hogeを継承した型を作った場合に具象型を得るgetThis()メソッドを使えるようにしたいわけだ。 public class Hoge<T extends Hoge<T>> { @SuppressWarnings("unchecked") public T getThis() { return (T) this; } } このHoge型のTに型をバインドするには継承を用いる。一部の方にはおなじみですね。 public class Piyo extends Hoge<Piyo> {} こうした場合、Piyo型にはなんの実装も行っていないが Piyo p = new Piyo(); Piyo t = piyo.getThis(); というように、スーパークラスの実装によりgetThis()からPiyo型をとることができる。 型の安全
11/10に開催されたJJUG CCC 2012 Fallでジェネリクスについてセッションを行いました。 このエントリはセッション内容を補足するものです。本セッションはジェネリックなクラスの設計を行えるようになって欲しいという狙いで話をしました。ジェネリックなクラスを利用できるというのは前提条件として書いてます。入門的な内容であれば Javaジェネリクス再入門 - プログラマーの脳みそ を参考にしてください。 セッション資料はこちら ジェネリクスの基礎と応用 JJUG CCC 2012 Fall ジェネリクスのスコープ まずジェネリクスのスコープの話から入ります。Javaのジェネリクスには2つのスコープがあります。 メソッドをスコープとした型変数 インスタンスをスコープとした型変数 後者はおなじみの public interface List<E> などの型変数です。 これに対して pub
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
