Reading resource files from a jar file

[Martin Gregorie]

I have a configuration file intentionally buried in a jar file I'm
building (and a tool to amend it before you ask). This is all working
correctly but could possibly have been done better.

Yesterday I searched for documentation on doing this type of thing but
couldn't find anything in the standard Java 6 documentation.
Embarrassingly, I can't even find the description of how to set it up
that I used in the first place. I'm probably missing something obvious,
so pointers on where to find this information would be most welcome.

The reason I need the documentation: I can write code that uses an
InputStream to read the configuration file provided its in the same
package as the class that reads it, but would prefer to put the file in
the root of the jar file. Is it mandatory for the file to be in the same
package as its reader or is there a way of accessing it when its placed
elsewhere?

 

[Nigel Wade]

I have a configuration file intentionally buried in a jar file I'm
building (and a tool to amend it before you ask). This is all working
correctly but could possibly have been done better.

Yesterday I searched for documentation on doing this type of thing but
couldn't find anything in the standard Java 6 documentation.
Embarrassingly, I can't even find the description of how to set it up
that I used in the first place. I'm probably missing something obvious,
so pointers on where to find this information would be most welcome.

The reason I need the documentation: I can write code that uses an
InputStream to read the configuration file provided its in the same
package as the class that reads it, but would prefer to put the file in
the root of the jar file. Is it mandatory for the file to be in the same
package as its reader or is there a way of accessing it when its placed
elsewhere?

Specify a class within the relevant jar as the "reference" for getClass,
then use an absolute path for the resource itself.

 

[John B. Matthews]

Specify a class within the relevant jar as the "reference" for
getClass, then use an absolute path for the resource itself.

Here's an example:

<http://robotchase.svn.sourceforge.net/viewvc/robotchase/trunk/src/org/gc
s/robot/RCImage.java?revision=64&view=markup>

 

[Martin Gregorie]

Here's an example:

<http://robotchase.svn.sourceforge.net/viewvc/robotchase/trunk/src/org/ gc
s/robot/RCImage.java?revision=64&view=markup>

So the 'absolute path' takes the class's package as its root. Gotcha.

 

[Roedy Green]

I have a configuration file intentionally buried in a jar file I'm
building (and a tool to amend it before you ask). This is all working
correctly but could possibly have been done better.

see http://mindprod.com/jgloss/resource.html
and http://mindprod.com/jgloss/image.html
for a number of examples.

The trickiest part is deciding whether to put the resource in a
package or in the root, then looking in the right place for it.

 

[John B. Matthews]

gcs/robot/RCImage.java?revision=64&view=markup>

So the 'absolute path' takes the class's package as its root. Gotcha.

Empirically, yes. It's my best interpretation of the getResource() API:

<http://java.sun.com/javase/6/docs/api/java/lang/Class.html#getResource(java.lang.String)>

 

[Lew]

Empirically, yes. It's my best interpretation of the getResource() API:

<http://java.sun.com/javase/6/docs/api/java/lang/Class.html#getResource(java.lang.String)>

I think you have that backwards.

AIUI, an absolute resource path (starts with '/') is relative to the class
path, and a relative path (doesn't start with '/') is relative to the
"modified_package_name".

I am citing from the link provided. Plus, when I've run tests, I've observed
behavior consistent with my interpretation.

The wiggle room comes from
"The rules for searching resources associated with a given class are
implemented by the defining class loader of the class."

So class loaders can change these rules.

 

[Daniel Pitts]

I have a configuration file intentionally buried in a jar file I'm
building (and a tool to amend it before you ask). This is all working
correctly but could possibly have been done better.

Yesterday I searched for documentation on doing this type of thing but
couldn't find anything in the standard Java 6 documentation.
Embarrassingly, I can't even find the description of how to set it up
that I used in the first place. I'm probably missing something obvious,
so pointers on where to find this information would be most welcome.

The reason I need the documentation: I can write code that uses an
InputStream to read the configuration file provided its in the same
package as the class that reads it, but would prefer to put the file in
the root of the jar file. Is it mandatory for the file to be in the same
package as its reader or is there a way of accessing it when its placed
elsewhere?

There is Class.getResource*, but you probably want ClassLoader.getResource*

My understanding is that The Class.getResource looks in the same package
as the class, where ClassLoader.getResource looks relative to the
class-path roots which it knows about.

 

[Lew]

There is Class.getResource*, but you probably want ClassLoader.getResource*

My understanding is that The Class.getResource looks in the same package
as the class, where ClassLoader.getResource looks relative to the
class-path roots which it knows about.

See the link provided by John B. Matthews and the corresponding entry in
the 'ClassLoader' Javadocs.

The 'Class' version's behavior depends on the presence or absence of a
leading '/' (slash) in the resource path. Without the leading slash,
the resource is found relative the class's package, with the slash it's
to the class path.

 

[Martin Gregorie]

See the link provided by John B. Matthews and the corresponding entry in
the 'ClassLoader' Javadocs.

The 'Class' version's behavior depends on the presence or absence of a
leading '/' (slash) in the resource path. Without the leading slash,
the resource is found relative the class's package, with the slash it's
to the class path.

Thanks to all in this thread. I've made notes, read the docs for the
Class and ClassLoader methods and now think I know enough to do what I
wanted to do.

 

[John B. Matthews]

Empirically, yes. It's my best interpretation of the getResource() API:

<http://java.sun.com/javase/6/docs/api/java/lang/Class.html#getResource(java

..lang.String)>

I think you have that backwards.

AIUI, an absolute resource path (starts with '/') is relative to the class
path, and a relative path (doesn't start with '/') is relative to the
"modified_package_name".

I am citing from the link provided. Plus, when I've run tests, I've observed
behavior consistent with my interpretation.

The wiggle room comes from
"The rules for searching resources associated with a given class are
implemented by the defining class loader of the class."

So class loaders can change these rules.[/QUOTE]

You've elucidated a subtle point that I'd overlooked previously: The
leading '/' is a convenient notation in Class#getResource(); package
names don't have a leading '.' to modify. The corresponding method in
ClassLoader returns null when given a leading '/'.