While going through the 1.10 API, I noticed this typo in MavenArtifactRepository. All “Url” methods on the MavenArtifactRepository object actually work with java.net.URI objects, not java.net.URL objects.
It’s a pretty small thing, but I thought I would mention it since I assume the fix is easy.
These methods accept a ‘String’, ‘File’, ‘URI’, ‘URL’, etc. Those that have a return value intentionally return a ‘java.net.URI’.
I was aware that the “set” methods would convert things into a URI, but I figured the naming was unintentional. Anyway, seems like the name/return value combination was not a mistake.
In general, ‘java.net.URI’ is a better representation for URLs than ‘java.net.URL’. The latter is mostly useful for accessing URLs.
Please don’t get me wrong, I don’t disagree with that at all! I use URIs whenever possible as well, my comment is just about the names. Since it’s such a small thing, I probably shouldn’t have brought it up.
What’s wrong with the naming? These are URLs, it’s just that we prefer to represent them using ‘java.net.URI’. If you will, the confusion stems from the Java class library and its implementation of ‘URI’ and ‘URL’.
What’s wrong the naming? Nothing, if it was named that way on purpose. When working with java (or a java-based language), I would expect a getUrl() method to return a URL. If it returns a URI, I would have expected it to be named getUri() instead. It’s not immediately clear to me what benefit there is in naming these methods with a Url suffix instead of Uri suffix, so I assumed it was just a mistake. It’s pretty clear from your responses that this was not an oversight, but intentional. So there is nothing wrong.
It was done in this way because logically, the methods accept/return an URL, not an URI (which is more general). It’s just that ‘java.net.URL’ is a poor general-purpose representation of an URL.