Java's garbage collector never sets any normal reference to null. It is a
fundamental property of JVM.
This sentence
'in this case the GC was a little late in erasing what was released
across the request cycle'
is not true.
Your problem was not related to the garbage collector at all.
'collection' was set to null, because Tapestry always set component's
fields to their default values for every separate request.
See http://tapestry.apache.org/component-classes.html.
'@Persist' might cause your component to work, but I believe it can easily
create more problems for you in the longer term,
if you don't actually understand how it works and why it solves this
problem.
Whether an object pointed earlier by 'collection' become garbage or not,
and whether garbage was collected by GC or not,
it is irrelevant.
You mention Numega bound checker, so I guess that you used C or C++.
Java's memory management is different than C/C++, and many assumptions
based
on C/C++ experiences would be wrong with Java.
You must also understand that Tapestry applies many changes to page and
component classes in runtime,
so they don't work exactly as normal Java objects would work.
Best regards,
Cezary
On Fri, Oct 12, 2012 at 8:14 PM, Ken in Nashua <kcola...@live.com> wrote:
>
> yeah... the pointer to the collection wasnt null... it looked like a
> legitimate allocated collection with a hiberate entity in it.
> But as soon as i attempted to reference the collection in the event
> handler... boom... NPE
>
> a numega type bounds checker would flush something like this out by
> flooding free'd memory or erasing free'd memory with 0's as it gets
> released.
>
> in this case the GC was a little late in erasing what was released across
> the request cycle
>
> enough to give me the jeebies... but glad everything is fine now.
>
> thanks alot guys for your generosity
> its nice to know everything is good
>
> :)
>
