yamicha.com's Blog - Presented by yamicha.com
Blog yamicha.com's Blog - 2017/09 の記事
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30]

yamicha.com's Blog
 諸事情により、現在更新休止中。ご了承ください。もし今後ブログを再開することがあるとすれば、その際にはこのブログスクリプトではなく、新しく開発したものによるかもしれません。
 当ブログ管理者についてはこちらをご参照。
開発魔法(737)
社会問題(733)
お知らせ(11)
質問・バトン回答(15)
ゲスト出演(8)
経済・知的財産(150)
ゲーム開発(182)
[Ada] 勝手に補足
- Note
- 金配りの次の一手


- Endless Ultimate Diary
- 銃世界

漢字バトン
- うるる雑記帳
- 漢字接力棒

ツキアイゲノムバトン
- ブログ@うにうに画像倉庫
- あぶ内閣

縺イ縺セ縺、縺カ縺励ヰ繝医Φ
- 月夜のボヤキ
- 騎士サーラバトン
パスワードを使う
名無し (2012/02/27)


開発者解放裁判
yamicha.com (2010/03/14)
Winnyに関しては、私も「純白」とまでは考えておりませんし、使用し..

開発者解放裁判
通りすがり (2010/03/08)
winnyに関しては「ダウンロードソフト板」なんてところを拠点に開発..

新型インフルエンザの恐怖
いげ太 (2009/11/03)
> C#などの「int Some(int , int)」は、F#では「(int * int) ->..

