Featured White Papers

• Why choose an Open Source BPM?
• 10 FAQs on Business Process Management
• Best Practices for Getting Started with BPM
• Free Your Devs From The Pain Of Java Redeploys
• Increase Velocity 40% by Using JRebel
• What Developers Want: The End of Application Redeploys
• Developer Productivity Report: Java Tools, Tech, Devs, and Data
• Coding with JRebel: Java Forever Changed
• Utilizing Fast Testing to Transform Java Development
• 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

• APIs for Java Programmers: Manage & Convert DOC, XLS, PPT, PDF & More

• Instantly Preview Java Code Changes: JRebel.com

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