Tags: OpenJDK
The other day I made a blog posting concerning
Bendy classes and dynamic programming, discussing a meme I'm seeing in developer blogging. That idea is there are various dynamic or scripting oriented languages which make it easy to write quick programs with loose binding (there are probably other benefits to those languages). Supposedly Java is a dinosaur with its rigid binding, compile time checking, etc. And you see a lot of discussion on the web that these other languages are going to kill Java.
My point is the compile time checking, strict checking, etc, done by Java offers developer productivity gains. Rather than being a hindrance, it's a benefit.
Chris Justus relates in
4 Reasons Java Will Outlive PHP (My interview with IEEE...) some points that are in line with the discussion on my blog posting.
I want to focus on the first point ... object oriented tools and principles in Java enhance developer productivity ... The example given is in actual practice, many development teams ignore all the best practices and just churn out code.
In best practices the new thing is "test driven development" and supposedly unit testing can catch all the errors in the application. But Chris relates the common situation is project deadlines cause teams to throw out the best practices, and they pray for the time "later" to go back and "do it right". 16 years ago I worked in a team using exactly that strategy, and witnessed the horrible code that resulted.
With the compile time checking and strict type checking offered by Java, such a team would have some checks automatically performed by the compiler. The team might not have time to write their unit tests or follow other good practices, but at least the compiler will be there actively helping them stay away from some problems.
On my blog posting we discussed the tradeoff between unit testing and the advantages offered by a dynamically bound language. Even when unit testing is done, my contention is it's not a panacea. Further, if the language offers little help like compile time checking, this increases the amount of tests which have to be written.
One thought about testing and test development is: "Testing is never finished, only exhausted". What that means to me is management has a budget in mind for testing activities, and when that budget is exhausted then testing is finished. Yes it might be short sighted on management's part. It's not a quality-driven approach to testing, but a budget-driven approach. This obviously affects the quality of the resulting software.
In a situation like Chris relates, management is pushing to meet the deadline at all costs. The developers are harried and rushed, they know they're not doing the right thing, and surely the resulting application is going to be buggy as heck. Chris's claim, and I agree, is Java and the tools available for Java help such teams stay in line. They can still write bad and buggy code (you can write spaghetti code in any language), but it won't be as bad and buggy as it could be.
Source:
weblogs.java.net
