じゃっば〜んとっぷ
How to set up pja

PJA Toolkit

What is PJA ?
PJA contents
Tested platforms
FAQ
History
What's next ?
Copyright and license

PJA documentation
PJA feedback

What is PJA ?

PJA (Pure Java AWT) ToolkitはeTeksが開発したグラフィクス描画用Java^TM ライブラリです。 PJA Toolkitは100% Pure Java でJVMが稼動するシステムのネイティブなグラフィクス資源を使用しません。
デフォルトのJVMにおけるdrawLine (), fillOval (), drawString (),..などのjava.awt.Graphicsのメソッドは、ネイティブなグラフィクス機能を使用して実装されています。 (Java2Dのような一部の例外を除く) : つまり、java.awt.Imageを使ってオフスクリーンの画像に描画する場合でさえ、drawLine () を呼び出せば、Windowsや、UNIXのX11などのGDIシステムコールを使用してしまうのです。 これは、Javaを使用したグラフィクス描画処理のパフォーマンスを最大限に引き出すためです。
しかし、このデフォルトの振る舞いは、問題となることもあり、PJAライブラリは、その問題点を解決してくれるでしょう。

• X11表示環境のないUNIXシステムや、Windows環境でGDIリソースが不足している場合など、JDK1.4より前の環境では、画像を表示する必要がなくても、java.awt.Graphics を使用した、オフスクリーン画像処理を行うことができません。 典型的な例として、パイチャートやグラフ、WEBカウンタの画像を動的に生成するようなサーブレットでこのような状況が発生します。
  
• PJAを使用すると、これらの動かしたいJavaのプログラムには変更を加えることなく、動作させることができます。JDK1.1の場合、必要な変更はシステムプロパティ"java.awt"の値として"com.eteks.awt.PJAToolkit"を設定することだけです。 (詳しくはFAQとcom.eteks.awt.PJAToolkit クラスのドキュメントをご覧ください。).
• 同様に、セキュリティマネージャによりToolkitやAWTライブラリにアクセスすることが禁止されている場合も、同様にオフスクリーンイメージの操作を行うことができませんが、この場合でも、java.awt.Imageのサブクラスであるcom.eteks.awt.PJAImageクラス のインスタンスを生成し、そのオブジェクトを利用することで、画像処理が可能となります。
• システム環境ネイティブ な機能を使用して描画すると、プラットフォームによって描画結果が異なる場合があります。例えば、SansSerifフォントのレンダリングは、それぞれのシステムでフォントのアンチエイリアス処理が行われたり行われなかったりするため、MacOS、Windows、その他のシステム毎に異なってしまいます。また、MacOS上では、円がJLSに既定されているとおりにはレンダリングされません。fillArc ()とdrawArc () は、それぞれ基準とする楕円が異なるのです。。。

  そしてついにGNUのGPLの元にPJA ライブラリが登場したのです。もちろん、Javaのソースコード付きで、以下のようなことを学ぶことができます：

• コンピュータの画像処理では、どのようにピクセルが描画されるか（com.eteks.awt.PJAGraphicsは直線と円の描画にBresenhamアルゴリズムを使用している）
• ImageConsumer/ImageProducer/ImageConsumerなどの画像処理インタフェースで規定されている画像管理手法の使用方法
• JavaのToolkitがどのような仕組みで動作するか、あるいは、動作すべきか.

  PJAを利用する開発者が画像処理メソッドを独自に改造／改善できるよう、ソースコード付きです。
  com.eteks.awtパッケージはJDK1.0互換ですがコンパイル時にはJDK1.2以上のライブラリが必要になります。（JDK1.2より前のコンパイラ使用時はlコンパイル時の-classpathオプションでclasses.zipの代わりにJava2のrt.jarを指定することでコンパイル可能。）

  PJAライブラリのコアクラスはランタイムで144KB（圧縮時73KB）です。
  

PJA contents

PJAライブラリは以下の内容を構成として配布しています：

• pja.jar とpjatools.jarのjarファイル。
• Java ソースコードファイル。.
• Javadoc ドキュメント。
• FAQ リスト。
• PJANativeToolkitComparison （PJAのToolkitを利用した場合とネイティブなToolkitを使用した場合の比較を行うデモ。 スピードメータを見れば、それぞれの平均的な処理時間が分かるでしょう。）
• PJAToolkitDemo （PJA Toolkitを使用してGIF画像を生成するデモ。）
• NativeToolkitDemo （ネイティブToolkitを使用してGIF画像を生成するデモ。）
• PJADemo （awtライブラリを使用を禁止するセキュリティマネージャ配下でPJAを使用してGIF画像を生成するデモ。）
• PJAFontCapture （フォントファイルを生成するユーティリティ。フォントの版権問題になる可能性があるためフォント自身は含んでいません。AWTが動作する環境であればどこでもこのポータブルなファイルを生成することが可能です。 ）
• TeksSurveyPie （パイチャートを生成するサンプルサーブレット。）

サーブレットの動作環境を持つホストプロバイダ も、版権情報を提示の上、WEBサイトと文書にhttp://www.eteks.comへのリンクをはることで、利用者のためにこのライブラリを導入して使用することができます。

Tested platforms

eTeksでは以下のシステム環境でPJAの動作確認をしました。

