> > There is no shortage of applications where RAII and smart> pointers do not suffice. These techniques require a strict> singular ownership of data which is sometimes less than> convenient.

Actually, shared ownership of objects is vastly overused. Other than some low-level data structures such as lock-free lists and trees, I can think of only very few cases when shared ownership is required (flyweight pattern, maybe?). I don't remember explicitelly calling delete once in the last five years or so: exclusive ownership + deterministic destructors work just fine.

>> I'll go out on a limb and say that most Java shops are >> enterprise IT. A lot of these shops couldn't care less >> about platform independence. Some do but it's not that >> big of a deal for most.

At the heart of my point is that if it weren't for the fact that Java is platform independent via the VM, no one would have bothered with it, especially at the server level. Aside from being a somewhat straight forward transition from C-derived languages, Java as a language is secondary.

Consider all the features of Java as a platform and you'll soon realize it's not about the language. Microsoft understood the true value of Java to be the platform and built .NET. Sure C# is an awesome language (what Java s/b imo), but C# is more or less just the API to the core technology that is .NET. Same holds true for Java.

> <p>Because I was on the C++ Standards Committee, I saw> these decisions> being made. They were all extremely carefully considered,> far more so> than many of the decisions made in Java.</p>> <p>However, as people have rightly pointed out, the> resulting language> was complicated and painful to use and full of weird rules

So we know committees don’t work even if they are comprised of experts. I’d have thought that the community process would be a great thing because of “community” involvement. I don’t know much about JCP but even with that model it’s like a hit or miss thing – Concurrency JSR I think was a success but few say that about Generics JSR. My question is why didn’t these experts raise a flag early enough to avoid the mistakes they complain about? Isn’t it fair to say that if Java failed, it’s the community to blame?

On another note, I don’t understand the need for backwards compatibility when JVMs have years of End of Life period and continued support. Maybe Java should have a BDFL who isn’t too concerned about backwards compatibility.

> At the heart of my point is that if it weren't for the> fact that Java is platform independent via the VM, no one> would have bothered with it, especially at the server> level. Aside from being a somewhat straight forward> transition from C-derived languages, Java as a language is> secondary.> > Consider all the features of Java as a platform and you'll> soon realize it's not about the language. Microsoft> understood the true value of Java to be the platform and> built .NET. Sure C# is an awesome language (what Java s/b> imo), but C# is more or less just the API to the core> technology that is .NET. Same holds true for Java.

I think we are talking about different things. You are talking about what initially made Java popular. I am talking about the legacy of Java the language. Yes, the JVM is probably more important than Java but they are not one-in-the-same.

I know it's hard for a lot of people to believe but for a lot of shops, the Java language is what they want and having to think about the JVM is largely an annoyance. I've worked in a number of shops where this is the case.

Look around at languages like Fan and you will see people trying to reclaim something like the balance of power and simplicity that Java had.

> "Java might be verbose and lack lots of "cool" features,> but it's really easy to figure out what some random code> is doing."> > Bingo.> > Such a huge part of professional software development is> reading, understanding, maintaining, and extending,> someone else's code. Java really helps with that.>

Not in my experience. The hegemony of get/set bean coding makes understanding an issue. If folks took the "tell don't ask" mantra of OO principles, then yes; see Holub or Thomas or (at times) Meyer.

If understanding in a particular IDE with a particular debugger written to a particular Framework is sufficient, then maybe. But at that point one is far from java as language.

> > Java strengths:> > ......> > garbage collection> > > > I'm afraid I've never really bought into this one. It> often seems to come over as a sort of Java religious> chant, in that the implication is that no language can be> any good without it.> > I've coded in C++ for a good number of years using modern> C++ techniques (RAII, smart pointers) and, for me, it just> not an issue at all.

Among other things, in large projects, a single memory model (who allocates, who releases, etc.) is invaluable.

If you're happy with what C++ does for you, then you should keep your head down in C++ so that you don't lose your happiness ;-)

