ColdFusionとJava

ColdFusionはイシカワさんと違って素人なのですが(そもそも私はWeb系全般に疎い…。それに比べてイシカワさんはCFの日本語の参考書を全種類買い集めた人です)。隣で他人がColdFusionのソースの改修でアワアワしていたので、なんとなくソースを見ていて、ナゾなところを、ちまちまとググっておりました（好奇心＆手伝いです）。

そんなこんなでウワサには聞いていたけど、CFってホントにJavaで実装しているんだなぁ、と妙に実感したサンプルソース。

<cfset fr=CreateObject("java","java.io.FileReader")>
<cfset fr.init("/tmp/testfile.txt")>
<cfset br=CreateObject("java","java.io.BufferedReader")>
<cfset br.init(fr)>
<cfloop condition="true">
  <cfset line=br.readLine()>
  <cfif not IsDefined("line")><cfbreak></cfif>
  <cfoutput>#line#<br></cfoutput> <!--- この部分 --->
</cfloop>
<cfset fr.close()>

参照元：逆引きColdFusion(1)

上記のソースで私にはよくわからなかったのが、initで、これはなんだろうと思ってググってみたら、リファレンスでは以下のような定義になっていました。

Use the init method, with appropriate arguments, to call an instance of the class.

CFML Reference

initメソッドでjavaのクラスのインスタンス生成というわけなんですね。initのカッコの中は当然コンストラクタの引数。なるほど。

さらにもう一つ、冒頭のソースで躓いたのは、

<cfloop condition="true">

conditionの後の""に条件式を入れるようですが、trueの存在がなんとなく唐突に見えてナットクがいきづらかったのですね。

  <cfif not IsDefined("line")><cfbreak></cfif>

で、読みこんだ行がカラッポだったら、ループを抜けるのでどーでもいいといえばどーでもいいのでしょうが、

<cfloop condition="br.ready()">
  <cfset line=br.readLine()>
  <cfoutput>#line#<br></cfoutput>
</cfloop>

とかの方がなんとなく、個人的には読みやすい気がする…。この辺は普段、自分がそういう書き方ばかりをしているせいなのでしょうか（あ、でも条件式にreadyメソッドを入れることが適切なのか、Javaに疎いので実はあまりわかっていません。どーなんでしょう？)。

ちなみにあれやこれやのサーフィンの道中に、書き込み速度のやり方の比較実験の記事も見つけました（読み込みにあらず）。

CFFILE vs Java.IO.BufferedWriter

CFFILE tag を使うより、圧倒的にJava.IOを使った方が早いんですね。

5.5MBくらいの書き込みでCFFILE tagをフツーに使っていたら600秒かかっていたものが、Java.IOを利用したら、1秒になったそうです。上記サイトの筆者は、当然のことながら、CFFILEはとても手軽だけど、大きいファイルを扱う時にはJavaのメソッドを使った方が良さそうだという結論をくだしています。

まーそりゃそうだろうな、と思いつつも、600秒って10分ですよ。落ちているかと思って、途中でブラウザを閉じてもおかしくない長さですよね。道具は適切に使い分けたいものですね。

memo→本日のブックマーク

はてなのブクマ

ColdFusionのブクマ。ColdFusionは手軽だし、エラーとかも返してくれて結構いいツールだと思うけど、なんで流行らないのでしょーか？

ColdFusionカフェテリア

フォーラム。CF8って.NET Framework 2.0も使えるのか。へー。ほー。でも.NETを使うと今のところWinに環境が限定されちゃうもんね(悲)。Monoプロジェクトに期待したいところだけど、そのままの移植は厳しそうかなぁ…。

Coldfusion-Style

なんか追っかけていたら色々と…。

Java/Officeストーリー

MSっ子な私はこれまでVB6.0なり.NetからのExcel出力部分ではCOM利用をしていて、その部分ではたいした苦労をしたことありません（COMオブジェクトの解放 はちと面倒臭いですけどねー）。ですが、JavaからのExcel出力には、なんだか随分大変な歴史があったのですね。

◆Javaを使ってOffice2007をクラックする

上記サイトの記事を読むと、COM利用の言語の人の場合は、「ExcelのCOMを利用すればいいじゃん」のヒトコトで済むわけなんですが、COMをサポートしてない言語ではCSVで吐いてみたり（それを聞いただけで泣ける…！）、涙と汗の紆余曲折。Office2003が登場したかと思えば、独自路線なXMLフォーマット。しかもそのフォーマットはきちんと文書化されていないという中途半端な状況で、トライアル・アンド・エラーを頻発させしながら、自分達でそのフォーマット状態を手探り状態で解明しなければならないという、暗中模索作業が待っていて…。

全般的に、Java/Officeストーリーは、控えめに言っても、極めて不快な状態でした。Javaの開発者はじっと耐えるか、「Officeは最低だ。とにかく、なぜ、誰かがそれを使いたがるんだい？」と言うことで、イソップ物語の１つを大いに連想するやり方で自分自身を慰めるか、単純に Officeを使っているユーザーに、Microsoft とSun の訴訟問題のせいで、JavaはOfficeを理解することができないのだ、と言ってみるかしかありませんでした。

Javaを使ってOffice2007をクラックする

極めて不快…、Officeは最低って…。憎まれちゃって、まぁ。憎むほど苦労する前に、その部分は、素直にCOMを使える言語を使えばいいのに…、とついつい憎まれっ子世に憚る（？）MSっ子としては呟きたくなるわけですが…。

上記サイトのストーリーを読むと、Office2007の登場でXML文書のZIPファイル以外何物でもないものになったので、やっとJavaの開発者もハッピーになりそうだ、というようなストーリーになっていますね。

もっとも、今のところ、私はOffice2007でのフォーマットの納品自体を頼まれたことはありません。むしろなるべく多くのOfficeで問題なく開くよう、バージョンダウンを意識しています。Java開発者がOOXMLで大手を振って納品できるようになるのはもう少し先のことなのかなぁ、と思うわけですが。

現在、企業ではOffice2007はどれくらい普及しているのでしょうかね。

memo

Microsoft、OOXML の SDK を5月に正式リリース