Applied MS VJ++ workaround for jkesselm
git-svn-id: https://svn.apache.org/repos/asf/xml/commons/trunk@225930 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
parent
41208535c4
commit
a2a37eb4cf
@ -203,8 +203,29 @@ class FactoryFinder {
|
|||||||
|
|
||||||
if( is!=null ) {
|
if( is!=null ) {
|
||||||
debugPrintln("found " + serviceId);
|
debugPrintln("found " + serviceId);
|
||||||
BufferedReader rd =
|
|
||||||
new BufferedReader(new InputStreamReader(is, "UTF-8"));
|
// Read the service provider name in UTF-8 as specified in
|
||||||
|
// the jar spec. Unfortunately this fails in Microsoft
|
||||||
|
// VJ++, which does not implement the UTF-8
|
||||||
|
// encoding. Theoretically, we should simply let it fail in
|
||||||
|
// that case, since the JVM is obviously broken if it
|
||||||
|
// doesn't support such a basic standard. But since there
|
||||||
|
// are still some users attempting to use VJ++ for
|
||||||
|
// development, we have dropped in a fallback which makes a
|
||||||
|
// second attempt using the platform's default encoding. In
|
||||||
|
// VJ++ this is apparently ASCII, which is a subset of
|
||||||
|
// UTF-8... and since the strings we'll be reading here are
|
||||||
|
// also primarily limited to the 7-bit ASCII range (at
|
||||||
|
// least, in English versions), this should work well
|
||||||
|
// enough to keep us on the air until we're ready to
|
||||||
|
// officially decommit from VJ++. [Edited comment from
|
||||||
|
// jkesselm]
|
||||||
|
BufferedReader rd;
|
||||||
|
try {
|
||||||
|
rd = new BufferedReader(new InputStreamReader(is, "UTF-8"));
|
||||||
|
} catch (java.io.UnsupportedEncodingException e) {
|
||||||
|
rd = new BufferedReader(new InputStreamReader(is));
|
||||||
|
}
|
||||||
|
|
||||||
String factoryClassName = rd.readLine();
|
String factoryClassName = rd.readLine();
|
||||||
rd.close();
|
rd.close();
|
||||||
|
|||||||
@ -203,8 +203,29 @@ class FactoryFinder {
|
|||||||
|
|
||||||
if( is!=null ) {
|
if( is!=null ) {
|
||||||
debugPrintln("found " + serviceId);
|
debugPrintln("found " + serviceId);
|
||||||
BufferedReader rd =
|
|
||||||
new BufferedReader(new InputStreamReader(is, "UTF-8"));
|
// Read the service provider name in UTF-8 as specified in
|
||||||
|
// the jar spec. Unfortunately this fails in Microsoft
|
||||||
|
// VJ++, which does not implement the UTF-8
|
||||||
|
// encoding. Theoretically, we should simply let it fail in
|
||||||
|
// that case, since the JVM is obviously broken if it
|
||||||
|
// doesn't support such a basic standard. But since there
|
||||||
|
// are still some users attempting to use VJ++ for
|
||||||
|
// development, we have dropped in a fallback which makes a
|
||||||
|
// second attempt using the platform's default encoding. In
|
||||||
|
// VJ++ this is apparently ASCII, which is a subset of
|
||||||
|
// UTF-8... and since the strings we'll be reading here are
|
||||||
|
// also primarily limited to the 7-bit ASCII range (at
|
||||||
|
// least, in English versions), this should work well
|
||||||
|
// enough to keep us on the air until we're ready to
|
||||||
|
// officially decommit from VJ++. [Edited comment from
|
||||||
|
// jkesselm]
|
||||||
|
BufferedReader rd;
|
||||||
|
try {
|
||||||
|
rd = new BufferedReader(new InputStreamReader(is, "UTF-8"));
|
||||||
|
} catch (java.io.UnsupportedEncodingException e) {
|
||||||
|
rd = new BufferedReader(new InputStreamReader(is));
|
||||||
|
}
|
||||||
|
|
||||||
String factoryClassName = rd.readLine();
|
String factoryClassName = rd.readLine();
|
||||||
rd.close();
|
rd.close();
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user