Vasily, If you could describe how NetBeans uses these fields, I could answer the question whether there are similar fields in Harmony. My best guess is that there aren't.
Regards, Alexey. >-----Original Message----- >From: Zakharov, Vasily M [mailto:[EMAIL PROTECTED] >Sent: Saturday, March 03, 2007 3:49 PM >To: dev@harmony.apache.org >Subject: RE: Netbeans addresses RI-specific fields > > >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 >correct, >the only impact on Harmony is a stack trace in the log file. > >I'm not sure if kitRegistryKey and kitTypeRegistryKey fields in >JEditorPane >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. > > Vasily > > >-----Original Message----- >From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] >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 >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
