MissingResourceException: Can't find bundle for base name sun.util.logging.resources.logging, locale en_US
Asked Answered
D

2

6

I am getting,

Caused by java.lang.InternalError: java.util.MissingResourceException: Can't find bundle for base name sun.util.logging.resources.logging, locale en_US 

in my application from firebase crash report.

Other details

Manufacturer: HTC
Model: HTC 10 
Android API: 24 

Here is the stack trace

java.util.logging.Logger$1.run (Logger.java:1385)
java.util.logging.Logger$1.run (Logger.java:1379)
java.security.AccessController.doPrivileged (AccessController.java:41)
java.util.logging.Logger.findSystemResourceBundle (Logger.java:1378)
java.util.logging.Logger.findResourceBundle (Logger.java:1425)
java.util.logging.Logger.setupResourceInfo (Logger.java:1523)
java.util.logging.Logger.<init> (Logger.java:266)
java.util.logging.Logger.<init> (Logger.java:261)
java.util.logging.LogManager$SystemLoggerContext.demandLogger (LogManager.java:734)
java.util.logging.LogManager.demandSystemLogger (LogManager.java:399)
java.util.logging.Logger.getPlatformLogger (Logger.java:474)
java.util.logging.LoggingProxyImpl.getLogger (LoggingProxyImpl.java:41)
sun.util.logging.LoggingSupport.getLogger (LoggingSupport.java:100)
sun.util.logging.PlatformLogger$JavaLoggerProxy.<init> (PlatformLogger.java:636)
sun.util.logging.PlatformLogger$JavaLoggerProxy.<init> (PlatformLogger.java:631)
sun.util.logging.PlatformLogger.<init> (PlatformLogger.java:246)
sun.util.logging.PlatformLogger.getLogger (PlatformLogger.java:205)
java.net.CookieManager.put (CookieManager.java:262)
okhttp3.JavaNetCookieJar.saveFromResponse (JavaNetCookieJar.java:47)
okhttp3.internal.http.HttpHeaders.receiveHeaders (HttpHeaders.java:182)
okhttp3.internal.http.BridgeInterceptor.intercept (BridgeInterceptor.java:95)
okhttp3.internal.http.RealInterceptorChain.proceed (RealInterceptorChain.java:92)
okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept (RetryAndFollowUpInterceptor.java:120)
okhttp3.internal.http.RealInterceptorChain.proceed (RealInterceptorChain.java:92)
okhttp3.internal.http.RealInterceptorChain.proceed (RealInterceptorChain.java:67)
okhttp3.RealCall.getResponseWithInterceptorChain (RealCall.java:185)
okhttp3.RealCall.execute (RealCall.java:69)

Here is the relevant Logger code

private static ResourceBundle findSystemResourceBundle(final Locale var0) {
        return (ResourceBundle)AccessController.doPrivileged(new PrivilegedAction() {
            public ResourceBundle run() {
                try {
                    return ResourceBundle.getBundle("sun.util.logging.resources.logging", var0, ClassLoader.getSystemClassLoader());
                } catch (MissingResourceException var2) {
                    throw new InternalError(var2.toString());
                }
            }
        });
    }

I have got crash report for locale en_AU too.

Since the crashing code is not controlled by me, how do I prevent this crash?

Dacosta answered 26/6, 2017 at 9:6 Comment(5)
Seems to be this issue: github.com/square/okhttp/issues/3334Forefather
@Dacosta Post your directory structure?Evaleen
Are you using proguard?Pleasant
Please add code which is calling method- findSystemResourceBundle.Timeous
@MimmoGrottoli YesDacosta
S
5

Analysis:

MissingResourceException: Can't find bundle for base name sun.util.logging.resources.logging, locale en_US

The system generates candidate bundle names

sun/util/logging/resources/logging_en_US
sun/util/logging/resources/logging_en
sun/util/logging/resources/logging

For each candidate bundle name, it attempts to load a resource bundle:

First, it attempts to load a class using the generated class name.

If such a class can be found and loaded using the specified class loader, is assignment compatible with ResourceBundle, is accessible from ResourceBundle, and can be instantiated, getBundle creates a new instance of this class and uses it as the result resource bundle.

Otherwise, getBundle attempts to locate a property resource file using the generated properties file name.

It generates a path name from the candidate bundle name by replacing all "." characters with "/" and appending the string ".properties". It attempts to find a "resource" with this name using java.lang.ClassLoader.getResource(java.lang.String). (Note that a "resource" in the sense of getResource has nothing to do with the contents of a resource bundle, it is just a container of data, such as a file.) If it finds a "resource", it attempts to create a new PropertyResourceBundle instance from its contents. If successful, this instance becomes the result resource bundle.

Have a more detailed look here how a ressource is resolved.

Since the system is looking in the classpath for any of these files in descending order (usually there are no _en*.properties)

sun/util/logging/resources/logging_en_US.properties
sun/util/logging/resources/logging_en.properties
sun/util/logging/resources/logging.properties

it would be a workaround to add such a file (or a class as mentioned above) to your app. The content of the property files looks like this:

# Localizations for Level names.  For the US locale
# these are the same as the non-localized level name.

# The following ALL CAPS words should be translated.
ALL=All
# The following ALL CAPS words should be translated.
SEVERE=Severe
# The following ALL CAPS words should be translated.
WARNING=Warning
# The following ALL CAPS words should be translated.
INFO=Info
# The following ALL CAPS words should be translated.
CONFIG= Config
# The following ALL CAPS words should be translated.
FINE=Fine
# The following ALL CAPS words should be translated.
FINER=Finer
# The following ALL CAPS words should be translated.
FINEST=Finest
# The following ALL CAPS words should be translated.
OFF=Off
Spade answered 5/7, 2017 at 6:43 Comment(4)
I will give it a shot. But the crash is happening only on HTC devices and API 24. So the resource bundle is available in other API and device combinations.Dacosta
I think the ressource bundle is usually part of android. It is just a workaround. I assume that on this device for some reason the classpath is corrupt or they forgot to add the resources or something prevents access to the jar.Spade
Hey, where do I add this file? Should I add it in the assets folder?Dacosta
The location of the propery file depends on your build tool. It should be located in a ressource folder of your project and end up in the java class path under "sun/util/logging/resources/logging.properties" in the end. I would probably create an extra project to build a jar only with this file and add it as dependency. For maven that would be creating "sun/util/logging/resources/logging.properties" under "/src/main/resources"Spade
G
3

If it works a resource file as suggested by the other answer is a better option, but if that doesn't pan out I have another option. Assuming that you don't need the logging you should be able to disable it like this:

try {
    Class<?> cls = Class.forName("sun.util.logging.PlatformLogger");
    Field field = cls.getDeclaredField("loggingEnabled");
    field.setAccessible(true);
    field.set(null, Boolean.FALSE);
} catch(Exception e) {
    // Failed
}

If you do that early the PlatformLogger should construct a DefaultLoggerProxy instead of a JavaLoggerProxy, so the broken code never runs. This is ugly as it depends on internal implementation details and as it disables logging, but perhaps it works for your application?

Gerald answered 5/7, 2017 at 8:40 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.