Issue1403

Currently, the standalone jar file contains .py files, which will have
to be compiled to .class files during runtime. I request that this be
either replaced with, or supplemented with an another standalone jar
that only contains the compiled .class files instead of the source .py
files to avoid the compilation overhead.

We have run into this same issue. Our program starts in 15 seconds with the normal standalone jar and with class files included this drops to 9 seconds.

Our system (Robot Framework) is restarted repeatedly in some environments, so this is a serious speed issue for us.

Here example times with just some simple imports (as noted, our program shows even bigger time differences):

time java -jar compiled.jar  -c 'import unicodedata, os, time, unittest, datetime, subprocess, zipfile, httplib'

real	0m6.710s
user	0m10.816s
sys	0m0.462s

time java -jar not_compiled.jar  -c 'import unicodedata, os, time, unittest, datetime, subprocess, zipfile, httplib'

real	0m8.858s
user	0m13.664s
sys	0m0.412s

Also, for some reason we didn't get this new jar with compiled classes to work without also including the original py-files. We had to include both class and py-files in the jar.

We couldn't figure out why this was.

I have a Jython application deployed with only .class files in the jars. Works fine. Just make sure you don't mix and match Java and especially Jython versions there. Class files compiled on a different Jython version don't work with another version -- the class loader simply ignores them.

Interesting. We are compiling the class files with the very same jython jar so that should not be the issue. Also java version stays the same.

Our own program does work without the py-files included. It is only the Jython standard libraries that seem to need the py-files in jar. Jython does find the class files though, because we do see that considerable speed up.

One drawback seems to be that such jars would be tied to a specific JRE vendor and major version. Any other restrictions that come to mind?

What we might be able to do is have an option in the installer to include or not include pre-compiled $py.class files. I don't think we want to explode the number of release packages more.

And if we did go with the installer route, we could also have an option to have only the $py.class files, leaving out the .py files for space.

I was hoping that one day this could be made into a JNLP extension, hosted somewhere (by the PSF?). For me, that was the main point.

Ah - maybe we should open up a new tracker item with that as the subject? I don't know exactly what is involved in making a JNLP extension, but I vaguely recall it isn't that difficult. We could make a JNLP target in our build.xml and then find out where the PSF likes to host things (I suspect it's the same place that the Jython website lives)

Urgent bug #2282 is essentially a duplicate

Now fixed in #2282, with a modest performance speedup:

# no $py.class files in Lib/ in the jar
time java -jar jython-standalone.jar  -c 'import unicodedata, os, time, unittest, datetime, subprocess, zipfile, httplib'

real	0m8.666s
user	0m16.299s
sys	0m0.448s

# with $py.class files in the Lib/
$ time java -jar jython-standalone.jar  -c 'import unicodedata, os, time, unittest, datetime, subprocess, zipfile, httplib'

real	0m6.134s
user	0m12.422s
sys	0m0.397s

So some improvement not having to compile these modules.

Currently Lib/test/** files are being excluded.