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

[Samuele P. <pe...@in...>]

Hi.

[Finn]
> Let us for a moment say that we disable lazy loading. Each class in the
> class list will then be resolved (through Py.findClassEx I think) into a
> Class instance and the PyJavaClass will be complete including the link
> from Class to PyJavaClass in PyJavaClass.classes.
> 
> When we in this theoretical senary receive the inst0 instance from the
> java side its class either match an entry in PyJavaClass.classes and if
> it does not match, we create a new entry with inst.getClass() as key.
> 
> So, lets add lazy loading. We now have an PyJavaClass.classes dict that
> looks something like this:
> 
>   {
>      org.python.core.PyJavaClass.class : PyJavaClass(PyJavaClass@1),
>      "jpkg.Bean" : PyJavaClass(null),
>   }
> 
> meaning that the PyJavaClass is fully initialized with its .class as key
> and that jpkg.Bean is lazily loaded and uninitialized with the string
> "jpkg.Bean" as key.
> 
> When we get a java instance inst0 from the java side we first check for
> a lazy entry. We find jpkg.Bean which is then resolved using the same
> classloaders setup as if the class was not lazy loaded. When the
> PyjavaClass is initialized the lazy entry is removed and the dict looks
> like this:
> 
>   {
>      org.python.core.PyJavaClass.class : PyJavaClass(PyJavaClass@1),
>      jpkg.Bean.class@2 : PyJavaClass(jpkg.Bean.class@2),
>   }
> 
> Now the inst0.getClass() is searched in the dict. If it happens to be
> the same as jpkg.Bean.class@2, the newly initialized PyJavaClass is
> returned. If it isn't, a new entry is added.
> 
>   {
>      org.python.core.PyJavaClass.class : PyJavaClass(PyJavaClass@1),
>      jpkg.Bean.class@2 : PyJavaClass(jpkg.Bean.class@2),
>      jpkg.Bean.class@3 : PyJavaClass(jpkg.Bean.class@3),
>   }
> 
> This last dictionary would match the situation where we had disabled
> lazy loading. The two jpkg.Bean classes would not be interoperable, but
> lazily loaded class would work just like the ordinarily initialized
> classes.
> 
> I still don't have a deep and intuitive understanding of the issues, so
> there is likely something I have forgotten.
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.
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.
So the principle: if there is a possible ambiguity around, we should force
loading of lazy loaded stuff with the involved name and check.

> >(2) I think it would be great to have both unloading support (meaning
> >...
> 
> Cool.
 
> >(3) For reloading also MakeProxies.makeClass should be changed:
> >...
> Right.

> >  Maybe it is better to distinguish between a class implementing sys.path
> >loading and a class for dynamic
> >  loading of discardable code. Actually BytecodeLoader does both things.
> 
> Yes, that would be goodness. Much confusion in the past have its roots
> in this double duty.

And I will start working seriously on all that.

 
> >[Finn]
> >> >And with such
> >> >a patch it should be possible to produce an experimental version
> >> >of reloading support (in form of a python module using __import__ hook).
> >>
> >> Good. I would like to get broader feedback on the reloading issues, so
> >> maybe some version of java reloading can go into 2.0-final marked as
> >> experimental. I would also like Guido's view on how pythonic he consider
> >> our java reload support to be.
> >Hope that our best is enough ;), in any case if we should keep our reload
> >support
> >separate from runtime (because it is not enough pythonic) we will encouter
> >the need
> >of some ihooks/imputil-like support and suffer the destiny of import-sig,
> >which has mostly ignored jython, otherwise people will not be able to hook
> >importing for other purposes.
> >
> >* A framework for extending importing would also be great for jython, for
> >example for poor-man freezing,
> > putting support for everything directly in the runtime being not a good
> >choice.
> >
> >* jythonc side
> >+ package relative import has not been fixed yet.
> >+ proposed --depend option.
> >+ for the future:
> >  - importing of compiled code into interp, and compiling code referring to
> >separate comp results.
> >  - (maybe) jythonc able to compile against a claspath/sys.path different
> >from the classpath/sys.path under which is running
> >
> >* (mostly a potential users wish) it is really difficult to effectively use
> >java security arch from jython and
> >  for jython code,  some kind of rexec mixing java/python policies is maybe
> >a necessary framework. (very complicated)
> >* performance issues?(?)
> 
> 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.
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.
 
regards, Samuele.