path for loading images when using packages

[Brandon McCombs]

hello,

Tonight I started to structure all my classes using packages and after
getting all the 'package' and 'import' statements working properly I ran
into issues with the code that loads images (nullpointer exceptions).
They were all working prior to the package changeover.

Previously I had this:
setIcon(new ImageIcon(LDAPMgr.class.
getResource("images/contIcon.gif")));

This works for images as long as they are within the JAR file:
setIcon(new ImageIcon(LDAPMgr.class.
getResource("/org/rekkanoryo/ldapmgr/utilities/resources/contIcon.gif")));

The problem is that I don't want to have to specify the whole path. Is
there a relative path I can use? If so, what other statements are needed
to allow relative paths?

Also, I need the ability for the loading of images to work from within
the packaged JAR file but also through the context of the filesystem and
it doesn't seem like the new code above will work for files that are
loaded from outside the JAR file in the file system so what can I do to
fix images that load that way?

From the filesystem I used to use this(the initial filename is from the
JAR file for the default photo but the method I use has to work with
images that aren't in the JAR that a user may load from anywhere on disk):

fileName = "images/noPhoto.gif";
image = tk.getImage(LDAPMgr.class.getResource(fileName));


thanks

 

[Brandon McCombs]

hello,

Tonight I started to structure all my classes using packages and after
getting all the 'package' and 'import' statements working properly I ran
into issues with the code that loads images (nullpointer exceptions).
They were all working prior to the package changeover.

Previously I had this:
setIcon(new ImageIcon(LDAPMgr.class.
getResource("images/contIcon.gif")));

This works for images as long as they are within the JAR file:
setIcon(new ImageIcon(LDAPMgr.class.
getResource("/org/rekkanoryo/ldapmgr/utilities/resources/contIcon.gif")));

The problem is that I don't want to have to specify the whole path. Is
there a relative path I can use? If so, what other statements are needed
to allow relative paths?

Also, I need the ability for the loading of images to work from within
the packaged JAR file but also through the context of the filesystem and
it doesn't seem like the new code above will work for files that are
loaded from outside the JAR file in the file system so what can I do to
fix images that load that way?

From the filesystem I used to use this(the initial filename is from the
JAR file for the default photo but the method I use has to work with
images that aren't in the JAR that a user may load from anywhere on disk):

fileName = "images/noPhoto.gif";
image = tk.getImage(LDAPMgr.class.getResource(fileName));


thanks

Seems that the tk.getImage() method works with specifying the package
path of the image (at least when running the app in Eclipse; a regular
JAR may have issues yet). I found a couple lines in my code that needed
updated so now I just need to have tips on shortening the package path
for the images (without just storing the path in a String but maybe
that's the only way).

thanks

 

[John Ersatznom]

Seems that the tk.getImage() method works with specifying the package
path of the image (at least when running the app in Eclipse; a regular
JAR may have issues yet). I found a couple lines in my code that needed
updated so now I just need to have tips on shortening the package path
for the images (without just storing the path in a String but maybe
that's the only way).

I'd just stuff the path in a String and concatenate the filename. The
other thing you could do is actually shorten the package name (in your
source file directory structure and your "package" and "import" statements).

Users loading files from arbitrary, user-supplied disk files is
different yet -- just get a filename or File object and load the image
via ImageIO rather than using getResource. Stuff that's self-contained
with your app, such as widget graphics, goes in the JAR and is got with
getResource; everything else is done with "normal" I/O. I think there
are AWT methods to read images from arbitrary disk files as well as the
ImageIO class (the latter's in Java 5 and later, but no earlier I think).

 

[John Ersatznom]

I'd just stuff the path in a String and concatenate the filename.

Say, does anyone know if code like:

private static final String foo = "some literal string";


someStringAcceptingMethod(foo + "another literal");

gets optimized by typical compilers to output the same bytecode for the
method call as if a single string literal had been used, without any
messy temporary StringBuffers under the hood? In theory it could do so
without violating the language specs, since strings are immutable and it
can prove that foo hasn't changed (the optimization is no longer safe if
"final" is removed from foo's declaration of course). It would still
need to keep foo as a separate literal in the string constant pool if
it's referenced in any situation that doesn't append anything static to
it, of course, though maybe not "another literal" if that occurs nowhere
else in the class.

 

[Chris Uppal]

Say, does anyone know if code like:

private static final String foo = "some literal string";


someStringAcceptingMethod(foo + "another literal");

gets optimized by typical compilers to output the same bytecode for the
method call as if a single string literal had been used, without any
messy temporary StringBuffers under the hood?

Not only do some Java compilers do it, but all Java compilers are /required/ to
do it -- the details are part of the Java language spec (I can't be bothered to
look up the relevent section of the JLS offhand).

-- chris

 

[Lew]

Not only do some Java compilers do it, but all Java compilers are /required/ to
do it -- the details are part of the Java language spec (I can't be bothered to
look up the relevent section of the JLS offhand).

Not true. According to JLS 3.10.5,
"String literals-or, more generally, strings that are the values of constant
expressions (§15.28)-are "interned" so as to share unique instances, using the
method String.intern."

That only applies to literals.

It goes on to say,
"Strings computed by concatenation at run time are newly created and therefore
distinct."

The expression 'foo + "another literal" ' is computed by concatenation at run
time, so it is distinct.

- Lew

 

[John W. Kennedy]

Not true. According to JLS 3.10.5,
"String literals-or, more generally, strings that are the values of
constant expressions (§15.28)-are "interned" so as to share unique
instances, using the method String.intern."

That only applies to literals.

No, it applies to literals and constant expressions.

A final initialized String is a "constant variable" (4.12.4).

An expression containing only constant variables and literals is a
constant expression.

 

[Lew]

No, it applies to literals and constant expressions.

A final initialized String is a "constant variable" (4.12.4).

An expression containing only constant variables and literals is a
constant expression.

Man, I never get tired of learning this language. It is delightfully nuanced.

Thank you for the clarification.

-Lew