Bug 40897

There has already been discussion on this issue on the project mailing list.
here's the email thread:

----------------------------------------------------------------------------
Hi Sean,

The penalty hit is taken when the strings are not equal, sadly of the
same length.
And have a lot of common begging characters. That is sadly a common
problem with namespaces URI, they are more or less equal in length and
have a lot of damn http://.../... or urn:....: whatever at the
begining. And that is why Xerces and other DOM implementations  intern
namespaces URI.

I have profile and it takes a lot of time.
My point is that all the parsers I know do the intern (or it did when
I do the implementation). And this is an old commit 8 months old(it is
true that it is not yet on a official release), and it takes a
measurable hit if not use in small messages(the kind of one that are
in xml protocols).

So I will first check other options (change the configuration of the
offending parser with a
feature[http://xerces.apache.org/xerces2-j/features.html] ).
If it does not work I will change from == to equals, but I will let
this as last resort.

On 10/5/06, Sean Mullan <Sean.Mullan@sun.com> wrote:
> String.equals will work for both interned and non-interned Strings,
> since it first checks if they are a reference to the same object. So
> using String.equals seems safer and should be comparable performance I
> would think. But maybe I'm missing something?
>
> --Sean
>
> Vishal Mahajan wrote:
> > Do others also have views on this discussion?
> >
> > Thanks,
> > Vishal
> >
> > Vishal Mahajan wrote:
> >> Hi Raul,
> >>
> >> The parser that I am working with clearly doesn't intern element
> >> namespace strings which is the reason I ran into this problem. And
> >> actually I am not sure whether it's a good idea for a parser to intern
> >> element namespace strings given that there could be huge number of
> >> elements being parsed and there's a potential risk of running out of
> >> memory. Also you mention that xerces might be interning namespace
> >> stings but looking at their code I was unable to find that. Can you
> >> point me to the relevant piece of code?
> >>
> >> Thanks,
> >>
> >> Vishal
> >>
> >> Raul Benito wrote:
> >>> Vishal the problem is that this codes is called gazillion of times,
> >>> and even it
> >>> seems a small thing, it takes a lot of accumulated time, I even think
> >>> in remove this checking altogether or control it by a property.
> >>> Perhaps there is a feature set in your DOM parser that interns the
> >>> namespaces. I have test with several DOM parsers (xerces, xmlbeans,
> >>> jaxb) and all of them the namespaces strings are interns.
> >>> If you are not able too toggle the behavior, We can begin to think in
> >>> other possibilities (create code on the fly, create an interface with
> >>> one implementation or the other a let the JVM inline it). But I think
> >>> will be the last resort.
> >>>
> >>> Regards,
> >>> Raul
> >>>
> >>> On 10/2/06, Vishal Mahajan <vmahajan@amberpoint.com> wrote:
> >>>> Any signature verification was failing for me, and I have a different
> >>>> DOM implementation in my environment, so probably you are right. It was
> >>>> such a basic error that it had to be something like this. In any
> >>>> case, I
> >>>> think we should keep string comparison safe.
> >>>>
> >>>> Vishal
> >>>>
> >>>> Raul Benito wrote:
> >>>> > Hi Vishal,
> >>>> >
> >>>> > The namespaces strings are intern, at least in xerces.
> >>>> >
> >>>> > Can you post the code that is failing?
> >>>> >
> >>>> > On 10/2/06, Vishal Mahajan <vmahajan@amberpoint.com> wrote:
> >>>> >> This problem was not allowing successful creation of signature space
> >>>> >> elements. Fix attached.
> >>>> >>
> >>>> >> Vishal
----------------------------------------------------------------------------