javax.management
注釈型 MXBean

@Documented
@Retention(value=RUNTIME)
@Target(value=TYPE)
public @interface MXBean

インタフェースに対して、MXBean インタフェースである、または MXBean インタフェースではないというマークを明示的に付けるための注釈です。デフォルトでは、SomethingMXBean のように、名前の末尾が MXBean のインタフェースは MXBean インタフェースです。次に示すインタフェースは、MXBean インタフェースです。

    public interface WhatsitMXBean {}

    @MXBean
    public interface Whatsit1Interface {}

    @MXBean(true)
    public interface Whatsit2Interface {}
    

次に示すインタフェースは、MXBean インタフェースではありません。

    public interface Whatsit3Interface{}

    @MXBean(false)
    public interface MisleadingMXBean {}
    

MXBean 仕様

MXBean の概念を使用すると、javax.management.openmbean により定義された、定義済みの型セットだけを参照する MBean を簡単にコーディングできます。これにより、リモートクライアントを含む任意のクライアントが、MBean の型を表す「モデル固有クラス」にアクセスしなくても、MBean を確実に使用できるようになります。

この概念は、Standard MBean の概念と比べて、理解しやすいものです。ここでは、管理対象オブジェクトを Standard MBean および MXBean として表現する方法について説明します。

Standard MBean	MXBean
public interface MemoryPoolMBean { String getName(); MemoryUsage getUsage(); // ... }	public interface MemoryPoolMXBean { String getName(); MemoryUsage getUsage(); // ... }

上記の記述から、定義は非常に類似していることがわかります。唯一の相違点は、インタフェースの命名規則として、Standard MBean では SomethingMBean を使用するのに対して、MXBean では SomethingMXBean を使用するという点です。

この管理対象オブジェクトでは、MemoryUsage 型の Usage という名前の属性があります。この種の属性の特徴は、データ項目セットの一貫したスナップショットを提供する点です。たとえば、メモリープール内の現在の使用済みメモリー容量や、現在のメモリープールの最大値を含めることができます。これらが別の項目になっていると、getAttribute を個別に呼び出して項目を取得するため、さまざまな時点の一貫性のない値を取得する可能性があります。max 値よりも大きい used 値を取得する可能性もあります。

このため、次のように MemoryUsage を定義できます。

Standard MBean	MXBean
public class MemoryUsage implements Serializable { // standard JavaBean conventions with getters public MemoryUsage(long init, long used, long committed, long max) {...} long getInit() {...} long getUsed() {...} long getCommitted() {...} long getMax() {...} }	public class MemoryUsage { // standard JavaBean conventions with getters @ConstructorProperties({"init", "used", "committed", "max"}) public MemoryUsage(long init, long used, long committed, long max) {...} long getInit() {...} long getUsed() {...} long getCommitted() {...} long getMax() {...} }

MXBean では MemoryUsage に Serializable のマークを付ける必要がないことを除けば、どちらの場合も定義は同じです (ただし、Serializable のマークを付けることは可能)。一方、MXBean には、コンストラクタパラメータを対応する取得メソッドにリンクするための、@ConstructorProperties 注釈が追加されています。この点については、あとで詳しく説明します。

MemoryUsage は、「モデル固有クラス」です。Standard MBean では、MemoryUsage クラスが不明な場合、MBean Server のクライアントは Usage 属性にアクセスできません。クライアントが、JMX 技術に基づく総称コンソールである場合を考えてみましょう。この場合、コンソールは、接続先の各アプリケーションのモデル固有クラスを使って設定する必要があります。Java 言語で記述されていないクライアントの場合、問題は一層難しくなります。この場合、MemoryUsage の内容についてクライアントに知らせる方法がない可能性があります。

このような場合に、MXBean は Standard MBean と異なります。管理インタフェースの定義方法はほとんど同じですが、MXBean フレームワークでは、モデル固有クラスが Java プラットフォームの標準クラスに変換されます。配列および標準 javax.management.openmbean パッケージの CompositeData クラスと TabularData クラスを使用することで、任意の複雑さのデータ構造を標準クラスだけを使用して構築できます。

この点は、2 つのモデルのクライアントを比較することでより明確になります。

Standard MBean	MXBean
String name = (String) mbeanServer.getAttribute(objectName, "Name"); MemoryUsage usage = (MemoryUsage) mbeanServer.getAttribute(objectName, "Usage"); long used = usage.getUsed();	String name = (String) mbeanServer.getAttribute(objectName, "Name"); CompositeData usage = (CompositeData) mbeanServer.getAttribute(objectName, "Usage"); long used = (Long) usage.get("used");

String などの単純な型の属性の場合、コードは同じです。ただし、複雑な型の属性の場合、Standard MBean のコードではクライアントがモデル固有クラス MemoryUsage を認識する必要があるのに対し、MXBean のコードでは非標準クラスは必要ありません。

ここに示すクライアントコードでは、MXBean クライアントの方がいくらか複雑になっています。ただし、クライアントがモデル (ここでは、MemoryPoolMXBean インタフェースと MemoryUsage クラス) を実際に認識している場合は、「プロキシ」の構築が可能です。モデルが事前にわかる場合には、Standard MBean を使用するか MXBean を使用するかに関係なく、この方法で管理対象オブジェクトとのやり取りを行うことをお勧めします。

Standard MBean	MXBean
MemoryPoolMBean proxy = JMX.newMBeanProxy( mbeanServer, objectName, MemoryPoolMBean.class); String name = proxy.getName(); MemoryUsage usage = proxy.getUsage(); long used = usage.getUsed();	MemoryPoolMXBean proxy = JMX.newMXBeanProxy( mbeanServer, objectName, MemoryPoolMXBean.class); String name = proxy.getName(); MemoryUsage usage = proxy.getUsage(); long used = usage.getUsed();

MemoryPool オブジェクトの実装の動作は、Standard MBean でも MXBean でも同様です。

Standard MBean	MXBean
public class MemoryPool implements MemoryPoolMBean { public String getName() {...} public MemoryUsage getUsage() {...} // ... }	public class MemoryPool implements MemoryPoolMXBean { public String getName() {...} public MemoryUsage getUsage() {...} // ... }

MBean Server への MBean の登録の動作は、どちらの場合も同じです。

Standard MBean	MXBean
{ MemoryPoolMBean pool = new MemoryPool(); mbeanServer.registerMBean(pool, objectName); }	{ MemoryPoolMXBean pool = new MemoryPool(); mbeanServer.registerMBean(pool, objectName); }

MXBean の定義

MXBean は、MBean の一種です。MXBean オブジェクトは、MBean Server に直接登録することも、StandardMBean の引数として使用し、結果の MBean を MBean Server に登録することもできます。

MBeanServer インタフェースの registerMBean や createMBean メソッドを使ってオブジェクトを MBean Server に登録すると、MBean の型を判別するためにオブジェクトのクラスが検査されます。

• クラスが DynamicMBean インタフェースを実装する場合、MBean は Dynamic MBean です。StandardMBean クラスはこのインタフェースを実装します。このため、これは StandardMBean クラスを使って作成された Standard MBean または MXBean に適用されます。
• それ以外で、クラスが Standard MBean の命名規則に一致する場合、MBean は Standard MBean です。
• 上記のいずれにも当てはまらない場合は、MXBean の可能性があります。次のインタフェースがあるかどうか、オブジェクトにより実装されたインタフェースのセットが検査されます。
  • クラス名が SMXBean のインタフェース。S は空ではない文字列であり、注釈 @MXBean(false) を含まない。
  • @MXBean(true) または単に @MXBean という注釈を含むインタフェース。
  正確に一致するインタフェースが存在するか、ほかのすべてのサブインタフェースであるインタフェースが存在する場合、そのオブジェクトは MXBean です。問題のインタフェースは MXBean interface になります。この例では、MXBean インタフェースは MemoryPoolMXBean です。
• これらの条件に当てはまるものがない場合、MBean は無効であり、登録を試みると NotCompliantMBeanException が生成されます。

MXBean インタフェース内でメソッドのパラメータまたは戻り値の型として示されるすべての Java 型が、次のルールに従って「変換可能」でなければなりません。また、パラメータが以下の定義に従って再構築可能でなければなりません。

上記のルールに準拠しない MXBean を構築しようとすると、例外がスローされます。

命名規則

MXBean 内のメソッドには、Standard MBean 内のメソッドと同じ命名規則が適用されます。

1. T getN() メソッド (T は void ではない Java 型、N は空でない文字列) は、N という名前の読み取り可能な属性が存在することを示します。属性の Java 型および公開型は、次のマッピングルールに従って決定されます。Object から継承した final Class getClass() メソッドは、取得メソッドの検索時には無視されます。
2. boolean isN() メソッドは、Java 型 boolean および公開型 SimpleType.Boolean の読み取り可能属性 N が存在することを示します。
3. void setN(T x) メソッドは、書き込み可能属性 N が存在することを示します。属性の Java 型および公開型は、次のマッピングルールに従って決定されます。パラメータの名前 x は関係ありません。
4. ほかのすべてのメソッドは、メソッドと同じ名前の演算が存在することを示します。戻り値および各パラメータの Java 型および公開型は、次のマッピングルールに従って決定されます。

getN および isN のルールにより、「取得メソッド」の概念がまとめて定義されます。setN のルールにより、「設定メソッド」の概念が定義されます。

同名の取得メソッドが 2 つ存在したり、同名の設定メソッドが 2 つ存在するとエラーになります。同名の取得メソッドと設定メソッドが存在する場合は、両方の T 型を同じにします。この場合、属性は読み取り/書き込み属性になります。取得メソッドと設定メソッドのいずれか一方が 1 つだけ存在する場合、属性はそれぞれ読み取り専用または書き込み専用になります。

型マッピングルール

javax.management.openmbean パッケージで定義されているように、MXBean は Open MBean の一種です。これは、属性、演算パラメータ、および演算の戻り値がすべて、「公開型」 (つまり OpenType の 4 つの標準サブクラス) を使って記述可能でなければならないことを意味します。MXBean では、Java 型を公開型にマッピングすることでこれを実現します。

すべてのJava 型 J で、MXBean マッピングの記述に次の情報が使用されます。

• 対応する公開型である opentype(J)。これは、OpenType のサブクラスのインスタンスです。
• 「マップされた」Java 型 opendata(J)。これはどの opentype(J) についても、1 つの opendata(J) に対しては常に同じです。これは Java クラスです。
• 値を J 型から opendata(J) 型に変換する方法。
• 値を opendata(J) 型から J 型に変換する方法 (可能な場合)。

たとえば、Java 型 List<String> について考えてみましょう。

• 公開型、opentype(List<String>) は ArrayType(1, SimpleType.STRING) であり、1 次元の String 配列を表します。
• マップされた Java 型、opendata(List<String>) は String[] です。
• List<String> は、List.toArray(new String[0]) を使って String[] に変換できます。
• String[] は、Arrays.asList を使って List<String> に変換できます。

J から opentype(J) を派生させるマッピングルールが存在しない場合、J を MXBean インタフェース内のメソッドパラメータまたは戻り値の型にすることはできません。

opendata(J) を J に再変換する方法がある場合、J は「再構築可能」であると言います。MXBean インタフェース内のすべてのメソッドパラメータは、再構築可能でなければなりません。これは、MXBean フレームワークがメソッドを呼び出す際に、これらのパラメータを opendata(J) から J に変換する必要があるためです。JMX.newMXBeanProxy により生成されたプロキシでは、これは、再構築可能でなければならない MXBean インタフェース内のメソッドの戻り値です。

null 値を使用できないプリミティブ Java 型を除く、すべての Java 型と公開型で、null 値が許可されます。J 型を opendata(J) 型に変換したり、opendata(J) 型を J 型に変換する場合は、null 値と null 値がマッピングされます。

次の表に、型マッピングルールの概要を示します。

Java 型 J	opentype(J)	opendata(J)
int、boolean など (8 つのプリミティブ Java 型)	SimpleType.INTEGER、 SimpleType.BOOLEAN など	Integer、Boolean など (対応する boxed 型)
Integer、ObjectName など (SimpleType の適用範囲内の型)	対応する SimpleType	J、同じ型
int[] など (プリミティブ要素型の 1 次元配列)	ArrayType.getPrimitiveArrayType(int[].class) など	J、同じ型
E[] (非プリミティブ要素型 E の配列、int[][] を含む。E は int[])	ArrayType.getArrayType(opentype(E))	opendata(E)[]
List<E> Set<E> SortedSet<E> (下記を参照)	E[] に対するものと同じ	E[] に対するものと同じ
列挙 E (Java 内で enum E {...} として宣言される)	SimpleType.STRING	String
Map<K,V> SortedMap<K,V>	TabularType (下記を参照)	TabularData (下記を参照)
MXBean インタフェース	SimpleType.OBJECTNAME (下記を参照)	ObjectName (下記を参照)
その他の型	可能な場合には CompositeType (下記を参照)	CompositeData

以降の節では、これらのルールについて詳しく説明します。

プリミティブ型のマッピング

8 つのプリミティブ Java 型 (boolean、byte、short、int、long、float、double、char) は、java.lang から Boolean、Byte などの対応する boxed 型にマッピングされます。公開型は、対応する SimpleType です。このため、opentype(long) は SimpleType.LONG に、opendata(long) は java.lang.Long になります。

long[] などのプリミティブ型の配列は、公開型として直接表現できます。このため、openType(long[]) は ArrayType.getPrimitiveArrayType(long[].class) に、opendata(long[]) は long[] になります。

JMX API 内の演算はプリミティブではなく常に Java オブジェクト上で実行されるため、実際には、プレーンな int と Integer の違いなどが明確になることはありません。ただし、配列で違いが明らかになります。

コレクションのマッピング (List<E> など)

List<E> や Set<E> (List<String> や Set<ObjectName> など) のマッピング方法は、同じ要素型の配列 (String[] や ObjectName[] など) と同じです。

SortedSet<E> も E[] と同じ方法でマッピングされます。ただし、これが変換可能なのは、E が Comparable を実装するクラスまたはインタフェースである場合だけです。このため、SortedSet<String> や SortedSet<Integer> は変換可能ですが、SortedSet<int[]> や SortedSet<List<String>> は変換不可能です。SortedSet インスタンスの変換は、null 以外の comparator() が存在すると、IllegalArgumentException をスローして失敗します。

List<E> は java.util.ArrayList<E> として、Set<E> は java.util.HashSet<E> として、SortedSet<E> は java.util.TreeSet<E> としてそれぞれ再構築されます。

マップのマッピング (Map<K,V> など)

Map<K,V> または SortedMap<K,V> (Map<String,ObjectName> など) は、公開型 TabularType を持ち、TabularData にマッピングされます。TabularType には、key および value という名前の 2 つの項目が含まれます。key の公開型は opentype(K)、value の公開型は opentype(V) です。TabularType のインデックスは、単一の項目 key です。

たとえば、Map<String,ObjectName> の TabularType は、次のようなコードを使って構築できます。

String typeName =
"java.util.Map<java.lang.String, javax.management.ObjectName>";
String[] keyValue =
new String[] {"key", "value"};
OpenType[] openTypes =
new OpenType[] {SimpleType.STRING, SimpleType.OBJECTNAME};
CompositeType rowType =
new CompositeType(typeName, typeName, keyValue, keyValue, openTypes);
TabularType tabularType =
new TabularType(typeName, typeName, rowType, new String[] {"key"});
    

typeName は、次に詳述する型名ルールに従って決定されます。

SortedMap<K,V> は同じ方法でマッピングされます。ただし、これが変換可能なのは、K が Comparable を実装するクラスまたはインタフェースである場合だけです。このため、SortedMap<String,int[]> は変換可能ですが、SortedMap<int[],String> は変換不可能です。SortedMap インスタンスの変換は、null 以外の comparator() が存在すると、IllegalArgumentException をスローして失敗します。

Map<K,V> は java.util.HashMap<K,V> として、SortedMap<K,V> は java.util.TreeMap<K,V> としてそれぞれ再構築されます。

TabularData はインタフェースです。Map<K,V> を公開データとして表現するのに使用される具象クラスは TabularDataSupport、または TabularDataSupport として直列化する TabularData を実装する別のクラスです。

MXBean インタフェースのマッピング

MXBean インタフェース、または MXBean インタフェース内部で参照される型は、別の MXBean インタフェース J を参照できます。この場合、opentype(J) は SimpleType.OBJECTNAME、opendata(J) は ObjectName です。

たとえば、次のような 2 つの MXBean インタフェースが存在する場合を考えましょう。

public interface ProductMXBean {
public ModuleMXBean[] getModules();
}

public interface ModuleMXBean {
public ProductMXBean getProduct();
}
    

ModuleMXBean インタフェースを実装するオブジェクトは、その getProduct メソッドから、ProductMXBean インタフェースを実装するオブジェクトを返します。ModuleMXBean オブジェクトと返される ProductMXBean オブジェクトの両方を、同じ MBean Server の MXBean として登録する必要があります。

ModuleMXBean.getProduct() メソッドは、Product という名前の属性を定義します。この属性の公開型は SimpleType.OBJECTNAME です。対応する ObjectName 値は、参照される ProductMXBean が MBean Server 内で登録される名前になります。

ModuleMXBean 用の MXBean プロキシを作成して、その getProduct() メソッドを呼び出す場合、別の MXBean プロキシを作成することにより、プロキシが ObjectName を ProductMXBean に再度マッピングします。つまり、JMX.newMXBeanProxy(mbeanServerConnection, objectNameX, interfaceX) を使って作成されたプロキシが objectNameY を別の MXBean インタフェースである interfaceY に再度マッピングする必要がある場合、JMX.newMXBeanProxy(mbeanServerConnection, objectNameY, interfaceY) が使用されます。この実装では、同じパラメータを使って JMX.newMXBeanProxy を呼び出すことで、以前に作成されたプロキシが返されることがあります。また、新規プロキシが作成されることもあります。

ModuleMXBean インタフェースを次のように変更することで、逆マッピングを実行できます。

public interface ModuleMXBean {
public ProductMXBean getProduct();
public void setProduct(ProductMXBean c);
}
    

setProduct メソッドの存在は、Product 属性が読み取り/書き込みであることを示します。以前と同様に、この属性の値は ObjectName になります。この属性を設定する場合は、ObjectName を setProduct メソッドで必要な ProductMXBean オブジェクトに変換します。このオブジェクトは、同じ MBean Server 内の指定された ObjectName の MXBean プロキシになります。

{ModuleMXBean 用の MXBean プロキシを作成してその setProduct メソッドを呼び出す場合、プロキシはその ProductMXBean 引数を ObjectName に再度マッピングします。これが機能するのは、引数が実際に、同じ MBeanServerConnection 内の ProductMXBean に対応する別のプロキシである場合だけです。プロキシは、別のプロキシから返されることがあります (たとえば、ModuleMXBean.getProduct() は ProductMXBean 用のプロキシを返す)。また、JMX.newMXBeanProxy により作成されることも、MBeanServerInvocationHandler またはサブクラスである呼び出しハンドラを持つ Proxy を使って作成されることもあります。

2 つの異なる ObjectName に同じ MXBean が登録されていると、別の MXBean からその MXBean への参照があいまいになります。このため、MBean Server に登録済みの MXBean オブジェクトを、別の名前で同じ MBean Server に登録しようとすると、InstanceAlreadyExistsException がスローされます。一般に、1 つの MBean オブジェクトを複数の名前で登録することは避けてください。特に、NotificationBroadcaster である MBean では、正しく動作しません。

その他の型のマッピング

Java クラスやインタフェース J が上記の表に示したそのほかのルールに当てはまらない場合、次に示すように、MXBean フレームワークにより CompositeType へのマッピングが試みられます。この CompositeType の型名は、次の型名ルールに従って決定されます。

取得メソッドのクラスは、上記の規則を使って検査されます(取得メソッドは public インスタンスメソッドでなければならない)。取得メソッドが存在しないか、取得メソッドの型が変換不可能な場合、J は変換不可能です。

1 つ以上の取得メソッドが存在し、どの取得メソッドにも変換可能な型が存在する場合、opentype(J) は各取得メソッド用の項目を 1 つ保持する CompositeType です。次の取得メソッドの場合、

T getName()

CompositeType 内の項目は name と呼ばれ、opentype(T) 型を持ちます。たとえば、次の項目の場合、

String getOwner()

項目は owner と呼ばれ、公開型 SimpleType.STRING を持ちます。次の取得メソッドの場合、

boolean isName()

CompositeType 内の項目は name と呼ばれ、SimpleType.BOOLEAN 型を持ちます。

最初の文字 (コードポイント) が、小文字に変換されることに留意してください。これは Java Beans の規則に従っています。歴史的な理由から、これは Standard MBean の規則とは異なります。Standard MBean または MXBean インタフェースでは getOwner メソッドは Owner という名前の属性を定義し、Java Bean またはマップされた CompositeType では getOwner メソッドは owner という名前のプロパティーまたは項目を定義します。

2 つのメソッドが同じ項目名を生成する場合 (getOwner と isOwner、getOwner と getowner など)、型の変換は不可能です。

公開型が CompositeType の場合、対応するマップされた Java 型 (opendata(J)) は CompositeData になります。J のインスタンスから、上記の CompositeType に対応する CompositeData へのマッピングは、次のように実行されます。最初に、J が CompositeDataView インタフェースを実装する場合、そのインタフェースの toCompositeData メソッドが呼び出されて、変換が実行されます。それ以外の場合は、項目ごとに取得メソッドを呼び出して対応する公開データ型に変換することにより、CompositeData が構築されます。これにより、次のような取得メソッドが、

List<String> getNames()

名前「names」および公開型 ArrayType(1, SimpleType.STRING) の項目にマッピングされます。CompositeData への変換により getNames() が呼び出され、生成された List<String> が項目「names」の String[] に変換されます。

CompositeData はインタフェースです。型を公開データとして表現するのに使用される具象クラスは、CompositeDataSupport または CompositeDataSupport として直列化する CompositeData を実装する別のクラスです。

CompositeData から Java 型 J のインスタンスを再構築する

opendata(J) が Java 型 J の CompositeData である場合、J のインスタンスを CompositeData から再構築可能であるか、J は再構築不可能であるかのどちらかになります。CompositeData 内のいずれかの項目が再構築不可能である場合、J も再構築不可能です。

指定した任意の J に関して、CompositeData から J のインスタンスを再構築する際、次のルールが適用されます。リスト内で適用可能な最初のルールが使用されます。

1. J が
   public static J from(CompositeData cd) メソッドを持つ場合、
   そのメソッドを呼び出すことで J のインスタンスが再構築されます。

2. それ以外で、J が ConstructorProperties 注釈を含む 1 つ以上の public コンストラクタを持つ場合は、これらのコンストラクタの 1 つ (常に同じコンストラクタである必要はない) を呼び出して、J のインスタンスが再構築されます。これらのすべての注釈は、コンストラクタが持つパラメータと同じだけの文字列をリストに含める必要があります。各文字列は J の取得メソッドに対応するプロパティーの名前にします。この取得メソッドの型は、対応するコンストラクタパラメータと同じにする必要があります。ConstructorProperties 注釈に記述されていない取得メソッドが存在するとしても、それはエラーではありません。これらは、オブジェクトの再構築には不要な情報に関連したメソッドである可能性があります。

   J のインスタンスは、CompositeData から再構築された適切な項目を使ってコンストラクタを呼び出すことで再構築されます。この CompositeData は、一部の項目が存在していなかった以前のバージョンの J に由来するものである可能性があります。このため、呼び出されるコンストラクタは、CompositeData 内に実在する項目に基づいて実行時に決定されます。コンストラクタが「適用可能」になるのは、ConstructorProperties 注釈に記載されたすべてのプロパティーが CompositeData 内に項目として存在する場合です。適用可能なコンストラクタが存在しない場合は、J を再構築する試みは失敗します。

   プロパティーを任意に組み合わせる場合は、次のいずかが当てはまります。(a) 適用可能なコンストラクタが存在しない、(b) 適用可能なコンストラクタが 1 つだけ存在する、(c) 適用可能なコンストラクタの 1 つが、ほかの適用可能な各コンストラクタが指定したプロパティーの適切なスーパーセットを指定する。つまり、選択するコンストラクタに関してあいまいさは存在しないことになります。この条件が true でない場合、J は再構築可能ではありません。

3. それ以外で、J が引数のない public コンストラクタを持ち、型が T で名前が N の J 内の各取得メソッドに対して同じ名前と型の対応する設定メソッドが存在する場合は、J のインスタンスが引数のないコンストラクタを使って構築され、設定メソッドが CompositeData から再構築された項目を使って呼び出されて値が復元されます。たとえば、
   public List<String> getNames() メソッドが存在する場合、
   このルールが適用される
   public void setNames(List<String> names) メソッドも
   存在する必要があります。

   CompositeData が J の以前のバージョンに基づく場合、一部の項目が存在しない可能性があります。この場合、対応する設定メソッドは呼び出されません。

4. それ以外で、J が取得メソッド以外のメソッドを持たないインタフェースである場合、J のインスタンスは、Proxy を使って構築されます。その際、変換対象の CompositeData を利用する CompositeDataInvocationHandler が使用されます。

5. それ以外の場合、J は再構築不可能です。

以下の例では、int および String で構成される NamedNumber 型をコーディングするいくつかの方法を示します。いずれの場合でも、CompositeType は次のようになります。

CompositeType(
    "NamedNumber",                      // typeName
    "NamedNumber",                      // description
    new String[] {"number", "name"},    // itemNames
    new String[] {"number", "name"},    // itemDescriptions
    new OpenType[] {SimpleType.INTEGER,
                    SimpleType.STRING}  // itemTypes
);
      

1. sｔatic from メソッド:

   public class NamedNumber {
       public int getNumber() {return number;}
       public String getName() {return name;}
       private NamedNumber(int number, String name) {
           this.number = number;
           this.name = name;
       }
       public static NamedNumber from(CompositeData cd) {
           return new NamedNumber((Integer) cd.get("number"),
                                  (String) cd.get("name"));
       }
       private final int number;
       private final String name;
   }
             

2. @ConstructorProperties 注釈を含む public コンストラクタ:

   public class NamedNumber {
       public int getNumber() {return number;}
       public String getName() {return name;}
       @ConstructorProperties({"number", "name"})
       public NamedNumber(int number, String name) {
           this.number = number;
           this.name = name;
       }
       private final int number;
       private final String name;
   }
             

3. 各取得メソッド用の設定メソッド:

   public class NamedNumber {
       public int getNumber() {return number;}
       public void setNumber(int number) {this.number = number;}
       public String getName() {return name;}
       public void setName(String name) {this.name = name;}
       public NamedNumber() {}
       private int number;
       private String name;
   }
             

4. 取得メソッドのみを持つインタフェース:

   public interface NamedNumber {
       public int getNumber();
       public String getName();
   }
             

データのコレクションを表現するだけのクラスは、通常、「不変」にしておくことをお勧めします。不変クラスのインスタンスは、構築後に変更することはできません。CompositeData 自体は不変であることに留意してください。不変であることには多数の利点があります。特にスレッドの安全性やセキュリティー面で大きなメリットがあります。このため、設定メソッドの使用は、可能な場合は避けるようにしてください。

再帰型

再帰 (自己参照) 型を MXBean インタフェース内で使用することはできません。これは、CompositeType の不変性によるものです。たとえば、次の型は自身を参照するため、属性の型になることはできません。

public interface Node {
public String getName();
public int getPriority();
public Node getNext();
}

このような再帰型を書き換えて、再帰型でなくすることはいつでも可能です。それには、新しい型を導入することが必要な場合があります。次に例を示します。

public interface NodeList {
public List<Node> getNodes();
}

public interface Node {
public String getName();
public int getPriority();
}

MXBean に対応した MBeanInfo の内容

MXBean は、Open MBean の一種です。ただし、互換性を維持するため、MBeanInfo は OpenMBeanInfo と異なっています。特に、属性、パラメータ、オペレーションの戻り値の型が int などのプリミティブ型または void (戻り値の型) である場合、属性、パラメータ、オペレーションはそれぞれ MBeanAttributeInfo、MBeanParameterInfo、MBeanOperationInfo で表されます。これらの getType() または getReturnType() はプリミティブ名 (int など) を返します。上記のマッピングルールで、opendata マッピングがラップされる型 (Integer など) と指定される場合でも、これは当てはまります。

MXBean の MBeanInfo.getConstructors() が返す public コンストラクタの配列 (MBean Server に直接登録される) には、その MXBean の public コンストラクタがすべて含まれます。MXBean のクラスが public ではない場合、コンストラクタも public でないとみなされます。StandardMBean クラスを使って構築される MXBean に対して返されるリストは、Standard MBean と同じ方法で取得されます。MXBean の構築方法に関係なく、コンストラクタパラメータは MXBean マッピングルールの影響を受けず、対応する OpenType を持ちません。

MBean Server 内に直接登録される MXBean が NotificationBroadcaster インタフェースを実装しない場合、その MXBean の MBeanInfo.getNotifications() が返す通知型の配列は空になります。それ以外の場合、これは、MXBean の登録時に NotificationBroadcaster.getNotificationInfo() を呼び出した結果になります。その後、このメソッドの結果が変わっても、MBeanInfo.getNotifications() の結果は変わりません。StandardMBean または StandardEmitterMBean クラスを使って構築される MXBean に対して返されるリストは、Standard MBean と同じ方法で取得されます。

MBeanInfo に含まれるすべての MBeanAttributeInfo、MBeanParameterInfo、および MBeanOperationInfo オブジェクトの Descriptor は、上記のマッピングルールで指定された OpenType を値とするフィールド openType を持ちます。このため、getType() が「int」 であっても、getDescriptor().getField("openType") は SimpleType.INTEGER になります。

これらの各オブジェクトの Descriptor も、MXBean インタフェース内に表示される Java 型を表す文字列である originalType フィールドを持ちます。この文字列の書式については、次の「型名」を参照してください。

MBeanInfo の Descriptor は、文字列「true」を値とする mxbean フィールドを持ちます。

型名

MXBean 内のメソッドパラメータや戻り値のマップされていない型 T を文字列として表現することが必要な場合があります。T が総称型でない場合、この文字列は Class.getName() により返される値になります。それ以外の場合、これは genericstring(T) の値になります。次にこの定義を示します。

• T が総称型でも配列型でもない場合、genericstring(T) は Class.getName() により返される値になります ("int"、"java.lang.String" など)。
• T が配列 E[] である場合、genericstring(T) は genericstring(E) のあとに "[]" を付加したものになります。たとえば、genericstring(int[]) は "int[]"、genericstring(List<String>[][]) は "java.util.List<java.lang.String>[][]" になります。
• それ以外の場合、T は、List<String> などのパラメータ化された型になります。 genericstring(T) はClass.getName() により返されるパラメータ化された型の完全指定名、左山括弧 ("<")、genericstring(A) (A は最初の型パラメータ)、2 番目の型パラメータ B が存在する場合は ", " (コンマと空白文字 1 つ) と genericstring(B)、および右山括弧 (">") で構成されます。

メソッドが int[] を返す場合は、これは、Class.getName() により返される文字列 "[I" で表されます。ただし、メソッドが List<int[]> を返す場合、これは文字列 "java.util.List<int[]>" で表されます。

例外

Java 型から公開型へのマッピングで問題が発生すると、OpenDataException により通知されます。これは、取得メソッドを持たない java.util.Random などの型を参照する場合など、MXBean インタフェースの分析中に発生することがあります。また、インスタンスの変換中 (MXBean 内のメソッドからの戻り値または MXBean プロキシ内のメソッドへのパラメータ) に発生することもあります。たとえば、SortedSet が null 以外の Comparator を持つ場合に、SortedSet<String> から String[] に変換するときに発生します。

公開型から Java 型へのマッピングで問題が発生すると、InvalidObjectException により通知されます。これは、再構築可能な型が必須のコンテキストで、上記のルールに従うと「再構築可能」ではない型を参照する場合など、MXBean インタフェースの分析中に発生することがあります。また、該当する名前の Enum 定数が存在しない状況で String から Enum への変換を行う場合のように、インスタンスの変換中 (MXBean 内のメソッドへのパラメータまたは MXBean プロキシ内のメソッドからの戻り値) に発生することもあります。

コンテキストに応じて、OpenDataException または InvalidObjectException を、RuntimeMBeanException や UndeclaredThrowableException などの別の例外内にラップできます。スローされる例外それぞれで、条件 C が true になります。"e は OpenDataException と InvalidObjectException のいずれか適切な方です。また、C は e.getCause()" の true です。

導入されたバージョン:

1.6

任意要素の概要

boolean

value 注釈付きインタフェースが MXBean インタフェースである場合、true になります。

value

public abstract boolean value

注釈付きインタフェースが MXBean インタフェースである場合、true になります。

戻り値:

注釈付きインタフェースが MXBean インタフェースである場合は true

デフォルト:

true