時効に関する思考
yamicha.com (2009/08/31)
>いげ太さんコメントありがとうございます。手元にドキュメントが少..
Homepage
Blog Top
Normal View
List View
Search
Calendar
Comment List
Trackback List
Blog RSS
Send Trackback
Phone Mode
Administrator
yamicha.com
Blog
るううるる。
Source
法令データ提供システム
FindLaw
Development
Java2 Platform SE 6
Java EE 6 API
MySQL Developer Zone
PHP Reference
MSDN Library
Ada Reference Manual
Objective Caml
Python Documentation
Erlang
Prolog Documents
銃世界
2007/04/18(Wed)21:07:08
 何と長崎市長銃殺。どうしてこうもあちこちで銃撃事件が起きるのでしょうか。米国の事件だけでなく、先に起こった日本の右翼による銃撃といい。何にしても、銃撃されるいわれのない市長を非民主的な暴力で攻撃しようなどという行為は絶対に許せたものではありません。前の右翼による銃撃事件では、犯人は「被害者の言葉が気に入らなかった」などと称して自己正当化を行っていたようですが、自分が神にでもなったつもりでしょうか。
 今回の事件は、現状の供述のみから判断する限り、思想に個人的な恨みが混ざった上での犯行のようですが、言うまでもなく罪は重いです。ヤクザとトラブルを起こしたら正義面して撃ち殺される恐れがあるなどとは、とんでもない世の中もあったものです。そもそも銃を平然と入手・使用できることからしてどうかしています。
 暴力団などの非合法組織を下手に残しておけば、市民も恐怖から逃れることができません。事件を起こした犯人には厳罰を下した上で、暴力団については徹底的に追放を図るべきです。映画などの芸術作品によって何となくイメージ良く誤解されがちな暴力団ですが、資金源は麻薬・武器密輸・ヤミ金、抗争時には街中でも拳銃をぶっ放し、普段から拳銃や刀剣など銃刀法違反とされる武器を所有する上、気に入らない相手には武器を持って襲い掛かるなど、極めて反社会的な存在です。暴力団根絶によって武器密輸や麻薬汚染、ヤミ金被害を軽減することもできるでしょう。
 米国の銃乱射などもあり、つくづく実感させられる話なのですが、どうやら人間は武器を持つと必ずそれを使ってしまうようです。ただし、ここで言う「武器」とは、殺傷能力を持つ兵器のみならず、身体的な攻撃に限らず様々な方面から相手を攻撃することができるものです。
 世の中、常人にはまず理解不能な、意味不明な右翼思想を持つ者がいます。何の根拠もないくせに、他人や他国について意味不明な非難を行う、客観的に見れば明らかに主張が支離滅裂な連中です。何が恐ろしいかといいますと、こうした右翼思想者が銃を持てば違う思想の人を正義気取りで銃撃しますし、インターネットを手に入れれば「中傷」「炎上」「嫌がらせ」。それは違法行為、またはマナー違反であると指摘しても、自分のみ正しいと考えているため、始末におえません。
 そういえば、国もテロに加担しているようなところがあります。反戦を主張する地方政治家が自らの考えを訴え、言い分を気に入らないと称する犯人に攻撃された際にも、政府の対応は及び腰。時に政府の姿勢を批判する政治家宅に火が放たれ、下手すると居住している老人が逃げ遅れる可能性もあった許しがたい言論封殺テロに対しても、やはり政府連中は積極的に怒りを口にするようなこともありませんでした。逆に、政府の思想に近い人間が攻撃されようものなら「テロは許しがたい」「言論封殺行為は絶対に許されない」。私はこういう対応が許しがたいです。
 ともかく、今回の犯人に対しては厳罰を望みます。地方政治家は国政政治家に比べて、また市町村の政治家は都道府県知事に比べて発言力が弱いものですが、そうした「小さな声」を踏み潰す行為こそ本当のテロなのです。

 関連しますが、バージニアの銃乱射事件について。米国では定期的にこの種の事件が起きている気がしてなりません。学校関係であればコロンバイン事件はまだ記憶に新しいところですし、銃乱射が起こるたびに「銃規制を強化すべし」との声が出てくるにもかかわらず、ライフル協会などの反対を受けて毎度のごとく規制案が消滅してしまいます。その結果はといえば、また何年か後に必ず銃乱射が起こるのです。
 米国のことですから口出しはできないとはいえ、他人事ではありません。30人も殺害されるというのは他国から見ても極めて痛ましい事件ですし、以前には日本人が撃ち殺される事件もありました。被害者の日本人がハロウィンパーティーか何かのパーティーに参加する際、うっかり入る家を間違えてしまい、無防備かつ全く殺意のない表情でその家の住人に近づいていったそうです。それに対して住人は「ストップ」などでなく「フリーズ」と叫んで威嚇したものの、被害者はその意味を理解できず、結果として住人が銃を持ち出してきて被害者を撃ち殺してしまったのです。
 これには元FBIのロバート・レスラー氏も疑問を呈しています。相手は無防備で笑顔であり、およそ攻撃性があるようには見えなかった上、それでも住人が被害者の行動を阻止したかったのであれば、いきなり銃で致命傷を負わせるのではなく、物で殴るなど殺傷力の低い方法でまず対処すべきであったというのです。合理的な考え方でしょう。
 ライフル協会などは「銃が人を殺すのではない」と主張しています。これはもっともですし、言い分は理解できるのですが、残念ながら世の中には銃を理性的に使えない人も存在するのです。誰もが銃を適切に使用できればこの主張は当たるのですが、実際にはそうでない場合も多く、「銃が人を変え、人が人を殺す」のです。
 日本にも無差別連続殺傷は存在します。その多くが刃物によるもので、池田小や駅乱入殺傷などの事件がこれに当たります。こちらも恐ろしい通り魔事件ではあるのですが、米国の銃乱射はこれよりもさらに被害者数が多い場合がほとんどです。今回の銃乱射事件では何と30人以上が犠牲になりましたが、日本でこれほどの被害を出したものといえば、「津山30人殺し」だけでしょうか。日本の厳しい武器規制が米国並みの事件を防いでいると考えることができます。
 当然ではありますが、日本は当面「銃なし」でいくべきです。はっきり言って日本ほど治安の良い国はそうそうあるものではありませんが、銃が持てないのも理由の1つでしょう。

 Java SE 6での既存パッケージへの追加機能といえば、和暦などが結構有名なようです。昭和やら平成というアレです。ちなみにJava SE 6では明治以降の和暦しか扱うことができず、江戸やら室町やらといった中世や古代の年号を使うことはできません。確かにBD.○○年は縄文時代何年かなどといわれても答えようがありませんが。
 しかし、私は開発中に和暦など意識したことがありません。データベースでも何でも西暦で事足りますし、スマートです。それなのになぜ和暦が必要かといいますと、未だに官の文書では和暦が使われているからなのだそうで。非常に非合理的ではないでしょうか。異種プラットフォーム間ばかりか世界規模でデータを交換するような時代に、和暦を使うメリットがどこにあるのでしょうか。「慣例」やら「伝統」といった意味不明な理由ではなく、例えば「和暦にすることで事務作業が軽減される」などのような具体的なメリットを示して欲しいものです。西暦に統一する方が明らかに合理的でしょう。
 現実問題、私はこの機能を怖くて使えません。西暦は正の無限大で永久に未来を表すことができますが、和暦では不可能です。人間1人が死ぬだけのことで名前が変わって年数がリセットされる年号などとても利用する気になれません。年号がいつ変わるのか、次の年号が何なのか、といったことを予測することは不可能ですし、不可能であるからには次の年号に関するデータもパッケージには入っていないわけで、正しい和暦を取得するためには、永久にパッケージが更新され続ける必要があります
 しかし、更新によってバグが出る場合などもあるため、アップグレードというのはかなり困難を伴う行為です。さらに年号に不整合が出てくる可能性も考えられます。例えば「○○、平成25年に完成予定」という記事と「次の免許更新日が平成24年○月○日以降の人は新規定の対象になります」という記事が存在するとしましょう。これらが同じVM上で動いているとします。
 そして、仮に平成が20年で終わり、平成20年が新年号元年になったとします。「○○、平成25年に完成予定」をそのままにしておくのはまずいですから、Javaをアップグレードしました。すると、ここは確かに「○○、新年号5年に完成予定」になったのですが、免許の方も「更新日が新年号4年の〜」に変わってしまいました。これでは大混乱を招くことは明らかでしょう。年号が変わるだけで大変な騒ぎになります。これを回避するには免許についての表示を定数にする(「平成24年〜」を文字列にする)ことなどが考えられますが、様々な記事をはじからこのように処理していては、柔軟性は明らかに失われます。
 日本もいい加減、西暦に統一すべしということで。和暦を存続するのは構いませんが、単に官が文書に使う年号を西暦にし、通貨などに使われている年号もそれに変えるだけで、効率が全く違ってくるはずなのです。さらに言えば、おそらく和暦などの「非効率」の積み重ねが公務を増大させ、役人の肥大化を招いているのでしょう。

 話がずれましたが、Java SE 6ではJDBC 4.0が導入されています。ドラフト仕様のJDBC 4.0では山のようにアノテーションが導入されており、好奇心を通り越してげんなりしたものですが、Java SE 6.0で実際に導入されたJDBC 4.0といえばどうでしょう。目立った変更がほとんどなされていないのです。
 ぱっと見で目立つものといえば、例外がやたら増えていることでしょうか。これまではどのような例外もSQLExceptionでしたが、それが色々なものに分かれています。とはいえ、これらはどれもSQLExceptionを継承していますから、開発者は個々の例外をキャッチしても良いですし、SQLExceptionでまとめてかき集めても良いのです。
 その他の変更点はといえば、正直言ってあまり見当たりません。ドラフトではあれほど見かけた(はずの)アノテーションは一切なくなっています。アノテーションで提供できそうな機能はすべてPersistenceに移管されたのでしょうか。確かにPersistenceは便利といえなくもありませんが、場合によってはJDBC直打ちしかできない状況もあるのですから、アノテーションが多少あっても良かった気はします。無論、意味不明にならない程度に、ですが。
 地味にありがたい機能としては、DriverManagerを使ってコネクションを作成する際、事前にドライバクラスを読み込んでおく必要がなくなっています。これまではClass.forName()などという不毛な作業を行わなくてはなりませんでしたが、今回からはDriverManager.getConnection()でいきなり接続を取れます。Servlet環境ではDriverManagerではなくDataSourceを使うのが普通でしょうが、こちらはTomcatでもDIがサポートされたとあって、接続作成時はSEでもEEでもClass.forName()なくしていきなりDriverManager.getConnection()か、JNDIルックアップを行うことなく@ResourceでDIという非常に簡単なものになっています。
 ところで、今回のJDBCの目玉は「XML」なのだとか。全く、XMLの一体何が楽しいのか良く分かりませんが、とにかくそういうことにしておきましょう。何でもSQLにはXML型なるものが存在し(MySQLにはないようですが)、それとのマッピングを提供するのだとか。
 そういうことを言われると、使いたくなってしまうのが私の性質です。早速MySQLのJDBC 4.0ドライバ(アルファ版)をダウンロードし、Tomcatで使ってみました。まずはJNDIルックアップして使ってみるところから。
