In Java, which doesn't have destructors, it's even worse because you've got exceptions with no automatic cleanup, which means you've got to have all sorts of ugly nested try/catch/finally and state management.
Java has finalize () instead of destructors, which is run once the garbage collector determines that it is safe to reap the object. This may not be good enough for expensive resources such as socket connections, etc., but it DOES allow cleanup upon destruction of the object.
Furthermore, suggesting that the lack of a destructor causes cleanup in response to exceptions to be ugly is nothing but a shortcut to thinking. All you need is:
SomeObject o = new SomeObject (); try { o.doSomething (); } finally { o.cleanup (); }
Why is explicitly showing in your code that the object gets cleaned up, exception or no exception, ugly? Personally, I think that this is good code for a production environment. It's self-documenting: immediately the reader knows that the object has resources that must be cleaned up after use. It also shows the would-be paranoid, that no matter what happens in the body of the try block, this object is going to be cleaned up after use. QED.
Honestly, my favorite programming language is C, but for a production environment, the best one is Java for reasons of code maintenance, reusability, readability, and many other reasons. I'm sorry, but if C++ was the cat's a$$, then companies would be using it instead. In practice, projects written in Java eat up less man hours and are much easier to maintain, even for Junior to Mid-Level programmers.
Do you want to be the one cleaning up a junior or mid-level programmer's dangling pointers because he is just too intimidated and too frustrated to do it effectively himself? I sure don't.
In an ideal world, the most efficient language would win. And that language would NOT be Java.;-)
The i-mode FeliCa serves as a "mobile wallet" that detects weak electronic signals from a reader/writer and can be used when the phone is off.
I wish I could find the original article I read about this technology some months back. The main concern of the technology's proponents at the time of writing was this: What if someone obtained a reader/writer device and modified it to increase the signal strength? Then, this person would theoretically be able to rob an entire subway platform full of people simply by walking around them with this device.
At the time of the article's writing, the problem had not been solved yet, and supposedly still required additional thought... so, what was the resolution? I haven't read anything as to the solution to this very real threat. Not that a solution doesn't exist, but I haven't seen anything suggesting that a solution has been found and implemented prior to product release.
Wots, uh, the deal?
Slashdot Mirror
In Java, which doesn't have destructors, it's even worse because you've got exceptions with no automatic cleanup, which means you've got to have all sorts of ugly nested try/catch/finally and state management.
Java has finalize () instead of destructors, which is run once the garbage collector determines that it is safe to reap the object. This may not be good enough for expensive resources such as socket connections, etc., but it DOES allow cleanup upon destruction of the object.
Furthermore, suggesting that the lack of a destructor causes cleanup in response to exceptions to be ugly is nothing but a shortcut to thinking. All you need is:
Why is explicitly showing in your code that the object gets cleaned up, exception or no exception, ugly? Personally, I think that this is good code for a production environment. It's self-documenting: immediately the reader knows that the object has resources that must be cleaned up after use. It also shows the would-be paranoid, that no matter what happens in the body of the try block, this object is going to be cleaned up after use. QED.
Honestly, my favorite programming language is C, but for a production environment, the best one is Java for reasons of code maintenance, reusability, readability, and many other reasons. I'm sorry, but if C++ was the cat's a$$, then companies would be using it instead. In practice, projects written in Java eat up less man hours and are much easier to maintain, even for Junior to Mid-Level programmers.
Do you want to be the one cleaning up a junior or mid-level programmer's dangling pointers because he is just too intimidated and too frustrated to do it effectively himself? I sure don't.
In an ideal world, the most efficient language would win. And that language would NOT be Java. ;-)
The i-mode FeliCa serves as a "mobile wallet" that detects weak electronic signals from a reader/writer and can be used when the phone is off. I wish I could find the original article I read about this technology some months back. The main concern of the technology's proponents at the time of writing was this: What if someone obtained a reader/writer device and modified it to increase the signal strength? Then, this person would theoretically be able to rob an entire subway platform full of people simply by walking around them with this device. At the time of the article's writing, the problem had not been solved yet, and supposedly still required additional thought... so, what was the resolution? I haven't read anything as to the solution to this very real threat. Not that a solution doesn't exist, but I haven't seen anything suggesting that a solution has been found and implemented prior to product release. Wots, uh, the deal?