harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: Netbeans addresses RI-specific fields
Date Wed, 07 Mar 2007 15:30:25 GMT
+1

I think this is the only thing we can do.

geir

On Mar 6, 2007, at 4:11 AM, Zakharov, Vasily M wrote:

> 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:alexey.a.ivanov@intel.com]
> Sent: Tuesday, March 06, 2007 11:35 AM
> To: dev@harmony.apache.org
> 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:vasily.m.zakharov@intel.com]
>> Sent: Monday, March 05, 2007 6:49 PM
>> To: dev@harmony.apache.org
>> 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:alexey.a.ivanov@intel.com]
>> Sent: Monday, March 05, 2007 4:52 PM
>> To: dev@harmony.apache.org
>> 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:vasily.m.zakharov@intel.com]
>>> 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:geir@pobox.com]
>>> 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


Mime
View raw message