Re: [Jython-dev] poor man freezing and loading from other sources: proposals and ideas

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

Hi.

[Finn]
> [Samuele]
> 
...
> 
> Yeah.
> 
> >On the other hand even if the only solution is to define packages
> >through sys.add_* apis, I think that opening the sys.classLoader API
> >and making imports even more regular is something necessary for many embedding 
> >related situations, in any case it is something not for the casual user, the 
> >others can pay the necessary attention and lack of comfort...
> 
> Yes, at least in principle. It's just that I can already hear the
> complaints that jython can't load java class: "I know the classloader
> works because I can load classes from java". It is painfull that the
> complaint is actually valid.
> 
> Maybe a different worded ImportError should be printed when
> sys.classLoader is set.
I can hear them too <wink>, once I imagined the following ?ugly? solution
(but no import * or dir) that technically means having the packageManager
existsPacakage return always true <wink>. Not a good default but as special
option ...
 
> ...
> I think listeners are less likely to be edited, and when they are
> changed, the loading/linking of the adapter will most likely fail.
> 
> Proxies are much more fragile since changes to both the java class and
> the python subclass can/should force a new proxy class to be generated.
> But to avoid two $py.class formats, we could always compile in the proxy
> classname and only use the name when running as a poor-man frozen
> application.
I see, it's a matter of coding that <wink>

> ...
> >Unfortunaly jar -i does not store enough information to support
> >dir and import *. In any case we would have to build a tool for
> >non java SE2 1.3 env (?).
> 
> Yes. I called this tool of ours for "jarindex". It would be a shell/.bat
> script written by the installer.
Ok.

> >To be honest this one  is the more complicated of the proposed changes,
> >here some concrete ideas:
> >
> >0. have a tool to "index" a jar in a way that supports dir (maybe the same
> >  as above under different options)
> 
> I believe that a .jar should only be scanned once. That means that if
> the scan result isn't cached we should reject un-indexed jars. Why don't
> you want to cache the scan result?
> 
> All in all this is my favorite.
Having the tool? caching things?

I would cache things per session but not across sessions. The problem is that
we never cleanup the global cache and this is absolute-path based, for trying
an api once that then is maybe discarded this is bad, for things moving around
the file-system is bad too, it's ok for jdk libraries or extension or ...

> >a. ignore performance issues, open and close jars on every import, scan
> > or read the index also lazily on import
> 
> There shouldn't be noticeable performance difference between putting a
> jar on sys.path or on classpath. I think we have to keep it open.
I agree.

> >b. like a) but keep jars open, but I don't see any good place to lazily
> >   close them that work at least in many situations if not for all.
> >   Just keeping them open sounds bad.
> 
> That is what the JVM does for the .zip files found on CLASSPATH. As for
> changes to sys.path se below.
Aware of that.


> >c. the overkill solution [maybe not that much but implies that we must live
> >   forever with the following CPython incompatibility (which is quite marginal):
> >      L=UserList.UserList()
> >      sys.path=L
> >   works in CPython but not in Jython, for c) we will have to even enforce this]
> >   add to builtin lists the possibility to have an observer (it costs
> >   the comparision between a ref and a null on every update method)
> >   that is notified for changes, so we can open, scan and close things
> >   on sys.path changes. Why every list? to make rare things work:
> >      L=['.','foodir']
> >      sys.path=L
> >      L.append('bazdir')
> >   When a list is assigned to sys.path its observer field is assigned,
> >   the field of the old one is reset...
> 
...
> 
> Or wrap the list 'L' above with an observable wrapper that intercepts
> __XXXitem__ calls. That would close the archive immeditatly but cause
> the value returned by 'sys.path' to be different from the value
> assigned. My favorite solution.
Ok for me but the example above that modifies sys.path trough L will not work (?)

and we still have to deal with unexpected modifications.

> I suppose that putting the zipfile instance itself into sys.path would
> solve the close problem. Until CPython decides to go the full length, I
> would prefer a less neat solution where we keep only strings in
> sys.path.
Yes.

regards.