Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Platform » (no subject)
(no subject) [message #695605] Tue, 12 July 2011 06:17 Go to next message
Eclipse UserFriend
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 #695649 is a reply to message #695605] Tue, 12 July 2011 08:45 Go to previous messageGo to next message
Dani Megert is currently offline Dani MegertFriend
Messages: 3801
Registered: July 2009
Senior Member
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?

Dani
>
> Thanks & Greetings from Bremen,
>
> Daniel Krügler
(no subject) [message #695718 is a reply to message #695649] Tue, 12 July 2011 11:45 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous message
Dani Megert is currently offline Dani MegertFriend
Messages: 3801
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
>
>
>
>
>
>
Previous Topic:Mac OS X Eclipse.app Cant Find Java Virtual Machine
Next Topic:Custom javadoc
Goto Forum:
  


Current Time: Sat Nov 29 10:06:34 GMT 2014

Powered by FUDForum. Page generated in 0.02976 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software