[274] Corrected javadoc for Part.write(String)

[janbartel]

Fix for #274

The javadoc for Part.write(String) contained the contradictory sentence: "Absolute paths are used as provided and are relative to getLocation()."
Changed to the agreed text: "Relative paths are relative to MultipartConfigElement.getLocation(). Absolute paths are used as provided."

[joakime]

What is a "relative path" in this?

If I'm running on Microsoft Windows.
And the Multipart location is D:\web\multipart and the offered String is Part.write("/foo.dat");, then what?

The /foo.dat is not an absolute path on Windows, as that would result in D:\foo.dat. (which is relative to the root D:\)

The test of what is a "relative path" should be based on what?
The provided argument?
The provided argument and the multipart filesystem type? (what if you are on a system with multiple filesystem active?)
This needs to be fixed to be extra clear on what "relative path" means.

If the deployment is on a Virtual File System then relative path is again vague.
What if the deployment on a java.nio.file.FileSystem that has multiple roots?

[gregw]

@joakime a "relative path" is not an "absolute path". An "absolute path" is described by the javadoc as system dependent, so I by extension, relative paths are also system dependent. So to determine what is a relative path then APIs like FileSystems.getDefault().getPath(String) need to be used to determine that in a system dependent way.

The issue here is that this API should never been created to allow either a filename or a path, as the moment that is allowed things become very system dependent.