Potential `JavaMembers` deserialisation problem.

[aardvark179]

Because NativeJavaObject recreates its JavaMembers on deserialisation, and because JavaMembers itself can lookup function prototypes dynamically, there is the potential for it all to go very wrong by causing that part of an object graph to be deserialised before enough of the top level scope has been recreated for the prototype to actually be looked up.

I stumbled across this in my scopes refactoring, and I think the only way to resolve this properly is by serialising most of java members so that nothing is looked up dynamically in scopes.

Have I ever mentioned that I hate Java serialisation?

[ZZZank]

Will lazily load JavaMembers be helpful in this case? This will also allow us to pass an explicit scope to JavaMembers.lookupClass

[aardvark179]

I've gone for simply serialising them, because that turned out to be very simple.

[gbrail]

Thanks -- the lazy loading approach might make sense. Can both of you look at both PRs and see if you can reach a consensus as to the best solution? Thanks!