JDK version	Windows	MacOS	UNIX
1.0	Win 98/SunJDK 1.0.2
1.1	Win 98/SunJDK 1.1.8	MacOS 9/MRJ 2.2	Linux/JDK 1.1.7 (without DISPLAY)
1.2	Win 98/SunJDK 1.2.2		Linux/JDK 1.2.2 (with and without DISPLAY)
1.3	Win 98/SunJDK 1.3.0

ユーザの方々から以下の環境で使用できたとのご報告をいただいています。

• Linux with JDK 1.3.0
• AIX with JDK 1.3.0
• Sun Solaris
• OS/390
• HP-UX with JDK 1.2.2 and JDK 1.3.1.02
• FreeBSD with JDK 1.3

FAQ

どのような場合にPJAを使えばよいのでしょうか？

対象	課題	解
開発／運用時	サーバ上でグラフィクス処理をするようなサーブレットやアプリケーションが動作するか不明。	com.eteks.servlet.DefaultToolkitTestサーブレットやPJAToolkitDemoアプリケーションが動作するか試してみましょう。
運用時	グラフィクス処理をするサーブレットをサーバ上で動作させようとしたところ問題が発生。	java起動時のコマンドラインオプションを変更できない場合	com.eteks.servlet.PJAServletTestを動かしてみてください。正常に動作するのであれば、 com.eteks.awt.servlet.PJARedirectServlet を使用して、グラフィクス処理サーブレットを実行させます。そうでなければ、サーブレットを動作させるサーバのシステム管理者に依頼して、javaコマンドラインオプションに、オプション を追加してもらいましょう。（最低限 -Xbootclasspath/a:pja.jarが必要です。)
		java起動時のコマンドラインオプションを変更できる場合	See which options to use.
これから開発	グラフィクス処理をするサーブレットをどこでも動作するように作りたい。	com.eteks.awt.servlet.PJAServletを継承しましょう（例：com.eteks.servlet.TeksSurveyPie）。そうすれば、Xディスプレイにアクセスできる環境での運用者へのサポートを最低限にすることができます。また、単純にPJAの画像処理系メソッドだけを使うという方法もあります。

 

UNIXプラットフォーム上でサーブレットを動作させるためにPJAを使う場合、どんなオプションを追加すればよいでしょう？

(JDK のバージョンはjava -versionで確認できます。)

• JDK version <= 1.1 : PJAToolkitDemo.shデモが該当します。実行には.pjafフォントファイルが必要となります。
  • まず、グラフィクス表示環境（Windows、MacOS、UNIXのX11）のあるプラットフォーム上で、PJAFontCaptureを実行して、少なくとも１つの.pjafフォントファイルを生成します。
  • .pjafファイルをPJAインストールディレクトリにコピー（またはバイナリモードファイル転送）します。
  • PJAToolkitDemo.shで指定されているクラスパスを確認します。
  • PJAToolkitDemo.shを実行します。このデモでは、グラフィクス系メソッドの大部分をテストし、４つのGIFファイルPJAToolkit*.gif)を生成します。できあがった画像が、このように見えることを確認してください。
  • 最後に、以下のようなjavaコマンドラインオプションを追加してください。
    • -classpath $CLASSPATH:pja.jar (またはCLASSPATH環境変数を変更).
    • -Dawt.toolkit=com.eteks.awt.PJAToolkit : このオプションは標準のAWT Toolkitの代わりに、PJA Toolkitを使用するように指定します
    • -Djava.awt.fonts=. または.pjaf ファイルを配置した場所
• JDK version >= 1.2 : PJAToolkitDemo1.2.shデモが該当します。このデモはJDKに添付されているLucida True Type fontsを使用します。
  • まず、PJAToolkitDemo1.2.sh の中で使用しているパラメタを確認します。
    • .java.awt.fontsプロパティの値は、Lucida*.ttfフォントファイルが配置されているディレクトリと一致していなければなりません。一般に、このディレクトリは.../jdk.../jre/lib/fontsになります。
    • user.homeプロパティはPJAをインストールしたディレクトリでなければなりません。
  • PJAToolkitDemo1.2.shを実行してみましょう。このデモはグラフィクスメソッドの大部分を試行し、４つのGIFファイル(PJAToolkit*.gif)を生成します。 画像がこのように見えることを確認してください。JVMがクラッシュしてしまう場合は、さらにこちらの修正をお試しください。
  • 最後に、以下のようなjavaコマンドラインオプションを追加してください。
    • -Xbootclasspath/a:pja.jar (通常のクラスパス変更だけでは十分ではありません).
    • -Dawt.toolkit=com.eteks.awt.PJAToolkit : このオプションは標準のAWT Toolkitの代わりに、PJA Toolkitを使用するように指定します
    • -Djava.awt.graphicsenv=com.eteks.java2d.PJAGraphicsEnvironment : このオプションはグラフィクス環境にPJAGraphicsEnvironmentを使用するように指定します。
    • -Djava2d.font.usePlatformFont=false : このオプションで、sun.java2d.loops.RasterOutputManagerが、JVMクラッシュを引き起こす可能性のある ネイティブメソッドgetPlatformFontVar()を呼び出さないようにします。
    • -Djava.awt.fonts=path Lucida*.ttfファイルの存在するディレクトリを指定します。他のTrueTypeフォントのディレクトリを":"セパレタで区切って追加することもできます。.
    • -Duser.home=dir PJAの font.properties ファイルのある"lib"の親ディレクトリを指定。このオプションの代わりに、lib/font.propertiesをシステムプロパティuser.homeに追加するか、またはJavaのfont.propertiesファイル（通常/.../jdk.../jre/libにあります）をPJAのfont.propertiesファイルで置き換える方法でもよいでしょう。
      国や、OSの種類に依存しますが、JDKの設定によってはfont.propertiesのファイル名や内容を変更する必要がある場合があります。詳しくは、Adding Fonts to the Java Runtimeをご覧ください。Win32環境では、フォントは符号化されている必要があり、また、TrueTypeフォントのみ利用可能です。
      ZapfDingbatsやSymbolフォントに関してはJDKで提供されていないため、必要に応じてfont.propertiesに追加する必要があります。

