xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <grm7...@yahoo.com>
Subject Re: String.intern() thoughts
Date Mon, 01 Dec 2003 22:16:06 GMT
--- "J.Pietschmann" <j3322ptm@yahoo.de> wrote:
> Glen Mazza wrote:
> > No need-the "gotcha" site you gave earlier did
> give
> > some specific drawbacks under string compares:  
> > 
> > http://mindprod.com/jgloss/gotchas.html#COMPARISON
> That's not a drawback. Interned strings allow
> comparision of
> references:
>    String a="a".intern();
>    String b="a".intern();
>    if(a==b) { System.out.println("equal"); }
> With non-interned strings you need a.equals(b),
> which
> may be slower, for longer strings anyway.
> The most important gotcha is that interned strings
> may lock
> up memory forever. 

Yes, I may have misread that--outside of the fact that
strings are not GC'ed away, the intern() function does
not look that bad (their mention of a possible 64K
limit may be an issue if we also keep property values,
however.)  Still, I still don't know enough at this
stage to rule out any particular design.

> If interning is done only for
> property
> names and enumeration tokens (in contrast to
> property values),
> this may be acceptable.

If we just do that, I believe we're back to
enumeration tokens, which don't need intern() anyway.

I think the next thing to consider is the storage of
specified vs. computed values.  Let's say we store
pointers for many properties to the same
{"property-name", "property-value"} pair.  A specified
property value of "10%" would not make this a very
helpful data structure if that percentage resolves to
different computed values for each property sharing
this pair.  I believe the goal for us then would be
just store the computed value for each pair (meaning
many more pairs), as long as we take into account the


Do you Yahoo!?
Free Pop-Up Blocker - Get it now

View raw message