Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fails with InvalidPathException when launched from Eclipse #79

Closed
tarioch opened this issue Jun 12, 2018 · 7 comments
Closed

Fails with InvalidPathException when launched from Eclipse #79

tarioch opened this issue Jun 12, 2018 · 7 comments
Assignees
@codecholeric
Labels
bug
Milestone
0.8.2

Comments

@tarioch
Copy link

tarioch commented Jun 12, 2018

I just tried to do a very simple case in my eclipse project and I'm getting an InvalidPathException

        JavaClasses importedClasses = new ClassFileImporter().importPackages("com.mypackage");
java.nio.file.InvalidPathException: Illegal char <:> at index 2: /C:/Software/eclipse/eclipse-neon-developer/eclipse/configuration/org.eclipse.osgi/432/0/.cp/
	at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
	at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
	at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
	at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
	at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
	at java.nio.file.Paths.get(Paths.java:84)
	at com.tngtech.archunit.core.importer.UrlSource$From.newFileUri(UrlSource.java:92)
	at com.tngtech.archunit.core.importer.UrlSource$From.parseClassPathEntry(UrlSource.java:86)
	at com.tngtech.archunit.core.importer.UrlSource$From.findUrlsForClassPathProperty(UrlSource.java:79)
	at com.tngtech.archunit.core.importer.UrlSource$From.classPathSystemProperties(UrlSource.java:71)
	at com.tngtech.archunit.core.importer.LocationResolver$Legacy.resolveClassPath(LocationResolver.java:38)
	at com.tngtech.archunit.core.importer.Locations.getLocationsOf(Locations.java:88)
	at com.tngtech.archunit.core.importer.Locations.ofPackage(Locations.java:63)
	at com.tngtech.archunit.core.importer.ClassFileImporter.importPackages(ClassFileImporter.java:128)
	at com.tngtech.archunit.core.importer.ClassFileImporter.importPackages(ClassFileImporter.java:138)
	at com.fisglobal.apexcollateral.DependencyCycleIntegrationTest.findCycles(DependencyCycleIntegrationTest.java:14)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

It looks like this is a classpath entry that was added by eclipse when running the Junit test. I see that UrlSource is already catching MalformedURLException, should it also catch InvalidPathException?
@codecholeric
Copy link
Collaborator

I've just tried running a JUnit test under Windows 10 with Eclipse Oxygen and I haven't run into that problem.
Are you using ArchUnit 0.8.1 ? I think 0.8.0 had a problem like this if you'd use Windows and Java >= 9.
If you're using 0.8.1 I have to look into it closer, why the error doesn't appear on my Windows box with Eclipse (any information about your setup would be helpful then, for example how System.getProperty("java.class.path") looks like)

@tarioch
Copy link
Author

tarioch commented Jun 13, 2018 •
edited
Loading

I'm using

  • Eclipse Neon
  • ArchUnit 0.8.1
  • Windows 10
  • JDK 8

path looks like this:

C:\projects\workspaces\playfield\dummy\target\test-classes;C:\projects\workspaces\playfield\dummy\target\classes;C:\projects\m2\repository\com\tngtech\archunit\archunit\0.8.1\archunit-0.8.1.jar;C:\projects\m2\repository\org\slf4j\slf4j-api\1.7.7\slf4j-api-1.7.7.jar;C:\projects\m2\repository\junit\junit\4.12\junit-4.12.jar;C:\projects\m2\repository\org\hamcrest\hamcrest-core\1.3\hamcrest-core-1.3.jar;/C:/Software/eclipse/eclipse-neon-developer/eclipse/configuration/org.eclipse.osgi/432/0/.cp/;/C:/Software/eclipse/eclipse-neon-developer/eclipse/configuration/org.eclipse.osgi/431/0/.cp/

@codecholeric
Copy link
Collaborator

Ah, I see. So from my point of view, this looks like a bug in Eclipse, i.e. Eclipse creates a wrong "java.class.path" system property. I've cross checked

