Alexey, The bug against Netbeans is already there: http://www.netbeans.org/issues/show_bug.cgi?id=97017
But it could take months until it gets fixed and makes it to release. So probably adding a stub for sun.awt.AppContext class to make Netbeans compilable on Harmony is reasonable, isnt't it? (see http://issues.apache.org/jira/browse/HARMONY-3280) Vasily -----Original Message----- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 06, 2007 11:35 AM To: [email protected] Subject: RE: Netbeans addresses RI-specific fields Vasily, It looks like kitRegistryKey and kitTypeRegistryKey are similar to the fields where contentType => editorKit matching may be stored. They might substitute the original editorKits to their own one using this non-public API. I have no idea what sun.awt.AppContext class does. Additionally a value is taken from AppContext, and then put back but wrapped into another type. All the above are just my guesses from reading the source of EditorModule.java -- I don't know for sure. Since there's a comment about using AppContext class // XXX this is illegal! Must use reflection and have a proper fallback. I think the best thing we can do is file a bug to NetBeans, and do nothing on our part. Regards, Alexey. -- Alexey A. Ivanov Intel Enterprise Solutions Software Division >-----Original Message----- >From: Zakharov, Vasily M [mailto:[EMAIL PROTECTED] >Sent: Monday, March 05, 2007 6:49 PM >To: [email protected] >Subject: RE: Netbeans addresses RI-specific fields > >Alexey, > >Here's a characteristic usage case (I've simplified the code a bit): > > 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); > sun.awt.AppContext.getAppContext().put(key, new >HackMap(table)); > } catch (Throwable t) { > t.printStackTrace(); > } > >It's a kind of registration of JEditorPane instances in >sun.awt.AppContext class. > >The things occur in org.netbeans.modules.editor.EditorModule class: >http://www.netbeans.org/source/browse/editor/src/org/netbeans/modules/e d >itor/EditorModule.java?view=markup > >You can find all the occurences by searching the code for >"getDeclaredField" string. > >Thank you! > > Vasily > > >-----Original Message----- >From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] >Sent: Monday, March 05, 2007 4:52 PM >To: [email protected] >Subject: RE: Netbeans addresses RI-specific fields > >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: [email protected] >>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: [email protected] >>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
