RE: [Jython-dev] Question about old python.proxy.savedir

[Humbel O. <Otm...@bi...>]

[Finn]

> The proxy cache recently discussed here is the in-memory mapping from
> class names to the PyJavaClass which represent the class. Calling it a
> cache is probably wrong, the PyJavaClass.classes hashtable is 
> not about
> performance, but about ensuring a 1-1 mapping between a class and its
> PyJavaClass. The problem we have been talking about is how to ensure
> this 1-1 mapping when the java class haven't been loaded yet (what we
> call "lazy loading") and when the java class gets reloaded (different
> class with the same name).

Many thanks for the explanation.
 
> The proxy.savedir option were OTOH a true performance cache with the
> name of the java class as cache-key. The option was never enabled for
> JPython-1.1. There were several reasons for this omission:
> 
> - The proxies classes does not have a uniquely identifiable name
>   anymore. The generated proxy class name include a serial number
>   that makes it difficult to use a cache like the one in 1.0.3.
> - JPython-1.1 included new and much improved ways of freezing. If
>   the dynamic proxy creation is too slow, jpythonc can create the
>   proxies for you in advance.
> - Having a performance cache without any means of flushing the cache
>   when it gets stale is bad design. We still have no way of detecting
>   when a java have changed.

jythonc creating the proxies in advance would solve 95% of our problems, I
believe. 
I completely agree with you about the 'bad design': the handling is
horrible.
 
> We always need better performance. I have been thinking a little about a
> design where the generated proxies is stored at the end of the $py.class
> file. This would still not solve the flushing issue, but it would make a
> manual flush of the cached proxy much easier.

This also sounds interesting. We'll give Jython a try soon !

Thanks again and best wishes,
Oti.