Description bungeman 2009-09-16 14:41:19 EDT

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.13) Gecko/2009080315 Ubuntu/9.04 (jaunty) Firefox/3.0.13
Build Identifier: M20090211-1700

The current code to read and write the bundles.info file uses the default encoding. For example in org.eclipse.equinox.internal.simpleconfigurator.utils.SimpleConfiguratorUtils#readConfiguration(URL, URI)

r = new BufferedReader(new InputStreamReader(url.openStream()));

should be

r = new BufferedReader(new InputStreamReader(url.openStream(), Charset.forName("UTF-8"));

The writer would need to be updated similarly.

There is an RCP application for which a bundles.info is generated during the build. Currently this is not a problem as all of the bundle names contain only lower ASCII characters which map the same in almost any character set. However, should there ever be a bundle with an odd name in the future, the bundles.info encoded on the build machine may not deserialize correctly on a customer machine with a different default encoding. A similar situation could occur in the rarer case that the default encoding should change.

Reproducible: Always

Steps to Reproduce:
1. Generate a bundles.info file with a bundle in a file named ಠ_ಠ.jar (note that this is "\u3232_\u3232.jar", as I realize bugzilla may bugger it up itself, or you may not have a font with this glyph).
2. Change the default character set, or move the file to a machine with a different default character set.
3. Watch the a jar not get picked up as a bundle.



characters != bytes && !plainTextFile.exists()