(I work on a product that has both Java and C++ implementations, among a few other languages, so I get to see the differences across those languages every time I make a fix or add a feature, and automatic garbage collection is such a great leap forward that you won't appreciate it until you've been working in a GC'd language and then have to go back to working on C++.)

> (I work on a product that has both Java and C++> implementations, among a few other languages, so I get to> see the differences across those languages every time I> make a fix or add a feature, and automatic garbage> collection is such a great leap forward that you won't> appreciate it until you've been working in a GC'd language> and then have to go back to working on C++.)> > Peace,

I worked with C# as the primary language in 2004/2005 and took the first opportunity to go back to C++. Garbage collection is nothing but trouble, thank you :)

> I worked with C# as the primary language in 2004/2005 and> took the first opportunity to go back to C++. Garbage> collection is nothing but trouble, thank you :)

OK, I'll bite .. ;-)

First, could you give some background on the type of things you build with C++, so that we have a frame of reference?

Then, could you describe how garbage collection causes trouble for someone trying to build those types of systems?

It's not that I don't believe you. It's just that my experience and thus my conclusion seems to be exactly the opposite of yours, so you have piqued my curiosity. I am curious if the systems you are building are simply inappropriate for C#/Java, or if there is some other factor.

> > First, could you give some background on the type of> things you build with C++, so that we have a frame of> reference?

Let's talk in the past tense - now I work on something completely unrelated. Anyway, I was working on high-volume language processing - machine translation, translation memories, terminology extraction.

> Then, could you describe how garbage collection causes> trouble for someone trying to build those types of> systems?>

Memory footprint. Memory is the tightest resource for such cirumstances and with a non-deterministic GC such as one provided by .NET it is impossible to control memory consumption - not that we did not try, but even calling GC.Collect manually would not release memory back to the OS. In best case scenarios, it was page faulting like crazy, and in some circumstances it would end up with an out of memory exception.

With C++, the strings would get released as soon as they went out of scope and it was never an issue.

> Memory footprint. Memory is the tightest resource for such> cirumstances and with a non-deterministic GC such as one> provided by .NET it is impossible to control memory> consumption - not that we did not try, but even calling> GC.Collect manually would not release memory back to the> OS. > In best case scenarios, it was page faulting like crazy,> and in some circumstances it would end up with an out of> memory exception.

I've never worked with .NET but the scenario you describe when in Java would (in general) be caused by having live references to objects that you thought were unreachable. In the Java world, this is often called a memory leak but it's more correctly called a space leak (i.e. a bug in your program.) The most effective way to resolve that is to use a memory profiler. Trying to tell the VM to release memory will have no effect. Since the objects are still live, there's nothing to release. In Java at least, the only time you will ever* get an out of memory exception is when you are actually using more memory than is available to the VM.

Also keep in mind that when a VM app run under windows, they appear to allocate a large amount of swap space. If you use the task manager, the amount of virtual memory appears to be really large. This disturbed me and I did some research and found that this is really not the case and that the swap is not actually allocated until it's really needed and that the task manager lumps a lot of things under virtual memory.

*concurrent collectors make it possible for race conditions on available memory data to occur.

> > Memory footprint. Memory is the tightest resource for such> cirumstances and with a non-deterministic GC such as one> provided by .NET it is impossible to control memory> consumption - not that we did not try, but even calling> GC.Collect manually would not release memory back to the> OS. > In best case scenarios, it was page faulting like crazy,> and in some circumstances it would end up with an out of> memory exception. > > With C++, the strings would get released as soon as they> went out of scope and it was never an issue.

In Java I regularly use heaps > 1 GB and provided the total live data required is less than the maximum permitted heap size by about 100MB, performance is good. In other words it needs about 10% or so free space to avoid excessive garbage collection (and paging).The current Java garbage collectors are very good at cleaning up short lived objects. You really don't have to care whether the space has been reclaimed yet or not, it just works. Longer lived objects aren't too bad either.

Even just a few years ago I found noticable performance gains by specifying a minimum heap size that was close to the amount I expected to be allocated. Now the gain from doing this is substantially less.

Garbage collectors have improved a lot and are still improving (at least those supplied with Java are improving). I'm looking forward to taking the new G1 collector for a spin with my code.

> > Actually, shared ownership of objects is vastly overused.> Other than some low-level data structures such as> lock-free lists and trees, I can think of only very few

A lot of my work involves graph structures where the cycles would prevent the use of smart pointers. I multi thread my algorithms as well which is a second strike against smart pointers (thread safe reference counting is usually more expensive than garbage collection).

Whatever the reason, we had no problem with memory consumption before using a garbage collected environment. Or after that, for that matter. In fact, there was an engineer in our team who worked on implementing a machine translation in Java before and warned us up front that they had to re-write their system in C (I think) because it was consuming too much memory, but his experience was ignored.

> > A lot of my work involves graph structures where the> cycles would prevent the use of smart pointers. I multi> thread my algorithms as well which is a second strike> against smart pointers (thread safe reference counting is> usually more expensive than garbage collection).

I am not talking about reference-counted smart pointers - they are also a way of enabling shared ownership, which is fundamentally a bad idea. An object lives in a scope and it is usually easy to identify the scope and (automatically) destroy the object when it reaches the end of it.

Having said that, I don't know your code and the problems you are solving; if you see a benefit of non-deterministic garbage collector, by all means use it.