| (no subject) [message #695605] |
Tue, 12 July 2011 06:17  |
Eclipse User |
|
|
|
Originally posted by:
We have some rare situations, where we use a ResourceBundle within
Eclipse RCP code where the resource contents are *only* queried in
dynamic form, i.e. via the ResourceBundle.getString() function and such
that the argument of this string are no compile-time constants. In this
case we already use the "old" form of a ResourceBundle without named
constants that would be without any use.
The problem is, that the otherwise very useful Eclipse tooling support
"Source > Find Broken Externalized Strings" applied to such a project
incorrectly warns about unused keys in the corresponding property file.
Does there exist a way to mark a property file or the corresponding
resource bundle such that they are ignored from this analysis?
Thanks & Greetings from Bremen,
Daniel Krügler
|
|
|
|
| (no subject) [message #695718 is a reply to message #695649] |
Tue, 12 July 2011 11:45  |
| Eclipse User |
|
|
|
Originally posted by:
On 2011-07-12 10:45, Daniel Megert wrote:
> On 12.07.2011 08:17, Daniel Krügler wrote:
>> We have some rare situations, where we use a ResourceBundle within
>> Eclipse RCP code where the resource contents are *only* queried in
>> dynamic form, i.e. via the ResourceBundle.getString() function and
>> such that the argument of this string are no compile-time constants.
>> In this case we already use the "old" form of a ResourceBundle without
>> named constants that would be without any use.
>>
>> The problem is, that the otherwise very useful Eclipse tooling support
>> "Source > Find Broken Externalized Strings" applied to such a project
>> incorrectly warns about unused keys in the corresponding property file.
>>
>> Does there exist a way to mark a property file or the corresponding
>> resource bundle such that they are ignored from this analysis?
>
> No. On the other hand: do you know *all* code paths so that you know for
> sure all the possible dynamic strings exist? ;-). If so, why not make
> them static?
In these special resource bundles, even the keys are generated
dynamically and thus there is no use for static constants. Yes, those
failures would be reported at runtime and that is ok in our use-case. I
mentioned that we intentionally switched to the old style of message
files here, because we hoped that the usage analysis would not apply for
these files. IMO there is no safe way for doing this analysis for those,
because you cannot statically proof whether pure dynamic queries like
String translate(ResourceBundle bundle, String key) {
return bundle.getString(key);
}
and where translate() gets dynamic string contents will use some
resource contents or whether it won't. I'm arguing that usage statics in
these cases is very questionable and misleading. In our case it had the
effect that some programmer unintentionally removed important resource
entries, because the Eclipse usage analysis gave a completely wrong
result. I'm fine with the existence of this analysis, but I'm strongly
arguing in favor for at least providing a way to mark a property file in
a way that this analysis is not performed.
Thanks,
- Daniel
|
|
|
| (no subject) [message #695767 is a reply to message #695718] |
Tue, 12 July 2011 13:55 |
 Dani Megert
Messages: 3802
Registered: July 2009 |
Senior Member |
|
|
On 12.07.2011 13:45, Daniel Krügler wrote:
> On 2011-07-12 10:45, Daniel Megert wrote:
>> On 12.07.2011 08:17, Daniel Krügler wrote:
>>> We have some rare situations, where we use a ResourceBundle within
>>> Eclipse RCP code where the resource contents are *only* queried in
>>> dynamic form, i.e. via the ResourceBundle.getString() function and
>>> such that the argument of this string are no compile-time constants.
>>> In this case we already use the "old" form of a ResourceBundle without
>>> named constants that would be without any use.
>>>
>>> The problem is, that the otherwise very useful Eclipse tooling support
>>> "Source > Find Broken Externalized Strings" applied to such a project
>>> incorrectly warns about unused keys in the corresponding property file.
>>>
>>> Does there exist a way to mark a property file or the corresponding
>>> resource bundle such that they are ignored from this analysis?
> >
>> No. On the other hand: do you know *all* code paths so that you know for
>> sure all the possible dynamic strings exist? ;-). If so, why not make
>> them static?
>
> In these special resource bundles, even the keys are generated
> dynamically and thus there is no use for static constants. Yes, those
> failures would be reported at runtime and that is ok in our use-case.
> I mentioned that we intentionally switched to the old style of message
> files here, because we hoped that the usage analysis would not apply
> for these files. IMO there is no safe way for doing this analysis for
> those, because you cannot statically proof whether pure dynamic
> queries like
>
> String translate(ResourceBundle bundle, String key) {
> return bundle.getString(key);
> }
>
> and where translate() gets dynamic string contents will use some
> resource contents or whether it won't. I'm arguing that usage statics
> in these cases is very questionable and misleading. In our case it had
> the effect that some programmer unintentionally removed important
> resource entries, because the Eclipse usage analysis gave a completely
> wrong result. I'm fine with the existence of this analysis, but I'm
> strongly arguing in favor for at least providing a way to mark a
> property file in a way that this analysis is not performed.
You can file an enhancement request against JDT Text - best along with a
patch ;-)
Dani
>
> Thanks,
>
> - Daniel
>
>
>
>
>
>
|
|
|
Powered by
FUDForum. Page generated in 1.30078 seconds
] 
Search
Help
Register
Login
Home
