Alexey,
Here's a characteristic usage case (I've simplified the code a bit):
try {
Field field =
JEditorPane.class.getDeclaredField("kitRegistryKey");
field.setAccessible(true);
Object key = field.get(JEditorPane.class);
Hashtable table = (Hashtable)
sun.awt.AppContext.getAppContext().get(key);
sun.awt.AppContext.getAppContext().put(key, new
HackMap(table));
} catch (Throwable t) {
t.printStackTrace();
}
It's a kind of registration of JEditorPane instances in
sun.awt.AppContext class.
The things occur in org.netbeans.modules.editor.EditorModule class:
http://www.netbeans.org/source/browse/editor/src/org/netbeans/modules/ed
itor/EditorModule.java?view=markup
You can find all the occurences by searching the code for
"getDeclaredField" string.
Thank you!
Vasily
-----Original Message-----
From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED]
Sent: Monday, March 05, 2007 4:52 PM
To: [email protected]
Subject: RE: Netbeans addresses RI-specific fields
Vasily,
If you could describe how NetBeans uses these fields, I could answer the
question whether there are similar fields in Harmony. My best guess is
that there aren't.
Regards,
Alexey.
>-----Original Message-----
>From: Zakharov, Vasily M [mailto:[EMAIL PROTECTED]
>Sent: Saturday, March 03, 2007 3:49 PM
>To: [email protected]
>Subject: RE: Netbeans addresses RI-specific fields
>
>
>They do NOT DEPEND on those things. They access them through reflection
>if they're available and catch all exceptions if not. Looks like they
>just set some RI-appopriate flags. The code is generally safe and
>correct,
>the only impact on Harmony is a stack trace in the log file.
>
>I'm not sure if kitRegistryKey and kitTypeRegistryKey fields in
>JEditorPane
>have something similar in our implementation, I'm not a Swing guru.
>And also I'm not sure we have something like sun.awt.AppContext those
>fields are used with.
>
> Vasily
>
>
>-----Original Message-----
>From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
>Sent: Friday, March 02, 2007 9:47 PM
>To: [email protected]
>Subject: Re: Netbeans addresses RI-specific fields
>
>I think also that :
>
>1) you might want to submit a bug to Netbeans asking them not to do
>stupid things like depend on private fields of a public API
>
>2) is "kitRegistryKey" something obvious that a reasonable
>implementation requires? IOW, does Harmony also have a similar
>structure, and can we simply rename it to keep the netBeans log noise
>down?
>
>
>On Feb 28, 2007, at 3:41 AM, Zakharov, Vasily M wrote:
>
>> Hi, all,
>>
>> I'm trying to run Netbeans on Harmony, and found an issue that I'm
not
>> sure how to deal with.
>>
>> Netbeans addresses private fields (JEditorPane.kitRegistryKey,
>> JEditorPane.kitTypeRegistryKey) and classes (sun.awt.AppContext)
>> existing in RI only.
>>
>> The code containing those references is generally equivalent to this:
>>
>> try {
>> Field field =
>> JEditorPane.class.getDeclaredField("kitRegistryKey");
>> field.setAccessible(true);
>> Object key = field.get(JEditorPane.class);
>> Hashtable table = (Hashtable)
>> sun.awt.AppContext.getAppContext().get(key);
>> } catch (Throwable t) {
>> t.printStackTrace();
>> }
>>
>> The code works ok if those RI-specific fields/classes are not found
>> (e.
>> g. on Harmony) as all the exceptions are caught.
>>
>> However, nasty NoSuchFieldException stack traces appear in Netbeans
>> log
>> file, and may make someone think that there is a bug in Harmony.
>>
>> Also, the code above won't compile if someone wants to build
>> Netbeans on
>> Harmony from sources, as sun.awt.AppContext class name is hardcoded.
>>
>> So, my suggestions are:
>>
>> 1. File a bug to Netbeans and suggest replacing hardcoded
>> sun.awt.AppContext class name with a reflection call:
>>
>> Class appContextClass = Class.forName("sun.awt.AppContext");
>> Hashtable table = (Hashtable)
>> appContextClass.getMethod("get", new Class[] {
>> Object.class }).invoke(
>> appContextClass.getMethod("getAppContext",
>> (Class[]) null).invoke(
>> null, (Object[]) null), new Object[]
{
>> key });
>>
>> 2. File a JIRA to Harmony to make sure this problem is not
>> forgotten and
>> is easily searchable and recognizable in future.
>>
>> 3. Propose a workaround patch to the JIRA above to include a
>> non-functional stub for sun.awt.AppContext to suncompat module, for
>> this
>> issue to not prevent Netbeans from compiling on Harmony.
>>
>> Any opinions, suggestions, objections?
>>
>> Vasily Zakharov
>> Intel ESSD