https://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html

where it pretty clearly states, that the classpath should be of the form "C:\foo;C:\bar" and not sth. like "/C:/" so I think Eclipse is at fault here. I've also found another issue with that respect 😉

gwtproject/gwt#9564

The combination of some entries of the form "C:..." and some entries of the form "/C:/..." seems strange anyway, I would guess it's some erroneous conversion of URL to path.

Originally I was wondering, if I should add more robustness against wrong classpath entries, or not, and decided against it, since I thought clients should just supply valid classpath properties (which so far seemed to work out within IntelliJ, Maven and Gradle). But I see that this is kind of hard to achieve when running tests within Eclipse, since (as far as I know) control over this part of the supplied classpath is limited.

I'll make this more robust and add error logging instead, if an invalid file path is encountered within the classpath property.

codecholeric added a commit that referenced this issue Jun 16, 2018
@codecholeric
Make UrlSource.From.classPathSystemProperties() resilient against ill…
31d3307 
…egal paths like older versions of Eclipse sometimes add to the classpath on Windows (e.g. '/C:/some/folder')

Issue: #79
Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>
codecholeric added a commit that referenced this issue Jun 16, 2018
@codecholeric
Make UrlSource.From.classPathSystemProperties() resilient against ill…
06f5af3 
…egal paths like older versions of Eclipse sometimes add to the classpath on Windows (e.g. '/C:/some/folder')

Issue: #79
Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>
codecholeric added a commit that referenced this issue Jun 16, 2018
@codecholeric
Make UrlSource.From.classPathSystemProperties() resilient against ill…
f152d84 
…egal paths like older versions of Eclipse sometimes add to the classpath on Windows (e.g. '/C:/some/folder')

Issue: #79
Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>
@codecholeric
Copy link
Collaborator

I've looked closer into this, and I could reproduce this issue with Eclipse Neon. It seems to be gone with Eclipse Oxygen, though.
It seems like the JRE itself is resilient enough to parse these types of entries (the respective URLClassLoader knows these URLs), so I've added a fallback to parse entries of the form "/C:/foo/bar" as well as "C:\foo\bar" (I've also labeled it as a bug now, instead of an enhancement, since the JRE can handle it 😉)
I'll release a new bugfix version soon.

@tarioch
Copy link
Author

tarioch commented Jun 16, 2018

Great thx a lot

@codecholeric
Copy link
Collaborator

It's on Maven Central now: https://search.maven.org/#search%7Cga%7C1%7Carchunit
I'm pretty positive that it solves the problem, since I've tried Eclipse Neon, too, and the problem disappeared with the upgrade, but I'd be happy about a short "works on my machine" from you 😉

@codecholeric codecholeric added this to the 0.8.2 milestone Jun 16, 2018
@codecholeric codecholeric self-assigned this Jun 16, 2018
@tarioch
Copy link
Author

tarioch commented Jun 18, 2018

Yep, can confirm, with 0.8.2 everything works fine, thanks a lot.

@tarioch tarioch closed this as completed Jun 18, 2018
msherman32 pushed a commit to msherman32/ArchUnit that referenced this issue Jun 27, 2018
@codecholeric
Make UrlSource.From.classPathSystemProperties() resilient against ill…
355b956 
…egal paths like older versions of Eclipse sometimes add to the classpath on Windows (e.g. '/C:/some/folder')

Issue: TNG#79
Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>
codecholeric added a commit that referenced this issue Feb 21, 2021
@codecholeric
Make UrlSource.From.classPathSystemProperties() resilient against ill…
c24aa07 
…egal paths like older versions of Eclipse sometimes add to the classpath on Windows (e.g. '/C:/some/folder')

Issue: #79
Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@codecholeric codecholeric

Labels
bug
Projects
None yet
Milestone
0.8.2
Development

No branches or pull requests
2 participants
@tarioch @codecholeric