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 mux2...@openoffice.org Thu Sep 17 09:19:51 +0000 2009 ------- Please reconsider the removal of the classloader setting code. The performance gains seem very dubious. It's unlikely that anything in the OOo context would spawn 1000s of threads which would be required to make the time savings visible on a macroscopic scale. Was this change triggered by actual results from *profiling* a real world use case? How large were the measured performance gains? If there were no actual measurements to justify the change this seems like a prime example of premature optimization (which as we all know is the root of all evil). Even if there are performance gains in some special situations, this has to be weighed against the negative consequences. As we can see from this issue you are buying your performance gains with complete breakage of existing components. Buying a little speed in a few use cases with complete breakage of widely deployed packages would be considered very unwise by most people. The worst thing is that this creates a permanent Sword of Damocles over the heads of Java component developers. There is no reason to expect that JEditorPane is the only code making the assumption that the context classloader is non-null. And there is no reason to expect that even if this bug is fixed in Swing it will not reoccur at some other place as code gets rewritten and added to the JRE. The Java execution environment OOo sets up with its null context classloader is obviously unusual, something not even the Java guys at Sun test for, not to speak of the many 3rd party libraries written by developers with even less knowledge of the hairy details of Java. And it cannot be emphasized enough that there is no general workaround for this problem (at least none has been mentioned here so far). There is no way I can simply set the context classloader of the EDT myself in my component. I've tried but it only works temporarily but gets reset at some point, which means I would need to sprinkle my code with classloader-setting code. And I have no way of knowing in which places it's needed. Swing and the JRE are moving targets. And if 3rd party libraries trigger this problem, there is no workaround at all, because I can't change the 3rd party library. So please back out that change until you can offer a reliable and generally applicable way for a Java component to ensure a non-null context classloader that includes 3rd party libraries. --------------------------------------------------------------------- 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: issues-unsubscr...@framework.openoffice.org For additional commands, e-mail: issues-h...@framework.openoffice.org --------------------------------------------------------------------- To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
