classpath path separator

[inria]

classpath path separator

[monperrus]

Hi Stefan,
The API is on purpose. The SpoonCompiler API is different from the Java Classpath API, which is irregular.
To me, the only problem with ":" as convention is that one cannot use path with drive names on Windows.
I tend to accept to pay this price instead of reproducing the Java Classpath API problem.
Another solution would be to use a completely different convention, for instance a comma.
What do you think?

[pschichtel]

Using the native path separator is pretty much the only thing you can use without the need for escaping. There is no character that is safe to use on any OS/filesystem, that's exactly why the File.pathSeparator constant exists.

instead of reproducing the Java Classpath API problem

What problem exactly do you mean?

[monperrus]

Furthermore I found in the code that you still use the File.pathSeparator to build up a default classpath

This is different, it's not the Spoon API of --source-classpath/setSourceClasspath that is handled there, it's a default strategy for backward compatibility.

instead of reproducing the Java Classpath API problem

What problem exactly do you mean?

A platform-dependent API

[swolf91]

But you use the source classpath which was set by the setSourceClasspath method or the classpath with the File.pathSeparator if the other doesn't exist... So both classpaths have different element separators. That should be a problem.

---

What do you mean exactly by platform-dependent API? Do you just want to have a program which can be used with Unix?

[pschichtel]

Well you're working with paths which are different on different platforms. I don't see how using File.pathSeparator makes you more platform dependent. Any other solution is either a mess to use or will just not work on at least one platform

[monperrus]

What do you mean exactly by platform-dependent API?

I mean an API whose usage depends on the platform.

For the interface SpoonCompiler, the solution is to avoid string parsing by slightly changing the contract and the signature.
signature: void setSourceClasspath(String... classpathElement); (note the ...)
contract: classpathElement must be a valid jar file or a folder containing bytecode files

For the command line API --source-classpath either we use File.pathSeparator or we allow multiple occurrences of the flag. I like the second solution.

--Martin

[seintur]

On 14 Aug 2014, at 13:26, Phillip Schichtel [email protected] wrote:

Well you're working with paths which are different on different platforms. I don't see how using File.pathSeparator makes you more platform dependent. Any other solution is either a mess to use or will just not work on at least one platform

Exactly. I agree with Philip and Stefan. The use of File.pathSeparator does not make you platform-dependent. On the contrary, it makes you platform-independent. It is just that the independence is parameterized by File.pathSeparator.

Lionel.

Prof. Lionel Seinturier
University Lille 1
http://www.lifl.fr/~seinturi

[swolf91]

@monperrus You can nevertheless change the signature of setSourceClasspath and change it for the command line api too. I agree with you at this points, because one can use one command line on different platforms. But please, you've to use the File.pathSeparator constant. How @pschichtel said, every other way doesn't work on at least one platform.

If you want I can provide a pull request which removes the CLASSPATH_ELEMENT_SEPARATOR and uses the File.pathSeparator instead.