問題タブ [taglet]

最初のタグレットが見つかったときに、いくつかの構成をロードします (プロパティで満たされたテキストファイルから始まります)。

構成オブジェクトは各Tagletオブジェクトに直接静的に保持されていますが、ガベージ コレクションが行わjavadoc.exeれ、後続のタグレットで再生成され、構成が何度も再ロードされているようです。

私はこれを正しく理解していますか?それを回避する方法はありますか? 構成が一度だけロードされるようにするにはどうすればよいですか?

ありがとう。

アップデート

コメントで述べたように、いいえ、これはパフォーマンスや正確性には影響しません。1 台のマシンで 1 人が使用するためjavadoc.exe、パフォーマンスはあまり問題になりません。

ただし、構成が読み込まれるたびにログが乱雑になり (実行ごとに少なくとも 5 回)、複数の Web サイトからの の読み込み、テンプレート ファイルの読み込みと解析、およびその他のファイル処理の束など、javadoc.exeやや重い処理が行われます。 package-list. 1 回の JavaDoc の実行でこれが何度も発生するのを防ぐ方法があれば、そうしたいと思います。

私はマルチスレッドの経験がないので、これは完全に間違っているかもしれません...しかし、構成をロードしてからすべてを静的に保持するだけのデーモンスレッドをセットアップするのはどうですか? この回答は、I/O ベースのデーモン スレッドが悪い考えであることを示唆していますが、それは進行中の I/O を実行するものを意味すると思います。

（これが手動で開始および停止する必要があるものなのか、それともプロセス自体がデーモンスレッドを開始できるのかはわかりません... BlochのEffective Javaの並行性の章を読むつもりです.. .)

JavaDoc Ant タスクに問題があります。java.lang.NoClassDefFoundError私が知る限り、間違いなくクラスパス上にあるクラスを私に与えています。ドキュメントによると、コンパイル中にクラスが存在するときに aNoClassDefFoundErrorがスローされますが、実行時に見つかりません。(ANoClassDefFoundErrorは ではありませんClassNotFoundException。)

クラスパス項目を削除すると、期待どおりに失敗し (多くのパッケージ/シンボルが見つからないエラー)、それでも同じNoClassDefFoundError. クラスがクラスパス上にあるかどうかに関係なく、タグレットでこれが失敗するのはなぜですか?

詳細：

見つからないクラスは と呼ばれcom.github.xbn.io.SimpleDebugable、次の jar ファイルにあります。

• jar ファイル:C:\data_jeffy\programming\sandbox\z__for_git_commit_only\codelet\z_build\jar_dependencies\xbnjava-0.1.4.2-all.jar

JavaDoc Ant タスク。上記の jar ファイルは、クラスパスの最初の項目です。

その結果、次のようになります。

完全な出力:

クラスパスからjarファイルを完全に削除すると、期待どおりに失敗し、数百package com.github.xbn.... does not existのsymbol not foundエラーが発生します。これは、クラスパス要素が明らかに「機能している」ことを意味します。では、なぜタグレットで機能しないのでしょうか?

クラスパスにないjarの出力：

続き (~1,500 行削除):

続き: ここでは最後に、jarがクラスパスにあったときと同じエラーが発生します。

元の (上記の) ターゲットでは、タグレットのパスは jar ファイルを指しています。以下では、タグレット クラス ファイルを jar からディレクトリに抽出し (これら 4 つのタグレット クラスのみが抽出され、それ以外はすべて jar に残ります)、タグレット パスをルート ディレクトリに変更しました。

そして今、それNoClassDefFoundErrorは起こりません。代わりに

問題は、このエラーが JavaDoc によって「飲み込まれている」ように見えることです。その痕跡はどう見てもわからないjava.lang.ClassNotFoundException。

完全な出力:

また、詳細な出力: http://dpaste.com/3T0B40X

、、などのドットで始まる名前のカスタム タグレット ライブラリを作成しました。JDK 7 でコンパイルされています。.codelet.codelet.and.out

1.7 を使用して JavaDoc を生成するjavadoc.exeと、正常に動作します。しかし、JDK 8 で生成すると失敗します。

タグレット（タグレットコード自体ではなく）を使用してコードを次のように変更すると{@codelet mypkg.Temp}：

タグレット ソース コードの名前をcod.elet(は既存のタグレット名であるcode.letため、適切ではありません) に変更し、その新しい名前を使用すると機能します。code

-tagオプションの JavaDoc ツール ドキュメント(セクションの下部付近) には、次のように記載されています。

競合の回避: 独自の名前空間を作成する場合は、パッケージに使用されるものと同様のドット区切りの命名規則を使用できます: com.mycompany.todo。Oracle は、名前にドットを含まない標準タグを引き続き作成します。作成したタグは、Oracle によって定義された同じ名前のタグの動作をオーバーライドします。@todo タグまたはタグレットを作成すると、後で Oracle が同じ名前の標準タグを作成した場合でも、定義した動作は常に同じになります。

ここで何か不足していますか？それとも、これは文書化されていない変更であり、本当にひどいものですか? その場合、ライブラリにかなり大きな変更が必要になるためです。

参考までに:タグレットの概要ドキュメント

タグレットが参照されているクラスに関する情報を取得するために、API を介してリフレクションを使用するカスタム javadoc タグレットを開発しました。クラスに " " をロードしますClass.forName(String)。

ToolProvider.getSystemDocumentationTool()「 」を使用して統合テストを実行し、結果のコンテンツを検証するところまで、タグレット自体のプロジェクトでこれを機能させることができました。

このアーティファクトを nexus サーバーにインストールしました。Maven と で構築されたクラスから参照しようとしていmaven-javadoc-pluginます。

タグが "Foo.java" で参照されているビルドを最初に実行したとき、指定されたクラスが見つからないことを示す ClassNotFound 例外がタグレット コードに表示されました。

これは、タグレット コードに侵入していることを示していますが、問題のクラスのクラス ファイルをロードできません。これはちょっと皮肉なことです。ここにたどり着く唯一の方法は、クラスに関連付けられたソース ファイルを見つけて解析することです。

そこで、maven-javadoc-plugin 構成を編集し、" additionalDependencies" ブロックを追加して、タグを参照するクラス ファイルを含むアーティファクトを指定しました。

また、「verbose」フラグを設定すると、結果の出力で「search path for class files」が出力されたときに、そのリストの最後に問題のクラスを持つアーティファクト jar が見つかりました。

ただし、まだエラーが発生します。

ここで他に何が問題になる可能性がありますか？

関連するコードの抜粋を次に示します。

含まれているクラスのロードを示す Taglet クラスのコードの一部を次に示します。

ビルドを実行すると、次の出力が表示されます。

そして、出力に次の行があることに気付きました (詳細がオンになっています)。

リストの最後にある jar を調べて、問題のクラスがそこにあることを確認しました。