参考：, JDK 1.4以降では、JDK自身がヘッドレスサポートシステムを持っています（JDK1.4ドキュメント「 Java 2 SDK, v1.4 での AWT の拡張」 の「ヘッドレスサポート」をご覧ください）。システムプロパティ java.awt.headlessをtrueにセットするか、 javaコマンドラインオプション-Djava.awt.headless=true を追加するだけで利用可能です。

JDK1.2以降でJServのbootclasspathにpja.jarを追加するには？

jserv.propertiesファイルに以下の様にpja.jarの適切なパスを追加しましょう。

wrapper.bin.parameter = -Xbootclasspath/a:/path/pja.jar

com.eteks.awt.PJAToolkitのインスタンスを生成できるのに、まだjava.awt.AWTError : Toolkit not Found in a java.awt.Toolkit.getDefaultToolkit () call という例外が出るのは？

getDefaultToolkit ()はシステムプロパティawt.toolkitで示されるクラスのインスタンスを生成しようとします。 このメソッドはtoolkitクラスの検索に、デフォルトクラスローダのシステムクラスパスを適用します。com.eteks.awt.PJAToolkitがユーザクラスパスや、サーブレットクラスパスに見つかる場合、あなたのプログラムからはこのクラスのインスタンスを生成できるかも知れないませんが、getDefaultToolkit ()では失敗します。
だから、pja.jarはjavaのコマンドラインオプション -classpath (JDK <= 1.1) または -Xbootclasspath (JDK >= 1.2)で指定しなければならない。コマンドラインオプションを直接変更できない場合は、「どのような場合にPJAを使えばよいのでしょうか？」と「サーブレットの中で問題なく使用できるToolkitメソッドは何でしょうか？」をご覧ください。

UNIXプラットフォームのフォントを使用するとなぜ、JVMはクラッシュするのでしょうか？

JDK1.2以降のいくつかの実装（特にSolaris上）において、sun.java2d.SunGraphicsEnvironmentクラスは private static native boolean validPropertiesFile (java.lang.String, java.lang.String)メソッドを使用しています。 このスタティックメソッドは適切なディスプレィのない状態で呼ばれた場合に、JVMをクラッシュさせるというバグがあると思われます。以下のようなパッチは美しくありませんが、役に立ちます：

• 適切なJDKバージョン（1.2または1.3）のSunの提供するWindows用rt.jarから最新のsun/java2d/SunGraphicsEnvironment.class（validPropertiesFileを使用しません）を、以下のコマンドで抽出します。
  jar xvf /.../jdk.../jre/lib/rt.jar sun/java2d/SunGraphicsEnvironment.class
• 先に抽出したファイルsun/java2d/SunGraphicsEnvironment.class を新しいjarファイルrtgraphics.jarに入れます。
  jar cvf rtgraphics.jar sun/java2d/SunGraphicsEnvironment.class
