Java Programming

There is no reference counting in Java. There is no reference counting in the context of WeakReference in Java.

my source says A weak reference is a reference that does not increase the reference count. This means that if there are only weak references to an abject, that object can be garbage collected.

I'd say that source is misusing the term "reference counting." A better source would be the [url http://download.oracle.com/javase/6/docs/api/java/lang/ref/package-summary.html]package spec and [url http://download.oracle.com/javase/6/docs/api/java/lang/ref/WeakReference.html]class documentation.

Additionally, that source explains right there in that quote what they mean.

As far as the Java language and that package and class are concerned though, there is no such thing as reference counting.

Your source is wrong. And unless your source is the Java Language Specification, the Java Virtual Machine Specification, or the JDK Javadoc, what it may or may not say is of zero relevance or interest.

Reference counting is a method used by some garbage collectors. It's what it sounds like: each object maintains a count of how many references to it exist. If that count drops to zero the the object gets recycled.

It's not a very useful method. Main problem is that if you ever get a cycle in the reference graph then the objects in that cycle are not recovered, even if there are no references from anywhere outside the cycle. Also it requires fairly complex actions to be taken every time a reference field or variable is changed. Java has never used it.

Java's primary GC method is called "Mark and Sweep" and it relies on marking all "reachable" objects by walking the reference graph, then recycling (sweeping up) all objects that aren't marked.

Yes there is a problem with cyclic object graphs but that does not make reference counting "not a very useful" ! Far from it. I used it for many year in C++ projects with very very positive results. I was involved quite late in the day (6 months to go on a 2 year project) in one C++ project where pointers to object collections were being passed round the system with no real concept of ownership. This meant that the system leaked like a sieve and crashed frequently when programmers were using objects after they had been deleted. I made myself very very unpopular by writing and distributing a short paper explaining how a simple use of reference counting using pointer objects would solve the problem. After a month of zero progress by the integration team trying to solve the problem by other means a permanent member of staff and myself, over a long weekend, converted a branch of the whole project to using reference counting pointers which completely eliminated the problem. Two days later this branch became the main branch when the management realized the benefits. To make sure the smart pointer were being used throughout the system, a code review process was introduced which gave the added benefit exposing poor programming and design well before it become too expensive to fix.

Other languages such as Python use references counting as standard and there are extensions that handle cyclic object graphs.
Not really. With C++ it is easy since it is all done behind the scenes using smart pointer objects. It is simply a case of "will the last man to leave the room please turn out the light'.
But is there anything in the language specification to disallow it? There could be significant advantages. For example, one could maybe then rely on finalize() to release resources such as database connections.

Agreed. I have witnessed a very similar experience in a C++ system. Half a loaf is better than no bread. Haven't checked , but I would imagine the use of the term 'garbage collection' would disallow it. A mechanism that can't cope with cycles can't satisfy the general requirement.

One might suppose that that is independent from your fix and might have solved the problem all by itself it it had been used before there was a problem.
I am surprised python uses it.

Garbage collection was invented for Lisp in 1959. Long before OO existed.

And I read articles about GC in Lisp long before OO existed and how they were moving away from reference counting for specific reasons.

The basic problem was one of system design which might have been found earlier has there been design reviews. This would probably have recognised the need for an ownership of the major business objects to be established and a procedure for registering an interest in these objects. It would probably have looked very like reference counting but not called reference counting.

The whole project was a QA nightmare (not the worst I have seen but close). No QA procedures worth a damn. Two very different source control systems run in parallel for holding all source and documents. These had to be kept in sync manually by the developers. The need to edit source files several times after test to indicate the status of each file - there were several instances of these edits damaging the source. Poor design documentation. etc etc etc.

> There is GC for Python to supplement the reference counting - http://docs.python.org/library/gc.html .

> Yes GC has been around for a long time and is now available even for C programs (I haven't followed the technology for many years but I will post a reference ( http://en.wikipedia.org/wiki/Boehm_garbage_collector ) if I can find one) .

Nobody pretends that reference counting is ideal; the problems are well known BUT it can have a place. As I said, I have used it on many C++ projects with very positive benefits and very very few problems. I even used it in a telephone network routing program that by it's very nature had a massive cyclic object graph that required the graph to be manually 'unzipped' to break the cycles. Not ideal but ...