harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivanov, Alexey A" <alexey.a.iva...@intel.com>
Subject RE: Netbeans addresses RI-specific fields
Date Tue, 06 Mar 2007 08:35:01 GMT

It looks like kitRegistryKey and kitTypeRegistryKey are similar to the
fields where contentType => editorKit matching may be stored.

They might substitute the original editorKits to their own one using
this non-public API. I have no idea what sun.awt.AppContext class does.
Additionally a value is taken from AppContext, and then put back but
wrapped into another type.

All the above are just my guesses from reading the source of
EditorModule.java -- I don't know for sure.
Since there's a comment about using AppContext class

// XXX this is illegal! Must use reflection and have a proper fallback.

I think the best thing we can do is file a bug to NetBeans, and do
nothing on our part.


Alexey A. Ivanov
Intel Enterprise Solutions Software Division

>-----Original Message-----
>From: Zakharov, Vasily M [mailto:vasily.m.zakharov@intel.com]
>Sent: Monday, March 05, 2007 6:49 PM
>To: dev@harmony.apache.org
>Subject: RE: Netbeans addresses RI-specific fields
>Here's a characteristic usage case (I've simplified the code a bit):
>        try {
>            Field field =
>            field.setAccessible(true);
>            Object key = field.get(JEditorPane.class);
>            Hashtable table = (Hashtable)
>            sun.awt.AppContext.getAppContext().put(key, new
>        } 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:
>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
>If you could describe how NetBeans uses these fields, I could answer
>question whether there are similar fields in Harmony. My best guess is
>that there aren't.
>>-----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
>>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
>>the only impact on Harmony is a stack trace in the log file.
>>I'm not sure if kitRegistryKey and kitTypeRegistryKey fields in
>>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
>>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
>>> 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
>>>         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

View raw message