日々の破片

_ Javaには良い点があるのか？

Javaは本当に良く使われているプログラミング言語だから、プログラミングを知らない人でもプログラムを記述できる。プログラミングを知っているというのは、この場合、ケースバイケースで記述することができるってことだ（というか、正直なところおれが知っているプログラミングはそのあたりまでで、ケースはわかってもプログラミングがわからなくて、まずいプログラミングをすることもたくさんある）。

そのため、プログラムとは言えないソースコードをたくさん目にする機会があってうんざりした。

どのくらいうんざりしたかと言うとコーディングの掟というケーススタディ本を上梓できたくらいだ。

コーディングの掟(最強作法) 現場でよく見る不可解なJavaコードを一掃せよ! (開発の現場セレクション)(arton)

というわけでうんざりしているのはJavaで書かれた妙なコードであって、Javaそのものはそれほど嫌いではなく、むしろ好きな部類に入る。interfaceがある言語は（それがヘッダの関数プロトタイプですら）好きだし。

そういうおれにとって、実に楽しく読めた本をオライリーから頂いたので紹介する。

Java: The Good Parts(Jim Waldo)

一言で説明すると、Javaの中の人が、Javaのコアなパートの良いパートについて、なぜそのパートが必要で、いかにそのパートを実装すべきで、どういう制約や考慮点があって、実際にどうそのパートを実装して、したがってこう利用しろといったパートについて、おれが教えてやる（と言うほど偉そうな感じはないか。おもしろいトピックだから教えてやるよ、っていうくらいのノリかも）という趣の本だ。

この本は技術エッセイとでも呼ぶべき性質のものだから、読みながらコンソールを叩いたりする必要は特にない。だから売り出されたら（売り出されるかどうかはわからないけれど）O'Reilly Japan Ebook Storeから電子書籍版を購入して移動メディアに入れておいて、拾い読みしたりするのにも向いていると思う。

著者はSunの研究所で分散システムをやっていた人らしい。それだけにRMIについて書いてあるパーツはとりわけおもしろい。RPCで継承を持つ型のオブジェクトを送る場合にピアでそのオブジェクトの実際の型を特定するのは難しいのでCORBAでは事実上リファレンスのみを扱うようにしているが、RMIはシリアライゼーションを使えるので本物の型を与えることができる、といった記述があるが、何気なく使ってはいるがそうかシリアライゼーション（と、おれは『シリアライゼーション』と書いているけど、本書ではこの用語については、きちんと『オブジェクトシリアライゼーション』と限定修飾子をつけて久野先生に怒られないよう考慮してある）という考えそのものが重要だったのであるな、と気付かされたり。

次のパートはどういう意味だろう?　

オブジェクトシリアライゼーションは、どんなリモートプロシージャコールシステムにも存在するオブジェクトのマーシャリングおよびアンマーシャリングとほとんど同じように見える。

え、何それ？ 同じことなんじゃないの？ と驚いて続く文章を読むと、え、何それ……しょぼい、みたいな答（それより未来から過去の話を読むと結構あることだ）を与えられてびっくりするのだが、とにかく、なぜマーシャリング/アンマーシャリングという用語を使わなかったのか、ここに解答があるようだ。つまり、オブジェクトシリアライゼーションは、マーシャルのようなちゃちなものとは違う！ という自負というか（……多分）。

取り上げられているパーツは、・型システム（これは好き）、・例外（まあ、中の人だし）、・パッケージ（文句なく同意）、・ガベージコレクション（というか、目次のインデントは編集ミスだな）、Java仮想マシン、Javdoc（良い点に目をつけた）、・コレクション（まったくだ）、・RMIとオブジェクトシリアライゼーション（赤い王子様の本もよろしく）、並行処理（ふむ）、エコロジー（IDE、JUnit、FindBugs）。それぞれ、基礎となる背景説明などがあって、次に見るべき観点ごとに書いている。

それにしても、こういう腰を落ち着けて書かれた技術読み物っては、やっぱり良いな。本当におもしろかった。

追記：糞も味噌もいっしょにSQLExceptionというたわけた仕様があるが、RemoteExceptionについての記述を読むと理屈がわかった。というよりも、型システムのところで明確にされているが、インターフェイスはセマンティクスの上位概念という強い設計思想で統一されているからだ。したがって、SQLExceptionというインターフェイスが示すセマンティクスについて、内部状態を参照することで明らかにすること（そのためのプロパティをオブジェクトは持っている）はプログラマの役割となる。（逆に、そこが実用言語としてのたわけっぷりとなるわけだが、このアカデミズム（実用性に打ち勝つ設計思想の強度をここでは学者的としてこう呼んでみた）とプラグマティズム（と実用主義を訳してみる）のバランスの微妙さ(絶妙では断固として無いね)がJavaのおもしろさ。

_ メソッドは状態なのだろうか？

drubyの実装がどうなっているのか興味はあるところだが、メソッドは状態だろうか、それともインターフェイスだろうか？

もしそれが状態であるならば、リモート呼び出しで値として転送することが可能だ、というよりも可能であるべきだ。

もしインターフェイスならば、それを転送する必要はない。プロクシ（スタブ）で用意すれば良い。

今、JavaScriptのオブジェクト転送を考えてみる。

var o = new Object();
o.state = 'hello';
// oはhelloを持つstateという状態を持つ。当然、oをjsonにマーシャルして送ることは可能。
// では
o.abc = function() { alert('abc'); }
// oはabcをポップアップするabcという状態を持った？ 
// oをマーシャルすると{ "state": "hello", "abc" : "function() { alert('abc')" } となる？
// でも、それ単なるStringだし。

関数がファーストクラスオブジェクトであるならば、それは転送できて当然だ（なぜならばファーストクラスオブジェクトだからだ）。JavaScriptの場合、jsonの範囲では関数はファーストクラスオブジェクトではないということになる。

突然、C#の拡張メソッドについて思いつくが、つまりあれは「拡張」であるから、ファーストクラスオブジェクトではない。当然、転送はできなくてもしょうがない。