開発用PCのOSをVistaに変更したら、Javaランタイムでタイムゾーンが正常に取れなくなりました。

SunのBugレポートを漁ってみたら、Vistaでシステムのタイムゾーンを識別するレジストリのキーが変更されたのが原因とのこと（下記リンク先参照）。

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6440819

確かにレジストリのタイムゾーンの指定キーが　XP：StandardName　->　Vista: TimeZoneKeyName　に変わってました。

で、このBugが修正されたのは1.5.0_10だったので、使用していた1.5.0_7では発生してしまっていたというわけでした。

Javaプログラム実行時にプロキシ経由接続が必要だと、java.net.ConnectExceptionが発生する場合があるようです。
今日Saxon+XSLTを使ったXML変換処理を行う際に発生する環境がありました(Saxonが接続しに行くのは、指定されたDTDを取りに行く為です)。

後述するSunのドキュメントで調べたところ、OSのバージョンによって自動でシステムのプロキシ設定を検出できないものがあり、

"最近のWindowsでは対応している"とのこと (なんて抽象的な!)。そしてどうやらVistaがこれに当たり、XPは該当しないようです。

自動検出されないＯＳの場合は、手動設定します。実行時に以下のいずれかのVMオプションを追加します。
・プロキシを直接指定する場合: -Dhttp.proxyHost=[ホスト名] -Dhttp.proxyPort=[ポート番号]
・システムのプロキシ設定を検出する場合: -Djava.net.useSystemProxies=true

例えば今回のSaxon+XSLTの場合は、
java -Djava.net.useSystemProxies=true -jar saxon8.jar -o out.xml in.xml transform.xsl
というようにします。

これらについてのより詳しい情報は、Sunの提供している"JDK Programmer Guides”に詳しく載っています(下記URL)。
http://java.sun.com/javase/6/docs/technotes/guides/net/proxies.html

"ありえるえりあ勉強会@溜池山王　～第1回ディープすぎるJava・・・～"のLT資料公開のはずでしたが、まさかの時間切れという結果になってしまった為、ここで改めて語らせてもらいます。

お題は"Java SE 7"です。"いつリリースするんだ"でお馴染みのJava SE 7ですが、意外と現状は知られていない気がするのでそのあたりを話します。主催者の大谷さんから渡されたお題は"Java 7をdisる"ですが、その目的もこれだけで果たせるかもしれません。

まず最初に断っておきますが、そもそもJava SE 7は今のところ計画されていません。今"そんなはずはない"とツッコミを入れた人がこの記事の対象読者です。できれば最後までお付き合いください。

ここ数年"Java"と"7"という2つのキーワードが耳に入ってくるのは確かです。でもそれらは決まってJDK 7の話であってJava SE 7の話ではありません。ややこしいのでしょうか？まずは用語の意味を明確にします。

まずJava SEとはなんでしょうか。Java SEは仕様です。JCP(Java Community Process)というオープンな仕組の中で作られます(ここでの"オープンな"の意味はその決定が1つのベンダーのみによって独占的に行われない、という意味です)。JSR(Java Specification Request)として提案され、それが段階を踏んで仕様としてリリースされます。これまでリリースされた各バージョンの仕様は以下にあります。

JSR-59: 1.4 (Merlin), JSR-176: 5.0 (Tiger), JSR-270: 6 (Mustang)

一方JDKはJava SEを実装したSunの製品です。そしてJava SEのSpec LeadでもあるSunが提供する参照実装です。

これで冒頭で"そもそもJava SE 7は計画されていない"が指していることがお分かりかと思います。つまりJava SE 7のJSRが存在しないのです。ここで疑問が湧いてきませんか？じゃあなぜJDK 7が存在するんだろう？仕様がないのに参照実装がある？そんなことあるんでしょうか。

JDK 7が存在するのはその役割が変わった為です。Sunが言うにはJDK 7はプロトタイプであり、将来Java SE 7を提案する為の準備らしいのです。受け入れられなかった時は潔く捨てるらしいのです。でも本当でしょうか。営利目的の企業が多くのリソースを注ぎ込んでデモの準備をするものでしょうか。あるいは百歩譲ってそれがSunの本心だとしても、なんでSunはJDKの意味を変えたのでしょうか。そのことに触れる前に、そもそも今どのくらい遅れているのかを確認したいと思います。

Java SEはこれまで2-3年ごとに提案、リリースされてきました。順当に行けばJava SE 7の提案は2007年頃、リリースは2008-2009年あたりです。そして今回のLTはJava SE 8についての話になっていたはずです。なぜこんなにも遅れているのでしょうか？考えられる理由をいくつかあげてみます。

1. Java SE 7を望む声が小さかった
多くの製品は未だにJ2SE 1.4で動いているようです。

2. Sunに体力が残っていなかった
 2008年、SunはOpenJDKとJavaFXをロンチしました。

3. JCP内でのいざこざ
政治的な問題に終わりが見えません。
 
3についてもう少し説明します。異なった文化が集まればそこにいざこざはつきものですが、それにしてもここ数年のJCPは酷い状態だったように思えます。代表的なのがApache Harmony論争です。Java SEはSpec LeadであるSunが知的財産権を持っています。Sun以外がJava SEを実装する場合、Sun
からライセンスを提供してもらう必要があります。その為にはまずTCK(仕様への準拠を証明する為のテストキット)のテストにパスする必要があり、そしてそのTCKを取得するにもSunとライセンス契約しなければなりません。Apache Harmony論争はこのTCKのライセンスをめぐる争いです。

ライセンスの契約内容は公開されていませんが、ApacheによるとTCKのライセンスに使用分野制限(field of use restriction)がついていて、そのTCKでテストしたHarmonyはPC内では利用できますが、ショッピングモールにある情報端末のような閉ざされた場所内では利用できないそうです。この使用分野制限が"オープンなライセンスで独自なJava SE実装を提供する"というプロジェクトの目的に反する為、ApacheはHarmonyをリリースできずにいます。そしてこの論争はJCPをも巻き込む騒動になりました。

政治的な問題を抱えたJCPに対し、Sunは修復よりも捨てる道を選びました。先日開催されたTheServerSide Java SymposiumでGosling(彼も既に去りましたが)がJCPと決別したいと言ったのは記憶に新しいところです。つまりこれがJava SE 7が未だにJCPの管理下になく、SunがJDK 7の役割を切り替えた背景でしょう。Java SEは今やオープンではなくなろうとしてるのです。オープンなのはJDKのソースくらいです。

しかし今年に入って少しばかり希望が出てきました。OracleによるSunの買収です。OracleはこれまでJCP内でのSunのやり方に否定的な立場を取っていました。純粋な目で見れば、解決は時間の問題に思えます。OracleがJCPを正常化し。より透明性の高いものにしてくれるはずです。もちろん力を手にした支配者が主張を変え、破滅への道を歩んだ例は数多くあります。Oracleがそうならないことを願います。