[Jython-users] Re: [Pythonmac-SIG] Cocoa from Jython on MacOSX

[Finn Bock]

[Steven D. Majewski]

>...

>I changed the jython shell script to add the path:
>
>/System/Library/Frameworks/JavaVM.framework/Versions/1.2/Home/bin/java
>-Dpython.home=/Users/sdm7g/jython-2.0 -classpath
>"/Users/sdm7g/jython-2.0/jython.jar:/System/Library/Java:$CLASSPATH" org.python.util.jython
>"$@"
>
>
>I don't know anything about how the installer works -- if there is a place
>for platform dependent mods, it might be nice to add that.

At the moment the MacOSX is considered a unix from the installer POV.

>(Also: strictly 
>speaking, the initial path OUGHT to be:
>	 /System/Library/Frameworks/JavaVM.framework/Home/bin/java
>which is symbolically linked to the current version. This script works,
>but it won't antomatically track any Java upgrades. If it's not simple
>to change, 

The installer uses the java.home property directly AFAICT. If the value
there isn't the right one, there is nothing the installer can about it.
Please try this 

>>> import java
>>> java.lang.System.getProperty("java.home")
'I:\\JAVA\\JDK1.3\\jre'
>>>

>you might just want to keep it in mind as another possible
>FAQ -- you may need to reinstall jython if you upgrade Java VM. )   
>
>
>I was able to get a slightly modified version of one of my PyObjC 
>AppKit  test programs to work in Jython. The main difference is 
>that the CPython <-> Objective-C bridge does a different name
>mangling than the Java bridge does. PyObjC tries to pythonify
>the objective-C method names -- for example 
>
>the objective-c statement:
>
> [ win initWithContentRect:rect styleMask:mask  backing:YES defer:NO ];
>
>actually uses the message selector:
>
>  initWithContentRect:style:Mask:backing:defer: 
>
>which gets name mangled by PyObjC to:
>
>  win.initWithContentRect_styleMask_backing_defer_ (frame, mask, YES, NO )
>
>
>but Jython gets to use the Java bridge's use of Java overloading of
>different polymorphic versions of the same method name (so there are
>a couple of different initWithContentRect 's with different numbers
>of args. ).
>
>In Jython:
>
>  win.initWithContentRect( frame, mask, YES, NO )
>
>
>( I don't know yet what happens when there are are two objective-c
>  methods with the same number but different args. ) 

Jython will succesfully call the correct method. It works flawlessly in
99.9% of all cases. For some of the remaining cases a helper object can
be used to specify which overloaded function to call. See:

   http://www.jython.org/docs/usejava.html

section

   "Overloaded Java Method Signatures"

For the remaining cases, like this:

  void foo(int x);
  void foo(Integer x);

jython picks one, and there is no way to select.

>I think there was some discussion on the old pyobjc-sig mailing list
>on whether or not to attempt this sort of overloading or to keep the
>more explicit name transformation. We may wish to revisit this 
>decision -- it would be nice to have the same Cocoa bindings for Jython 
>and CPython+PyObjC. 

The pure pleasure of having overloading just work suggest that it is
worth the additional implementation. The ability of calling overloaded
java methods from jython without any manual mangling, was a fundamental
necessity for jython's success.

OTOH, there is a performance issue, at least with the way Jython
implements overloaded methods.

Overloaded methods are sorted according to the precedents of the
arguments and when a method is called, the runtime will attempt to
coerce the actual arguments into the argument that each of the
overloaded java method expect. If there is a lot of overloaded method 
with the same number of args, all the coercion attempts will take time.

As an example look at String.valueOf method:

>>> import java
>>> java.lang.String.valueOf
<java function valueOf at 5314727>
>>> java.lang.String.valueOf.argslist
<list of java methods that the argument will be attempted coerced into>

regards,
finn