Bug ID: JDK-8101978 Add explicit dispose() method to MediaPlayer

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 7	JDK 8
7u40Fixed	8Fixed

Add explicit dispose() method to MediaPlayer.

Explicit dispose() method is needed to free native resources used by MediaPlayer. Garbage collector is not reliable enough to free native resources fast enough, thus when MediaPlayers are created fast enough we may run out of native memory. Normally, user does not need to call dispose() method on MediaPlayer if application does not create them often. After dispose() is called MediaPlayer cannot be used again and should be disregarded. Media and MediaView associated with disposed MediaPlayer can be reused. Dispose() will be valid in any states. For example, when player is playing call to dispose() will stop playback and release all resources.

Verified in 2.2.40.
24-07-2013
Adding 2.2.40 fix version since there was RTeam decision to port fix to 2.2.40
12-06-2013
See my comment in RT-30834.
05-06-2013
So, how can i fix the problem of RT-30834, where the Webview crashes every single time after playing a video..? This is a real problem for my software..we have a launch next week and it is the only problem left..since we rely a lot on Webviews, if they crash on a video the software is useless..
05-06-2013
WebView should call dispose() on MediaPlayer, when it is no longer needed. So user should not do this.
04-06-2013
Hello, just a quick question..how do you get a reference to a video playing within a webview so that you can call dispose() on it?
04-06-2013
MediaPlayer is asynchronous in it's nature. Its doesn't make sense to use it in try-with-resources clause because to get any information we need to register listeners and it's not necessarily that we can get ANY information in try-with-resources block. So we'll stick with dispose() paradigm.
04-04-2013
Changing priority to major. The lack of such method is preventing a number of bugs to be fixed
01-04-2013
Consider to implement AutoCloseable instead, which would make it compatible with the new Automatic Resource Management. http://docs.oracle.com/javase/7/docs/api/java/lang/AutoCloseable.html http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
11-03-2013
New DISPOSED status will be added to MediaPlayer.Status to indicate that MediaPlayer is disposed. Runnable onDisposed similar to onReady or onPlaying will not be added since transition to DISPOSED is synchronous and triggered by developers. MediaPlayer will go to DISPOSED state before dispose() method is returns.
08-03-2013
Be sure to spec exactly what happens on the class after it has been disposed. The Skin class has a dispose method, and is spec'd so that various methods either have no effect or return null, and that calling dispose twice has no effect (ie: subsequent invocations are no-ops).
07-03-2013
dispose() is also convenient when dealing with large files, when it's necessary to explicitly release internal file handlers.
06-03-2013

Relates :	JDK-8120818 - Memory leak with media objects
Relates :	JDK-8118236 - Runtime crashes with an EXCEPTION ACCESS VIOLATION after playing a video and then loading other URLs
Relates :	JDK-8120263 - Too many open files and Memory leak
Relates :	JDK-8120882 - Crash while using extended Seek While Scroll on Windows for MediaPlayer
Relates :	JDK-8094930 - Memory-Leak in Media Components
Relates :	JDK-8124054 - Application crashes on random loading of media file
Relates :	JDK-8125133 - JavaFx Application crashes
Relates :	JDK-8128496 - Possible leak while playing video in a loop using JavaFX 2
Relates :	JDK-8123986 - JavaFx MediaPlayer not release the file handle for the file it played Window specific