So I'm pretty sure you don't need a URL. However, if you do, then the
best way to go is to get a File object first, and then say:
File file; // the file object you start with
URL url = file.toURI().toURL();
Then yes, you are perfectly fine using the URL to refer to files on the
local disk. This is actually guaranteed to work, as all Java virtual
machines are required to support the URL scheme for accessing local
files. However, since the exact syntax is platform-specific, the
conversion methods above are your best bet here.
I don't agree.
Because of my long experience with applets, I have come to loath
using File's for *reading* resources, except where absolutely necessary.
Note that while an URL can refer to a local File..
- A File cannot pull a resources.jar!/README.txt straight out of
the archive, while a (jar) URL can.
- A File cannot refer to a resource on an http site, or ftp, or..
About all I uses File's for is when I am working on the local system
in a fully trusted applet or application and need a
File.listFiles()/File.listFiles(FileFilter), or File.listRoots().
[ Oh, and all that *O* of I/O. ]
As a further note, you mention the "exact syntax is platform-specific"
as a downside. But how many times have you seen code similar to this?
File props = new File("resources\\properties.xml");
...use of File's can easily be made 'platform specific', purely by accident.
As far as getting a handle on the resource, I would recommend an
alternate route (where practical*).
Class.getResource() - removes the platform specific parts from needing
any programmer intervention, the rest is handled automatically (which
is good, since I have a devil of a time remembering the format of
those 'jar file' URL's!).
* Which it is not, if the resource is not on the classpath!
In any case, if I offer the end user a 'File' chooser, the returned File
will (generally) be converted to an URL within the next few code lines..