-
Bug
-
Resolution: Fixed
-
P4
-
9
-
b76
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8135809 | emb-9 | Daniel Fuchs | P4 | Resolved | Fixed | team |
JDK-8283529 | openjdk8u342 | Alex Kasko | P4 | Resolved | Fixed | b01 |
The class com.sun.org.appache.bcel.internal.util.ClassPath does not seem to serve any useful purpose in the JDK.
- There's only one instance created, using its default empty constructor.
- There's only one method called on that instance, from SyntheticRepository.java: _path.getInputStream(className);
- Because _path was created using the default (and deprecated) empty constructor, and because ClassPath is loaded from the BCL (ClassPath.class.getClassLoader() == null), then _path.getInputStream(className) will always throw an IOException.
Therefore - it seems that in the JDK - the use of com.sun.org.appache.bcel.internal.util.ClassPath is reduced to an elaborate means of throwing an IOException.
Whether we could remove this class should be investigated.
- There's only one instance created, using its default empty constructor.
- There's only one method called on that instance, from SyntheticRepository.java: _path.getInputStream(className);
- Because _path was created using the default (and deprecated) empty constructor, and because ClassPath is loaded from the BCL (ClassPath.class.getClassLoader() == null), then _path.getInputStream(className) will always throw an IOException.
Therefore - it seems that in the JDK - the use of com.sun.org.appache.bcel.internal.util.ClassPath is reduced to an elaborate means of throwing an IOException.
Whether we could remove this class should be investigated.
- backported by
-
JDK-8135809 jaxp: Investigate removal of com/sun/org/apache/bcel/internal/util/ClassPath.java
- Resolved
-
JDK-8283529 jaxp: Investigate removal of com/sun/org/apache/bcel/internal/util/ClassPath.java
- Resolved