|
From: Samuele P. <ped...@bl...> - 2001-12-25 13:24:28
|
> [Samuele] > > >The problem here is that there are two choices: > >1) loading the $py.class through loadClass > >2) load it as a resource (work only with Java 2 unless > > the .class extension is changed to something else) > > Generally speaking, I have no problem if this new feature only works for > java2. I also like the possibility of adding some other toplevel path > component to the entries in the .ar file, eg. Lib/string$py.class. > > So I'm leaning towards #2 myself. I see, but I should repeat that it means you cannot package modules that way with an untrusted applet, because option #2 requires the permissions to create classloader. A solution could be that we have sys.classLoader with #1 and sys.path things with #2. > I disagree with both your positions <wink>. > > I feel that classloader loading should be handled like zip loading. > Users should somehow be able to add a classloader to sys.path (maybe > with an additional top-level path component). No hardcoded precedence > policy needed. > OK for me, that probably means that sys.classLoader should be integrated in the new picture. Anyway we could use some kind of string wrapper in this case too, to deal for example with subpackages. regards, Samuele Pedroni. |