From: <bc...@wo...> - 2001-02-28 21:21:18
|
[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 |