You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Zakharov, Vasily M" <va...@intel.com> on 2007/02/28 12:41:33 UTC
Netbeans addresses RI-specific fields
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
Re: Netbeans addresses RI-specific fields
Posted by Mikhail Loenko <ml...@gmail.com>.
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. <ge...@pobox.com>:
> 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
>
>
Re: Netbeans addresses RI-specific fields
Posted by Alex Astapchuk <al...@gmail.com>.
... better late than never :-)
Ivanov, Alexey A wrote:
> 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.
It seems (see [1], [2]) that AppContext is a part of security machinery
built in the swing. It seems it's about supporting several applets
running inside the same JVM with the swing/awt resources isolated from
each other.
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4168569
[2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6442752
The quote:
'All the static methods in Swing/AWT do not store their state in static
fields, rather the values are stored in the AppContext'
--
Yours faithfully,
Alex
> 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
>
Re: Netbeans addresses RI-specific fields
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
+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
RE: Netbeans addresses RI-specific fields
Posted by "Zakharov, Vasily M" <va...@intel.com>.
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
RE: Netbeans addresses RI-specific fields
Posted by "Ivanov, Alexey A" <al...@intel.com>.
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
RE: Netbeans addresses RI-specific fields
Posted by "Zakharov, Vasily M" <va...@intel.com>.
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/ed
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
RE: Netbeans addresses RI-specific fields
Posted by "Ivanov, Alexey A" <al...@intel.com>.
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
RE: Netbeans addresses RI-specific fields
Posted by "Zakharov, Vasily M" <va...@intel.com>.
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
Re: Netbeans addresses RI-specific fields
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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
RE: Netbeans addresses RI-specific fields
Posted by "Zakharov, Vasily M" <va...@intel.com>.
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:alexey.a.petrenko@gmail.com]
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 <va...@intel.com>:
> 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
>
Re: Netbeans addresses RI-specific fields
Posted by Alexey Petrenko <al...@gmail.com>.
I agree with such kind of resolution.
SY, Alexey
2007/2/28, Zakharov, Vasily M <va...@intel.com>:
> 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
>