Monday, December 08, 2008

New in Java 7

Java 5 was the first version of Java that I found usable after years of developing in C and C++. The inclusion of generics and other syntax enhancements combined with the appearance of Eclipse made developing in Java finally much less tedious and more productive. Java 6 seemed like more of a maintenance release, though it did provide some nice enhancements such as a better JAXB. I am particularly excited about some of the things promised in Java 7, including closures, BigDecimal operator support, type inference, improved catch clauses, and other fixes that will make working with collections more natural. I still wish they would just give us real operator overloading. The one that has me scratching my head, though, is automatic resource block management. In an attempt to rid Java code of most finally code, they have come up with:
    do (BufferedInputStream bis = new BufferedInputStream(is); BufferedOutputStream bos = BufferedOutputStream(os)) {
// do stuff with bis and bos
Which is certainly an improvement, but I just don't understand why we can't get a real destructor in Java. My nearly twenty years of OO programming have convinced me that if a language has a constructor, it should have a destructor. Exceptions are academic languages and pseudo code, both of which are free of resource concerns. Real world programming is almost always working with some sort of a finite resource, such as database connections. It is not just good form to clean these up the moment you are done with them, but often simply necessary to make things work in a busy production system.

These new blocks are an improvement I suppose, but they still suffer the fatal flaw of resource management in Java which is that it is dependent upon the programmer to always remember to free up resources. My real world experience has also taught me that the less that you have to have programmers do manually, the less problems you'll have. I'll gladly accept the new features of Java 7, but I'm still waiting for a truly automatic solution to resource management in Java.

Monday, December 01, 2008

Don't Just Stand There, DO Something!

Finally, an article that quantifies what I have often felt but didn't know how to explain concerning the inefficiencies of big corporations: They become inefficient because they have too much process, or, as Paul Graham explains, because they are too careful.

On a smaller scale, I've realized that it is often better to simply DO something rather than spend too much time thinking, or really, agonizing, about how it should be done. If you're not sure how to proceed, then simply exclude any stupid directions and pick randomly from what is left. If you happen to have chosen the right path, then you are done. If you chose wrong, then you have effectively reduced the number of choices and can perhaps even use the experienced gained to choose better between those that are left. Often you can go through several cycles of trial and error before you could have made a decision simply by thinking about it.

You may say there are some endeavors where this does not work such as spaceflight or safety systems, but I suggest you can use this same principle there. Not that you won't have failure, but if you are working in engineering, you should be working with test harnesses and other simulators. In software, this has led to "agile development" or "test driven development". If you're not doing this, start.