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 Wed, 28 Feb 2007 14:03:30 GMT

Ok, thanks.

I wonder, how should stub methods (for 3.) be implemented?
Should they return null, or throw
java.lang.UnsupportedOperationException or throw
org.apache.harmony.luni.util.NotImplementedException?

 Vasily


-----Original Message-----
From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com] 
Sent: Wednesday, February 28, 2007 3:21 PM
To: dev@harmony.apache.org
Subject: Re: Netbeans addresses RI-specific fields

I agree with such kind of resolution.

SY, Alexey

2007/2/28, Zakharov, Vasily M <vasily.m.zakharov@intel.com>:
> 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