久しぶりにJAVA

久しぶりにJAVAでプログラムを作成中。趣味グラム自体が久しぶりな気がします。

＃前作りかけたのは、作りかけのまま放置してるし。

今回はブログに画像をアップロードする専用ツール。JAVA自体の画像処理に色々問題があるので、作業は遅々として進みません。ちょっと大きなJPEGを読み込んで保存するだけで、もう次からメモリ違反の例外が発生してしまいます。原因を調査してみたけど、ちょっと複雑そうです。しょんぼり。

というわけで、バグ修正はほっといて、画像処理を色々組み込みたいです。今は、縮小処理ぐらいしかありませんが…。エンボス加工とか、グレー画像処理とか色々入れてみたい。

Javaの配布は結局どうしたかのかというと

結局、JavaWebStartを利用した場合「実行せんほうが良いよ」とか出ちゃうので、専用のインストーラを作成しました。

専用のインストーラを作成するということは、各OS毎にインストーラを作成しないといけないことになります。Windows版は嫌になるほど携わってきたので、その中から「Inno Setup」を利用することにしました。Windows版は戸惑うところなどなく、完了です。

んで、困ったのはMac版です。正直、Macなどほとんど触ったことなかったので、インストーラといわれてもチンプンカンプンです。最初に目をつけたのは、「DMG Maker」というツールでした。これで、JARファイルのエイリアスと本体各種JARファイルを入れたフォルダを格納したDMGファイルを作成し、無事にイメージファイルが作成できたかのように思えましたが、それだけでは終わりませんでした。

エイリアスを利用した方法でも良かったのですが、Macでは「パッケージ」という概念があり、フォルダをひとつのアプリケーションとして機能させることができるようで、一般的にはその機能を利用しているようです。このルールには従わないといけません。でないと、余計な混乱をユーザーに与えてしまいます。

そこで、一旦完成したかのように思えたMac版のインストーラは、この「パッケージ」作成の段階、つまり振り出しに戻ったことになります。

あれこれと調査した結果、単純な実行形式であればパッケージを作成することができました。やり方は、色んなサイトで解説してあるんですが、フォルダの拡張子を「.app」に変更して、後は中に必要な階層とファイルを作成するだけです。

ですが、今回の実行ファイルはJARファイルであり、単純にその手法では動きませんでした。あれこれと自作でパッケージの肝であるinfo.plistファイルをいじってたのですが、どうやっても上手くいきません。そんな困った状況のときに、ふとMacのDeveloperツール内を探索してみると「Jar Bundler」なるツールを発見しました。怪しげな名前です。そこで、期待をこめてダブルクリックしてみると…。これが、JARファイルから「パッケージ」を作成する専用のツールでした。非常に単純なことですが、こういうので引っかかっちゃうんですよねorz。

さて、無事に「.app」が作成できたら、さきほどの「DMG Maker」を利用して、DMGファイルを作成するだけなのですが、拡張子が.appのフォルダだと上手く作成ができません。あれこれと試行錯誤してみますが、どうやっても上手くいかないので、方針を変更して「PackageMaker」ってのを使ってみることに。

そしたら、あっさりと出来てしまいました。

つまり、JARファイルをMacで配布するには、JavaWebStartが利用できない場合は、「Jar Bundler」→「Package Maker」というコンボで完璧です。配布に困った人は、ぜひ、このコンボを使ってみてください。（って、居ないだろうなぁ^^;）

コードサイニングな話

Javaのプログラムの配布を、JavaWebStartを利用して配布しようとしてみました。しかし、そこには大きな落とし穴が…。

JavaWebStartは非常に強力なJavaプログラムの配布ツールです。一つJNLPを用意すれば、WindowsだろうがMacだろうがLinuxだろうが、ブラウザからのワンクリックでJavaのプログラムのインストールができてしまいます。もちろん、このJavaのプログラムからはローカルへのファイルアクセスは、バリバリと行うことができます。

まあ、ここまで書いちゃうとある程度推測できると思いますが、つまりセキュリティ的に問題があるわけです。ブラウザからワンクリックしただけで、環境に害を及ぼすことが可能なプログラムを実行してしまう。これだけでは、強力すぎて使えません。

そこで、JavaWebStartにはデジタル署名を検証する機能がついてます。JavaWebStart自身が抱えているデジタル証明書と照らし合わせて、信頼おける認証機関から署名をほどこされている場合には、「信頼できるプログラムみたいですよ」メッセージが出ます。もちろん、署名がいい加減な署名でも、「実行しない方がいいよ」という警告つきで、ユーザーの選択によっては起動させることは可能です。

このあたりは、私個人としては慣れ親しんでたActiveXと同じです。

さて、ここでの問題は、この公的な認証機関からの署名になるのですが、これはコードサイニング署名と呼ばれているモノで、この署名をしてもらおうと思ったら、年間で十万～数十万円もの費用がかかってしまいます。

今回作成した、小さなツールでは、これだけの予算は出ません。

つまり、JavaWebStartなど使わずに各OS毎のインストーラを用意して、インストールして使ってもらわなくてはいけないという事になりました。だって、「オレオレ証明書」なんて使ってたら、信用がた落ちですから。

