If I only stored "Images/foo.gif" in config file, someone looking at the
code would have to *INFER* that it was in a jar and was going to be obtained
via this.getClass().getResource(). But what if I wanted to be able to
specify a file that wasn't necessarily in the classpath? The file could be
anywhere, even online or elsewhere in the file system.

"Images/foo.gif" is not going to be found by the program if it is *not* in a
jar on the classpath. In fact, I wouldn't be able to use
this.getClass().getResource() to find it; if it was in a standalone file in
the file system, I'd do this:

File myFile = new File(filename);
URL fileURL = myFile.toURL();

It seems to me that if you clearly and unambiguously notate the origins of a
file, including the protocol name and the jar name (where applicable!) as
well as the path(s) and the specific file name, anyone maintaining the code
is going to be very clear on exactly where that file is. The only wrinkle is
that I'm not aware of a standard way of saying that a file is in a jar on
the classpath and we don't need to know the jar name. That's why I'm
proposing the notation that I mentioned.

However, for all I know, there is already an existing convention to get the
same idea across which differs from mine. If so, I'd like to use the already
established notation, whatever it is, rather than muddying the waters by
using a different notation.

In a sense, I suppose this is basically about making the code both
self-documenting and flexible. Rather than relying on someone to write and
maintain comments in your imaginary config file saying that the file is
found in a jar on the classpath, I'd like to be able to point to any file in
the file system or online (or in a jar that is in the filesystem or online
or in the classpath) and be confident that program would use the appropriate
methods to find the file based on the way the file location was notated.

Am I making sense yet? :-)

I'm glad we're having this dialog, it is helping me clarify in my own mind
what I'm trying to accomplish and why it seems useful.

Rhino

You might be on to something there! Hmm, let me think that over a bit....

Rhino

Would anyone care to compose a paragraph outlining what you have to do
to add a new protocol handler? I would like to add this to the java
glossary.

What Interface(s) do you have to implement?
What do you do to get it registered on the list so that your code will
get called when someone does.

URL url = new URL( "weird://www.billabong.com:80/songs/lyrics.txt" );
URLConnection urlc = url.openConnection();

I know this is possible because a team I worked on added a number of
custom protocol handlers to deal with various stock market ticker
streams.

Yes, I think this is the heart of the issue. I really only _need_ a
convention/notation/protocol for use within my own programs; however, I'm
_hoping_ to find something that other people would understand fairly
intuitively if they tried to maintain my code. The ideal would be to come up
with a standardized way of saying "the file is in some jar of the classpath
but we don't need it's name" that the whole industry would understand and
accept.

Even better, an overall convention on describing the position of ANY piece
of information would be wonderful. It would be really neat to see a concise,
descriptive way of noting the location of a piece of data, even if was in a
database or on a network share or a floppy disk in someone's house. Then,
just hand that location to a blackbox method that will return the data in
the file, assuming the "data source" is actually available (e.g. the floppy
disk is actually in someone's drive) and there are no security roadblocks
(e.g. there are no file permissions or access issues for that particular
piece of data).

Yes, I agree, "protocol" may not be the right word for this; but if there is
an existing word that is more suitable, I haven't thought of what it is.
Maybe this needs a new noun - maybe a "Fritsch" or a "Rhino" - but let's put
that aside for now :-)

Damn! I'm starting to like this idea a lot! This approach would make it
pretty easy for others to adopt this new "protocol" too. Eventually, it
could become part of the API itself so that it wouldn't have to be loaded
separately.

I'm going to mull this over a bit; I may just decide to take this further.
But I need to think about what my own application needs first before I get
too caught up in this :-)

Thanks for your very interesting suggestions!

Rhino