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 Sat, 03 Mar 2007 12:49:05 GMT

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.


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

View raw message