でも、よく考えてください。インストーラ使ってインストールするプログラムは、同じプログラムなんですよね。しかも、インストーラ使うってことは、インストールするときに管理者権限が必要になるわけで…。セキュリティ的には、不味い方向に向かってる感じがします。でも、こうしないといけない。変な話です。

JavaWebStartに望むこととしては、このプログラムに対する証明書が間違いない手順で送られてきている場合に、このプログラムについてる署名と、その手に入れた証明書の検証を行って、問題がないかを確認する機能を設けて欲しいです。

現在も似たような機能はあるのですが、その証明書を追加する場所が「ルート証明書」なんで、一旦ルート証明書として追加されちゃうと、実は非常にやっかいな問題を証明書の発行側が担わないといけなくなっちゃうんです。それを避けるために、今回はJavaWebStartの利用は止めました。

これじゃ、JavaWebStartが流行るわけありません。こんな落とし穴があるなんて、気付かなかった私もアホですが、このぐらい大きな落とし穴をいつまでもほったらかしにしてたらダメなんじゃないかなぁ…。

まあ、愚痴っぽくて非常に分かり辛い話でした。

ImageIOのメモリリークと不具合

結局、メモリリークはImageIOのImageReaderが上手く破棄されないためにリークしていることが判明しました。

よって、対応策としては、一度作ったImageReaderを使いまわせば良いことになります。というわけで、一度作成したImageReaderを使いまわすコードを書いてみたのですが、今までは読み込むファイルに対応するImageReaderを常に新規作成してたのですが、そのコードを削除し、一度作ったImageReaderと対応付けけないといけません。

そのために、Streamから読み込めるかをチェックしてみたのですが、これが仕様どおりに動いてくれません。setInput関数で、読み込みできないときは例外が発生すると書いてあるのですが、例外が発生しませんでした。しかも、それを繰り返すと、画像の読み込みが全くできなくなるし…。むきー。

というわけで、仕方ないので拡張子からImageReaderを取得するように変更し、拡張子に対応したImageReaderのリストを確保するようにしました。

やれやれ。

まあ、これでなんとか形になったので、アルファ版として納品を終えました。まだまだ整理していかないといけないことはあるのですが、後は得意分野の話なので、なんとでもなると思います。

ところで、JARファイルにアイコンとか付けれませんかね？アイコンがださくて困ってるんですが。

JAVAでメモリリーク

JAVAの何が良いって、オブジェクトの管理から解放されることですよね。

というわけで、newしてほったらかしってのをやって悦に入ってたのですが、今日作り上げたプログラムのチェックをしてると、どうもメモリリークをしてるようです。画像ファイルを開いて保存するだけなんですが、開いた段階で確保したメモリがどうやっても解放されません。

どうやら、ImageIOにバグがあるとかないとか書いてあるんですが、ほんまかなぁ。１枚開くと展開後のサイズ分ぐらいを必ずリークするんですよ。絶対何かが間違ってる気がするんです。

MLに特攻してみようかなぁ…。でも、JavaHouseの人達怖いしなぁ…。うぬぬ。

レイアウトマネージャ

JAVAで画面設計をしてみました。DelphiとかC++Builderとか、ダイアログエディタとか使ってきた私としては、思った位置に配置できないのは非常にやり辛かったです。

でも、これも汎用性を高めるために必要なことというのが分かったので、なんとか堪えてレイアウトマネージャを利用しつつ目的の画面を作成することができました。

とはいえ、エディタ＋JDKでやるにはちょっとどころかかなり辛かったので、JBuilderを活用して、画面にポトリペタリをして、出来上がったソースをそのままコピペしたり、コピペだけじゃプログラマっぽくないので（汁）、コードの意味を調べてみたり、などなど。

JAVAを使い始めて、毎日が新鮮で楽しいです。

しかし、JBuilderみたいに重たいのじゃなくて、Swingだけでいいからポトリペタリしたらコードを吐き出してくれるツールがあっても良いような気がするんですけどね。JAVAのMLとか読んでると、JDK＋エディタ至上主義な人が目立ってるのもあって、なかなかそういうツール系は生まれにくいのかもしれません。

でも、絶対必要だと思うけどなぁ…。画面設計のコンポーネントの配置が目的でJBuiderを使うほど馬鹿げた話もありませんから、何とかして欲しいと思ってます。

え、そんな事言うんだったら、お前が作れって？

今はまだJAVAに全く自信がないので、無理です。もうちょっと勉強して自信がついたら、考えてみようかなぁ…。

画像ライブラリ

今回作成するJAVAのプログラムは、画像ファイルを読み込んで同じ形式で保存する必要があります。

