JDK-8341659 : Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D
  • Type: CSR
  • Component: javafx
  • Sub-Component: graphics
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: jfx24
  • Submitted: 2024-10-07
  • Updated: 2024-12-13
  • Resolved: 2024-12-13
Related Reports
CSR :  
JDK-8339603 - Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D
Description
Summary
-------

Node, Camera, LightBase, Shape, and Shape3D cannot be extended by user code and will be sealed.

Problem
-------

None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. Since Java now supports sealed classes, we can turn a run-time error into a compile-time error.

Solution
--------

Seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead.
Comments
Moving to Approved; please keep my advised on results of discussions with the javadoc team.
13-12-2024
Actually, I see that you already list it for Node (it permits AbstractNode) even though it doesn't show up in the generated javadocs. Given that, I think it's OK to leave it as you have it.
13-12-2024
[~kcr] Regarding "without specifying the internal class in the spec", do you mean that I should remove the diffs for MediaView and SwingNode?
12-12-2024
I was thinking the same thing. Let's finalize it "as is", without specifying the internal class in the spec. I'll separately follow-up with the javadoc team on this.
12-12-2024
[~kcr] It doesn't seem to me that this should hold up this ticket.
12-12-2024
Hmm. Okay, there is a javadoc policy for how to display the less-than-fully-public superclass of a public class. For example, over in core libs, java.lang.{StringBuffer, StringBuilder} in their javadoc have java.lang.Object listed as their superclass but in the implementation they both directly extend the package-private AbstractStringBuilder. However, IIRC, there are other cases where javadoc will display a non-public type, such as implementing a package-private interface. I suggest checking with the javadoc team if they have any suggestions on how to finesse this situation. HTH
12-12-2024
My quick take on this is that it is a javadoc bug. The javadoc tool is perfectly happy to exclude classes in a non-exported package of the same module from the class hierarchy, but doesn't do the same across module boundaries in the presence of qualified exports between modules. If this is the case, the fact that the AbstractNode appears in the javadoc-generated API docs is a bug that we wouldn't want to specify. [~darcy] Does this seem reasonable to you?
10-12-2024
[~darcy] [~kcr] Any news on this issue?
08-12-2024
This looks good although I have a question for Joe about `MediaView` and `SwingNode`. These now extend the non-exported `com.sun.javafx.scene.AbstractNode` class. While that class is not accessible to applications, it does show up in the javadoc-generated API spec. [~darcy] What would you recommend for the spec in this case? Here are the diffs for those two classes: ``` --- a/modules/javafx.media/src/main/java/javafx/scene/media/MediaView.java +++ b/modules/javafx.media/src/main/java/javafx/scene/media/MediaView.java @@ -87,7 +88,7 @@ * * @since JavaFX 2.0 */ -public class MediaView extends Node { +public class MediaView extends AbstractNode { --- a/modules/javafx.swing/src/main/java/javafx/embed/swing/SwingNode.java +++ b/modules/javafx.swing/src/main/java/javafx/embed/swing/SwingNode.java @@ -114,7 +115,7 @@ * </pre> * @since JavaFX 8.0 */ -public class SwingNode extends Node { +public class SwingNode extends AbstractNode { ```
26-11-2024
Moving to Provisional, not Approved.
07-10-2024