Re: [Jython-dev] cache design + ...

[<bc...@wo...>]

[Finn on how lazy and non-lazy loaded classes could be handled]

>... jpkg.Bean classes would not be interoperable, but
> lazily loaded class would work just like the ordinarily initialized
> classes.

[Samuele]

>Very good point, that was also my first design idea, then I found bad the loading 
>needed for the check, but up to performance is not that bad to load
>something that is somehow lazy loaded.
>Given the more complicated setup of load-sets (=> many classloaders) and if we want 
>lazy load also from them we will have to check a class against all possible
>lazy versions around.

Yes, that will make the implementation more complicated but still possible.

>And to deal with the case of lazy loading coming after the creation of
>a PyJavaClass from a true class. We will have to find all the classes
>with that name, and if this set is not empty we will have to force loading
>and do the checks also in this case.

Yes. I had forgotten that situation.

>So the principle: if there is a possible ambiguity around, we should force
>loading of lazy loaded stuff with the involved name and check.

Right. And I not concerned about the performance in this situation at all.

>> I agree with all of this. I'm unsure how we should maintain this list.
>> The CPython people have their PEP-0042 for this. 
>My suggestion (given the not so formal settings of jython development) is to
>create something like a moinmoin site, like the new Python2.0 Info Area,
>that's will be a good place for the FAQ because anyone can contribute
>and developers can if the case improve, rewrite not totally correct answers,
>and for feature requests and for keeping track of design discussions.
>That's just a suggestion.

I'll look into it. Thanks.

>Some of my proposal are clearly not small features: about that I can only say:
>* jythonc things are quite interesting, given the time and when more important things
>are solved I can try to do something, but the sematics question should be solved
>before.
>* for imputil/ihooks (personally I should first read both codes) maybe we should
> join import-sig and try to be helpful, or at least to clarify jython needs.
>* rexec/security architecture is really *hard*:
> e.g. java1.1 and java2 are different in that respect,
> and we should exploit seriously the java security arch otherwise
> any security effort/statement will be vague.

I'll look at this later. (I'm trying to focus on 20a1 for now)

regards,
finn