This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 142468 - o.n.bootstrap/org.netbeans.JarClassLoader broke NB jMaki plugin
Summary: o.n.bootstrap/org.netbeans.JarClassLoader broke NB jMaki plugin
Status: RESOLVED INVALID
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-31 19:48 UTC by Ayub Khan
Modified: 2008-12-23 08:41 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ayub Khan 2008-07-31 19:48:09 UTC 
Recent change to Netbeans module o.n.bootstrap/org.netbeans.JarClassLoader broke
the jMaki NB plugin 1.7.3 that I am using with NB6.5 dev build. Here is the change

http://hg.netbeans.org/main/rev/e7036dc03341

Below is the exception while invoking Add JMaki Library:

INFO: org.netbeans.JarClassLoader.addSources(java.util.List)
java.lang.NoSuchMethodException:
org.netbeans.JarClassLoader.addSources(java.util.List)
	at java.lang.Class.getDeclaredMethod(Class.java:1909)
[catch] at
org.netbeans.modules.sun.jmaki.complib.RegisterLibrary.addResourcePaths(RegisterLibrary.java:224)


See jMaki issue for detail https://ajax.dev.java.net/issues/show_bug.cgi?id=360
Comment 1 Jesse Glick 2008-07-31 20:09:40 UTC 
I guess the jMaki plugin will need to do something else. Don't know why it was calling this undocumented and
package-private method to begin with. If you need to load resources from a JAR whose location can only be determined at
runtime, you can create a URLClassLoader etc.
Comment 2 _ ludo 2008-08-05 04:13:13 UTC 
Jesse, you are correct, we should not be doing that. We did it to bypass severe Nb Palette APIs.
We cannot find a way for the solution (see 
http://www.netbeans.org/issues/show_bug.cgi?id=93451
)
I wanted to removed the hack for 6.5. If you can find a solution to
http://www.netbeans.org/issues/show_bug.cgi?id=93451, I am happy to implement it. 
(I can forward internal emails for this request as well). Otherwise,  Nb 6.5 will not have jMaki support as opposed to
Eclipse 3.3 and 3.4.
The current NB Palette APIs(/and/or JSP/HTML usage of old APIS) are not good enough for advanced palette content
extension, and RFE are not getting traction given schedule constraints.

We could continue our hack (I understand now how to use introspection to change final variables, but it is not the way I
want to work). The RFE I ask to be filed on Palette is pretty old now...
Comment 3 Jesse Glick 2008-08-07 01:16:17 UTC 
Modifying a final variable is no worse a hack than calling a private method IMHO. At any rate, if you plan to do
something like that you must communicate with the owner of the affected code and make sure there is a way to maintain
the functioning of the hack and a plan to fix it properly in the future.

Standa has suggested some options in issue #93451 which I would encourage you to explore. You can certainly escalate the
issue if it is critical for shipping jMaki support. I don't know anything about the Palette APIs so I could not be much
help.