102

I'm looking at a piece of Java code right now, and it takes a path as a String and gets its URL using URL resource = ClassLoader.getSystemClassLoader().getResource(pathAsString);, then calls String path = resource.getPath() and finally executes new File(path);.

Oh, and there are also calls to URL url = resource.toURI(); and String file = resource.getFile().

I'm totally confused right now - mostly because of the terminology, I guess. Can someone please walk me through the differences, or provide a few links to Dummy-proof material? Especially URI to URL and Resource to File? To me, it feels like they should be the same thing, respectively...

The difference between getFile() and getPath() is explained here: What's the difference between url.getFile() and getpath()? (Interestingly they both seem to return Strings, which probably adds a whole lot to my state of mind...)

Now, if I have a locator that references a class or package in a jar file, will those two (i.e. path an file strings) differ?

resource.toString() would give you jar:file:/C:/path/to/my.jar!/com/example/, after all (note the exclamation mark).

Is the difference between URI and URL in Java that the former doesn't encode spaces? Cf. Files, URIs, and URLs conflicting in Java (This answer explains the general, conceptual difference between the two terms fairly well: URIs identify and URLs locate;)

Lastly - and most importantly - why do I need File object; why isn't a Resource (URL) enough? (And is there a Resource object?)

Sorry if this question is a bit unorganized; it just reflects the confusion I have... :)

Community
  • 1
  • 1
Christian
  • 5,291
  • 9
  • 40
  • 85
  • Just to add to the confusion, there is also this line, which makes me doubt the hypothesis that `File` actually represents a "file"... `directory = new File(resource.toURI());` – Christian Jan 08 '15 at 17:05
  • 5
    And you not even started to look at `Path` and FileSystem from NIO :) – eckes Jan 08 '15 at 17:10
  • 2
    @eckes One headache at a time, please. ;) – Christian Jan 08 '15 at 17:12
  • 1
    Well in the context of your question File/URL+URI are not related. The one is a mean to name and operate on files the other is a method to name and read from resources (which can be files). The getFile and getPath methods deal with the components of an URL which are (confusingly) named like file objects. Classloader resources are not represented as files as they can have different origins (or be nested in JAR files). – eckes Jan 08 '15 at 17:23
  • 1
    I would note that this code is unlikely to work as intended. A `URL` is _opaque_ - as you show it's `jar:file:`, i.e. a resource in a `.jar` archive. Whacking that into a `File` is very unlikely to result in anything useful. – Boris the Spider Jan 09 '15 at 08:42
  • 1
    The heart of your problem is that the words *resource* and *path* can have different meanings, depending on the context. – Raedwald Jan 12 '15 at 07:58

5 Answers5

58

I'm totally confused right now - mostly because of the terminology, I guess. Can someone please walk me through the differences, or provide a few links to Dummy-proof material? Especially URI to URL and Resource to File? To me, it feels like they should be the same thing, respectively...

The terminology is confusing and sometimes befuddling, and mostly born from the evolution both of Java as an API and as a platform over time. To understand how these terms came to mean what they do, it is important to recognise two things that influence Java's design:

  • Backwards compatibility. Old applications should run on newer installations, ideally without modification. This means that an old API (with its names and terminology) needs to be maintained through all newer versions.
  • Cross-platform. The API should provide a usable abstraction of its underlying platform, whether that be an operating system or a browser.

I'll walk through the concepts and how they came to be. I'll answer your other, specific questions after that, because I may have to refer to something in the first part.

What is a "Resource"?

An abstract, generic piece of data that can be located and read. Loosely said, Java uses this to refer to a "file" that may not be a file but does represent a named piece of data. It does not have a direct class or interface representation in Java, but because of its properties (locatable, readable) it is often represented by an URL.

Because one of Java's early design goals was to be run inside of a browser, as a sandboxed application (applets!) with very limited rights/privileges/security clearance, Java makes a clear (theoretical) difference between a file (something on the local file system) and a resource (something it needs to read). This is why reading something relative to the application (icons, class files, and so on) is done through ClassLoader.getResource and not through the File class.

Unfortunately, because "resource" is also a useful generic term outside of this interpretation, it is also used to name very specific things (e.g. class ResourceBundle, UIResource, Resource) that are not, in this sense, a resource.

The main classes representing (a path to) a resource are java.nio.file.Path, java.io.File, java.net.URI, and java.net.URL.

File (java.io, 1.0)

An abstract representation of file and directory pathnames.

The File class represents a resource that is reachable through the platform's native file system. It contains only the name of the file, so it is really more a path (see later) that the host platform interprets according to its own settings, rules, and syntax.