• javaコマンドラインオプション-Xbootclasspath を -Xbootclasspath/p:pja.jar:rtgraphics.jarに変更します。 (rtgraphics.jar がデフォルトのbootclasspathよりも先に位置し、JVMが確実にrtgraphics.jarのsun.java2d.SunGraphicsEnvironmentを使用するようにする必要があります。）

このパッチの作業を行う際に、sun.java2d.SunGraphicsEnvironmentのインナークラス（SunGraphicsEnvironment$*.classという名前の全てのファイル）をrtgraphics.jarに含める必要があるという報告を受けています。（JDKのバージョンによります。）
このバグは、JDK1.3の最新版では存在しないようです。

サーブレットの中で問題なく使用できるToolkitメソッドは何でしょうか？

グラフィクス処理を行うサーブレットの問題は、UNIXプラットフォームでグラフィクスディスプレイを利用できない環境でデフォルトのAWT Toolkitにアクセスできないことにより発生します。この場合、java.awt.Toolkit や java.awt.Font のインスタンスを生成することができないため、Toolkitのインスタンスを必要とするjava.awt.Componentのメソッドを呼び出すことができません。
この様な場合、サーバ管理者でないなどの理由でJVMの オプション を変更できないというわけでなければ、デフォルトのToolkitの代わりにPJA Toolkit を使うことで解決できます。

• サーブレットの中でSystem.setProperties () か System.setProperty ()を呼び出すことで、システムプロパティを変更することができます。例えば、System.setProperty ("awt.toolkit", "com.eteks.awt.PJAToolkit") で起動時コマンドラインオプションに -Dawt.toolkit=com.eteks.awt.PJAToolkitを指定する代わりになります。
• 起動時コマンドラインオプション-classpath $CLASSPATH:pja.jar (または -Xbootclasspath/a:pja.jar)は容易には代替でききません。 サーブレットコンテナ(JServ や JRunなど)によっては、ユーザごとに、個別のクラスパスを設定できるようになっているので、その機能を利用してpja.jarをクラスパスに追加すればよいでしょう。このクラスパスは、サーブレットコンテナのクラスローダがサーブレットや、その他依存するクラスをロードする際に使用されるでしょう。
  しかし、AWT toolkitはjava.awt.ToolkitクラスのgetDefaultToolkit()メソッド呼び出しによりインスタンス化され、このメソッドはシステムプロパティ awt.toolkit を参照して、実際にインスタンス化するクラスを決定します。一般に、java.awt.Toolkitとこの決定されたクラスのロードにはシステムデフォルトクラスローダが使用されます。 システムクラスローダはcom.eteks.awt.PJAToolkitをロードする際にも、システムクラスパスを使用するため、pja.jar が上記のようにサーブレットクラスパスにあってもシステムクラスパスにはなく、システムクラスローダは見つけることができません。

com.eteks.awt.servlet.PJAServlet クラスを利用することで、このクラスパスの問題を解決することができます。但し、セキュリティマネージャの設定によっては、今度はセキュリティ上の問題が発生する可能性があります。 このクラスはクラスパスや他のシステムプロパティにアクセスしたり、クラスローダのインスタンス化を行える権限が必要です。。。
PJA では、デフォルトのtoolkitをインスタンス化されていない状態でもグラフィクス処理を行うための方法も提供しています。以下に、java.awt.Toolkit.getDefaultToolkit()を呼ぶことによるAWT Toolkitのインスタンス化なしで使用できるメソッドを示します :

Default AWT toolkit			PJA toolkit (package com.eteks.awt)
Toolkit	getImage (URL url)		PJAToolkit	getImage (URL url)
Toolkit	getImage (String file)		PJAToolkit	getImage (String file)
Toolkit	createImage (ImageProducer producer)		PJAToolkit	createImage (ImageProducer producer)
Toolkit	createImage (byte[] imagedata, int imageoffset, int imagelength)		PJAToolkit	createImage (byte[] imagedata, int imageoffset, int imagelength)
Toolkit	prepareImage (Image image, int width, int height, ImageObserver observer)		PJAToolkit	prepareImage (Image image, int width, int height, ImageObserver observer)
Toolkit	checkImage (Image image, int width, int height, ImageObserver observer)		PJAToolkit	checkImage (Image image, int width, int height, ImageObserver observer)
Toolkit	getColorModel ()		PJAToolkit	getColorModel ()
Component	createImage (int width, int height)			new PJAImage (int width, int height)
Component	createImage (ImageProducer producer)		PJAToolkit	createImage (ImageProducer producer)
Graphics	getFont ()		PJAGraphicsExtension	getFontName () getFontStyle () getFontSize ()
Graphics	setFont (Font font)		PJAGraphicsExtension	setFont (String fontName, int fontStyle, int fontSize)

PJAToolkitは"new PJAToolkit ()"でインスタンス化可能です。
PJAImage のインスタンス上への描画に使用する PJAGraphicクラスはPJAGraphicsExtension を実装しています。つまり、new PJAImage (width, height).getGraphics()の返値のGraphicsインスタンスはPJAGraphicsExtension のオブジェクトとしてキャストすることができます。

com.eteks.awt.PJAImageはJava2Dを実装していないため、この場合、Java2D やGraphics2D の機能は使用しないことになります。
また、文字列の描画では.pjaf フォントファイルを使用することになります。

JDK1.3以上ではjava.awt.Component クラスのshow()やsetVisible()はなぜClassCastExceptionをスローするのでしょうか？

これらのメソッドは、sun.awt.GlobalCursorManagerを使用していますが、このクラスでは、 java.awt.ToolkitクラスのgetDefaultToolKit()で返されるAWT toolkitがsun.awt.SunToolkitを継承していると想定しているからです！com.eteks.awt.PJAToolkitはjava.awt.Toolkitを直接継承しているため、ClassCastExceptionがスローされます。
これらのメソッドの代わりに、 java.awt.FrameインスタンスのaddNotify()を使用すれば、java.awt.FrameクラスのcreateImage ()でオフスクリーンイメージを生成することができ、さらに、show()メソッドが呼ばれた時に、どこにフレームが現れてしまうのだろうなどということを気にする必要もありません。

PJAではどんなフォントを使って文字を描画できますか?

JDK1.2以降では通常のTrue Typeフォントを使用します。
JDK1.1以前または、JDK1.2以降でシステムプロパティcom.eteks.awt.nojava2dの値がtrueの場合、 .pjaf フォントファイルが使用されます。このファイルはPJAFontCaptureユーィリティで既存のフォントから生成することができます。

.pjafファイルは何のためにあるのですか?

JDK1.1以前のデフォルトのtoolkitの場合、文字列描画の際、JVM稼働環境のプラットフォーム（UNIX, Windowsなど）のネイティブなメソッドとフォントを使用します。 PJA Toolkitではpure javaで文字列の描画を行えるようにするためにフォントに関して多少別の情報が必要になります。XやTrue Typeフォーマットのデコーダを実装する代わりに、.pjaf という拡張子を持つファイルに保存された新しい形式の情報の使用を採用しました。このファイルは、ポータブルで、各フォントの文字を描画するためのビットマップ情報を保持しています。PJAFontCapture ユーティリティを利用してネイティブフォントから.pjaf ファイルを生成することができます。
Java2Dは独自のTrue Typeフォントファイルのデコーダを持っているため、JDK1.2以降では.pjaf ファイルを利用する意味がありません。代わりに、既にあるTrue Typeフォントを使用します。

なぜPJAFontCapture (java com.eteks.tools.fontcapture.PJAFontCapture) が正常に動作しないのでしょう？

PJAFontCapture は、動作時に、JVMデフォルトのtoolkitを使用します。そのため、グラフィクス表示環境を利用できないUNIX環境では動作しません。
グラフィクス表示環境を利用できないUNIX環境で.pjaf フォントが必要な場合は、デフォルトのtoolkitを実行可能な環境(Windows, MacOS, X11 Displayを使えるUNIX) でPJAFontCapture を実行して下さい。その後 ftp (もちろんバイナリモード) などでコピーして.pjaf ファイルを使用したいUNIX環境に導入します。

生成した画像はどのようにして保存したらよいのでしょう？

PJA Toolkitやそれ以外のJavaのクラスで生成したオフスクリーンイメージは、様々な形式で画像ファイルやストリームを生成するエンコーダを使用して保存することができます。エンコーディングの処理はほんの数行の簡単なプログラムで処理することができます。ToolkitDemo.javaのソースコードはACMEのGIF エンコーダを使用する１つの例ですのでご覧ください。
PJA　Toolkitで正常に動作確認できたフリーのエンコーダを３つご紹介します。（テストは ToolkitDemo.java に多少の修正を加えることで行いました。):

