Pivotal Labs

Main menu

Skip to primary content
Skip to secondary content
  • About
  • Case Studies
  • Team
    • Executives
    • Locations
      • San Francisco (HQ)
      • Boston
      • Boulder
      • Denver
      • London
      • Los Angeles
      • New York
  • Community
    • Blogs
    • Tech Talks
    • Events
  • Careers
    • Lifestyle
    • Principles & Practices
    • Benefits
    • FAQ
    • Apply
  • Contact
    • Press Room
    • Press Releases
    • In The News
    • Press Kit
  • All
  • Labs
  • Standup
  • Tracker

Java Stink

Alex Chaffee
Monday, February 11, 2008

After about two years in which the only Java I wrote had a “Script” after it, I’ve recently started working in my old favorite language again. It was clear to me long before I made the leap that somewhere along the line Java took a sharp turn towards Scarytown. (Maybe the writing was on the wall when the “Hello World” program comprised five lines, two declarations, and a static reference, but back in 1995 we were all so excited about getting objects without C++ that our judgement was clouded.)

Anyway, I will always have a place in my heart for the old bird (picture a portly English matron with flower dress and pocketbook and floppy hat), but Stu at Relevance Blog points out why coding in Java now feels like trying to sprint with 30-pound weights strapped to my ankles.

Java is a high-ceremony language. At every turn, Java enforces a high busy-work/real-work ratio. Specifically:

  1. Java’s checked exceptions bloat code, make components harder to use and maintain, and lead to tons of boilerplate code, each line of which is a bug-in-waiting.
  2. Java’s new operator/constructors cannot pick a return type. The amount of code that exists only to work around this is staggering. Two entire cottage industries have sprung up to deal with this single issue: factory patterns and dependency injection.
  3. Java has no metaprogramming features to automate common tasks such as field accessors, standard constructors, and simple delegation.
  4. Primitives, functions, and classes are not first-class objects, leading to huge code bloat to deal with these types specially.
  5. Java’s core reflection and interception capabilities are clunky, requiring tons of bolt-on technologies to make them workable, including AOP, annotations, and code generators.

That’s a pretty big stink, but if you are used to it you probably can’t smell it anymore.

(And that’s not even mentioning the prevalent idioms of programming with massive amounts of indirection and wrappers and statics and service locators and and BigLongClassNamesThatIncludeTheirAncestry (I always say, “Do we call it a DogMammalVertebrateAnimal? No, we call it a dog!”) and redundant JavaDoc on every method and…)

I ranted and spoke and even blogged about some of these issues before, but now that I’m a visitor in that world I just feel vaguely amused and sad when I see all the hoops Java programmers still have to jump through. Yeah, control-space completion is nice, but gotapi works pretty well, and at the end of the day, no matter how many curly braces my IDE inserts for me, I’d rather have my code look like this:

parse_args(["--topping", "pepperoni"])

than this:

String[] args = {"--topping", "pepperoni"};
parseArgs(new ArrayList<String>(Arrays.asList(args)))


Wouldn’t you?

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

4 Comments

  1. Viktor says:

    Ive always worked with java. I think its quite simple in comparison and a bit more interactive. It’s the only one ive been comfortable with actually.

    February 12, 2008 at 11:53 am

  2. Chad Woolley says:

    For #1, you should convert all checked exceptions into unchecked exceptions as soon as possible.

    Can’t help you with the others, sorry :)

    February 12, 2008 at 7:11 pm

  3. Joubin says:

    if(cant(invoke(setterOf(Property(field))), withThisValue)){
    set(field, withThisValue);

    // .. or say something silly about java ..
    }

    February 19, 2008 at 6:47 am

  4. Will Sargent says:

    I can help some.

    String[] args = {“–topping”, “pepperoni”};
    parseArgs(new ArrayList(Arrays.asList(args)))

    With 1.5, we can cut this down:

    import static java.util.Arrays.*;
    parseArgs(asList(“a”, “b”, “c”));

    Or, if we assume varargs…

    public void parseArgs(String… args) { … }
    parseArgs(“a”, “b”, “c”)

    February 24, 2008 at 6:42 pm

Add New Comment Cancel reply

Your email address will not be published.

Alex Chaffee

Recent Posts

  • Code Monkey
  • RubyGems Warningitis Outbreak
  • Upgrading your Rakefile from RSpec 1.3 to RSpec 2
Subscribe to Alex's Feed

Author Topics

ruby (14)
gem (5)
ruby on rails (24)
erector (2)
rspec (4)
activerecord (4)
database (3)
sinatra (1)
postgresql (1)
css (1)
html (1)
git (2)
mac (5)
java (3)
agile (12)
iphone (1)
migrations (1)
fun (5)
dot (1)
graphing (1)
subversion (1)
test (1)
demeter (1)
puzzler (1)
  • About
  • Case Studies
  • Team
  • Community
  • Careers
  • Contact
  • Labs
  • Events

Contact Us

contact@pivotallabs.com
+1 415-77-PIVOT
TwitterLinkedInFacebook

Pivotal Tracker

Tracker is the award-winning agile project management tool that enables real-time collaboration around a shared, prioritized backlog.
Visit pivotaltracker.com >