 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2007path for loading images when using packages
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 > hello, > [quoted text clipped - 29 lines] > > 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 > 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). > 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. > Say, does anyone know if code like: > [quoted text clipped - 5 lines] > 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 John Ersatznom wrote: >> Say, does anyone know if code like: >> [quoted text clipped - 4 lines] >> 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). 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 Ersatznom wrote: >>> Say, does anyone know if code like: [quoted text clipped - 18 lines] > > 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.  SignatureJohn W. Kennedy "The blind rulers of Logres Nourished the land on a fallacy of rational virtue." -- Charles Williams. "Taliessin through Logres: Prelude" > 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.