-
Bug
-
Resolution: Fixed
-
P3
-
9
-
java9-ea-u180
on pulling VirtualContainerBase into public scope, createVirtualFlow changed visibility from protected to package-private, thus fighting Its own api intent:
/**
* This enables skin subclasses to provide a custom VirtualFlow implementation,
* rather than have VirtualContainerBase instantiate the default instance.
*/
VirtualFlow<I> createVirtualFlow() {
return new VirtualFlow<>();
}
I would consider it a regression from fx8 (except that technically it probably isn't because the scope of the class changed) because the method was introduced (or made visible? dont remember) as a fix ofJDK-8103503 so hiding it now feels more like an accident.
Along with the factory method, it's getter must be protected as well, to not force illegal access attempts on developers.
/**
* This enables skin subclasses to provide a custom VirtualFlow implementation,
* rather than have VirtualContainerBase instantiate the default instance.
*/
VirtualFlow<I> createVirtualFlow() {
return new VirtualFlow<>();
}
I would consider it a regression from fx8 (except that technically it probably isn't because the scope of the class changed) because the method was introduced (or made visible? dont remember) as a fix of
Along with the factory method, it's getter must be protected as well, to not force illegal access attempts on developers.
- csr for
-
JDK-8191855 VirtualContainerBase: createVirtualFlow must be protected
-
- Closed
-
- relates to
-
JDK-8207942 Add new protected VirtualFlow methods for subclassing
-
- Resolved
-