<%@page import="java.io.* , java.sql.* , javax.sql.* , 
javax.annotation.* , javax.xml.transform.* , 
javax.xml.transform.dom.* , org.w3c.dom.*" 
contentType="text/xml;charset=Shift_JIS" %>

<%!
@Resource(name="jdbc/MySQL") private DataSource ds;
%>

<%
Connection c = ds.getConnection();

// 適当な XML が保存されたカラムを指定
PreparedStatement ps = c.prepareStatement(
	"SELECT xml FROM y_rss_data WHERE number = ?");
ps.setInt(1 , 1);
ResultSet rs = ps.executeQuery();

try{
	while(rs.next()){
		SQLXML xml = rs.getSQLXML("xml");
		DOMSource source = xml.getSource(DOMSource.class);
		Document doc = (Document)source.getNode();

		Transformer tf = TransformerFactory.newInstance().
			newTransformer();
		tf.transform(source , new StreamResult(out));

		xml.free();
	}
}catch(Throwable e){
	e.printStackTrace(new PrintWriter(out));
}

c.close();
%>
 が、例外を投げられて撃沈。どうやらResultSetはTomcatが提供するデリゲートであるらしく、現状ではサポートされていないのか、getSQLXML()の部分でエラーが出ています。
 しかし私はあわてず騒がず、ResultSetをラップ解除して使うことにしました。これならMySQLのResultSetですから、何とかなるでしょう。まずはMySQLのJDBCが収録されたJARバイナリを無理やりテキストエディタで開き、「ResultSet」で検索してそれらしいクラスを探し、それをunwrap()の引数に指定してラップ解除します。
