OOXMLをサポートするApache POI 3.5がリリースされた

作者 Charles Humble , 翻訳者 徳武 聡 投稿日 2009年11月1日

セクション

運用/インフラ,

デベロップメント,

設計/アーキテクチャ

トピック

Java ,

Java+.NET ,

オープンソース

タグ

OOXML ,

Apache ,

Microsoft Office

原文(投稿日：2009/10/29)へのリンク

ApacheはPOIのバージョン3.5をリリースした。POIはJavaでMicrosoftのドキュメント形式を扱うためのライブラリだ。POIの以前のバージョンではMicrosoftのOLE2複合ドキュメントフォーマットをサポートしていた。このフォーマットはOffice 97-2003 (バージョン 8.0 - 11)で使われていたものだ。最新バージョンであるPOI 3.5ではMicrosoftのOffice Open XML (OOXML)ドキュメント標準がサポートされている。これはOffice 2007のデフォルトのフォーマットだ。

前バージョンのHSSFがOOXMLをサポートしていないにもかかわらず、HSSFユーザモデルを使っている既存のコードは、POI 3.5を使う場合、既存のコードをそのまま使い続けて大丈夫だ。というのは、OOXMLとOLE2の両方をサポートするために最新バージョンのPOIには新しいSSユーザモデル(org.apache.poi.ss.usermodel)があり、双方のフォーマット共通のAPIを提供するからだ。この新しいSSモデルは、なるべくHSSFモデル(org.apache.poi.hssf.usermodel)に準拠して作られているので、開発者はHSSFモデルを扱っているのと似たような感覚でSSモデルを扱える。HSSFからSSへの移行も特別に大変な作業ではない。主要な違いはパッケージ名とクラス名からHSSFが除かれたことだ。しかし、SSモデルには、まだサポートされていない機能があることは注意しておく必要がある。POI 3.5のリリースマネージャであるYegor Kozlov氏は下記のように教えてくれた。

現在、SSユーザモデルはHSSFが提供する機能の90%をカバーしています。ゴールは完全にカバーすることです。とりわけ、条件付き書式とデータ検証はまだXSSFによってサポートされていません。また、グラフィックやリッチテキストについてもやらなければならないことが残っています(これはHSSFとXSSFの両方です)。

POIのOOXMLサポートはスクラッチで開発され、OpenXML SDKからも独立している。POIと合体したJulien Chable氏のOpenXML4Jプロジェクトと共に、バージョン3.5のOOXMLの実装に大きく貢献したのは、Sourcesense社だ。Sourcesenseはオープンソースを扱う会社であり、このPOIの作業についてMicrosoftから委託された。MicrosoftのRobert Duffner氏の話では、同社はSourcesenseを開発パートナーと位置づけ、OOXMLに関わる開発に関して資金やプログラムやマネジメントを提供し、アーキテクチャの指針や今後の優先順位付け、リリース戦略について共有していく、とのことだ。

Microsoftの関与は間違いなくある種の論争を引き起こすだろう。POIに貢献している開発者の中には、MicrosoftのOpen Specification Promise (OSP)特許ライセンスの有効性について疑問を抱く者もいる。Apache POIの設立者であるAndrew Oliver氏は以前、自信のブログに下記のように書いていた。

互換性は求められるが仕様を実装する必要はないというような微妙な事案については、OSPでは何も規定されていません。しかし、Microsoftは一段と踏み込んで自分たちが資金提供しているPOIの開発についてこのような事案も扱えるようにApacheとの間で特約を結んでいます。さらに、必要な改訂が加えられながら今後、OSPはオープンソースプロジェクトで利用されているライセンスのような形に発展していくでしょう。

しかし、我々がAndrew Oliver氏に話を聞いたとき、氏はOOXMLの仕様が潜在的に抱える特許の問題について懸念を抱いていることを明らかにした。

OOXMLの仕様と一致する範囲のみこの特許条項は有効になります。つまり、この仕様を利用している製品の互換性に対しては有効にはなりません。Microsoftはこの特許条項に漏れる可能性のある(例えばOOXMLのドキュメントを読むメソッドはこの枠組みに従いません。)重要な特許を保持しています。これらの特許はOOXMLの仕様に準拠しませんが、POIプロジェクトのミッションとは関わりがあります。プロプライエタリな人気ソフトウエアであるOfficeとの互換性を実現するというミッションです。

はっきり言うと、Microsoftの社員のRobert Duffner氏と以前まで社員であったSam Ramji氏はこの問題をどうにかする意思を持っていたと思いますが、現在、これらの問題を解決するために十分に注力されているとはいえません。また、POIの開発者コミュニティ自体の抱える知的財産権の問題にも力が注がれていないように思えます。Microsoftを信頼して、同社はうまく問題を解決するつもりがあり、何か悪いことをすること自体が同社の利益に反すると考える向きもあります。しかし、私はこの考えに賛成しません。企業戦略/利益は変化します。またPOIプロジェクトも今までよりも知的財産権の監査や全体のガバナンスをしっかりする必要があります。この件に関しては最近、このプロジェクトはあまり良い仕事をしていないと思います。

さらに、他の意図せずに、あるいは、意図的にMicrosoftが保持している特許を実装する製品について、その製品がOOXMLの仕様と一致している必要なく、Microsoftからもらったわずかな資金でSourcesenseが作ったものである場合について、なにか規定しようとは努力していないようです(この"特許条項"の適用外です)。SourcesenseはApacheとCLAを締結しました。しかし、ApacheとMicrosoftの間では同様の契約は締結されていません。ということは何か問題が起きたときには、理論的に言ってSourcesenseはApacheに対して責任を負うということになります。しかし、Sourcesenseが責任を負うだけで問題が解決するとも思えません。これらすべての問題を解決するために、開発者コミュニティが積極的な役割を果たすことを期待しています。

