You shouldnt need to call System.gc(); ever.
So program should ever want to to perform a full GC at a time of it's choosing and should always let it happen at some unknowable point in the future outside of its control? For games, say at points where there's a natural pause in gameplay anyway?
... you have to manually delete the memory you allocate using Unsafe,
Not allocate once, keep forever memory. A common use-case.
The "real" problem with unsafe usage is: behavior may change across release (distribute a specific VM with program solves this one). Undocumented, so you have to be very careful. And you can put yourself into untested (another be very careful) cases of VM behavior.
this means, you need to add deconstructors like methods to every Java class you use,
In addition the above "not necessarily", there's allocations naturally dominated by a container.
..if you simply let a reference to an object go, the GC will never clean it up, meaning you got a memory leak.
GCed objects can memory leak as well. In either case poor design will bite you.
I will stand by my "If you are starting to require memory management in Java, you should change languages".
Possibly...depends on a person's knowledge of, comparative productivity in the languages in question and the overall "problem space" of the program. Many factors here.
You are probably going to be limited by something else before memory management in java is your concern.
Problem space and programmer's understanding of it. On the whole, you're way overgeneralizing.
There are things you can't do without Unsafe.