Go: Fix Java.util.MissingResourceException:Can ' t find bundle for base name com ... Config, locale zh_cn error

Solve Java.util.MissingResourceException:Can ' t find bundle for base name com ... Config, Locale zh_cn

At Java.util.ResourceBundle.throwMissingResourceException (resourcebundle.java:836)
At Java.util.ResourceBundle.getBundleImpl (resourcebundle.java:805)
At Java.util.ResourceBundle.getBundle (resourcebundle.java:576)

You know Java are looking for a properties file in a specific locale.  You are baffled why Java keeps complaining it can ' t find a properties file which is right there. A few things to keep on mind when debugging this type of errors:

1. These resource properties files is loaded by ClassLoader, similar to Java classes.  so you need to include them in your runtime classpath.
2. These resources has fully-qualified-resource-name, similar to a fully-qualified-class-name, and excerpt you can ' t import A resource into your Java source file.  why? Because its name takes the form of a string.
   
   
3. resourcebundle.getbundle ("config") tells the ClassLoader to load a resource named " Config " with default package (that's, no package) .  It does not mean a resource in the current package that H As the referencing class.
4. Resourcebundle.getbundle ("Com.cheng.scrap.config") tells The ClassLoader to load a resource named "config" with package "Com.cheng.scrap."   its fully-qualified-resource-name is "Com.cheng.scrap.config"

For instance. A project like


C:\WS\NETBEANS5\SCRAP>
|   build.xml
+---Build
|   \---Classes
|       \---com
|            \---Cheng
|                \---Scrap
|                        Scrap.class
|
+---src
|   \---com
|       \---cheng
|            \---Scrap
|                    config.properties
|                    Scrap.java



For the statement in Scrap.java:ResourceBundle config = resourcebundle.getbundle ("config"); To work, you'll need to  CP src\com\cheng\scrap\config.properties build\classes\ such that conf Ig.properties is directly under classes , and at the same level as com .  alternativel Y, you can put config.properties to a Config.jar such that config.properties is a t the root of Config.jar without any subdirectories, and include Config.jar in the classpath.

Scrap.java: ResourceBundle config = ResourceBundle.getBundle("com.cheng.scrap.config"); for the statement in to work, you'll need to such that's cp src\com\cheng\scrap\config.properties build\classes\ com\cheng\scrap\ config.properties directly under classes \ com\cheng\scrap\ , an  D at the same level as scrap . Alternatively, can put com\cheng\scrap\ config.properties (along with the long subdirectories) into a config.jar ,and include config.jar in the classpath.  

You are wondering why are it made so confusing? The benefits is Two-fold, as I see it:

1. Location transparency.  At runtime, Config.properties was not a file, it's just a loadable resource. Config.properites exist in your project at all, and the person who wrote Scrap.java could have never seen this Resou  Rce.  A urlclassloader can find it in a network path or URL at runtime. This was especially important for server-side components such as EJBS, Servlets, JSPs, etc, who was normally not allowed to AC  Cess file systems. When your ask classloaders for a resource, it physical location becomes irrelevant.
2. Namespace mechanism. Having a package allows multiple packages to has the resources with the same short name without causing conflicts. This was no different from Java packages and XML namespaces.

Go: Fix Java.util.MissingResourceException:Can ' t find bundle for base name com ... Config, locale zh_cn error