-
Bug
-
Resolution: Unresolved
-
P4
-
18
Remove the terminally deprecated finalize() method from the java.awt.Graphics class and sub-classes
The java.awt.Graphics class defines
public void finalize() {
dispose();
}
which https://bugs.openjdk.java.net/browse/JDK-8276748 deprecates for removal.
The original design expectation was that sub-classes would appropriately implement
public abstract void dispose();
and this would release native resources held by a per-platform Graphics implementation class.
But a long time ago (JDK 1.4 or thereabouts) the need for this in the JDK implementation was obsoleted.
All the concrete subclasses in the implementation then needed to ensure they over-rode finalize() to
be an empty method to take advantage of a VM optimization which skipped finalization in such a case,
thus allowing more prompt garbage collection.
The implementation classes in question are :-
sun.java2d.SunGraphics2D.java
and several classes used in printing API implementation
sun.print.PeekGraphics.java
sun.print.ProxyGraphics.java
sun.print.ProxyGraphics2D.java
In theory, instances of the Graphics class are not created directly by library or application code.
Only the JDK implementation should create concrete sub-classes and then it hands them out where needed.
In practice, people have found that implementing java.awt.Graphics and java.awt.Graphics2D is a powerful
way to be able to get applications to be able to create documents in formats such as PDF with minimal code/changes.
The assumption is that at least some of these uses rely on finalize() to guarantee the release of resources,
or close output streams terminating rendering.
So until java.awt.Graphics no-longer defines finalize() for that use case we are blocked from removing
finalize() from the sub-classes.
But with a JEP in progress for deprecation of the entire finalization mechanism [1] and previewing its
later removal , it becomes moot.
Such libraries will have to migrate to a different mechanism such as java.lang.ref.Cleaner if they need it.
We need to remove all these methods above to enable moving ahead with removal of the finalization mechanism.
This needs to be done no earlier than the release after terminal deprecation of the API-visible finalize() method
and no later than the release when finalization usage would generate warnings and if possible, an earlier release.
[1] https://openjdk.java.net/jeps/421
The java.awt.Graphics class defines
public void finalize() {
dispose();
}
which https://bugs.openjdk.java.net/browse/JDK-8276748 deprecates for removal.
The original design expectation was that sub-classes would appropriately implement
public abstract void dispose();
and this would release native resources held by a per-platform Graphics implementation class.
But a long time ago (JDK 1.4 or thereabouts) the need for this in the JDK implementation was obsoleted.
All the concrete subclasses in the implementation then needed to ensure they over-rode finalize() to
be an empty method to take advantage of a VM optimization which skipped finalization in such a case,
thus allowing more prompt garbage collection.
The implementation classes in question are :-
sun.java2d.SunGraphics2D.java
and several classes used in printing API implementation
sun.print.PeekGraphics.java
sun.print.ProxyGraphics.java
sun.print.ProxyGraphics2D.java
In theory, instances of the Graphics class are not created directly by library or application code.
Only the JDK implementation should create concrete sub-classes and then it hands them out where needed.
In practice, people have found that implementing java.awt.Graphics and java.awt.Graphics2D is a powerful
way to be able to get applications to be able to create documents in formats such as PDF with minimal code/changes.
The assumption is that at least some of these uses rely on finalize() to guarantee the release of resources,
or close output streams terminating rendering.
So until java.awt.Graphics no-longer defines finalize() for that use case we are blocked from removing
finalize() from the sub-classes.
But with a JEP in progress for deprecation of the entire finalization mechanism [1] and previewing its
later removal , it becomes moot.
Such libraries will have to migrate to a different mechanism such as java.lang.ref.Cleaner if they need it.
We need to remove all these methods above to enable moving ahead with removal of the finalization mechanism.
This needs to be done no earlier than the release after terminal deprecation of the API-visible finalize() method
and no later than the release when finalization usage would generate warnings and if possible, an earlier release.
[1] https://openjdk.java.net/jeps/421