// ...

ResultSet rs = ps.executeQuery();
rs = rs.unwrap(com.mysql.jdbc.JDBC4ResultSet.class);

// ...
 で、例によって撃沈。何とunwrap()でも例外を投げてくるのです。この様子では、少々あがいた程度ではどうにもならないでしょう。しかし、なんとしてでもcom.mysql.jdbc.JDBC4ResultSetは欲しいところです。
 こうなったら、もうアレしかないでしょう。
Connection c = DriverManager.getConnection(
	"jdbc:mysql://www.localyamicha.com/yamicha?" + 
	"user=yamicha&password=password" + 
	"&useUnicode=true&characterEncoding=SJIS");
 切り札・DriverManager。これなら確実にMySQLのクラスを取得することができます。JNDIを使おうにも、Tomcatではラップ解除すらできず、どうしようもないのですから仕方ありません。JDBC 4.0を含むJava SE 6が出たのはJava EE 5の後ですから、TomcatがJava EE 5に準拠しようとしたのなら、JDBC 4.0がサポートされないのはやむを得ません。おそらく次のバージョンにもなれば修正され、ラップ解除だのといった操作をしなくても使えるようになっているでしょう。
 そういうわけで、とにかく適当なXMLを読んでみることにしました。ひとまずRSSリーダーで使っているテーブルに登録されているXMLでも。4.1以降のMySQLでは文字コードが厳密に設定されており、CHAR、VARCHAR、TEXT系カラムに様々な文字コードのデータを登録することはできませんから、様々な文字コードが混在する可能性のあるXMLについては、VARBINARYかBLOB系カラムに登録するのが適切です。こうした事情から、XMLデータはMEDIUMBLOBに登録されているのですが、これをgetSQLXML()を使って読み込んでみました。
 そしてテキストノードを表示してみたところ、意味不明な文字の嵐。どうやら完全に文字化けを起こしてしまっています。MySQLのJDBC 4.0でのXMLデータの取得が一体どのように行われているのかは私には分かりませんが、内部で過剰にエンコードしてしまうのか、逆にエンコードしないために文字化けしてしまうのか。ともかくMySQLにXML型が導入されれば解決する問題でしょうが、それは当分先でしょう。
 仕方がないので新しくテーブルを作り、今度はTEXTカラムにXMLを登録してみることにしました。テストもかねて2パターン登録してみます。