Note that File doesn't need to point to something local, just something that the host platform understands in the context of file access, e.g. a UNC path in Windows. If you mount a ZIP file as a file system in your OS, then File will read its contained entries just fine.

URL (java.net, 1.0)

Class URL represents a Uniform Resource Locator, a pointer to a "resource" on the World Wide Web. A resource can be something as simple as a file or a directory, or it can be a reference to a more complicated object, such as a query to a database or to a search engine.

In tandem with the concept of a resource, the URL represents that resource the same way the File class represents a file in the host platform: as a structured string that points to a resource. URL additionally contains a scheme that hints at how to reach the resource (with "file:" being "ask the host platform"), and so allows pointing at resources through HTTP, FTP, inside a JAR, and whatnot.

Unfortunately, URLs come with their own syntax and terminology, including the use of "file" and "path". In case the URL is a file-URL, URL.getFile will return a string identical to the path string of the referenced file.

Class.getResource returns an URL: it is more flexible than returning File, and it has served the needs of the system as imagined in the early 1990's.

URI (java.net, 1.4)

Represents a Uniform Resource Identifier (URI) reference.

URI is a (slight) abstraction over URL. The difference between URI and URL is conceptual and mostly academic, but URI is better defined in a formal sense, and covers a wider range of use cases. Because URL and URI are/were not the same thing, a new class was introduced to represent them, with methods URI.toURL and URL.toURI to move between one and the other.

In Java, the main difference between URL and URI is that an URL carries the expectation of being resolvable, something the application might want an InputStream from; an URI is treated more like an abstract thingamajig that might point to something resolvable (and usually does), but what it means and how to reach it are more open to context and interpretation.

Path (java.nio.file, 1.7)

An object that may be used to locate a file in a file system. It will typically represent a system dependent file path.

The new file API, iconified in the Path interface, allows for much greater flexibility than the File class could offer. The Path interface is an abstraction of the File class, and is part of the New IO File API. Where File necessarily points to a "file" as understood by the host platform, Path is more generic: it represents a file (resource) in an arbitrary file system.

Path takes away the reliance on the host platform's concept of a file. It could be an entry in a ZIP file, a file reachable through FTP or SSH-FS, a multi-rooted representation of the application classpath, or really anything that can be meaningfully represented through the FileSystem interface and its driver, FileSystemProvider. It brings the power of "mounting" file systems into the context of a Java application.

The host platform is represented through the "default file system"; when you call File.toPath, you get a Path on the default file system.

Now, if I have a locator that references a class or package in a jar file, will those two (i.e. path an file strings) differ?

Unlikely. If the jar file is on the local file system, you should not have a query component, so URL.getPath and URL.getFile should return the same result. However, pick the one you need: file-URLs may not typically have query components, but I could sure add one anyway.

Lastly - and most importantly - why do I need File object; why isn't a Resource (URL) enough?

URL might not be enough because File gives you access to housekeeping data such as permissions (readable, writable, executable), file type (am I a directory?), and the ability to search and manipulate the local file system. If these are features you need, then File or Path provide them.

You don't need File if you have access to Path. Some older API may require File, though.

(And is there a Resource object?)

No, there isn't. There are many things named like it, but they are not a resource in the sense of ClassLoader.getResource.

Community
  • 1
  • 1
JvR
  • 1,034
  • 8
  • 8
  • Wow, very thorough. Just going through it, but already have the first follow-up question: When you say a File "contains only the name of the file", don't you contradict your initial statement that it's "An abstract representation of file and directory pathnames" - i.e.more? – Christian Nov 22 '16 at 12:26
  • 1
    @Christian I meant "only the name" as in: does not in any way model the contents of the file; it's merely a thin wrapper around a string. The "abstract representation" part is quoted from the API docs. ;) – JvR Nov 22 '16 at 15:53
  • This answer deserves to have much more upvotes... will update my accepted answer to point readers to this one. – Pavel Horal Apr 12 '17 at 09:45
45

UPDATE 2017-04-12 Check JvR's answer as it contains more exhaustive and exact explanation!

Please note that I do not consider myself 100% competent to answer, but nevertheless here are some comments:

  • File represents a file or directory accessible via file system
  • resource is a generic term for a data object which can be loaded by the application
    • usually resources are files distributed with the application / library and loaded via class-loading mechanism (when they reside on class-path)
  • URL#getPath is getter on the path part of URL (protocol://host/path?query)
  • URL#getFile as per JavaDoc returns path+query

