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 Mon, 05 Mar 2007 13:52:17 GMT

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.


>-----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
>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 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

View raw message