POI 3.5のリリースマネージャであるYegor Kozlov氏はAndrew Oliver氏の評価に反対している。氏によれば、"この件については少し前に大きな議論になりました。詳細はここで確認できます。"

結果的には、この件はAndy Oliver氏とApache/Microsoft/Sourcesenseとの戦いでした。というのは、Andy Oliver氏は、MicrosoftがOpen Specification Promise (OSP)を納得のいく形に書き換えるまでOOXMLの開発を拒否している唯一の人物だったからです。悲しいことに、氏は結局、Apache POIプロジェクトを去ることになってしまいました。

MicrosoftはISO/IEC 29500とECMA 376を広めることに興味を持ち、このふたつの規格を利用しやすくしたいと思っている。そう考えることに、私は(そしてApache POIコミュニティのすべての人々も)正当な理由があると思います。また、特許や互換性について心配はないと思われているオープンソースプロジェクトは他にもあります。OpenOfficeもその中のひとつです。

MicrosoftでのPOIプロジェクトのテクニカルリードであるVijay Rajagopalan氏もYegor Kozlov氏の考えに同意している。

開発者達がOpenXMLファイルフォーマットを使って一般的な課題を解決できるようにするのが我々の至上命題です。開発者の開発環境が.NETかJavaなのかは関係ありません。我々はスプレットシート上で計算処理をする必要があるJavaの開発者がシンプルで使いやすいAPIを使ってその処理を実現できるようにしたいと思っています。そして、POIプロジェクトはこれを実現しました。POIプロジェクトのこの達成を評価し、我々はこのオープンソースプロジェクトに資金提供し、以前よりも大きくなったコミュニティと協業して実際の相互運用性についてデモをするようになりました。

特許の問題と同じように、OOXMLの現在の標準にも難点がある。POIは正式にISO/IEC　29500:2008バージョンをサポートしている。このバージョンはEcma International Technical Committeeで承認されて、2008年の11月に公開されている。しかし、このバージョンはOffice 2007が発売されてから変更が加えられているので、Office 2007自体がこのバージョンに完全には準拠していない。したがって、このままだと何らかの矛盾が発生する場合、POIはOffice 2007のフォーマットと互換性を持つ必要がある。Vijay Rajagopalan氏によれば、

POI OpenXML Java APIは開発者の実際の利用ケースに基づいて作られています。決して標準を巡る政治に動かされているわけではありません。APIを設計するときには、常にユーザ/開発者のことを念頭に置いていました。

一般的に言って、と氏は続けた。

どのようにして標準を作っているのかについて、我々は以前以上に透明にしています。例えばIE 8はこの情報開示の素晴らしい例です。我々はW3CのCSSテストケースとCSSの仕様に貢献しました。同じようにOfficeチームは実装ノートを文書化し、この標準がどのように実装されているのか図解しています。

続けて、我々はOffice 2010が出荷されたときにPOIの実装はどうなるのかについて話をした。Vijay Rajagopalan氏によれば、

Office 2010はISO/IEC 29500:2008を採用する予定です。なので我々は開発者のノートとコミュニティの検証プロジェクトを使って問題に対処しようと計画しています(詳細はここをご覧下さい)。検証プロジェクトはFraunhofer研究所が指揮をとり、相互運用のあるシナリオで仕様と整合するかどうかを検証します。

 

我々はApacheのYegor Kozlov氏に将来のPOIプロジェクトの計画について話を聞いた。氏が取り上げたのは、これから注力したいと考えている4つの分野のことだった。

1. ExcelのチャートをHSSFとXSSFの両方でサポートすること。これは長い間考えていた計画でPOI-3.6では完成させたいと思っています。
2. メモリ使用量の改善。HSSFもXSSFもメモリをたくさん使います。両方ともモデルの全体をメモリ内に保持するため、10Kくらいのレコードを使って大きなグリッドを生成すればOutOfMemoryが発生してしまいます。もちろん、実際のメモリ使用量の上限値は利用できるヒープのサイズに依存します。
   ファイルに対して読み取り(テキストの抽出や索引作成等)しか行わないアプリケーションなら回避策があります。利用するメモリの量が少ないイベントベースのAPIを提供してやればいいでしょう。しかし、ユーザモデルAPIを使って大きなグリッドを作成する場合は問題が起きます。
3. 試験的なプロジェクト。HWPF(DOC書式)とHSLF(PPT書式)は、POIに試験的に実装されてるままになっています。つまり、これらのプロジェクトはメインのjarファイルに含むことができるほど十分には"成熟"していないということです。残念なことに、現在これらモジュールの開発者はいません。我々も時々、パッチを適用したり修正をしたりしているだけです。POIプロジェクトのこの部分についてはもっと注目されなければなりません。
4. DOCXとPPTXモジュールについて、作業を継続する必要があります。

プロジェクトの設立者であるAndrew Oliver氏も将来解決すべきこととしてメモリの問題があると考えている。氏が言うには、

OLE2FSのコードはRandomAccessFileとメモリマッピングを使うように考え直したほうがいいと思います。そうすれば、大きなファイルに変更を加えるときに、5倍から10倍ものメモリ/ヒープを使わなくて済みます。もともとこのコードを書いたときには、まだJava NIOは存在しませんでした。

最終バージョンでフィックスされた案件についての詳細は変更履歴で確認できる。ソースコードとバイナリはApacheのミラーサイトからダウンロード可能。POI 3.5がサポートするのはJava 1.5以上のバージョンだ。

• 次へ >