Encoder format	JDK version supported	Link
GIF	1.1	http://www.acme.com/java/ JDK1.0でも動作するAcme.JPM.Encoders.GifEncoder クラスの修正版がPJAの配布で提供されています。
JPEG	1.1	http://www.obrador.com/essentialjpeg/
PNG	1.1	http://catcode.com/pngencoder/

Sun Microsystemsからもデコーダとエンコーダを含む以下の２つのライブラリが提供されています。

• JIMI, JDK1.1以上で動作。サポートする形式は： GIF (デコーダのみ), JPEG, TIFF, PNG, PICT, Photoshop, BMP, Targa, ICO, CUR, Sunraster, XBM, XPM, PCX。
• JAI (Java Advanced Imaging), JDK1.2以上で動作。サポートする形式は：BMP, GIF (デコーダのみ), FlashPix (デコーダのみ), JPEG, PNG, PNM,TIFF。

FYI: JDK1.2以上ではcom.sun.image.codec.jpeg.JPEGImageEncoderクラスが提供されており、java.awt.image.BufferedImageのインスタンスの画像をJPEG形式で円コードすることができます。

PJAを利用した描画処理が遅すぎます。どうすればパフォーマンスを改善できますか？

JDK1.2以降でPJA Toolkitをお使いの場合、画像ファイルの読み込みを除く大部分のAWTのメソッドはJavaの標準ライブラリの既存のクラスによって実装されています。これらのメソッドの多くは、SunがCのライブラリを使用して実装しており、今後、速度の向上を期待することは困難でしょう。
JDK1.1以前であるか、システムプロパティcom.eteks.awt.nojava2dがtrueにセットされているか、または、com.eteks.awt.PJAImageとcom.eteks.awt.PJAGraphicsクラスを直接使用する場合、PJA描画メソッドが使用されます。この場合、com.eteks.awt.PJAGraphicsの描画メソッドは、昔ながらの描画アルゴリズムを使用していてまだ改善の余地がある実装になっているため、PJA ToolkitはデフォルトのToolkitよりも処理が遅くなります。これはPJAがフリーであることの理由の一つです。PJAのパフォーマンスを改善できるアルゴリズムをご存知の方は、是非お知らせください。そうすれば我々がそれを実装して、他のPJAユーザの方々の環境を改善することができるでしょう。
いずれの場合でも、JIT (Just In Time)かHotSpotコンパイラがオンになっていることを確認してください。

PJA Toolkitは100%Pure Javaですか？

SunのJavaPureCheck ツールによるテストでは、PJAは100% Pure Javaではありません。
PJAはJDKのインターナルクラスであるsun.awt.image.ByteArrayImageSource と sun.java2d.SunGraphicsEnvironment を使用しているため、以下の２つのエラーがリストアップされます。

• sun.awt.image.ByteArrayImageSource class is used in the method createImage (byte [] imagedata, int imageoffset, int imagelength) of com.eteks.awt.PJAGraphicsManager class, and is the same implementation as sun.awt.SunToolkit.
• sun.java2d.SunGraphicsEnvironment is the super class of com.eteks.java2d.PJAGraphicsEnvironment. Its use can't be avoided because the class java.awt.Font casts the default graphics environment returned by the method getLocalGraphicsEnvironment () of java.awt.GraphicsEnvironment to sun.java2d.SunGraphicsEnvironment !
  この２つ目の理由で、PJAは JavaPureCheck ツールのテストに合格することは今後もないでしょう。

 

