今回は、Excel だけでなく、Word, PowerPoint など、
すべての API を移植しました。

（JDK 1.5 から 1.4 への移植のノウハウ）

忘れないうちに、JDK 1.4 への移植のノウハウを記載しておきます。
（こういう移植のケースはあまりないと思いますが、参考までに。）

ジェネリクスをすべて削除する。（ソース全体を正規表現で置換。）

	Set --> Set
	List --> List
	Map --> Map

アノテーションをすべて削除する。（ソース全体を正規表現で置換。）

	@Override --> 削除

JDK 1.5 で簡略化された for 文を元の古い書き方に直す。（手作業。Eclipseのインテリセンスで雛形作成。）

	（修正前）
	for (Record r : records) {

	（修正後）
	for (Iterator iterator = records.iterator(); iterator.hasNext();) {
		Record r = (Record) iterator.next();

キャストを追記する。（手作業。Eclipseの自動訂正候補が補完。複数候補が出たときは要注意。）

	（修正前）
		Record r = iterator.next();

	（修正後）
		Record r = (Record) iterator.next();

JDK 1.4 にはオートボクシング機能がないので、型をあわせる。（手作業。確実に型をあわせる。）

	（修正前）
	int i = new Integer(10);

	（修正後）
	int i = new Integer(10).intValue();
	または
	Integer i = new Integer(10);

Integer クラス（他に Byte, Short, Long, Double）の valueOf() メソッドはないので、new Integer() に変換する。（ソース全体を正規表現で置換。）

	Integer.valueOf(i) --> new Integer(i)
	Long.valueOf(i) --> new Long(i)
	Double.valueOf(i) --> new Double(i)

JDK 1.4 には enum がない。しかし class と static な変数を使って書き直すと、enum と同じ働きをする。（正規表現で置換。必要に応じて手直し。）

	（修正前）
	public enum LayoutMode {
		EDGE,
		FACTOR
	}

	（修正後）
	public class LayoutMode {
		public static final LayoutMode EDGE = new LayoutMode();
		public static final LayoutMode FACTOR = new LayoutMode();
	}

Comparator インターフェースが implements されているクラスの compare メソッドの引数を Object 型に直す。（手作業。）

	（修正前）
		public int compare(String a, String b) {

	（修正後）
		public int compare(Object in_a, Object in_b) {
			String a = (String) in_a;
			String b = (String) in_b;

JDK 1.4 では Exception クラスのコンストラクタの引数として Exception オブジェクトを渡せないので、エラーメッセージを渡す。（手作業。）

	（修正前）
		throw new RuntimeException(e);

	（修正後）
		throw new RuntimeException(e.getMessage());

別々のクラスで static な変数どうしを参照した場合、JDK 1.5 では問題はおきないが、JDK 1.4 では変数の値が NULL になるので、参照ではなくお互いに new する。（手作業。）

足りないクラスやメソッドは自作する。入念なユニット試験を行う。

大原則として、ロジックを変更しない。

（あとかぎ）

2012-03-26 に POI 3.8-FIANL がリリースされたので、
移植しようかどうか、迷っていましたが、
POI 3.7-FINAL の不具合として
「Excelファイルを編集すると、たまにファイルを読み込めなくなる問題（再現性あり）」が
POI 3.8-FINAL で解消されていたため、勉強もかねて移植を決めました。

昨年同様、ゴールデンウィークの4月末から JDK 1.4 への移植を始めました。
休みの日を使い、2012-05-20 になって、なんとかリリースできました。

前バージョンの POI 3.7 とは違い、想定していたよりも修正ファイルが多く、
途中で投げ出しそうになりましたが、POI 3.7 JDK 1.4 をリリースした責任もあり、
きっと役に立つことを期待して、完成までこぎつけました。

なお、移植作業は今バージョンの POI 3.8-FINAL を最後にします。
さすがに数年後に JDK 1.4 で動いているサーバーはかなり少数と思われますし、
POI 3.7-FINAL に比べて POI 3.8-FINAL は大分安定していますので。

あと、どうなんでしょう？
このライブラリ、日本よりも海外で利用されている気が。。
きっと古いサーバー環境で頑張っているんだろうなー。

2012-01-03

サーバ側の入力値妥当性チェックをJavaScriptで！

あけましておめでとうございます。
このエントリは Java Advent Calendar 2011 の 1/3 のエントリーです。

今回、ご紹介するライブラリは
InputValidator 3.00 beta
です。
（本ブログ掲載までに準備が間に合わず、beta版を公開します。数ヶ月以内に正式版を公開する予定です。）

このライブラリを使うと、一つの「チェック仕様定義ファイル（JSON形式）」を読み込んで、
クライアント側（JavaScript）とサーバ側（Java）で入力値の妥当性を検証できます。

何が目新しいかと言いますと、
「クライアント側のユーザビリティ向上と同時に、サーバ側のセキュリティ（妥当性検証）も確保される」
ということなんです。

百聞は一見にしかず、ということで、サンプルをご覧ください。

InputValidator 3.00 beta
http://inputvalidator.appspot.com/

InputValidator は容易に拡張でき、必要に応じて案件ごとにチェック仕様をカスタマイズできます。
チェック仕様を JavaScript で記述できるので、要望に応じて柔軟な対応が可能です。

ところで、話はかわりますが、Web アプリにとって必要なセキュリティ対策とは何でしょう？
XSS 対策、SQL インジェクション対策、ディレクトリトラバーサル、コマンドラインインジェクション、CRSF 等々。
皆様ご経験されているとおり、やるべきことが沢山あります。
予算やスケジュールの都合と言い訳をして、手を抜けばいくらでも手を抜けますが、後で必ず痛い目をみます。
だからこそ、セキュリティ対策をしながら、いかに楽しくコーディングをするかが重要です。
（アプリケーション設計の腕の見せ所でしょうか！）

こういった理由から、「クライアント側の入力値妥当性チェック」はますます優先度が下がることになり、
フレームワークに導入される機会が減っていると思います。

また、HTML5 になって「クライアント側の入力値妥当性チェック」が導入されたのはご存知かと思います。
最初は「これでクライアント側の入力値妥当性チェックの導入が促進するのでは？」と思いましたが、疑問点が残ります。
結局、クライアント側とサーバ側と２重でチェックロジックを実装することになり、プログラマの仕事は増えているのです。
そうなると、結局のところ、手間のかかる「クライアント側の入力値妥当性チェック」はやめよう、となりがちです。

ちょっとまってください！！

「クライアント側の入力値妥当性チェック」は利用者のウケが良いです！（顧客満足度向上やモチベーションアップにも繋がります。）
業務で JavaScript をいじった経験のある方ならば、画面にちょこっと細工するだけで、顧客満足度向上に繋がる経験をしていると思います。
10年前とは状況は異なり、ユーザの目は肥えてきています。難しい要望（ユーザビリティ向上）をガンガン言ってきます。

近年の JavaScript は、ユーザービリティ向上やモバイル対応において、もはや無視できない存在です。
さらに、Rhino の登場により、サーバ側で JavaScript が動作するようになりました。
そして、InputValidator が誕生しました。

本ライブラリ以外にも、有用な JavaScript の Validation ライブラリがあります。
それらについても同様にサーバ側で動くような仕組みができると、もっと活用できるようになるのになぁ、と期待しております。

本ライブラリについて、フォロー/「いいね！」いただけると幸いです。

2011-07-25

テクニカルステーションSKEさん、ありがとうございました。

知り合いのＰＣを新マシンへ移行中、大事なデータの入ったＨＤＤ（１６ＧＢ）へ突如アクセスできなくなってしまいました。
ＵＳＢアダプタを使ってアクセスするも、リズミカルにジジッ、ジジッと回転音が聞こえるだけで、画面はフリーズしたまま。
いろいろ環境や接続をかえても良い兆候はなく、これ以上は素人では無理と判断し、近所のＨＤＤ復旧専門の小さな会社に修理見積もりを依頼しました。
しかし、残念ながら、症状は軽度ではなく、ＨＤＤの分解が必要であり、金額が数十万かかる可能性があり、最悪の場合データが復旧しません、という連絡が入ったので、調査を中断し、一旦ＨＤＤを送り返していただきました。
知り合いから預かった大事なＨＤＤをこのままにはしておけない、ということもあって、ＨＤＤ復旧会社のホームページを検索して電話したり、さらには口コミを検索して、良い情報や悪い情報がないかどうか、入念に調査しました。
たくさんの情報の中から、嘘の情報や誘導ブログを排除し、総合的に判断して、やっとの思いで信頼できそうな会社「テクニカルステーションＳＫＥ」を見つけました。
早速、ホームページからＳＫＥさんに修理依頼を依頼（フォーム入力）したところ、翌朝に電話が入り、（ハイテンポな口調で）「ＨＤＤの症状診断」していただきました。
具体的に症状を説明した結果、結論としては「プラッタ破損です。」とキッパリ。（他にも専門的な内容も細かく説明いただけました。）
「中度、重度の場合でも、調査は無料。（ただし、ＨＤＤの郵送代は依頼者もち）」とのこと。
「プラッタの壊れた部分はデータが破損しているので、最悪復旧しない可能性があります。その場合は、一切料金は頂きません。」とも。
即日ＨＤＤを郵送したところ、２日後ＨＤＤが届きましたとのご連絡あり。
また、その翌日にも電話があり、「何の連絡だとおもいますか？」と思わせぶりな切り出し。
あまりの早い連絡に「ＨＤＤが復旧できなかった、ということでしょうか？」と答えたところ、「（まだ一部ですが）データが復旧できました。」とのこと。
ＳＫＥさんの技術力には信頼を置いていたので、さすが！というか、助かった、という思いでした。（ＨＤＤの持ち主の方に良い報告ができるので。）
金額のお話しになりましたが、私の心情を察してか、重度のＨＤＤ障害でありながら、５万円台というこの業界では破格の金額で処理してくれました。
その２週間後、復旧したデータはＵＳＢメモリに保存されて帰ってきました。
普段は、ＨＤＤに復旧データを保存して返送し、使い終わったらＨＤＤを返却する、というルールらしいのですが、今回は特別に返却不要なＵＳＢメモリ（４ＧＢ）でいただけました。
正直な感想として、たしかに返却不要なのは助かりました。（復旧データを手にしたとたん、本当に安心してしまって、緊張の糸が切れてしまい。）
また、頂いたＵＳＢメモリを移動用やバックアップ用途としても使えるので、一石二鳥ですね！（そのまま知り合いの方にプレゼントしました。）
他の方のブログには「神対応」と書かれていましたが、その心情もわかるような気がします。
お電話にていろいろとお話しさせていただきましたが、「志を高く持ち、チャレンジ精神の旺盛な方」なんだろうな！と私は思いました。
できれば、ＨＤＤが壊れてほしくはないのですが、また身近でＨＤＤが壊れるようなことがあれば、私はＳＫＥさんにお願いすると思います。
以上で「ＨＤＤ復旧」レポートを終わりたいと思います。

2011-05-09

「Apache POI 3.7 migrated to JDK 1.4 RC2」をリリースしました。ooxmlに対応。

ゴールデンウィークの休み中の目標の一つとして、
「Apache POI 3.7 migrated to JDK 1.4」の ooxmlフォーマット対応を考えていた。
試しに調査してみたところ、大きな問題もなさそうだったので、
思い切って移植しました。

POI scrachpad の移植はわりと簡単で、2時間程度。
POI ooxml の移植は結構大規模で、トータルで2〜3日程度。
最後の試験工程では一部の機能で問題が発生したものの、無事にすべて解決でき、
Excel 2007 や 2010 のファイルも読み書きできるようになりました。

Excel 以外の Word や Power Point もたぶん動作しますが、未試験です。
大抵の場合、POIを使う理由は Excel の読み書きであり
他のファイルを POI で利用した事例がないため、個人的に対象外としています。

http://sourceforge.jp/projects/poi-jdk14/releases/?package_id=12043

2011-03-27

POI 3.7 をJDK 1.4 に移植してみた。

POI 3.7 をJDK 1.4 に移植してみました。
（具体的には JDK 1.5 → JDK 1.4 への移植）
トータル作業時間は３日程度。

ほとんどのロジックはそのまま移植できたものの、
Formatter クラス(JDK 1.5 only）を使った処理は、
オリジナルの POIFormatterUtil クラスを作成して対処したため、
少し手間がかかりました。

4/17 SourceForgeにバイナリとソースを公開しました。
http://sourceforge.jp/projects/poi-jdk14/releases/?package_id=12043

2010-10-02

android emulator 非通知の試験方法

ddms の「Incoming number」に # を入力して「呼び出し」ボタンを押下する。

2009-04-15

Swingオブジェクトを使ったアプリをSolaris10上で動かす方法

Swingオブジェクトを使ったアプリをSolaris10のTomcat上で動作させると、妙な不具合に悩まされた。
まずアプリケーションを１度動作させる。（この時は正常動作する。）
後に、コンソール（X Window）を閉じると、Tomcatサービスまで停止（エラー発生）してしまう、といったもの。

Tomcatのエラーログに
X connection to string:0.0 broken (explicit kill or server shutdown).
というメッセージが残っていたので、このキーワードを手がかりに調査したところ、
簡単な設定変更が必要であることがわかった。

Tomcat(Java)を起動する時のオプションとして
-Djava.awt.headless=true
をつけることで、Solaris10のTomcat上でSwing(awt)オブジェクトを使用しても、
先述のような不具合が発生しなくなった。（Tomcatのエラーも消えた。）
（参照資料）
http://sdc.sun.co.jp/java/docs/j2se/1.4/ja/docs/ja/guide/awt/AWTChanges.html#headless

Windowsサーバ、Linuxサーバで入念な試験を実施していたので、
Solarisサーバ上で発生したこの不具合に焦った焦った。
とりあえず、解決したので、でめたしでめたし！

sarapapaブログ

「Apache POI (3.8 final) migrated to JDK 1.4」をリリースしました。