Community
Participate
Working Groups
Build Identifier: org.eclipse.osgi.service.localization.BundleLocalization#getLocalization() does not state that it may return null. Reproducible: Always
I see a couple of cases where null may be returned. Out of curiosity, do you have a scenario we can use to reproduce the return of null? I am inclined to return an empty ResourceBundle as a fix instead of null. Updating the javadoc to all of a sudden state that null can be returned would be an incompatible change to the API contract in my opinion.
> I see a couple of cases where null may be returned. Out of curiosity, do you > have a scenario we can use to reproduce the return of null? The typical scenario is when developers forget to update their build.properties file to include the "OSGI-INF/" folder, containing their plugin.properties file. So, you don't see the problem during development; the NullPointerException only occurs in your built application. To reproduce at dev time, delete the bundle's localization file and then ask for it. I agree that returning EmptyResouceBundle instead of null would be better.
If we were allowed to I would opt to throw a MissingResourceException here. Thinking more on this I am not sure returning an empty ResourceBundle is the answer. Returning null is better because it indicates that there really was nothing found that we can read the ResourceBundle from. Returning an empty ResoureBundle may work around your NPE but it will mask the issue of not finding anything and likely make such a situation even more difficult to debug. Since this has been the behavior since the beginning I think it may be better to simply update the javadoc to indicate that null can be returned.
Created attachment 174080 [details] javadoc patch Javadoc updates.
(In reply to comment #3) > If we were allowed to I would opt to throw a MissingResourceException here. > Thinking more on this I am not sure returning an empty ResourceBundle is the > answer. Returning null is better because it indicates that there really was > nothing found that we can read the ResourceBundle from. If I call getLocalization(bundle, "pa-pk"), you wouldn't be able to throw a MissingResourceException even if the bundle isn't translated into Punjabi. The "default" locale (English) is always the fallback resource bundle, and its almost always present. > ResoureBundle may work around your NPE but it will mask the issue of not > finding anything and likely make such a situation even more difficult to debug. I disagree. Returning an empty resource bundle would result in a MissingResourceException as soon as you call getString on it, which is not difficult to debug. The NPE is difficult to debug because it can't be reproduced during development (the common culprit being build.properties).
John, I would like your opinion on this matter. org.eclipse.osgi.service.localization.BundleLocalization.getLocalization(Bundle, String) That method's javadoc makes no statement about ever returning null. The problem is the implementation has always returned null if no ResourceBundle can be found for the specified Bundle. The main consumer of this service in the Eclipse platform is the extension registry. I have reviewed the extension registry's usage of this API and it does expect null to be returned in this case. If we changed the implementation to all of a sudden return empty ResourceBundles instead then the extension registry is going to start seeing MissingResourceException when it tries to use the empty ResourceBundle. Currently the extension registry will detect null and instead will use some default value. So this will impact the extension registry if we change the behavior of the implementation. It could also impact other clients that may have been coding to the current behavior of the implementation. This service has been around since 3.0 and has always behaved this way (possibly returning null). 7 releases later I would prefer to update the javadoc to be inline with the implementation instead of changing the implementation to be in line with the javadoc.
Forgot to CC John. Please see comment 6 John.
The current javadoc doesn't state its behavior either way when the bundle has no localization defined. So this is more of a javadoc omission than a mismatch between spec and implementation. The lowest impact solution is certainly just to improve the javadoc (in line with current implementation) to cover that case.
I went ahead with the javadoc changes.
