Deterministic destruction of Objects in Java - An idea

I love programming in C++, despite the hues and cries against it as a "most programmer unfriendly" language. I have my own reasons to like C++. Top two reasons being:
  • Bjarne was born in 1950, it was the year when my father was born.
  • Initial C++ (C With Classes) was released in 1979, it was the year when I was born. :-)
Nevertheless, there is one aspect of C++ that I find very useful and will definitely help prevent resource leaks. It is the destructor of an object. In simple terms, whenever we exit a lexical block (a block enclosed within "{" and "}"), all the objects constructed within that block are guaranteed to be destructed. The guarantee is true even when the exit happens due to thrown exceptions.

This guarantee is a very strong weapon for any programmer. It makes destruction of an object a deterministic phenomena. Objects created in heap using new key word require the user to explicitly destroy them, and thats not what I am discussing here.

One of the good programming practice is to acquire and release any resource within the same lexical scope, as much as possible. (I hear you yelling "Its not always possible, fella" and I agree with you!)

If we look at the object life cycle models provided by C++ and Java, C++ implicitly supports the above mentioned practice. But in Java, every user of the object must remember to invoke the destructor's equivalent (freeResources, resetAll, etc). finalize method in Java is altogether for a different purpose, and the language inventors themselves strongly discourage using and relying upon finalize method.

I was chewing this idea for sometime and this is what I feel.
Garbage collection and object destruction are two different things. Whenever a lexical scope exit happens, the JVM has the list of objects within that scope. JVM can decide if an object still has any references to it, or it is safe to be destructed. Thus destructed object can wait in heap till GC occurs.
My thought is not too deep to be incorporated into a production release! But it certainly is worthy enough to be considered.

Is there a rationale behind not supporting deterministic object destruction in Java?

Comments

Harris Baskaran said…
Being a java programmer, its my duty to defend java. So here it is.

-Java has the garbage collection feature jus to ensure no memory leaks occur.
-I think in Java there is way to explicitly call the Garbage collection. So no one waits :)
-Introducing destructors concepts in Java will lead to memory leaks and mismanaged objects. This when creating large enterprise softwares will be a huge overhead.


These are just my ideas. So no hard feelings towards C++. C++ is still capable of doin so many things Java cannot do.
1/31/2007 07:48:00 PM
Roy said…
To Harry: My thought was not to remove GC. But to make object destruction a deterministic one. Of course, I love the availability of GC in Java. And I tend to disagree that "no one waits for GC", as no one explicitly invokes GC either (at least in the code that I have seen). And I don't see any guarantee from System.gc() call that GC will happen, it is only a "best effort" call and not a guarantee.
1/31/2007 08:20:00 PM
Harris Baskaran said…
System.gc() is a best effort call and not a guarantee call. But incorporating object destruction methods for java will mean that there will be more memory leaks. And since object destruction will be dynamic, it will mean more and more debuggin to find "bad references".

Though GC maynot be the best way to handle "dead" objects, its sure is a good effort to ease the programmer. Maybe a new GC design will be the solution. ;)
2/02/2007 08:47:00 AM
Anonymous said…
Hey i have read this post and I totally agree it would be a good thing to have object timelife restricted to a scope
Maybe Harris did not get the point because he is a Java native and never has known the usefullness of creating an object through the stack

.NET provides the 'using' keyword that enables you to do that ¿is there anything similar in java?

thanks
Fernando Simoes
8/28/2014 09:38:00 AM
Post a Comment

Popular posts from this blog

The mysterious ORA-03111 error

Recently one of the applications that I developed started throwing exceptions, that had the following message: SQL state [72000]; error code [1013]; ORA-03111: break received on communication channel When I googled around, I couldn't come across anything useful. Sadly enough most of the sites just showed the documentation for that error, without any explanation from anyone experiencing that issues. So here you go, with the best possible explanation that I could come up with. My application sets two things on the connection that is throwing this exception: It sets the fetchSize to be 2500 rows It sets the query timeout to be 10 seconds The database server and the application are separated over a long latency network (actually there is a NetEm box that emulates the long latency between these two boxes) which has a latency characteristic of 50+/-5 milliseconds. This is the whole setup. It is important to understand how the timeout is handled by the Oracle client (in my case JDBC clien
Read more

Note on allocationSize parameter of @SequenceGenerator while using JPA

I ran into what I thought as an issue while I was using the sequence ID generation strategy in JPA. The JPA provider I am using is Hibernate. I think sharing my experience will save someone some time. To use a sequence (For e.g. Oracle sequence) to generate values and assign them to the ID field of your persistence object, you will following something like this: @Id @Column(name = "ITEM_ID") @GeneratedValue(strategy = GenerationType.SEQUENCE, generator="ItemIdSeqGenerator") @SequenceGenerator(name="ItemIdSeqGenerator", sequenceName="ITEM_ID_SEQ", allocationSize=1) private long itemId; This means the following things: The @Id annotation says that the field itemId is a primary key. The @Column annotation says that the corresponding column in the database is ITEM_ID. The @GeneratedValue says that the value that needs to be populated in the itemId should be generated, while that object is persisted. The strategy to generate the value is to
Read more

A note on Java's Calendar set() method

Remember that the Calendar's internal fields include year, month, date, hour, minutes, seconds, milliseconds and time zone. Whenever you are calling a set() method with multiple fields, like set(year, month, date), it will not affect the rest of the fields. Remember that there is no set() method with multiple fields available to set the milliseconds. If you would like to set the milliseconds, you must use set(Calendar.MILLISECOND, value). Likewise, if you are planning to set all the fields, its a good idea to reset all the fields using clear() method. This will clear milliseconds as well. Most of the times, millisecond field may not be of interest to you. But if you are going to use the UTC milliseconds, by calling getTimeInMillis(), then make sure you set the right values for milliseconds as well.
Read more