In Java, URI is just a data structure for manipulating the generic identifier itself.

URL on the other hand is really a resource locator and offers you features to actually read the resource via registered URLStreamHandlers.

URLs can lead to file-system resources and you can construct URL for every file system resource by using file:// protocol (hence File <-> URL relation).

Also be aware that that URL#getFile is unrelated to java.io.File.

Why do I need File object; why isn't a Resource (URL) enough?

It is enough. Only if you want to pass the resource to some component which can work only with files, you need to get File from it. However not all resource URLs can be converted to Files.

And is there a Resource object?

From the JRE point of view, it's just a term. Some frameworks provide you with such class (e.g. Spring's Resource).

Community
  • 1
  • 1
Pavel Horal
  • 16,843
  • 2
  • 59
  • 84
  • 6
    There's also `java.nio.file.Path`, which is basically a (Java 7+) replacement for `java.io.File`, as the latter API was apparently poorly thought out in the early days of Java. – ntoskrnl Jan 08 '15 at 18:27
  • 1
    Generally, you should minimize usage of URL unless it is absolutely needed. The reason is that the URL's [equals](http://docs.oracle.com/javase/8/docs/api/java/net/URL.html#equals-java.lang.Object-) and [hashCode](http://docs.oracle.com/javase/8/docs/api/java/net/URL.html#hashCode--) methods are implemented in a surprising way: they are blocking method calls. – kibibyte Jan 15 '15 at 02:37
  • 3
    @kibibyte: I would expect the call to be blocking, to have an asynchronous implementation of hashcode and equals now that would be very unsettling. I think what you meant is that the calls will try and resolve the host to find if they are equivalent and thus could potentially make blocking network calls. – Newtopian Jan 29 '16 at 15:44
12

Pavel Horal's answer is nice.

As he says, the word "file" has totally different (practically unrelated) meanings in URL#getFile vs java.io.File - may be that's part of the confusion.

Just to add:

  • A resource in Java is an abstract concept, a source of data that can be read. The location (or address) of a resource is represented in Java by a URL object.

  • A resource can correspond to a regular file in the local filesystem (specifically, when its URL begins with file://). But a resource is more general (it can be also some file stored in a jar, or some data to be read from the network, or from memory, or...). And it's also more limited, because a File (besides being other things than a regular file: a directory, a link) can also be created and writen to.

  • Remember in Java a File object does not really represents "a file" but the location (the full name, with path) of a file. So, a File object allows you to locate (and open) a file, as a URLallows you to access (and open) a resource. (There is no Resource class in Java to represent a resource, but neither there is one to represent a file! once more : File is not a file, it's the path of a file).

Community
  • 1
  • 1
leonbloy
  • 65,169
  • 19
  • 130
  • 176
3

As I understand them, you could categorize them as following:

Web-Based: URIs and URLs.

  • URLs: An URL is a definite location on the internt (just a normal webaddress like - stackoverflow.com)
  • URIs: Ever URL is an URI. But URIs can also contain things like "mailto:", so they are also, well some what of a "script" I'd say.

And local: Resource, Path and Files

  • Resource: Resources are files inside your jar. They are used to load files out of jars / containers.
  • Path: A path is basically a string. But it comes with some handy functions to concatenate multiple strings, or add files to a string. It makes sure the path you are building is valid.
  • File: This is a reference to a directory or file. It's used to modify files, open them etc.

It would be easier if they would be merged into one class - they are really confusing :D

I hope this helps you :)

(I just took a look at the documentation - look at docs.oracle.com)

Cyphrags
  • 508
  • 1
  • 7
  • 16
0

A File is an abstract representation of an entity in the local filesystem.

A path is generally a string indicating the location of a file within a file system. It usually doesn't include the filename. So c:\documents\mystuff\stuff.txt would have a path with the value of of "C:\documents\mystuff" Obviously the format of absolute filenames and paths would vary enormously from filesystem to filesystem.

URL is a susbset of URI with URL usually representing resources accessible over http. I don't think there is any sort of ironclad rule about when something has to be a URI vs a URL. URIs are strings in the form of "protocol://resource-identifier" such as bitcoin://params, http://something.com?param=value. Classes like URL generally wrap the string and provide utility methods that String would have no reason to supply.

No such thing as Resource, at least not in the sense you're talking about. Just because a method is named getResource doesn't mean it returns an object of type Resource.

Ultimately the best way to figure out what a Class's methods do is to create an instance of it in your code, call the methods and then either step through in debug mode or send the results to System.out.

Jim W
  • 482
  • 2
  • 11