Community
Participate
Working Groups
Created attachment 190145 [details] As JRE library use.jpg Using a pseudo translation language pack where all Latin characters are replaced with double-byte characters, entries in the "As JRE library use" preference dropdown box do not display. This problem will cause all translations in other languages to be displayed as question marks too. Test Data: ========== Replace the following string NewJavaProjectPreferencePage_jre_container_description=JRE container in eclipse\plugins\org.eclipse.jdt.ui\org\eclipse\jdt\internal\ui\preferences\PreferencesMessages.properties to NewJavaProjectPreferencePage_jre_container_description=[G'\uff2a\uff32\uff25 \uff43\uff4f\uff4e\uff54\uff41\uff49\uff4e\uff45\uff52\u0130\u0131\uff5c]
Need to fix this for 3.7.
Fixed in HEAD (NewJavaProjectPreferencePage.java, rev. 1.34). Available in builds >= N20110413-2000.
This part of the fix is a no-op: // Backwards compatibility check (before 3.7 M7 the name was also encoded) if (!description.equals(decodedDescription)) return decodedDescription; return description; It could just as well return decodedDescription. Wouldn't it better be this? if (!"".equals(decodedDescription)) //$NON-NLS-1$
(In reply to comment #3) > This part of the fix is a no-op: > > // Backwards compatibility check (before 3.7 M7 the name was also encoded) > if (!description.equals(decodedDescription)) > return decodedDescription; > > return description; Indeed! Fixed.
This caused a regression, see bug 347302 for details.
> This caused a regression, see bug 347302 for details. This is a critical issue. We'll revert the changes for this bug for 3.7. Note that this problem only happens when you use a translation pack with multi-byte characters, but the platform encoding from System.getProperty("file.encoding") cannot represent multi-byte characters. This is unlikely to occur in practice. When the platform encoding is e.g. UTF-8, then this bug is not reproducible any more. For 3.8, I think we should just hardcode NewJavaProjectPreferencePage#fgDefaultEncoding to "UTF-8".
Changing the encoding could be a problem for stored data. JDT does not store the encoded strings in the preferences. We just set the default preferences. Stored preferences could only come from third-party plug-ins that write preference values although the PreferenceConstants class API clearly says that clients must not do that. A fully backwards-compatible solution for bad clients would be to store a version along with the encoded library string and then do the decoding based on the version. A scheme to store the version could be: ' ' + version + ' ' + encode(desc) + ... The space at the beginning would indicate a new-style string. But I still think it's fine to just switch to "UTF-8". Just wanted to dump our findings and a possible backwards-compatible version scheme somewhere. (In reply to bug 347302 comment #14) > +1. Though you could leave in the changes to the comments. The comment changes should be released again along with this bug's fix.
Fixed in master http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=89b6316e31bfe1e38e0ebf5b73f38ec7c82be93c Verified that we don't bring back bug 347302.
