Re: [Jython-dev] importing compiled code

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

Hi.

first some bugs status:
1) I have put in place the fix for [ Bug #122610 ] SecEx in MS applerviewer.
    http://sourceforge.net/bugs/?func=detailbug&bug_id=122610&group_id=12867
2) Bug [ Bug #122793 ] Calling reload on java class loaded from sys.path
cause NPE
    http://sourceforge.net/bugs/?func=detailbug&bug_id=122793&group_id=12867
    is clearly closed because actually reload for a jclass is nop,
   or open if we want to keep it as reminder that we should implement
reloading for jclasses <wink>.
3) [ Bug #122864 ] importing java packages
    http://sourceforge.net/bugs/?func=detailbug&bug_id=122864&group_id=12867
    has been closed by my patch that treats jars and dirs symmetrically.
4) [ Bug #122876 ] Import error with mixed classpath is solved by my patch
too.
    http://sourceforge.net/bugs/?func=detailbug&bug_id=122876&group_id=12867

2nd:
[Finn]
> >Why the InitModule and his support code are still left around?
> >Should we clean that?
>
> I have not removed it in the small hope that 3rd part modules which uses
> InitModule would continue to run with jython. I have not tested this, so
> this kind of compatibility may have been broken by some other change.
I think, it still works, e.g. PyDictionary still used it, I have just
changed that
but we can keep InitModule for 3rd part compatibility.

Now about importing compiled code:

I'm not convinced about *my* proposal:

[Finn]
> ...
> >Notice that with this design choice if someone load a compiled
> >module through a java package it will get simply the java class
> >not the module, for me this makes sense
>
> I fear it will be FAQ. In some setups you will get the module, in others
> you will get the proxy. They have the same name so it is not obvious
> which you happened to import.
> ...
>
> I would not mind too much if the generated proxy classes wasn't
> available from jython at all. As long as the module and all the classes
> inside the module are available.
>
I'm not conviced that what we can quickly(?) implement is what people
expect.
It seems to me that jythonc is more there to build applets or make jython
classes
resemble java classes, such that people can forget about their jythonic
nature.
If someone subclasses a swing panel or builds a bean with jythonc I believe
it expects a class
not a module when he imports that back in the interpreter.
I know this is just philosophy...
but there is also a technical side:
* as noticed the java class and the python module have the same name,
  this is really a problem, e.g w.r.t. to sys.modules
  I always felt that top-level jclasses should not end up in sys.modules but
that
  is what jython does. My viewpoint is that java classes are not modules...
* actually one can get to import the compiled class, but constructed
instances
  do not work, I have done few experiments and read the code a bit, so maybe
I'm missing something,
  but this point could be solved making the PyJavaClass.__call__ return a
python
  class in this case, here it does not make sense to put a proxy around a
proxy. We should take care of
  this also by subclassing. (see transcript at the end).
* but the most serious issue is the following and this is an issue
concerning both choices (class/pkg import):
   we should be careful  choosing with which classloader we load things, in
mixed java/jython code case
   it is quite is easy and natural use the pre-built proxy from the java
side (and this at java compilation time), I can imagine  that if   we are
not careful we risk to load things twice and get a new series of interop
problems ...
* what should reload do?

Are we in hurry to offer such a feature. Personally I need more time to
study the issue.
Could you [Finn] list what is left to do (up to bugs), what should be in for
alpha1 ... and the final release.
For example the cache issue as a step toward reloading - I think - is
important.

About that there are still some questions around that I should answer you.
I will post the answers together with a list of ideas (many are very
low-prio).

Comments are welcome.

regards, Samuele

----- an experiment
This just indicates that the other choice (class import) is not hopeless,
but this does not mean easy.

Setup:
<Z.py>
import java

class Z(java.lang.Object):
 def value(self):
  "@sig public int value()"
  return 1
</Z.py>
This gets compiled with jythonc to Z.class and Z$_PyInner.class.

<SZ.java>
public class SZ {
 public static int svalue(Z z) {
  return z.value();
 }
}
</SZ.java>
This gets compiled with javac against Z.class (from jythonc) to SZ.class.

The bad news:
Jython 2.0 pre-alpha on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> import Z
>>> z=Z()
>>> z.value()
Traceback (innermost last):
  File "<console>", line 1, in ?
AttributeError: abstract method "value" not implemented

The "good" news:
Jython 2.0 pre-alpha on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> import sys
>>> from java.lang import Class
>>> import Z,SZ
>>> (Z.getClassLoader(),SZ.getClassLoader()) # things loaded from sys.path
(org.python.core.BytecodeLoader@ae1cf, org.python.core.BytecodeLoader@ae1cf)
>>> sys.modules['Z']
<jclass Z at 8321686>
>>> del sys.modules['Z'] # otherwise we get an exception
>>> z=Class.newInstance(Z)
>>> z
<Z.Z instance at 3180698>
>>> z.value()
1
>>> sys.modules['Z']
<module Z at 4920025>
>>> z1=Class.newInstance(Z)
>>> sys.modules['Z']
<module Z at 4920025>
>>> (SZ.svalue(z),SZ.svalue(z1))
(1, 1)
>>> class Y(Z):
...  pass
...
>>> y=Y()
>>> y.value()
Traceback (innermost last):
  File "<console>", line 1, in ?
AttributeError: abstract method "value" not implemented
>>> # but
>>> class Y(z.__class__):
...  pass
...
>>> y=Y()
>>> y.value()
1
>>> # and most important
>>> SZ.svalue(y)
1
>>> # seems to work.