CREATE TABLE jdbc_xml(number INT , xml MEDIUMTEXT , PRIMARY KEY(number));

INSERT INTO jdbc_xml VALUES(1 , '<?xml version="1.0" encoding="Shift_JIS"?>
<Data>テキストノード</Data>');
INSERT INTO jdbc_xml VALUES(2 , '<?xml version="1.0" encoding="UTF-8"?>
<Data>テキストノード</Data>');
 後者はエンコード指定こそUTF-8ですが、文字コードはShift_JISです。内部で変換していれば、おそらく後者は文字化けするはずです。それでは、JSPでこれを読み込んでみます。
Connection c = DriverManager.getConnection("...");

PreparedStatement ps = c.prepareStatement(
	"SELECT xml FROM jdbc_xml");
ResultSet rs = ps.executeQuery();

try{
	while(rs.next()){
		SQLXML xml = rs.getSQLXML("xml");
		DOMSource source = xml.getSource(DOMSource.class);
		Document doc = (Document)source.getNode();

		out.println(doc.getElementsByTagName("Data").
			item(0).getFirstChild().getNodeValue());

		xml.free();
	}
}catch(Throwable e){
	e.printStackTrace(new PrintWriter(out));
}

c.close();
 結果は何と次の通り。
テキストノード
テキストノード
 どうやら全くもって変換を行ってくれていないようです。これはおそらく、MySQLのJDBCが「とりあえず文字列を取得してXMLにする」という処理のみを行っているためでしょう。DBでもJDBCでも変換が行わなければ、結果として変化が見られないのも当然です。
 JDBC 4.0の仕様では、標準でDOM、SAX、StAXをサポートしています。どれでも好きなものに変換することができるようです。また、書き込むことも可能になっているようです。
 では適当なXMLをデータベースに書き込んでみましょうか。
// characterEncoding は SJIS でも良い
Connection c = DriverManager.getConnection(
	"jdbc:mysql://localhost/yamicha?" + 
	"user=yamicha&password=password&useUnicode=true&" + 
	"characterEncoding=UTF8");

String names[] = {"DOM" , "SAX" , "StAX"};
String fullnames[] = {"Document Object Model" , 
	"Simple API for XML" , "Streaming API for XML"};
String reading[] = {"可能" , "可能" , "可能"};
String writing[] = {"可能" , "不可" , "可能"};

try{
	PreparedStatement ps = c.prepareStatement(
		"INSERT INTO jdbc_xml VALUES(? , ?)");

	for(int i = 0; i < names.length; i++){
		SQLXML sqlxml = c.createSQLXML();
		OutputStream os = sqlxml.setBinaryStream();
		out.println(os);

		XMLOutputFactory factory = XMLOutputFactory.newInstance();
		XMLStreamWriter xml = factory.createXMLStreamWriter(
			os , "UTF-8");
		xml.writeStartDocument("UTF-8" , "1.0");

		xml.writeStartElement("Parser");

		xml.writeStartElement("Name");
		xml.writeCharacters(names[i]);
		xml.writeEndElement();

		xml.writeStartElement("FullName");
		xml.writeCharacters(fullnames[i]);
		xml.writeEndElement();

		xml.writeStartElement("Reading");
		xml.writeCharacters(reading[i]);
		xml.writeEndElement();

		xml.writeStartElement("Writing");
		xml.writeCharacters(writing[i]);
		xml.writeEndElement();

		xml.writeEndElement();

		xml.close();
		os.close();

		ps.setInt(1 , i + 1);
		ps.setSQLXML(2 , sqlxml);

		ps.executeUpdate();

		sqlxml.free();
	}
}catch(Throwable e){
	e.printStackTrace(new PrintWriter(out));
}

c.close();
 コードにするとこれだけですが、疲れました。
 おそらくMySQL JDBC 4.0(しかもアルファ版)の仕様と考えられるのですが、JDBCのAPIドキュメントにも
StAXResult staxResult = sqlxml.setResult(StAXResult.class);
XMLStreamWriter streamWriter = staxResult.getXMLStreamWriter();
 サンプルとしてこのようなコードが書いてあるにもかかわらず、これで実際に返してくるのはnullです。ただし、getXMLEventWriter()ならXMLEventWriter()が返ります。StAXResultのgetXMLStreamWriter()の説明によれば「この StAXResult が XMLEventWriter に基づいて作成された場合、XMLStreamWriter は null になります」とのこと。コンストラクタにXMLEventWriterを取るものとXMLStreamWriterを取るものの2種類がありますので、「基づいて作成」とはこれのことでしょうか。MySQLではXMLEventWriterが引数のコンストラクタを使っており、結果としてXMLStreamWriterは使えない、と考えれば不自然ではありませんが、APIのサンプルコードではXMLStreamWriterを取得する例が堂々と例示されているのに、これはあまりに不親切です。
 これがもしMySQL ABのミスとすれば、JDBC 4.0のバグ修正版ではXMLStreamWriterが返るようになり、XMLEventWriterが使えなくなる恐れがあります。この辺の実装がベンダーの自由とされているなら、ベンダーごとの互換性はゼロに等しくなります。本当はXMLStreamWriterとXMLEventWriterの好きな方を取得できれば最も良いのですが、StAXResultのコンストラクタを見る限りでは片方しか登録できないようです。ベンダーが独自に継承クラスを作れば良いだけの話ではありますが。
 仕方がありませんので、今度はWriterを使おうとしました。XMLSQLからWriterを取得し、StAXの出力先としてセットしてやれば良いのですから。これはsqlxml.setCharacterStream()で得られるのですが、実際に実装してみたところ、何とこちらも上手く動作しないのです。何でも、NullPointerExceptionだそうで。
 仕方がないのでOutputStreamを使った今回の実装になりましたが、非常に困ったことが1つ。最初の方で書いている通り、BLOB型のデータをXMLとして読み込むと文字化けが発生し、上手く動作してくれません。ですから今回はTEXT型を使っているのですが、TEXT型は文字コードを厳密に管理します。MySQLでは「SET NAMES」コマンドなどで使用する文字コードを設定できるのですが、仮にXMLが「encoding="Shift_JIS"」に設定されていても、EUC-JPであっても、UTF-8であっても、データベースのデータは現在設定している文字コードに変換されて返ってくるのです。つまり、例えば文字コードをUTF-8に設定して読み込んだ場合、XMLのencodingがShift_JISであれ、EUC-JPであれ、XMLデータはUTF-8に変換されて返ってくるため、明らかに不整合な状態になります。
 しかも、XMLSQLでOutputStreamを使って保存する場合、例えばOutputStreamの文字コードにShift_JISなどを指定すると、データをShift_JISに変換してOutputStreamに書き込んでしまいます。それをデータベースに保存しようとすると、データベースに保存する際にさらに変換を行うような動作になるらしく、文字化けが発生してしまいます。すなわち、XMLSQL側の文字コードはUTF-8でなければなりません。
 本当はBLOBで保存できれば良いのですが、現状でそのような贅沢は言えません。少なくとも現状のMySQL JDBC 4.0(Connector/J 5.1.0)ではXMLで使用するエンコードはUTF-8に統一しておくことが必要と考えられます。ただし、現状のMySQLコネクタではSQLXMLを使用する場合にはエンコード関連の処理を行わないらしいため、明らかにencoding指定とXML中のエンコードが違っていようが、一切無問題でしっかりパースしてくれるようです。とはいえ、この仕様に頼るのは危ないでしょう。そのうち修正される可能性が濃厚です。
 とにかく無事にデータを登録できたら、今度はそのデータを読み込んでみましょう。DOMでもSAXでもStAXでもお好きなように。DOMなら以下のようになるでしょうか。
<html>
<head>
<title>JDBC 4.0</title>
</head>
<body>

<%
Connection c = DriverManager.getConnection(
 "jdbc:mysql://localhost/yamicha?" + 
 "user=yamicha&password=password&useUnicode=true&" + 
 "characterEncoding=SJIS");

PreparedStatement ps = c.prepareStatement("SELECT xml FROM jdbc_xml");
ResultSet rs = ps.executeQuery();

try{
 while(rs.next()){
  SQLXML xml = rs.getSQLXML("xml");

  DOMSource source = xml.getSource(DOMSource.class);
  Document doc = (Document)source.getNode();

  Element root = doc.getDocumentElement();
  String name = root.getElementsByTagName("Name").
   item(0).getFirstChild().getNodeValue();
  String fullname = root.getElementsByTagName("FullName").
   item(0).getFirstChild().getNodeValue();
  String reading = root.getElementsByTagName("Reading").
   item(0).getFirstChild().getNodeValue();
  String writing = root.getElementsByTagName("Writing").
   item(0).getFirstChild().getNodeValue();

  out.println("<table border=\"1\">");
  out.println(
   "<tr><td bgcolor=\"#CCDDFF\">パーサ名</td><td>" 
   + name + "</td></tr>");
  out.println(
   "<tr><td bgcolor=\"#CCDDFF\">正式名称</td><td>" 
   + fullname + "</td></tr>");
  out.println(
   "<tr><td bgcolor=\"#CCDDFF\">読み込み</td><td>" 
   + reading + "</td></tr>");
  out.println(
   "<tr><td bgcolor=\"#CCDDFF\">書き出し</td><td>" 
   + writing + "</td></tr>");

  xml.free();
 }
}catch(Throwable e){
 e.printStackTrace(new PrintWriter(out));
}

c.close();
%>

</body>
</html>
 ついでにStAXを使おうとしたのですが、何とNullPointerException。どうやら私のミスではなく、MySQLのJDBCドライバ内のメソッドで起きているようです。無論、JavaのAPIにはSQLExceptionを投げるとは書いてありますが、NullPointerExceptionを投げるとは書かれていません。JDBC 4.0が出てまだ日も浅いことですし、アルファ品質ではこの辺りが限界でしょうか。
 この辺りは正式版が出てから試してみるとしましょう。まずはJDBC 4.0より何よりMySQL 5.1の正式版が待ち遠しいです。XA Transactionの完全サポート、FULL OUTER JOINなど、5.1で可能になるのでしょうか。
カテゴリ [開発魔法][社会問題] [トラックバック 1][コメント 0]
<- 前の記事を参照 次の記事を参照 ->

Trackback(1)
(from Endless Ultimate Diary) - 2007/04/18(Wed)22:09:15
16日午前、アメリカのバージニア工科大学で銃乱射事件が勃発、容疑者含め33人が死亡。17日夜、長崎駅前で伊藤一長長崎市長が狙撃され、心肺停止の重体。……国こそ違えど、なぜ2日も続けてこんなとんでもない銃撃事


- Blog by yamicha.com -