ジェネリクスと配列 - プログラマーの脳みそ
Javaのジェネリクスは一般に配列と混ぜてはいけないとされるが、混ぜて用いた場合に何が問題となるのか。 歴史的な問題 Javaが1995年に登場した当時、Javaに配列はあったがジェネリクスはなかった。 ジェネリクスを含む型システムの理論的な整備は、1990年代から2000年代にかけてのJavaのバージョンアップの時期に並行して行われていた。これは1995年当初のJavaになぜより良いジェネリクスを搭載した形でリリースされなかったのか？ということにひとつの答えを示すだろう。つまり、1995年当時にはジェネリクス（Java5に搭載されたような変性を含むもの）は未来の技術であって、まだ理論的に固まっていないものであった、というわけだ。 Java言語仕様にも記述されているが Historically, wildcards are a direct descendant of the work b
言語機能としての型、概念としての型 - プログラマーの脳みそ
某エントリが型について再考するきっかけになったのは事実だが、個々人の思想の成否を問う気がないのでとくにリンクはしない。ここでは型とは何かという点について僕なりの思想を記しておきたい。 データ型を区別しない世界 ごくシンプルなチューリングマシンを考えよう。 チューリングの仮想機械は、 無限に長いテープ その中に格納された情報を読み書きするヘッド 機械の内部状態を記憶するメモリ で構成され、内部状態とヘッドから読み出した情報の組み合わせに応じて、次の動作を実行する。 ヘッド位置のテープに情報を書き込む 機械の内部状態を変える ヘッドを右か左に一つ移動する 上の動作を、機械は内部状態が停止状態になるまで反復して実行し続ける。 チューリングマシン この原始的な世界において「型」はない。メモリは抽象的で全てのメモリは同等に扱われ区別する必要はない。 また、チューリングマシンに程近い原始的なプログラム
Javaのジェネリクスとリフレクション - プログラマーの脳みそ
今回のテーマはジェネリクスとリフレクション。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
ジェネリクスによるVisitorパターン拡張の考察 - プログラマーの脳みそ
先日twitterで "Expression Problem" という問題を知った。 静的な型付けの下で、場合分けのデータ構造に対して、新しい場合分けとその場合に対する新しい処理を、元のソースコードに手を加えることなく拡張定義すること 2009-05-16 この問題が意図するところを語るにはまずオブジェクト指向から流れを辿らねばなるまい。 オブジェクト指向のポリモーフィズム Javaのようなオブジェクト指向の言語で、ある特定のメソッドがあることを抽象クラスHogeで保証するとしよう。 public interface Hoge { void hoge(); } このとき、機能性、つまりメソッドというのは増えることがない固定のものだが、継承して実装されたクラスというのは自由に増やすことができる。そして、抽象型Hogeを扱っている既存コードは修正する必要がない。 これはいわゆる開放/閉鎖原則(
Javaのクラス宣言5種+α - プログラマーの脳みそ
Javaのクラス宣言には5種類ある。 トップレベルクラス・ネストしたクラス・内部クラス・ローカル内部クラス・匿名クラス(無名クラスとも言われる)の5種類だ。 今回はこの5種類のクラス宣言のおさらい。 トップレベルクラス これは普段使っているクラス。拡張子が.javaのファイルを作り、そのファイル名とクラス名を合致させなくてはいけない。そのjavaファイルのトップレベルに位置する。 ネストしたクラス 「ネストしたクラス」(Nested class)とはクラスの中にクラスがネストしている状態。トップレベルクラスの内側にstaticキーワードをつけてクラス宣言を行う。 public class Outer { public static class Nested { } } このネストしたクラスは、トップレベルクラスと同等の機能性を持つ。 クラス名はOuter.Nestedという名前で扱われるが
Threadの割り込みを活用する - プログラマーの脳みそ
確実に一定時間スリープする - terazzoの日記ではThreadの割り込みがあっても確実に一定時間の停止を試みているが、そもそもこのようなコードは書いてはいけない。 Thread.sleep()は一定時間止まるための便利メソッドとしてよく知られているが、そのときに発生するInterruptedExceptionについての理解は広まっていない気がする。割り込みとはなんなのか。どういう時に使うのか。 目覚まし時計 お昼休みに昼寝をしようとする。寝過ごすといけないので15分後にアラームを鳴らす設定をした。 さて、ひと眠りするか、というところに友人がやってきた。昼寝はやめて売店に行くことにした。果たして売店でアラームが鳴り始めた。 さて、このとき、アラームは15分間の待機を命じられたわけだけども、お昼寝がキャンセルされたことで、もう待機しなくてよくなってしまった。むしろ、さっさと待機をやめてく
セミコロンレスJavaの構造化＆オブジェクト指向 - プログラマーの脳みそ
昨日、Java 7th moon 富山が開催されました。参加者21名と小規模ながら、会場は非常に盛り上がりました。ああ、凄く楽しい。こんなに楽しいのは久しぶりだ。スピーカーをしてくださった皆さん、参加してくださった皆さん、本当にありがとうございます！ LT(ライトニングトーク)で昔のネタを引っ張り出してSemicolonless Javaをやったのだけど、LTなので時間もなく一番アツイ部分が伝えられなかったのでちょっと書いておこう。 歴史 Semicolonless Java(セミコロンレスJava)はJavaのサブセットで、Java言語からただひとつセミコロンを取り除いただけのプログラム言語だ。 この言語自体は1996年にJavaがリリースされたと同時に実装が存在したが、誰にも知られていなかった。この言語が発見されたのは2010/3/21で場所は熱海。java-ja温泉というイベントの2
異型のオブジェクト比較 - プログラマーの脳みそ
異なる型のオブジェクトの順序比較が今回のテーマ。 Javaの場合、オブジェクトの順序を比較する王道はふたつある。 ひとつはjava.lang.Comparable *1（こんぺあらぶる）を実装する「自然順序付け」と呼ばれる方法。 public class A implements Comparable<A> { int a; @Override public int compareTo(A o) { return this.a - o.a; } } もうひとつはjava.util.Comparator （こんぱれーたー）を用いる方法。*2 public class MyComparator implements Comparator<A> { @Override public int compare(A o1, A o2) { return o1.a - o2.a; } } 見て分かるよう
Javaパフォーマンス計測 JITとの闘い - プログラマーの脳みそ
前回の文字列操作編では適当に文字列操作のパフォーマンスを測定しようとしたらGC様とJITコンパイラ様に阻まれた、という話だった。モヒカン族*1が「てめえの計測はなっちゃいねー！ひゃっはー！」と殴りかかったらケンシロウみたいなのが出てきて「あべしっ」となった、ぐらいのつまらない話だったが、反省してこれらと向かい合ってみたい。 JITコンパイラについての情報 JITコンパイラ（Just In Time compiler）とはインタープリタ方式のプログラム言語のランタイムが実行時に必要に応じて部分的にネイティブコード（CPUが直接実行できるマシン語）に変換することで高速化するというコンパイラである。もともとはもっと狭義のニュアンスだったが、今ではJITコンパイルとHotSpot動的コンパイルを併せて広義にJITコンパイル、それを実施する実態をJITコンパイラと呼んでいる感じだ。*2 ただ、やみく
Javaパフォーマンス計測 文字列操作編 - プログラマーの脳みそ
前回でパフォーマンス計測に用いるタイマーについての理解を深めたので、やっとパフォーマンスの計測を始めることができる。 今回のテーマはJavaの文字列連結だ。タイムリーだね。 文字列連結についての基礎知識 Javaの文字列連結についての言語仕様まわりは Stringの連結はそう簡単なものではない - じゅんいち☆かとうの技術日誌 が詳しい。しかし、パフォーマンス計測がなっちゃない。パフォーマンスの計測はそう簡単なものではない。 currentTimeMillis()で計測しておいて plusTime:14780, concatTime:7053, sbuilderTime:7, sbufferTime:13 とか、その7とか13の有効数字はいくつだっての*1。 そんなわけで、計測方法を工夫してみよう。二重ループとし、内側を1000回、それを500回繰り返す。ループが1回まわる間に1回ずつSy
Java 30byte FizzBuzz - プログラマーの脳みそ
なっちゃん（以下な）「なんかさー。タイトルが無理すぎない？」 ぎぃくん（以下ぎ）「まあ流行りだからね」 せっちゃん（以下せ）「流行りって言ってもFizzBuzzを３０バイトで - Togetterが1/24だし、1週間経ってるけど。どちらかと言えばオワコン？」 な「まあまあ」 ぎ「とりあえず、どのぐらい無理っぽいか見てみるかい？」 普通のFizzBuzz せ「じゃぁまあ普通のFizzBuzzをみてみましょ。」 な「FizzBuzz Javaでググって…これかな？ Fizz Buzz - Semicolonless Java」 public class FizzBuzz { public static void main(String[] args) { for (int i : new int[] { 0 }) { while (++i <= 100) { if (i % 15 == 0)
Javaによる高階型変数の実装 - プログラマーの脳みそ
高階関数というものをご存知か。関数自身を引数あるいは戻り値に取る関数のことである。「高階」は「こうかい」と読む。その昔「たかしな」と読んだ人がいたとか、いないとか。 先のエントリ「HttpSessionを型安全にする」では「javax.servlet.http.HttpSessionのsetAttribute()/getAttribute()のようなモノをどうやって型安全にするか」という動機付けから、 public class KeyValue<K> { public <T> void put(K<T> key, T value){} } といったことをやろうとして、Javaの言語仕様上、型変数に型変数を持たせることができないので実現できないと述べた。 簡単に解説すると、ここでKayValueはHashMap的なキーを渡せば値を返すオブジェクトで、型変数Kはキーの集合体を表現している。ty
ジェネリクスの代入互換のカラクリ - プログラマーの脳みそ
Javaジェネリクス再入門 - プログラマーの脳みそでは、「変数の型の宣言」の項で「ジェネリクスの<>の中は一般のJavaの型の代入互換性とは異なる。このことはよく覚えておかなくてはいけない。」と言ったものの、深入りはしなかった。 このあたりについて深入りしてみようじゃないか。 とりあえずサンプルコードはJavaで記述していくが、このあたりはジェネリクス指向の概念の部分だから、あまり言語に依ることはない。便宜的にJavaで書く、としておこう。 まず、型変数の境界について考えるために以下の継承関係のクラスを用意しておく。 public class A {} public class B extends A {} public class C extends B {} public class B2 extends A {} public class C2 extends B {} これは図で
Javaジェネリクス再入門 - プログラマーの脳みそ
ジェネリクスでは、「型」を変数にした「型変数」というものを取り扱う。型変数で何が嬉しいかというと、メジャーな例ではコレクションAPIが挙げられる。java.util.Listとかjava.util.Mapとかのデータを格納するタイプのユーティリティクラスのことだ。 2004年にJavaのバージョンが5.0となるまでは、Javaにはジェネリクスの機能はなかった。なので、Listにデータを格納し、取得する場合は List list = new ArrayList(); list.add("hello!"); String str = (String) list.get(0); といったソースコードになる。 add()の引数はObject型で宣言されており、どんな参照型でもadd()することができた。 get()の戻り値もObject型で宣言されておりキャストが必要だった。このキャストはプログラ
再帰的ジェネリクスの代入互換性 - プログラマーの脳みそ
Javaのややこしいジェネリクスの話をしよう。*1 再帰的ジェネリクス クラスHogeがあったとして、型変数Tを取る。 public class Hoge<T> {} このHogeの型変数Tがextends Hogeとすると public class Hoge<T extends Hoge> {} すると、T extends Hoge の Hoge が raw型だと警告される。Hogeの<>の部分にHoge型を継承した型を指定しなければならない。ここで型変数T が extends Hogeだったので、丁度いいからT型をおさめよう。 public class Hoge<T extends Hoge<T>> {} これは再帰的ジェネリクス(recursive generics)と呼ばれているようだ。 追記：僕は勝手に自己言及型ジェネリクスなどと呼んでいた。情報サンクス！併せてタイトルなども表現
Javaでセミコロンなしでプログラムを書く - プログラマーの脳みそ
java-ja温泉2日目の夕食。 @yoshiori がpythonのワンライナの楽しさを得々と語っていた。 @yoshiori「Brainf*ck を Python-oneliner にコンパイルする Python-onelinerを書いたけど全ッ然反応がなかった。こんなに面白いのに！」 @yamashiro「だって分かりにくいもん」 西尾先生が通常ワンライナではtry-catchが使えないけど子プロセス立ち上げて例外を出力してパースすればエラー処理ができるとか(http://www.nishiohirokazu.org/blog/2006/08/python_12.html参照)そんな話で盛り上がる中、 @nagise「Javaでセミコロンなしでプログラムが書けるような気がしてきた」 Javaの場合、普通にセミコロン(;)でマルチステートメントにかけるのでただ1行にしようというなら改行
Java変態文法最速マスター - プログラマーの脳みそ
Java基礎文法最速マスター - いろいろ解析日記をリスペクト。 Javaの変態文法・技法一覧です。Javaの基礎をある程度知っている人はこれを読めばJavaの変態をマスターしてJavaを書くことができるようになっています。簡易リファレンスとしても利用できると思いますので、これは足りないと思うものがあれば教えてください。 1.基礎 エンクロージング型内部classの作成 外部classのインスタンスに紐付くインスタンスを生成します。外部クラスのインスタンス - 内部クラスのインスタンス間に、クラス - インスタンスのような関係を持たせることができます。 public class Outer { public class Inner { } } というようなクラスを作った場合、 Outer o = new Outer(); Inner i = o.new Inner(); となります。new
契約書に捨印を押す - オブジェクト指向と型システムの狭間で例外を考える その2 - プログラマーの脳みそ
オブジェクト指向と型システムの狭間で例外を考える - プログラマーの脳みその続き。 僕は不勉強なのでメイヤー氏の思想というものをそれほどトレース出来ていない。だから開放閉鎖原則についての哲学のようなもの、というのはデザインパターンから嗅ぎとったもので、誤りがある可能性が高いということをあらかじめ断っておく。間違いは指摘してもらえると嬉しい。 検査例外は開放閉鎖原則に反しない まず、検査例外は発生したその場、もしくは直接の呼出し元で処理しない限り、throws に記述せざるを得ない。 そうしない場合、より上位層の throws を追加する必要が出てくる。このような追加、もしくは変更は、中間のクラスの再リリースという手間も必要となる。 これは、明らかに開放閉鎖原則に違反する。 例外について色々と考えてみた - ぐるぐる～ 「検査例外はアジャイルやオブジェクト指向の考えに反するという事実」につい
コードコメントに書くべきは「意図」 - プログラマーの脳みそ
2.トリッキーな実装 ソースを読んだだけではすぐにわからないようなアルゴリズムを採用している場合や、使用しているライブラリのバグ回避のための特殊な処理を行っている場合、または他の人が見たときや自分が数年後に見た時に「なぜここでこんなことを？」と感じる可能性がある場合にはソースコードにコメントを追加するべきだ。これは言わばトリッキーな実装である。 ソースコードのコメント率は20%を切ることが望ましい : 小野和俊のブログ 私はこの部分にはもうちょっと汎用的に「意図」を書くべき、とすることを提案しよう。*1 トリッキーな実装というのは、「普通」ということが分かっていて初めてトリッキーかが分かる。普通か、トリッキーか、というのは時代背景*2というかハード的な制約も関係するだろう。常識は移ろいゆく。本人がトリッキーではないと確信して書かれるコードと、トリッキーなコードとの線引きはどうしたらよいのだ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://nagise.hatenablog.jp/entry/20110729/1311950039