To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102164
------- Additional comments from [email protected] Fri Sep 18 14:22:36 +0000 2009 ------- @mux2005: "a new thread is started for every call": No, it is a single (native) thread that makes multiple JNI calls to Java, one after another. Each such call must attach the thread to the JVM (and then detaches it again). "would it not be possible to set the context classloader at least for the non-application-controlled threads such as the event dispatching thread": No, that would not work or would not solve the problem. For one, those threads that now have a null context class loader are those attached to the JVM through incoming JNI calls and those in turn spawned from them; so, if there is a problem with the event dispatch thread having a null context class loader, this would imply the event dispatch thread was spawned from such a native thread attached to the JVM, so we would be back to square one. For another, some scenarios (like javax.xml.xpath.XPathFactory.newInstance() or new JEditorPane()) need not even happen in the event dispatch thread. The only two ways out I see are: 1 Back out the changes to jmvaccess::VirtualMachine::AttachGuard again for now (i.e., do set a context class loader for attached threads again) and either live with the performance degradation in Base for now or somehow modify Base so that it calls the AttachGuard not around individual Java calls, but around larger quantities of such calls combined (diminishing the negative impact of the setContextClassLoader call per AttachGuard creation). Later, once every code using the context class loader anywhere would be fixed properly, the backed-out changes could be put back into AttachGuard. 2 Back out the changes to jvmaccess::VirtualMachine::AttachGuard again and offer an additional interface ("jvmaccess::VirtualMachine::FastAttachGuard") that does not set the context class loader, and change the Base code to call FastAttachGuard instead of AttachGuard. I would prefer 1 over 2: In an ideal, correct world, we would only need the fixed version of AttachGuard (that does not set a context class loader). Solution 1 could be turned into such a solution once the world is cleaned up, by just changing the implementation of AttachGuard. Solution 2, on the other hand, would have to introduce a new FastAttachGuard as a sort of a hack to the stable URE API, and could not remove it again once it becomes unnecessary. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
