Fixed classloader construction for GenericClassImpl

[henryhchchc]

Fixed the class not found issue arising when there are multiple elements in target class path.

[henryhchchc]

Closed due to impatience.

[jose]

Hi @henryhchchc,

Thanks for taking the time to contribute to this project.

I might be able to review this pull request, but I would need a few details/context to understand it. For example, what do you mean by

... when there are multiple elements in target class path

Additionally, could you please develop at least one system test that exhibits the issue this pull request fixes?

[henryhchchc]

The problem is that, when EvoSuite is launched with -projectCP 'a.jar:b.jar:c.jar', the URLClassLoader in GenericClassImpl is constructed with a single URL, i.e., new URL[] { "file://a.jar:b.jar:c.jar" }, which does not point to any of the JAR files in the class path. In this case, ClassNotFoundException will be thrown even the class can be found in these JAR files.

To resolve the classes correctly, in this PR I split the class path with the path separator and construct the URLClassLoader with an array of URLs, i.e.,new URL[]{ "file://a.jar", "file://b.jar", "file://c.jar" }.

428 might be due to this bug. The class cannot be found even the dependencies are specified in -projectCP.

[jose]

Thanks @henryhchchc. I'm a bit confused though. How have others (including mysefl) been successfully using EvoSuite with several dependencies in the -projectCP argument if, as you said

the URLClassLoader in GenericClassImpl is constructed with a single URL, i.e., new URL[] { "file://a.jar:b.jar:c.jar" }, which does not point to any of the JAR files in the class path.

[henryhchchc]

Please give me some time to construct an example to demonstrate the issue.