On Mon, Jul 13, 2009 at 7:09 AM, Martin Probst<mail_at_martin-probst.com> wrote:
>> AFAIK It is the looking up of the implementation that is expensive:
>
> Ah yes of course, I see. In that case it's pretty annoying that they
> didn't make them thread safe. Maybe (hopefully) the change in the
> JavaDoc is a progression in that direction ;-)
I am pretty sure JavaDoc is either incorrect, or just being too
conservative... it's very unfortunate of course.
Some other links that explain or refer to this overhead are:
http://www.servlets.com/archive/servlet/ReadMsg?msgId=484899&listName=servletexec-interest
https://forums.sdn.sap.com/message.jspa?messageID=7618662
it really is too bad that although service implementation discovery is
dynamic and flexible, it is inefficient enough to be considered
severely broken at this point. :-/
As far as I know, this code was originally from SAX, made its way into
JAXP, and has been copied in many other places since then (including
Stax, xpath provider etc. etc.)
This is also the reason why I usually explicitly define factory
implementation classes for services, to specifically instantiate
factory by class.newInstance(). This avoids expensive introspection,
but can still be configured externally if necessary.
Same can be achieved by using Java system properties too btw: this is
the first part of lookup, and definition does prevent use of slow
lookups.
-+ Tatu +-