New Year’s Resolutions for the Java Developer
blog.jelastic.com
blog.jelastic.com
In my experience, you can be more productive in Java than in any other language, because it has by the best tools and libraries. However, don't use reflection, don't use cloning, avoid automatic (de)serialization, don't doc needlessly, don't separate interface and implementation when you don't have to, use refactoring and code generation, don't feel bad about code duplication.
Most of all, always consider that coding is cheap. Changing a constant? Easy, not hard. Changing interfaces? Easy, not hard. Introducing an alternative implementation? Easy, not hard. Changing names? Easy, not hard. Adding new types? Easy, not hard. You don't need to think about easy things in advance, think about the problem instead.
That's quite a bold claim...
I'd expect languages that require far less code for pretty much anything, and have far more compile-time safety to be more productive both at the prototyping stage, and at long term software maintenance.
It wasn't a broad claim, it was an observation.
Learn YAGNI. Tattoo it on your friggen foreheads. Run lean... No, you DONT need to build a framework to complete your project!
Stop abstracting god dang everything. Interfaces and composition are GOOD, use them. Inheritance and generalization use SPARINGLY, or not at all! Before you create an abstraction, are you CERTAIN sometime in the future you will swap the impl out or are you more likely to throw away the code? Think about that.
Instead of Spring, consider CDI on TomEE. Dependency injection is GOOD, but you don't need to friggen inject everything in the mothafriggen world. Since CDI has a smaller feature set than Spring, you will be forced to not be as stupid. -Said a recovering spring-a-holic
Here's a slight disagreement with the article:
JPA is fine, but Hibernate is bad, slow, and it's made by Gavin King, the man who has a terminal case of 'wasn't invented here' syndrom. Use EclipseLink and stick JPA2, and pull in Redis/Mongo where appropriate.
Writing a service? Use dropwizard[0]
Avoid EE6's version of CDI (WELD/OWB) and EE6 all together. Its slow and causes more problems than its worth. If you really want CDI, use gluice.
Guava is your friend.
Avoid JPA, specifically the parts regarding session management. Never liked it myself and Ebean[1] is a far cleaner ORM which reuses the JPA annotations for mapping classes.
Writing a user facing website? I don't have a good answer here honestly. JSF/EE6 is terrible, GWT - yuck, Wicket - yuck, in my opinion they all suck. For related options Grails seems ok, Play! seems ok, Rails on JRuby seems ok but I haven't used any of them enough to have any real opinion of them. We're currently using angular.js and Jersey for the API on the backend.
Groovy 2 is pretty awesome when performance isn't critical, use it.
Most IDEs tend to hide a little of the noise associated with anonymous inner classes and, at least, with IntelliJ, the auto-completion for things like Guava's Function are huge time savers that make it much more bearable.
Now, should you think twice before you reach for an anonymous inner class? Of course! But there are many situations in which "closures"/"functional-style" anonymous inner classes can significantly decrease the amount of code written and/or make it much clearer. Basically, it lets you stay D.R.Y. much better.
One very common situation is reusing a complicated data structure traversal, just to be able to do two different things with the same inner pieces of data. Without the ability to "pass in code" using anonymous inner classes, the way to avoid code duplication is to accumulate the final destination items in a list and return that from the traversal code, such that this intermediate list can then be fed into the two different code paths. Of course, often such a refactoring is not easy or litters the otherwise-clean traversal code with the details of the intermediate list population. If the intermediate list gets too long to fit into memory or if pagination is required, then you end up having to return an iterator of lists, etc. It just gets messy.
Contrast that with code that takes in an anonymous inner function to apply to each piece of data. Bam, it's so much simpler. Want to start paginating the traversal? No problem, the calling code is none the wiser.
Developers who've been using closures are very familiar with this style of coding. The ugly syntax of anonymous inner functions raises the bar for using them above many simpler situations, but the greater utility cannot be disputed.
Why? Because learning new programming paradigms is beneficial whether you stick with them or not. And Scala is easier for a Java developer to start with than Lisp or Haskell or Z or anything so foreign.
It is simple to get into because you can start basically like "java without semicolons", and IntelliJ community edition has excellent Scala support.
I'm a little hesitant to call Scala "Java without the semicolons". Going too implicit too soon might cause things to go horribly wrong while climbing the learning curve. Besides that, it might scare my colleagues if I was ever to bring that kind of code to work.
I completely agree here. If you're not getting value out of the abstractions, don't introduce them.
However, abstractions in general and OO design does solve many issues that arose from procedural programming. The trick is to recognize the problems, and focus your design around those.
In my last project, I was asked to send a file, that was uploaded by users onto our servers, as a SOAP message over TIBCO where another application read the SOAP message and put the file into a folder where it was processed by a nightly batch job. On the plus side , the managers and executives responsible for the design were all well connected charming people with PMP certification.
Writing code using annotations? Dynamic languages on top of the JVM like Scala? ;)