Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Got resources?

Two strategies for loading resource bundles and property files from Java code

By Vladimir Roubtsov, JavaWorld.com, 11/22/02

November 22, 2002

What is the difference between
Class.getResource() and ClassLoader.getResource()?

Because Class.getResource() eventually delegates to ClassLoader.getResource(), the two methods are indeed very similar. However, the first method is often preferable. It provides a nice extra feature: it looks up package-local resources. As an example, this code snippet

     getClass().getResource("settings.properties");

executed from a class some.pkg.MyClass looks for a resource deployed as some/pkg/settings.properties. You might wonder why this is better then the equivalent

getClass().getClassLoader().getResource("some/pkg/settings.properties");

The reason is the possibility for future refactoring. Should you decide to rename pkg to betterpkgname and move all classes and resources into the new package, the first code snippet requires no further code changes. The second code snippet embeds the old package name in a string literal—something that is easy to forget and can become a runtime error later.

Another advantage of Class.getResource() is that it does not require the getClassLoader runtime security permission, which the other approach requires.

I should mention a few extra details. Is it better to acquire the relevant Class object using the getClass() instance method or using MyClass.class? The answer depends on whether you plan to have classes in other packages extend MyClass. Since getClass() always returns the most derived class, it might return a class in a package different from some.pkg, possibly coded after MyClass is conceived. If this is a possibility, you should safeguard against potential lookup errors by using the class literal syntax form, MyClass.class. As an added benefit, it also works from static methods.

About the author