harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: Netbeans addresses RI-specific fields
Date Fri, 02 Mar 2007 18:47:10 GMT
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