Now in Java there is "new" but no "delete", and all the dirty works are left to GC.
I wonder why is that?
If we have "delete" in java, developers can take partial responsibility of clean their own mess.
Is it possible that someday we have "delete" in Java?
Programmers can delete as many objects as they can remember and GC will only have to deal with things forgotten.
That will make Java more efficient.
Because people make mistakes and cause really hard to find memory leaks and do bad memory management such as double deletes so you get all these security leaks that you see often in the news. Plus it adds a whole lot of ugly boiler plate code.
Java is already very efficient; I don't know why you would want to go back to something as fragile as manual memory management just to squeeze a little more out. Better focus on learning how to properly work with the garbage collector so it can do its job properly in stead.
> That will make Java more efficient.
I seriously doubt that.
The common VMs are far more efficient than the standard C++ heaps in managing memory for running applications. That is possible because the algorithms used are far more complex.
C++ has delete but larger applications often need to take over memory management to make it more 'efficient' because of that.
And this presumes that, in general, programmers would be able to manage the memory more efficiently. Doing this correctly in C++ requires a deep understanding of how a specific application runs and how allocations occur. Along with a deep understanding of how C++ allocation works. Most programmers spend most of their time creating business flows and do not spend time learning and practicing the skills necessary to handle both of the those correctly. So in general those average programmers will not in fact be able to create more efficient management techniques. There is even a chance that they will in fact make it less efficient.
Yes, that. I spent the better part of 4 years diving that deep into C/C++ and assembly, becoming a technical wizard with it. At the end of those 4 years I started to come to my senses and drop the hate I had for Java at that time and could only come to one conclusion: why have I been wasting my time on that for so long focusing on low level code when I could have been learning how to properly develop applications and get a decent job?
It is almost unthinkable that Java would allow programmers to manually manage memory because then one of the major arguments in favour of the language would be lost, namely its high "safety" against programmer errors. Ultimately it could lead to the demise of Java.
Even C++ is now trying to move in the direction of greater safety by introducing a lite form of GC called smart pointers. It's quite likely that this trend will continue and that there will be more fullblown GCs avaliable in the future (at the moment there's just one substantial GC for C++ I think)
C# initially was very much like Java but has reintroduced certain memory features from C++ such as value objects and the ability to control when an object is GCed. This is something Java could also do without losing its soul.
Another Microsoft language called C++/CLI basically is ordinary C++ extended with features to control the Microsoft counterpart to the JVM. It's like having C++ and the VM capabilities of Java/C# in one language. It's an interesting approach but it has never caught on and one reason I suppose is because Microsoft don't want a major competitor to C# in the house.
Finally it's always possible to use C++ from Java by way of JNI. So if a part of an application would benefit greatly from being written in C++ it's always possible to do so. In fact one major part of the Oracle Java infrastructure is written mostly in C++ namely the JVM.
> Even C++...more fullblown GCs avaliable in the future
Rather certain that there were GCs available for C++ before java existed. Certainly there were GCs at about the time Java came into existence because I can remember looking at some of them (as I remember some were commercial as well.) Not surprising given that GC idioms existed before Java.
> C#...the ability to control when an object is GCed
Don't believe so. C# objects are controlled by the .Net memory manager. If you want those managed objects out of memory then you do in the same way you do in java, clean all references and call the GC API (repeatedly.) Unmanaged code requires that one must explicitly manage the objects but that is certainly analogous to JNI - integration doesn't change the nature.
> Another Microsoft language called C++/CLI basically is ordinary C++ extended with features...
Eh? C++ is either managed or unmanaged. The managed part is nothing more than another language on top of .Net and there is nothing magic about it. And specifically destructors in managed code has the same semantics as in C#. Unmanged C++ allows one to mess around as much as one wants but one must still correctly structure the application if one attempts to mix managed and unmanaged in a single application.
> Oracle Java infrastructure is written mostly in C++ namely the JVM.
That depends on what your definition of the "JVM' is and what "mostly" means. Perhaps with the integration of JRocket there is more C++ in the core but there was certainly a lot of Java in the VM itself when Sun was maintaining it. I doubt all of that is gone.
Thank you for your comments.
I was wrong on one account. It's not possible to control exactly when a managed C# object should be destructed. But my point was that C# has reintroduced features of C++ that Java is unlikely to follow. There are benign examples such as value objects and a more elaborate notion of a destructor, but also malign examples represented by the unsafe keyword.
Regarding GCs, I'm also rather certain they existed for C++ before the advent of Java. But my point was that C++ is slowly moving in a direction where you're likely to see more fullblown GCs at par with those avaliable for Java and C# today. It's a trend and the first sign is the introduction of reference counting smart pointers in the C++ standard. On the general GC front the situation is still very meager. To the best of my knowledge there's only one substantial C++ GC and that's the one of Boehm. I expect this to improve.
Regarding C++/CLI, this language is an extension of C++ (in the same way C++ is an extension of C). Sure there is tension between the C++ heap and the CLI heap but C++/CLI it is a coherent .NET language in its own right. C++/CLI is not unmanaged traditional C++ with a managed extension on top (as was the case with an earlier attempt called Managed C++). All of C++/CLI is managed but you can mix in unmanaged traditional C++ if you want. But my point was that C++/CLI is an interesting example of what might have been. It's the evolution of C++ many would've preferred over new languages such as Java and C#. Then why on earth isn't C++/CLI a huge success? It came too late, it was a Microsoft effort, the C++ standard committee wasn't involved, and not even Microsoft wanted it really (other than as a pathway for legacy C++ onto the .NET bandwagon). Too bad it never got the chance it deserved.
Finally regarding whether the JVM is mostly C++? My point wasn't to what extent C++ is used but that C++ is used at all in major JVM implementations. It indicates that instead of making Java more like C++ the preferred way is to use C++ as a complement in situations where Java is wanting. Another example could be OpenGL.
All points above are in support of my main point to the OP namely that Java is very unlikely to evolve back toward "the unsafe C++ situation" it was designed to escape from. Java will stay Java and when it doesn't cut it one can always mix in a little C++.