> -----Original Message-----
> From: Glen Mazza [mailto:[EMAIL PROTECTED]

<snip />
> Oh no, it wasn't--but we know the status quo *wasn't* acceptable, and
> that the performance argument was no longer valid because of the
> research you did on .equals().  Now you and Andreas can finish out the
> argument -- intern() or equals()? -- and if the former wins, just switch
> the code to intern().  If the latter wins, than do nothing, we're done.

It's not a question of which one 'wins' --on the FOP side. No noticeable
changes there, but I really saw no NEED whatsoever, to change it either.

The status quo wasn't acceptable to someone that is developing an
application embedding FOP, but from where we were standing, it was perfectly
acceptable to leave everything as is, and have Nils change his application
to feed interned strings to the relevant portions of our code, not?

Here it doesn't seem to matter all that much, but the main point is: we
can't just jump and change our code because *one* single user/developer has
a problem with it. Better to inform him/her on what else could be done to
avoid that problem.

If he has a problem with interning the strings, let HIM come up with
compelling arguments/figures/numbers to persuade US. At least, we'll all
learn from it.

But to make changes so quickly, based on a rough description of one
scenario? --I dunno



Reply via email to