harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zakharov, Vasily M" <vasily.m.zakha...@intel.com>
Subject RE: Netbeans addresses RI-specific fields
Date Mon, 05 Mar 2007 15:49:11 GMT
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:alexey.a.ivanov@intel.com] 
Sent: Monday, March 05, 2007 4:52 PM
To: dev@harmony.apache.org
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:vasily.m.zakharov@intel.com]
>Sent: Saturday, March 03, 2007 3:49 PM
>To: dev@harmony.apache.org
>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:geir@pobox.com]
>Sent: Friday, March 02, 2007 9:47 PM
>To: dev@harmony.apache.org
>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

Mime
View raw message