On Fri, Apr 30, 2010 at 13:56, Kevin Wright <[email protected]> wrote: > As for "Best Practices", they change!
Of course they can, but I think as they mature they change less. > Boilerplate in Java risks getting ever more burdensome as new > features are added (like having to specify type params twice when > instantiating a variable using generics) and Frameworks and developers are > increasingly saying ENOUGH! What is interesting: Although I found it annoying in C(++) to deal with the header files nobody is complaining about that. And I never even thought about a boilerplate-code issue before I was learning Java. Then I noticed, yes, there is code I could consider to be boilerplate also in my VB programs. I didn't ever notice that before. OK, when I was doing COBOL and thought of writing english poems, that was just a single thing of boilerplate. After that everything was just short. :) > Consider that the terms "Dependency Injection" > or "IoC" were almost unheard of when Java was originally created, should we > therefore not use these patterns on the grounds that they're not traditional > idiomatic Java? No, we should not ignore such idioms or ideas. But as with many other things, I hear everybody talking and writing about those things although I think that a lot of those idioms (not necessarily the two you mentioned above) make sense only in particular situations. As of inversion of control I do see disadvantages also. None of these idioms will fix the problem with the hunger in the world (I mean, none of these idioms will solve everything without drawbacks at other ends). I would go even further: I would even say, that while discussing those language features other maybe more important topics are not discussed. For instance: Everything that has been there for WYSIWYG web development in NetBeans has been withdrawn although such tools would be more important. Last week two customers with new projects and guess what: Part of the specification was that it must be implemented in MS Access because non-programmers can then easily change forms or tables if they need an additional field later and don't want us to contact whenever that is necessary. - Even on Windows and VB I had a free tool for form design that I could integrate with my applications and customer IT was able to make smaller changes themselves without the need being a programmer. - From the practical point of view: Who cares of closures or whatever? My customers don't. They want things like more tight integration with their OS for instance. I was so glad when Java 6 introduced the system tray feature. Works fine on Windows and Gnome as well (did not test it on KDE or Mac but imagine it works). Now waiting for the file notification API in Java 7 but there is more to do. Those things are IMHO much more important than reducing a little boilerplate. I am sure that you all loose much more time by trying to get some tricky things to work that touch limits of the Java platform (if it is by using Ruby, Scala or Java). And here it comes to my understanding of Joe's position when he put the focus on the customers. If the developer has to write a few more code has NO effect on the customer. So the customer and the management can't care less about that. On the other hand the possibility to write automated tests for your application was a real gain because it reduces testing time and costs by increasing reliability. And guess what: It needs even more code to be written than before! Or tools like Findbugs help increasing code quality - which means reducing bugs and that has effect on the customer. > Books on best practices always risk being out of date the very moment they > are printed, > and the real state of the art exists in blogs and mailing lists and the > source code for the various frameworks we use. While I think you are right about the state of the art being found in blogs - or forums like this ;-), I also think you are fairly exaggerating when you assume most of books like "Effective Java" being out-of-date as soon as available. > How much of "Effective Java" > do you think will still remain a best practice once we have closures and > method handles in Java 1.7? For that particular case I do already very seldom inline defining of classes as I have only very seldom a class that isn't useful in either 5 other places. I design my classes multi-use - that's a core idea of object orientation, isn't it? So I do not really care about closures. I would use them in rare conditions only, I think. > If it is to survive and prosper as a language, then it seems important that > Java should evolve as newer programming paradigms mature. Agree - as they _mature_! -- Martin Wildam -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
