Title: Regression in PySystemStateTest (leading slash)
Type: behaviour Severity: normal
Components: Core Versions: Jython 2.7
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: jeff.allen, stefan.richthofer
Priority: normal Keywords: easy

Created on 2015-10-10.10:05:00 by jeff.allen, last changed 2018-04-13.17:15:31 by stefan.richthofer.

msg10343 (view) Author: Jeff Allen (jeff.allen) Date: 2015-10-10.10:04:58
I notice that I get a regression test failure from:
ant -Dtest=PySystemStateTest singlejavatest

I think the test might be right and the code wrong: in the failing case, don't we need the slash?

I admit I don't run "ant javatest" anything like as often as "ant regrtest": mending my ways belatedly, I have traced the problem to .

I searched a bit and found:, which steers us towards what the Java platform provides, rather than wrestling as we do with the OS-specifics.
msg11894 (view) Author: Stefan Richthofer (stefan.richthofer) Date: 2018-04-12.13:19:08
Also see for the reasoning of making getJarFileName() public. Since it states "FileName" I suppose it should return a string that is valid as a file name, e.g. when used to construct a object. A leading slash would break this assumption/promise (on Windows) as it is a malformed file name.

What solution would you suggest? What is the exact failure?
msg11896 (view) Author: Jeff Allen (jeff.allen) Date: 2018-04-12.20:22:09
Failure in more detail:

    [junit] Testsuite: org.python.core.PySystemStateTest
    [junit] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.313 sec
    [junit] Testcase: testGetJarFileNameFromURL(org.python.core.PySystemStateTest):     FAILED
    [junit] expected:<[/]some_dir/some.jar> but was:<[]some_dir/some.jar>
    [junit] junit.framework.ComparisonFailure: expected:<[/]some_dir/some.jar> but was:<[]some_dir/some.jar>
    [junit]     at org.python.core.PySystemStateTest.testGetJarFileNameFromURL(

There isn't a drive letter involved here, but I appreciate the existence of drive letters invalidates otherwise correct manipulation in a lot of contexts. I've done some of that myself in the code base. (I never made getcwd() work correctly on the D-drive.)

Ideally we would depend on the nice people at Oracle/OpenJDK to get this stuff right. I'd love to re-work all this guff using java.nio.Paths one day. For now, I think is probably the right answer.

>>> from import File
>>> from java.util.jar import JarFile
>>> from import URL
>>> f = File(r"dist\lib\test\blob.jar")
>>> f.getAbsoluteFile()
>>> f.toURI()
>>> j = JarFile(r"dist\lib\test\blob.jar")
>>> list(j.entries())
>>> u = URL("jar:" + str(f.toURI()) + "!/")
>>> u
>>> import os
>>> os.path.relpath(u.getPath().split(':',1)[1].split('!')[0][1:])

To be honest, I've lightly lost the thread of #2386, and why we ended up with this test failure.:/ Does something in the round-trip I just made suggest a simple, cross-platform and correct version of getJarFileNameFromURL or getJarFileName ?
msg11897 (view) Author: Jeff Allen (jeff.allen) Date: 2018-04-12.20:50:44
Ah, is this what we want to reproduce URL -> file?

>>> u = URL("jar:file:/some_dir/some.jar!/a/package/with/A.class")
>>> c = u.openConnection()
>>> File(c.getJarFileURL().toURI())

And with that pesky drive:

>>> u = URL("jar:file:/C:/some_dir/some.jar!/a/package/with/A.class")
>>> c = u.openConnection()
>>> File(c.getJarFileURL().toURI())
msg11900 (view) Author: Stefan Richthofer (stefan.richthofer) Date: 2018-04-13.17:15:30
Oh, sorry; in I overlooked that `some_path` can have different meaning than `/some_path`. However fixing paths like `/C:/some_path` was still important. Apart from that I did not touch getJarFileNameFromURL implementation. It stems from older work. As part of #2386 I just moved it from another module to public API. Changing it to make better use of Java API is the best solution I suppose. Also simplifies its code a lot.

should do it...
Date User Action Args
2018-04-13 17:15:31stefan.richthofersetmessages: + msg11900
2018-04-12 20:50:45jeff.allensetmessages: + msg11897
2018-04-12 20:22:10jeff.allensetmessages: + msg11896
2018-04-12 13:19:09stefan.richthofersetmessages: + msg11894
2018-04-10 19:45:52jeff.allensetkeywords: + easy
priority: normal
2015-10-10 10:05:00jeff.allencreate