Effective Java – Rationale

This series of articles is the culmination of nearly a decade of hard work, academic study, maturation, and procrastination of an entry level Computer Information Systems research project. As such, it should be really amazing :) 

As stated in the precursor article, this series will be focused on Effective Java engineering. The concepts covered will be based on a pragmatic combination of professional experience & academic research; I try not to preach from the Ivory Towers of computing theory, nor do I bastardize my work with the mindset that “this is how things work in the real world”. In my opinion and experience, there is a middle ground to be found that allows the best of both worlds. Where applicable, I’ll provide references to external resources that either provide context or back up my beliefs.

Note: This series has no affiliation to Josh Bloch’s Effective Java book, though I do consider it the “Java Bible”. If you work in the Java space professionally and haven’t read his book, do yourself a favor & pick it up immediately!

 

Preface

Before getting started, I should mention that this is not a “Hello World” introduction to the Java language. I’m expecting the reader to have some familiarity with the Java syntax and basic language constructs.

I’ll cover the basics of getting your environment setup & identify “holes” that many developers have in their knowledge of the Java ecosystem, but I’m not going to hold your hand. You’re expected to do the heavy lifting and fill in those gaps where necessary.

Rationale

Java Problem factory

Why would I write this? Do we really need another series of articles on how to use a language that has been around for nearly 2 decades?

Frankly, yes, I feel we do. Due to the language’s ancient roots, the internet is plagued with horrible Java tutorials that have muddied the waters and created overzealous haters who don’t really understand what they’re hating on. The Java ecosystem is a huge and incredibly powerful tool when wielded correctly, but some unfortunate attempts to make it the end-all-be-all platform of everything has given it a bad reputation in some camps.

I hope to identify where Java fits in nicely and address the nastier areas that are a byproduct of the one-size-fits-all-paradigms approach. A secondary goal would be to provide novices & neck beards with a consolidated resource that shows there is a very well defined sweet spot for Java that facilitates rapid development of a maintainable product.

Are you just another fan boy?

Despite what it may look like, I’m actually not a Java zealot. To be perfectly honest, in my opinion Java is a horrible awful ancient language with an incredibly verbose syntax and a surplus of less-than-steller engineers.

Unfortunately, it’s also the cheapest and easiest ecosystem to facilitate large scale software development in a sustainable manner, both from a business and a engineering standpoint.

Honestly, I’d love for something to come along and knock Java off it’s pedestal, but I have yet to see anything with the momentum to do so. Sure, there are many great up-and-comers, but it’s hard not to take the niceties of these newer technologies and roll them back into the JVM, allowing you to leverage the best of the new stuff along with the tons of already written good stuff. Hopefully by the end of this series, you’ll see why I have a hard time letting go.

So where does Java fit in?

Ah, a great question with a fairly simple answer: middleware. Java has proven itself to be a great middleware language. More importantly, Java has proven where it’s not a great fit:

  • Desktop Software – Sure, JavaSE’s “Write Once, Run Anywhere” sounded like a great idea for things like GUIs (Swing) and data platforms, but we quickly ended up writing code to the lowest common denominator and coming up with slogans like “Write Once, Debug Everywhere”
  • Mobile Software* – I don’t have a lot of experience here, but I hear horror stories of JavaME
  • Browser Plugins – No. Just no. There’s no need to discuss “the myth that Applets are slow” because Applets are slow… and a maintenance nightmare… and terrible for all the reasons JavaSE sucks.

* Android is somewhat an exception, partially because it only utilizes the Java language (rather than the Java Virtual Machine) and only a subset at that.

Let’s get started

Alright, enough with the small talk. In the next article I’ll cover getting started and the basics of being a productive Java developer …