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