History

Version 2.4 03/14/2002

• getImage () methods of com.eteks.awt.PJAGraphicsManager : InputStream not immediately closed once GIF images were read.
• Added a contructor in com.eteks.awt.image.GIFDecoder to be able to chose the close of the input stream once the image is read.
• createImage (byte[] imagedata, int imageoffset, int imagelength) method of com.eteks.awt.PJAGraphicsManager bug : zero length arrays shouldn't throw exceptions.
• Added methods to com.eteks.awt.PJAComponentPeer, com.eteks.awt.PJAFramePeer and com.eteks.java2d.PJAGraphicsConfiguration to enable PJA to run with JDK 1.4 (some useless methods were commented to be able to compile PJA with 1.2 rt.jar library).
• Added information in the FAQ.

Version 2.3.1 07/05/2001

• copyArea () method of com.eteks.awt.PJAGraphics bug : wrong method call to get the height of the image (thanks to Dean Brettle).
• No use of character encoding in writeString () method of Acme.JPM.Encoders.GifEncoderNoCM, so headers of GIF images are correctly generated under OS/390. Note that users of Acme.JPM.Encoders.GifEncoder may force the correct character encoding with the -Dfile.encoding=ISO8859_1 java option that sets the file.encoding system property.
• Changed -Duser.home=. to -Duser.home=.. in PJAToolkitDemo1.2.sh.
• Added information in the FAQ about rtgraphics.jar patch.

Version 2.3 03/23/2001

• getImage (File filename) method of com.eteks.awt.PJAToolkit and com.eteks.awt.PJAGraphicsManager tries to find the image filename in a path relative to user.dir system property as before, and then if image isn't found with that path it tries to find filename with the path returned by the method getAbsolutePath () of the class java.io.File.
• Java2D is turned off if JVM version returned by the system property java.version returns something that can't be parse in the form x.y.z, where x, y and z are numbers.
• PJA fonts management and drawString () method of com.eteks.awt.PJAGraphics optimized : drawing strings run up to 4 times as fast (thanks to Fernando Echeverria).
• Inlined code com.eteks.awt.PJAGraphics for optimization (thanks again to Fernando Echeverria).
• Added support for 8 bit color images using java.awt.image.IndexColorModel in com.eteks.awt.Image and com.eteks.awt.PJAGraphics classes : All images created with PJA toolkit can use a 8 bit/pixel buffer with an indexed color model if the class name given by the system property com.eteks.awt.colormodel inherits from java.awt.image.IndexColorModel.
  The new com.eteks.awt.image.Web216ColorModel class can be used as an indexed color model for that purpose (thanks again to Fernando Echeverria).
• Added information in the FAQ.

Version 2.2 11/02/2000

• Changed the condition that detects GIF transparency in the class com.eteks.awt.image.GIFDecoder.
• readCode () method of com.eteks.awt.image.GIFDecoder bug : fixed raster over-run errors (thanks to Alan Dix).
• Better GIF detection from content type in com.eteks.awt.PJAGraphicsManager (thanks to Fernando Echeverria).
• Added minimum support for EventQueue in com.eteks.awt.PJAToolkit.
• getClipBounds () method of com.eteks.awt.PJAGraphics bug : returns a correct Rectangle instance.
• create () method of com.eteks.awt.PJAGraphics bug : changed com.eteks.awt.PJAGraphics constructors.
• translate () method of com.eteks.awt.PJAGraphics bug : changed to enable the cumulative effect of translations after multiple call to translate ().
• Clipping bugs in com.eteks.awt.PJAGraphics.

Version 2.1 07/30/2000

• PJA library is available under GNU General Public License from this version.
• PJA is now supplied with a font.properties file using the Lucida True Type fonts provided with JDK 1.2. The described properties use a font format that works with com.eteks.java2d.PJAGraphicsEnvironment class. It uses the same font format as its super class sun.java2d.SunGraphicsEnvironment and as Windows implementation.
  This file is required with JDK version greater or equal to 1.2 when using com.eteks.awt.PJAToolkit and com.eteks.java2d.PJAGraphicsEnvironment classes on a UNIX platform. It must be in a lib sub directory of the directory defined by $HOME or user.home system property.
  Check if the path you set in java.awt.fonts system property contains the directory /.../jdk.../jre/lib/fonts where Lucida True Type fonts files are by default.
  If you need to change font.properties yourself, have a look at the document Adding Fonts to the Java Runtime.
• Created the com.eteks.awt.servlet.PJAServlet class extending javax.servlet.http.HttpServlet.
  This class should be used by developers as a super class to ensure their graphics servlets will work with all servlet servers in almost any case.
• Created the com.eteks.awt.servlet.PJARedirectServlet class extending com.eteks.awt.servlet.PJAServlet.
  This class should be used by users of graphics existing servlets to provide an AWT toolkit to their servlet server if they have some problems using the default JVM one.
• Added a FAQ list.
• Organized differently PJA files.
• Splited pja.jar in two files : pja.jar and pjatools.jar.
  • pja.jar contains the core PJA classes (packages com.eteks.awt, com.eteks.awt.image, com.eteks.awt.servlet and com.eteks.java2d).
    This jar file contains all the classes needed to replace default JVM toolkit.
  • pjatools.jar contains some utility classes, the classes used for demo and PJAFontCapture utility class.