幸い、JAVAには既に強力な画像処理ライブラリが組み込まれています。以前は大変だったようですが、現在は非常に楽です。実際に、テストプログラムではたったの１行で読み込みが完了してました。楽すぎだっちゅーの(^^;。

ですが、実際に読み込んで同じ形式で書き込もうとすると、それまで使っていた簡易なメソッドでは処理できないことがだんだんとわかってきました。同じ形式で保存するには、下記のようにやらなくてはなりません。

1. Fileオブジェクト作成
2. ImageIO.createImageInputStreamでImageInputStreamオブジェクトを作成
3. ImageIO.getImageReadersのリストをFileストリームから作成する
4. ３のリストから取得したImageReaderで読み込み処理を行ってみる
5. 読み込めたImageReaderを保管しておく
6. 保存時にImageIO.getImageWriterを使って、ImageReaderに対応したImageWriterオブジェクトを得る
7. ６で得たImageWriterを使ってファイルに保存する

最後の方ははしょりましたが、上記のようにやらなくてはなりません。しかも、フルパスからファイル名だけを抜き出す関数や、拡張子だけを抜き出す関数、拡張子を変更する関数などなど、ファイル名に関するライブラリを見つけることができなかったので、仕方なく、全部自作してしまいました。関数名は、ほぼVCL（Borlandの作ったライブラリ）からパクってますが…。

やっぱ、使い慣れた環境が一番楽ですね。新しい環境は、思わぬところで時間を食ってしまいます。

まあ、当初の予定よりちょっと遅れぐらいで作業は進んでるので、かなり順調な方でしょう。もうちょっとで完成なので、頑張っていきたいと思います。今週末には、多分納品できるかなぁ(^^;。

参考にしたサイト
ImageIOのリファレンス(公式)
Image I/O API ガイド(公式)
Image I/O(非公式)

JAVAアプリ実行環境のインストール

JAVAで作成したアプリケーションを実行させるには、JREという環境を先にインストールしなくてはなりません。

このJREですが、サイズが１５ＭＢほどもあります。作成しようとしてるプログラムのバイトコードファイルのサイズが５０ＫＢぐらいしかないのに、１５ＭＢも付けないといけないってのは、なんとなく釈然としません。

まあ、その１５ＭＢに含まれるクラスライブラリを活用してるから、非常にサイズが小さくすんでるんですが(^^;。

というわけで、あれこれと探していたのですが、ぐぐっても良い情報は得られませんでした。結局は、Ｓｕｎのトップページからリンクをたどって、やっとでたどり着いた下記ＵＲＬでようやく情報を得ることができました。
http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/deployment/index.html

どうやら、必要な物だけダウンロードしてインストールしてくれる奴があるようです。こいつのサイズが1.35ＭＢほどなので、なかなか良い感じです。

というわけで、こいつを使ってインストールすることになりました。このJREのインストーラを使うと、JARファイルのダブルクリックで動作してくれるようです。これで、なんとかなりそうな予感です…。

週末情報

本屋でJAVAの本を漁ってると、配布方法について情報がありました。おおーっと思って読んでみると、

「JREを含めて配布することができ、詳しいライセンス条件などは、Sunのサイトで公開されてるよ」

とのことでした。なるほど、これが入り口っぽいですね。英語なページしかなかったら、バビロンに頼りつつ解読していこうと思います。

というわけで、今週一週間も頑張ります。

JAVAの開発環境

まずは、どういう開発環境で開発を行うかを調査して決定しなくてはなりません。

C++の場合、Windowを表示してメッセージを表示させるだけのプログラムを組むのに、ネイティブC++だと大変辛い作業になってしまいます。そこで、RADツールと呼ばれるツールを使うことにしてたのですが、JAVAの場合はどうでしょうか。

とりあえず、調査したところ、ウィンドウを表示してチョメチョメするぐらいなら、数行でいけることが分かりました。凄いぞJAVA君。

ウィンドウを表示するだけで、大変苦労するようだと統合環境を利用することを考えてたのですが、こんだけ簡単なら、いきなり統合環境を利用して統合環境側の問題で振り回されることがないように、最初はJDKとエディタで開発をすることにしました。JDKとエディタの開発で限界を感じたら、統合環境を利用すれば良いんじゃないでしょうか。

んで、肝心のJAVAソースをコンパイルしたバイトコード（.classのファイル）を、WindowsからMAC環境で動作させて、問題なく動くかのチェックをしてみました。

私は知らなかったのですが、JREってのはMAC用には用意されてないんですね。MAC用には、全く別にJAVAの実行環境が用意されているとのことです。これは、びっくり。となると、ますますきちんと動くかどうかが心配になってきます。まあ、私などが心配しなくてもちゃんと動いてるんでしょうが(^^;。

んで、単純にWindowにファイルをドラッグ＆ドロップしたら画像ファイルを表示するプログラムを作成して、WindowsとMACで動作させてみました。

最初、バージョンが違うとかなんとかエラーが表示されてMACでは動作しませんでした。これは大変困ったのですが、MAC側でJAVAソースからバイトコードを作成したら、何の問題もなくMAC側とWindows側で動作しました。

この問題の解決から分かったことは、開発するJDKのバージョンを変更しないと駄目みたいです。とりあえず、JDK1.5では駄目っぽいので、JDK1.4で開発することに決定です。

さて、ココまできても分からないのは、インストーラの作成方法です。この仕事は、来週に持ち越しです。週末は、JAVAの勉強かなぁ…。まあ、最低でも本を物色には行かなくてはなりませんね。良い本があれば良いのですが。