I'm a little unclear about what "Change fieldTypes to be Strings
instead" means. Do you mean the key in the map, or something?
One other solution would be to get rid of the Map and just use some
sort of weak Set, but lookups would need to iterate through the set
every time. I don't know what kind of performance hit this would incur.
The best solution would probably to just eliminate this (and all) non-
constant static fields. I remember trying very hard to do this some
time ago, but I kept hitting walls preventing the complete
elimination. Maybe smarter minds than me can figure it out, though.
On Jul 16, 2007, at 3:17 PM, robert burrell donkin wrote:
On 7/16/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
> Anyone have any ideas?
Change fieldTypes to be Strings instead, and dematerialize them as
needed.
after spending hundreds of hours pursuing other solutions to a similar
issue, i that this would be wise.
<rant>
sounds very similar to the infamous commons logging leak. after a
*lot* of work, Brian Stansberry wrote a custom hashtable
implementation which (after a lot of testing and rewriting) didn't
seem to leak with modern JVMs. we used reference queues and periodic
purging.
IMO the real problem is that the J2EE specification lacks application
life cycle events. i've heard of other leaks (eg when using
reflection) which are hard or impossible to fix. of course, it doesn't
help that the classloader specifications are broke too...
</rant>
- robert
