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. <[EMAIL PROTECTED]>:
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
