-
Bug
-
Resolution: Fixed
-
P3
-
7
-
b53
-
generic, x86
-
generic, linux
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2189551 | 6-pool | Xueming Shen | P3 | Closed | Won't Fix |
Builtin charsets can be trusted more than user-provided charsets,
and this provides optimization opportunities.
/**
* A {@link Charset} that is provided as part of the JDK.
* Such a charset guarantees that the following pathological
* conditions never occur:
*
* <ul>
* <li>no collisions among builtin charset names or aliases
* <li>the charset encoders and decoders never retain references to
* the source or destination arrays after a coding operation
* <li>the {@code Charset} constructors are always called with valid
* arguments
* </ul>
*
* <p>The default security manager enforces that user-provided
* charsets do not subclass this class.
*/
public abstract class BuiltinCharset extends Charset {
protected BuiltinCharset(String canonicalName, String[] aliases) {
super(canonicalName, aliases);
}
}
In particular, do the CharsetEncoder and CharsetDecoder constructors really need to
validate their input every single time, given that their parameters are build-time
constants in practice?
{#if[encoder]?protected:private}
Charset$Coder$(Charset cs,
float average$ItypesPerOtype$,
float max$ItypesPerOtype$,
$replType$ replacement)
{
this.charset = cs;
this.average$ItypesPerOtype$ = average$ItypesPerOtype$;
this.max$ItypesPerOtype$ = max$ItypesPerOtype$;
this.replacement = replacement;
if (cs instanceof sun.nio.cs.BuiltinCharset)
assertConstructorPreconditions(cs,
average$ItypesPerOtype$,
max$ItypesPerOtype$,
replacement);
else
checkConstructorPreconditions(cs,
average$ItypesPerOtype$,
max$ItypesPerOtype$,
replacement);
}
Also, the StringCoding class could do this to check for whether defensive copies
are necessary:
private static boolean charsetIsTrusted(Charset cs) {
return System.getSecurityManager() == null ||
cs instanceof sun.nio.cs.BuiltinCharset ||
cs.getClass().getClassLoader0() == null;
}
and this provides optimization opportunities.
/**
* A {@link Charset} that is provided as part of the JDK.
* Such a charset guarantees that the following pathological
* conditions never occur:
*
* <ul>
* <li>no collisions among builtin charset names or aliases
* <li>the charset encoders and decoders never retain references to
* the source or destination arrays after a coding operation
* <li>the {@code Charset} constructors are always called with valid
* arguments
* </ul>
*
* <p>The default security manager enforces that user-provided
* charsets do not subclass this class.
*/
public abstract class BuiltinCharset extends Charset {
protected BuiltinCharset(String canonicalName, String[] aliases) {
super(canonicalName, aliases);
}
}
In particular, do the CharsetEncoder and CharsetDecoder constructors really need to
validate their input every single time, given that their parameters are build-time
constants in practice?
{#if[encoder]?protected:private}
Charset$Coder$(Charset cs,
float average$ItypesPerOtype$,
float max$ItypesPerOtype$,
$replType$ replacement)
{
this.charset = cs;
this.average$ItypesPerOtype$ = average$ItypesPerOtype$;
this.max$ItypesPerOtype$ = max$ItypesPerOtype$;
this.replacement = replacement;
if (cs instanceof sun.nio.cs.BuiltinCharset)
assertConstructorPreconditions(cs,
average$ItypesPerOtype$,
max$ItypesPerOtype$,
replacement);
else
checkConstructorPreconditions(cs,
average$ItypesPerOtype$,
max$ItypesPerOtype$,
replacement);
}
Also, the StringCoding class could do this to check for whether defensive copies
are necessary:
private static boolean charsetIsTrusted(Charset cs) {
return System.getSecurityManager() == null ||
cs instanceof sun.nio.cs.BuiltinCharset ||
cs.getClass().getClassLoader0() == null;
}
- backported by
-
JDK-2189551 Optimize handling of builtin charsets
-
- Closed
-
- duplicates
-
JDK-6682541 Optimize Character en/decoding
-
- Closed
-
- relates to
-
JDK-7183053 Optimize DoubleByte charset for String.getBytes()/new String(byte[])
-
- Closed
-