harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: Netbeans addresses RI-specific fields
Date Sat, 03 Mar 2007 02:33:17 GMT
BTW, this class is serializable.

Does serial form include this field? (1.5 spec misses serial form, 1.3 spec
has that form but does not mention that field)

Thanks,
Mikhail

2007/3/3, Geir Magnusson Jr. <geir@pobox.com>:
> 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