Hi.
I have subscribed to the sourceforge lists and so I have received the last mail
from Finn (twice).
Have I missed something in between? at the moment there is no
archive access.
Things seem to get clearer both for semantic and possible implementation
up to Barry inputs.
[Finn]
> Right, I think I understand now. The list of module would then look
> like:
>
> module_list = ['x', 'x.y']
>
> and the code that look for java packages would then look like this:
>
> if module_list != None:
> if modName in module_list:
> # here modName is not a java package, so there
> # is no need to try an expensive forName(modName)
> # across the network.
> return null
> // do normal java package load here.
Yes, that is what I meant and it should solve the performance problem.
As I wrote java package load should deal also with sys.path java loading
(semantic: virtually sys.path is appended to CLASSPATH)
and main "problem" is to handle sys.path more dynamic nature.
I clarified to myself that jythonc should build the list, use the new
order dealing with imports but it is not necessary that it find out
that a py pkg is also a java pkg :). The modified runtime support
can deal with this.
But there is another issue: I have not yet analyzed it in depth.
One can compile a set of py modules/py pkg under a user-defined
java pkg (package jythonc option) so for example py mod x.y
will be userpkg.x.y.
If the code in interpreted mode load a java class x.JClass what should do
at runtime the same code when compiled and put in the pkg userpkg,
just still try to load x.JClass or userpkg.x.JClass, try both.
In any case something like java.lang.* should still be loaded as java.lang.*.
Can we separate the different cases? What is the more coherent semantic that
can be actually implemented?
regards, Samuele
PS: as I wrote, all the compiler.*Maker should not use Class.forName.
I noticed that AdpterMaker is also used by jythonc so we should pay attention.
|