Version 2.0 06/23/2000

• After a close study of the JDK 1.2.2 sources available at Sun, support of Java2D in Pure Java AWT images was added for JVM version greater or equal to 1.2 (using java.awt.image.BufferedImage class or java.awt.Component class createImage () method). It may interest people who want to generate images with Java2D features even if they don't have access to any X11 Display on UNIX machines.
  This study was done respecting this process :

• In the import instructions and in the code of all the classes of java.awt package and sub packages, search the non standard Java classes they need. Most of these classes belongs to sun.dc, sun.awt, sun.java2d and sun.security.action packages and sub packages.
  Untill Java 1.1, all java.awt classes imported classes only from standard Java packages (and Sun shouldn't have changed this paradigm !).
• In the import instructions of all the classes of the latter packages, search what other packages are needed. A few ones use conversion classes of sun.io package, sun.security.action.GetProperty class, sun.security.action.LoadLibraryAction class and sun.misc classes for weak references (nothing that seems annoying).
• In the classes of java.awt, sun.dc, sun.awt and sun.java2d packages and sub packages, search abstract classes and classes with native methods (event managing classes were a little neglected because they aren't usefull in PJA).

The result of this research told roughly :

• Which abstract classes are extended in platform dependent classes or not (classes of sun.awt.motif and sun.awt.windows packages).
• Which native methods are implemented using common portable C code (sources found in share/native/sun/awt, share/native/sun/dc and share/native/sun/java2d directories) or using platform dependent code (using Windows GDI or an X11 display for example).

All the native classes of java.awt package and sub packages are named initIDs (). The implementation of initIDs () is only used by native objects to initialize their struct data and don't use any X11 Display but requires the awt library to be loaded.
Almost all the methods of the class java.awt.image.BufferedImage used to render Java2D are implemented in common Java classes or C programs, except a few ones that are corrected by the following classes.

The following new classes belong to the package com.eteks.java2d. The classes of com.eteks.awt package don't require them if you wish to work with JDK 1.1 or if a DISPLAY is available.

• Created the com.eteks.java2d.PJAGraphicsManager2D class extending com.eteks.awt.PJAGraphicsManager.
• Created the com.eteks.java2d.PJAGraphicsEnvironment class extending sun.java2d.SunGraphicsEnvironment.
  • java.awt.graphicsenv system property have to be set to com.eteks.java2d.PJAGraphicsEnvironment to permit the change of java.awt.GraphicsEnvironment implementation.
• java.awt.fonts system property have to be set to the path where True Type fonts files will be loaded from.
  This path can be equal to :
  • WinDir\Font directory on Windows
  • /usr/openwin/lib/X11/fonts/Type1:/usr/openwin/lib/X11/fonts/TrueType directories on Solaris
  • ($JAVAHOME)/lib/fonts
  • Any directory list containing True Type fonts.

  When drawing in images of class java.awt.image.BufferedImage, .pjaf font files are not used.

• Created the com.eteks.java2d.PJAGraphicsDevice class extending java.awt.GraphicsDevice.
  
• Created the com.eteks.java2d.PJAGraphicsConfiguration class extending java.awt.GraphicsConfiguration.
• Created the com.eteks.java2d.PJABufferedImage class extending java.awt.image.BufferedImage. It has the same constructors as BufferedImage and overrides the method public Graphics2D createGraphics (); to return the Graphics instance returned by the method createGraphics () of PJAGraphicsEnvironment.
• Changed the methods createImage (int width, int height) and createImage (ImageProducer producer) of the class com.eteks.awt.PJAGraphicsManager to return a PJABufferedImage instance if JVM version is greater or equal to 1.2.
• For security reasons or for a need of homogeneous image result whatever JDK is used, the boolean system property com.eteks.awt.nojava2d can be set to true to disallow Java2D in PJA.
  In that case, PJAImage will be used as images class along with PJAGraphics class and .pjaf fonts.
  

Version 1.2 06/08/2000

• Added the method public int charWidth (char ch) in the class com.eteks.awt.PJAFontMetrics (it overrides java.awt.FontMetrics to return the width of a character).
• com.eteks.awt.PJAImage bug : drawing images constructed by a prepareImage () call could throw exceptions.
• Changed com.eteks.awt.PJAComponent default background color : new images created by createImage (int width, int height) are now white by default (when setBackground () is not set on the component).
• Created the com.eteks.awt.PJAMenuComponentPeer class for internal needs.
• Created the com.eteks.awt.image.GIFDecoder class : it is now the default GIF files loader (it avoids the exception java.lang.UnsatisfiedLinkError: parseImage with JDK 1.1).
  If you need a GIF loader, it can be used alone without com.eteks.awt package (it implements the interface java.awt.image.ImageProducer).

Version 1.1 05/30/2000

• Version 1.0 .pjaf font files are not compatible with PJA version 1.1.
  Please use font capture utility to produce PJA 1.1 new font files. For security reasons and wider platform compliance, it was impossible to support PJA 1.0 fonts in PJA 1.1.
• Version 1.0 targeted the replacement of Java standard AWT Toolkit by PJA Toolkit when standard Toolkit couldn't be instantiated.
  Version 1.1 aims at enabling the creation of an image and drawing into it with all the java.awt.Graphics methods, even if no Toolkit can be instantiated by getDefaultToolkit () static method of the class java.awt.Toolkit, for security or other reason (JServ 1.1 refuses to load the class com.eteks.awt.PJAToolkit because it's not in its default classpath).
  Version 1.0 allowed to create an instance of com.eteks.awt.PJAImage but using java.awt.Graphics drawString () threw an AWTError exception, when no Toolkit was available. This is because the class java.awt.Font requires the instance of a Toolkit to be instantiated in Java 1.1 and without any Toolkit you can't get any font to draw strings...
  com.eteks.awt.PJAGraphics was changed in version 1.1 and now has a default internal font created from a .pjaf font file. This default font is used in drawString () method to draw text.
  On the other hand, in Java 1.1, the creation of a java.awt.Font object is still impossible without a Toolkit instance, which prevents from changing the default font to an other one, with Graphics setFont () method. To be able although to modify the font used in drawString (), the non standard setFont (String fontName, int fontStyle, int fontSize) method of the new interface com.eteks.awt.PJAGraphicsExtension was implemented in PJAGraphics class (see also com.eteks.awt.PJAToolkit class).
• Following the same idea, version 1.0 was modified to enable the use of PJA even if the awt library can't be loaded for security or other reasons. If awt isn't available, a lot of AWT classes (in particular, java.awt.Color, java.awt.Rectangle, java.awt.Font, java.awt.FontMetrics, java.awt.image.ColorModel) can't be loaded preventing some graphics operations. Changing the current color and querying font metrics is although possible when awt library isn't available thanks to com.eteks.awt.PJAGraphicsExtension new methods implemented in PJAGraphics class (see the new PJADemo.java example to see what it may change in your Java code).
  
• Changed com.eteks.servlet.TeksSurveyPie to improve error catching and provide a good model for Image creation.
  
• Changed createImage (int width, int height) method in the class com.eteks.awt.PJAComponent to fill the image with component background color.
  
• Improved Javadoc documention of all classes.
  
• Cleaned import instructions in PJA classes to enhance maintenance ; there are no more import ...*; and class prefixed with its package (except when a class name is in a String, and mustn't be loaded) : all the classes of foreign packages used in a class have an import.
• Created the com.eteks.awt.PJAGraphicsManager class into which the font loading methods of the class com.eteks.awt.PJAToolkit were copied.
• Created the com.eteks.awt.PJAFontData class into which all the font data management code of the class com.eteks.awt.PJAFontMetrics was copied.
• com.eteks.awt.PJAGraphics class optimization : this class doesn't use anymore floating point Java type (float or double). Thanks to this change, floating point is useless in the package com.eteks.awt, enabling PJA to be used in a J2ME environment.
• com.eteks.awt.PJAGraphics class change : this class doesn't use anymore the classes java.awt.Color, java.awt.Rectangle, java.awt.FontMetrics or java.awt.Polygon for internal use.
• com.eteks.awt.PJAGraphics bug : Large ellipse weren't drawn correctly, ellipse generator uses long now.
• com.eteks.awt.PJAGraphics drawString (AttributedCharacterIterator iterator, int x, int y) method implemented.
• com.eteks.awt.PJAImage flush () method correctly implemented.
• PJA 1.1 now supports JDK 1.0.2.
• Changed demo programs.
• To reduce the size of the package com.eteks.awt, the two next methods moved :
  • The main () method of the class com.eteks.awt.PJAFontPeer moved to the new class com.eteks.tools.fontcapture.PJAFontCapture.
  • The main () demo method of the class com.eteks.awt.PJAToolkit moved to the new class PJAToolkitDemo (with no package).

Version 1.0 05/17/2000

First version. JDK 1.1 compliant.

What's next

Javadoc documentation should be clearer and more consistent. Meanwhile, if you have problems using PJA library, please read first the FAQ.

Features that may be interesting to implement in PJA :

• Supporting Java2D in PJA for JVM version 1.1 :
  It's a great amount of work that could be simplified by using or modifying JDK 1.2 classes sources (if possible), but Sun may not grant the authorization to distribute such modified JDK 1.2 classes for JVM version 1.1 use.
  Maybe, supporting anti-aliasing on current PJA would be enough for most people...
• PJAToolkit getPrintJob () method could be implemented as sun.awt.motif.MToolkit getPrintJob () method.
• Stuff not implemented in PJAToolkit should throw java.awt.AWTError.
• Keep track of all PJAGraphics calls, to be able to generate vector PNG files.
• The method sync() of the class PJAToolkit should do something.
  
• PJAFrame should be linked to JInternalFrame to looks like a frame and then allow to capture it.

Copyright and license

Copyright © 2000-2001 Emmanuel PUYBARET / eTeks. All Rights Reserved.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

Visit eTeks web site for up-to-date versions of PJA and other Java tools and tutorials : http://www.eteks.com/

---

Copyright © 1996,1998 by Jef Poskanzer. All rights reserved. (for the use of Acme.JPM.Encoders.GifEncoder class)

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Visit the ACME Labs Java page for up-to-date versions of this and other fine Java utilities : http://www.acme.com/java/

日本語駄訳：つ∞たん佐藤＠ｎｇＭＡＴ
Last Update : 2002/12/01