Do we intend the -jar option to work?

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