From: Jeff A. <ja...@fa...> - 2018-09-14 07:20:48
|
The question is a lot like that of SystemRestart, although I haven't done as much code archaeology. At present, we appear to support an option -jar to the jython command. Just type jython -h or see: https://hg.python.org/jython/file/tip/src/org/python/util/jython.java#l91 But we don't. When you try to use it, all that happens, and has happened for a while, is this: PS startup2> jython -jar test.jar C:\Jython\2.7.0\bin\jython.exe: No module named __main__ The reason it doesn't work as promised is that before we try to run the JAR, we try this: https://hg.python.org/jython/file/tip/src/org/python/util/jython.java#l316 and since the attempt to get an importer for a JAR is successful, that method returns true, and so we never check the -jar option. The handler runMainFromImporter() can't run it, because it expects a __main__ module (the -jar flag expects a __run__.py instead), and that leads locally to a System.exit(). Functionally, runMainFromImporter(), which was added in 2.7 to implement CPython behaviour, is very similar to the much older runJar() although not exactly the same. I think if we were doing this now, we'd only provide that later mechanism. CPython can run exactly the same JAR (with a __main__.py) that I'm using to test runMainFromImporter(). When I correct the logic so that -jar calls runJar() as it used to, it doesn't work that well anyway: the script runs, but my import produces warning messages about the (assumed) package name of my script, and what ought to be the source code context in the message looks like binary from the JAR. However, runJar() is public so maybe there are applications that call it. I'll make a commit with the -jar option restored for comparison, but I think the command option could be removed immediately and a deprecation warning slapped on runJar(). Any contrary thoughts? Jeff -- Jeff Allen |