I'm a Software Developer with over a decade's worth of experience in the IT Industry. While primarily a Java Developer I've working in - among other things - everything from C to Visual Basic to JavaScript to Ruby to Objective-C to C#. I officially consider myself a member of the cult of Lisp which tends to colour the way I think about how code should be written Julian is a DZone MVB and is not an employee of DZone and has posted 11 posts at DZone. View Full User Profile

New Years Resolutions for the Java Developer

01.01.2013
| 6947 views |
  • submit to reddit

 So in closing on a rather eventful year for me personally it's always good to reflect and think and thus we apply the cliché of the new years resolutions - with a twist - in that they will be Geeky.

So without further ado here we go.

Use Spring Less.
I plan to use vastly less Spring this year.

Now Spring has pretty much become the de facto component framework in the Java ecosystem. This is not a bad thing; that is until every software nail must be nailed flat with the Spring hammer.

I been on the Spring Bandwagon now since about 2005 when Spring was still the breath of fresh air promising to save us from the evil Darth Ee-jay-bee. From about that time every developer with a glint in their eye and a will to type has tried to shoehorn everything to "integrate" into Spring.

Again this is not necessarily bad, however I work for a company where the perception is that anything prefixed with the word "Spring" is automatically better, sometimes coming at the cost of something that is actually better.

But lets not stop there...

  • I'm tired of the "For Real?" look I get from my developers when they are debugging Spring configuration and they ask my why Spring is better.
  • I'm tired of the massive War files I get and often the dependency clashes I have to fix because of the other stuff I need to pull in.
So this new year I plan to use Spring in it's pure simple form.

Stop treating JPA/Hibernate as the one stop shop for Java based persistence.

I want to use something besides JPA/Hibernate to do persistence this year, I want to do this because of the following
  • I want to have POJOs that are still POJOs at runtime.

  • I want to stop having weird hibernate exceptions that happen after we've been in production for a bit, and then have my customer stop screaming at me.

  • I want to stop having the rich domain model being so tantalisingly close to my grasp only to have it all come crashing down when the realities of ORM kick in.

  • In reference to the previous point: I hate DAOs; JPA/Hibernate don't make them go away (at least not completely).

  • I'm tired of the "For Real?" look I get from my developers when they are debugging JPA/Hibernate issues and I'm explaining to them how JPA/Hibernate simplifies things.

Now to fair a lot of the points listed is because JPA/Hibernate does a lot of complex heavy lifting on my behalf, but in many cases the power is just not needed. Stop using Anonymous Inner classes and just bite the bullet and wait for 8.

I've been excited about the inclusion of closures in Java for a long, long time. I am a self confessed "closurist " and I fully plan to find as I many nails as I can when I get my closure powered hammer.

But I also have to accept that Java 8 especially in full production use is still going to be some ways away.

And before that I resolve to resist the temptation to butcher code with anonymous inner classes in order to recreate that style of coding.

Stop worrying about the procedural code.

Hah! bet you never saw that one coming. 
I've been looking at the code that we produce, typically I do a lot of SOAP web services in my job, and what I see a lot of is that while we normally try to stick to SOLID principles, I don't see a lot of value coming out of the abstractions we create.
We have an anaemic domain model and most of the work is done in the Service tier implementation delegating to DAOs for data operations (although I've started introducing newer patterns here).
I can't help feel that had I done this code in pure C it probably wouldn't feel massively different. To this end I sometimes wonder if all we do is procedural code with a bit of OO sauce on top. I also wonder is this is necessarily a bad thing; the code works, it's simple to follow and read and is not burdensome to maintain, so this coming year I plan to to stop worrying about it :)
Published at DZone with permission of Julian Exenberger, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Dapeng Liu replied on Sun, 2013/01/06 - 1:29pm

pick an app server (glassfish for example), then replace @Component with @ApplicationScoped, then replace @Autowired with @Inject, then port JdbcTemplate over

then profit!

spring is like taking 99% the size of the war files (we are having 30 wars, i have to build a custom zip to reduce the total deployment package size to be reasonable)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.