So, I never really dispose of anything. Is that a bad idea not to dispose of stuff? I mean, doesn’t OS or OpenGL automatically do that for me?
I just started messing around with libgdx and noticed that “dispose” method which disposes of texture and batch. So do I need to manually dispose stuff upon application exit?
Resources allocated by native code are not always visible to the JRE, and if you don’t dispose/release them back to the system you will cause memory leaks. If the Garbage Collector isn’t aware of objects, it’s not able to process them. Never rely on the OS to take care of your leaks, it’s just bad practice.
Er, opposite stance here. The OS releases everything when the process exits. Save yourself the hassle and just let it do it for you.
Cas 
Yes - it makes the OS more robust. If it didn’t, our computers would be at the mercy of C programmers and their memory management.
Since we’re talking about stuff stored in VRAM instead of virtual memory…you have dispose of it yourself.
Process exits -> OS destroys OpenGL context -> driver frees VRAM.
Cas
Me bad…no read title
I’m guessing then that the disposal methods are there in case you need to clean up memory while still running the process?
Yes, that’s right. When it comes to games, it is unlikely you’ll ever need to worry about it.
Cas
Personally, I destroy direct NIO buffers when I no longer need them, for example when I go from a level to another one. If I didn’t do that, I would run out of native memory. I will probably have to go that in one of my applications too.
You should really just set them up at app startup and leave them.
Cas
If I do so, I’ll have to increase a lot the maximum size of the direct memory (-XX:MaxDirectMemorySize) except if I succeed in reusing large direct NIO buffers. Maybe I see what you mean.
How do you even do that?
As I use Ardor3D, I know the root node of the game “state” (Fettle API), I visit all its children. When I find a leaf node, I look at its mesh data which contain several direct NIO buffers for vertices, colors, texture coordinates, fog, … Then I have to destroy the both parts of these resources, i.e the data stores on the GPU (by using glDeleteBuffers) and the direct NIO buffers not allocated on the GPU (I don’t use glMapBuffer/glUnmapBuffer). I use the cleaner of each direct NIO buffer to release its native memory in the meantime (a public API will be added into Java 1.9 to do that without relying on classes that might be removed).
References:
http://ardor3d.forumatic.com/viewtopic.php?f=10&t=5182&hilit=NIO&start=10#p25407
Same as cas. Don’t care about disposing stuff. That’s the job of the modern OS’
If it were that important I couldn’t kill processes which don’t support Alt+F4. Well I could, but not for long then 
Disposing stuff when exiting an application doesn’t seem to be mandatory (except maybe in some particular cases) but disposing stuffs that use some memory on the native heap to avoid running out of native memory at runtime isn’t a bad idea.
There aren’t many use cases for creating and destroying native byte buffers. Typically what you should be doing is re-using them. For example, loading textures in a “fast” way: you have one native buffer big enough for any texture you’re going to use; then you repeatedly load your texture data from disk into that one buffer to send it to OpenGL.
Cas
I could create a single very big direct NIO byte buffer as the very beginning and slice it, it would eliminate the need of destroying any direct buffer. It is doable when you have the full control on the whole software stack but not in several major scenegraphs which encapsulate the creation of those direct NIO buffers. They have no mechanism allowing to override that, either they already have a manual build-in feature for the disposal of native resources that you may use at your own risk (JMonkeyEngine 3, LibGDX?) or they are “smart” enough to do it automatically partially (only the OpenGL part) when the garbage collector takes care of some buffers, they let you extend this mechanism and call it whenever you want which is useful when you run out of native memory before running out of Java memory (Ardor3D).
I did quite a bit of research on the whole Nio bytebuffers things and found that they actually do get garbage collected but only when the normal stack/heap fill up. This means that because they are allocated natively they are not seen as taking much up and do not add anything when a garbage requests happens and thus do not get cleaned up.