An abstract, generic piece of data that can be located and read.
It does not have a direct class or interface representation in Java
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.
@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. ;)
An abstract representation of file and directory pathnames.
An object that may be used to locate a file in a file system. It will typically represent a system dependent file path.
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.
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.
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.
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...
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.
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.
Lastly - and most importantly - why do I need File object; why isn't a Resource (URL) enough?
No, there isn't. There are many things named like it, but they are not a resource in the sense of ClassLoader.getResource.
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.
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?
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.
Represents a Uniform Resource Identifier (URI) reference.
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.
The host platform is represented through the "default file system"; when you call File.toPath, you get a Path on the default file system.
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.
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:
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.
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.
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.
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.
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.
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?
You don't need File if you have access to Path. Some older API may require File, though.