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