Issue2697

classification

Title:	name$py.class is ignored when in a JAR with name.py
Type:	behaviour	Severity:	normal
Components:	Core	Versions:
		Milestone:

process

Status:	open	Resolution:
Dependencies:		Superseder:
Assigned To:		Nosy List:	jeff.allen
Priority:	normal	Keywords:	easy

Created on 2018-07-11.13:32:05 by jeff.allen, last changed 2018-07-11.13:32:05 by jeff.allen.

Messages
msg12048 (view)	Author: Jeff Allen (jeff.allen)	Date: 2018-07-11.13:32:04
When we JAR together a Python module and its source, as we do for jython-standalone, and want to for the Gradle build, Jython always chooses to re-compile the source, rather than use the pre-compiled class. This is apparently because in org.python.imp.readCodeData, we check that the time embedded in the $py.class file is the same as the last-modified time on the source file. The former is taken from the filesystem (via java.io.File.lastModified) during compilation, and pretends millisecond resolution. The latter is taken from the ZIP file directory and has been rounded to 2 seconds, DOS-style. I think the answer is to make the comparison more forgiving where the importer is a zipimporter (by overriding a comparison function, say). I noticed this when testing the JAR produced by Gradle. In #1090, I was unable to reproduce the OP's problem, but it may be that having the source in there was the key. Not sure of this, and it's been 10 years, so I'm raising new issue.

msg12048 (view)

Author: Jeff Allen (jeff.allen)

Date: 2018-07-11.13:32:04

When we JAR together a Python module and its source, as we do for jython-standalone, and want to for the Gradle build, Jython always chooses to re-compile the source, rather than use the pre-compiled class.

This is apparently because in org.python.imp.readCodeData, we check that the time embedded in the $py.class file is the same as the last-modified time on the source file. The former is taken from the filesystem (via java.io.File.lastModified) during compilation, and pretends millisecond resolution. The latter is taken from the ZIP file directory and has been rounded to 2 seconds, DOS-style.

I think the answer is to make the comparison more forgiving where the importer is a zipimporter (by overriding a comparison function, say).

I noticed this when testing the JAR produced by Gradle. In #1090, I was unable to reproduce the OP's problem, but it may be that having the source in there was the key. Not sure of this, and it's been 10 years, so I'm raising new issue.

History
Date	User	Action	Args
2018-07-11 13:32:05	jeff.allen	create