On resource managment, c++, java, .net

Going into Java vs Native is a hopeless battle. Their respective crowds remain the same.

Let's just believe that there exists optimal tools for tasks with well defined boundaries. 

For any hobby project my choice was usually Java (now it is Scala). At work, it's C++ or C.

I love working on the JVM because of how easy it is to set up server-client architectures, run multiple threads across platforms, guarantee cross thread visibility and for each error getting standardized stack traces with thread and code line references - out of the box.

But when it comes to what most people consider the flagship (or devil) of Java, the Garbage Collector, I don't like him. He might be fast, efficient, but he is only capable of a small range of tasks.

If you pile up junk on a big heap he will do his job fine.

If want to help out with your neighbors trash, the GC gets confused - Because the GC goes "lalalala, I only see your pile of trash". When he's at it (that is, collecting your garbage) you can tell him to also help your neighbor, but you can't order him to actually observe your neighbors heap of junk on his own.

Suppose instead your neighbor is a set of file resources, network resources, video card resources, exernal device resources, etc, the list can be made arbitrarily long. Automatic management and collection can't be handled by the GC, because he doesn't really know when things are no longer needed.

Enter C++ and RAII, and the wonders of smart pointers - you may reference count anything you like, and it works beautifully. You may argue all you want that java's try-with-resources or C#'s using pattern exist, but in reality they are nowhere near the capability of hooking into deterministic stack push/pop behaviour.

Dear Oracle: Would you please introduce a ref counting Generic class (RefCnted<T>, or RefCnted ifc that you implement) which does not imply automatic garbage collection, but instead behaves like a normal C++ smart pointer/stack object? JVM languages would be much richer with such capability. JVM byte-code is stack based afaik, pease let us use that power :).