New Year’s Resolutions for the Java Developer
blog.jelastic.com
New Year’s Resolutions for the Java Developer
1–10 of 18 posts
Re: New Year’s Resolutions for the Java Developer
#2As a Scala developer I'm obviously biased, but I would add "try out scala" to this list.
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.
Re: New Year’s Resolutions for the Java Developer
#3Looks like Spring/Hibernate is losing it's shiny new gloss. I wonder what the next round of 'hammer to fit all nails' that 'we need to rewrite everything in!'
Writing code using annotations? Dynamic languages on top of the JVM like Scala? ;)
Re: New Year’s Resolutions for the Java Developer
#4This year ,I will recover from my Spring addiction. The grim realization that Spring ruining me a as a programmer dawned upon me when I looked at my project that was using Spring Integration and I could not figure out what the heck was happening . There was so much xml that my eyes bled ! Other Spring addicts suggested using the Spring IDE for visualizing Spring Integration xml, but I think the Spring way of life just makes simple things complicated. I have decided to refactor all my Spring Integration code and instead use Clojure ( perhaps in most non-idiomatic fashion) to glue java static methods into a sequence of functions that provide the same workflow as Spring Integration. If this works out, I will target Hibernate next; I hate having to do master hibernate/ORM api to do SQL operations.
Re: New Year’s Resolutions for the Java Developer
#5>Stop worrying about the procedural code [...] I don’t see a lot of value coming out of the abstractions we create.
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.
Re: New Year’s Resolutions for the Java Developer
#6I would add "stop using SOAP" to this list. Its 2013!
Re: New Year’s Resolutions for the Java Developer
#7I'm a Java advocate. Here's a few more:
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.
Re: New Year’s Resolutions for the Java Developer
#8I would add "stop using SOAP" to this list. Its 2013!
Good luck with that ! You are not using SOAP because two programmers decided it was the best integration solution for distributed computing . We, you and I, are using SOAP because our CIO /Sr. VP was invited to an offsite retreat or management executive seminar where over a course of the finest hooch and blow, an enterprise vendor ( most likely IBM or Oracle) convinced your exec that having SOAP is like having an insurance against personal accountability for project disasters; after all nobody has ever got fired for buying IBM. So rail and rant against SOAP at your own peril.
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.
Re: New Year’s Resolutions for the Java Developer
#9As a Scala developer I'm obviously biased, but I would add "try out scala" to this list. 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 exce…
2013 Scala newbie here. Scala feels nice in the way that Python feels nice. They both give the newcomer some say in what programming paradigm they get to think in. I like languages like that.
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.
Re: New Year’s Resolutions for the Java Developer
#10Java is a language for people good at resisting temptation. It gives you all sorts of ways to make your code look nicer, more elegant, but the only way to be productive in Java is to avoid all of them.
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.