Evan Summers's Blog

Java is all you'll ever need

In his blog, Damien Katz wrote on "Signs you are a crappy programmer, and don't know it." At the top of the list is "Java is all you'll ever need." Since i'm guilty of that, here is my response - why i choose not to add other languages to my toolbox.

So you have some system task to do. This is where you jump into vi and hack together a bash, python or perl script to accomplish this task in quick (and dirty) way, right?

This first problem for me is that this means leaving my Netbeans environment. These days I'd rather go to the dentist for root canal than do that.

Like most people, I guess I don't like going to the dentist. It does have one advantage though, which is if you aren't enjoying your job, you can schedule the dentist in the late afternoon and leave work early. Which i did regularly one year, when i wasn't enjoying my job, and had to go to the dentist a few times for a nagging pain. For my perly whites. Yes, I was using Perl at the time, and vi. So I'd be in that dentist's chair, with the drill screeching in my ears, and thinking, "Ah, what a pleasure not to be at work right now!"

So faced with some small task for which the sharpest drill is python, we should use that because in Java it takes "more lines" of code? No, sorry, I'm gonna take the 5th Netbeans amendment. When all you use is Netbeans, everything starts looking like being nailed.

So I choose Netbeans, to build up a library of support classes for various archetypes of tasks, eg. system tasks. This sharpens my skills in Java in different elements of the standard libraries, eg. System and Runtime. And it keeps me "thinking in Java."

I'm obsessive compulsive about code. Happily Netbeans lets me rename things, to keep my code "clean." Writing in python and C, I get an immediate dentist reaction to lazy and legacy programming conventions, like abbreviations and underscores. I've had that sore tooth removed so that pain would never come back.

Incidently, C# is shaping up well for system tasks, with the C# .Net command-line in Vista. Hopefully the Java community will get a similar thing via Groovy at some point.

In a large company, every engineer and programmer might choose their own favourite language, to automate various tasks. Very soon you end up with an unmanaged and unmanageable environment which is held together with prestuck and sticky-taped scripts, written by ex-employees, in every language you've heard of, and some you haven't.

If I was a CIO, i would have everything done in one language (Java of course), everything managed and versioned in Subversion, and everything documented, ie. javadoc'ed.

And a great way to encourage employees to write overview documentation (in addition to javadocs) is to have a technical company newsletter or blog - and incentivise and reward submissions, with gift vouchers, public praise, and "get out of the dentist's chair free" cards - you know, the important things in life!

But LAMP hackers are real men and use vi innit. They don't want or need an IDE, or strict conventions. The problem is that in large teams, some programmers are veteran gurus of the system, while others are one-month newbies (which might be future veteran gurus, or otherwise working for your competition). Now those newbies want IDEs, to navigate the (javadoc'ed) code with ease, to be prompted with method names, etcetera. And you, the CIO, want to help them help you - show them the Netbeans!

Having those fantastic hackers that Paul Graham waxes lyrically about, is great, until they leave the company to go and work for Google. And leave fantastically terse, undocumented code, behind. To make their newbie replacement's life a spaghetti hell for a few months. Time for the dentist!

Another thing Damien mentions, is cutting and pasting. I think that API's, and superclasses and such, should be blindingly simple. Because it's difficult to predict how you might want to (re)use them in future. So if you build in functionality you need for your current problem, that might render that superclass unsuitable later, for a different unforeseen case. And in trying to change that superclass, or API, you tend to break older code that has been working fine.

So cutting and pasting can serve to isolate code, to make it safe from the rug being pulled out from under it later. An (over-engineered) superclass or API, that is great today, might be a sore tooth tomorrow...

Update. Check my blog "A Fool's Errand" which follows on from this, and introduces an upcoming series "Bin Bash Java" inspired by this blog entry.

Comments

• I for one would rather see badly designed, non-OO, static utility methods everywhere than cut & paste code. I recently worked on a legacy codebase where well over half of it turned out to be cut & paste. I reckon about half of what remains is *still* duplication, but over time it gets harder to find as bugfixes are applied to one file but not another, and the partial duplicates that remain inevitably turn out to be the source of bugs. A few utility methods here and there and things would never have got so bad.

  Posted by: bazzargh on May 15, 2006 at 03:40 AM

• 
  Bazzargh, thanks for your comment. You are right that duplicating the same code everywhere via cutting and pasting, is not something to be recommended.

  I personally prefer functionality in helper/friend classes rather than common superclasses (move it out sideways, not up).

  In one project, we wanted to simplify maintenance using "powerful reusable" superclasses. Those over-engineered superclasses tripped us up later when we needed some slightly different behaviour for some new subclasses - it got complicated and messy and unclear. In the end, we reverted to a flatter heirachy, with simpler and clearer code, even though there was some duplication (via cutting and pasting).

  When there is a lot of duplication, then clearly it's a good idea to refactor that out eg. sideways into library, eg. reusing static utility methods.

  Moving it up into the superclass is tempting, but that can cause problems later, and only it's subclasses have access to that functionality.

  Within a helper/static library class you can readily cut and paste some method into a new method with new behavior for different client classes. It's safer than changing methods used by lots of other classes, and still reusable. And it's quite clear and simple what's going on, whereas with inheritance hierachies, it's not always as clear.

  Also it gives new programmers on the project to ability and confidence to make changes to the API in an isolated way - compared to changing superclasses. There is a risk of messy proliferation of methods, eg. letsDoThis() and letsDoThisLeeroyJenkinsWay001(). But when the team leader is on leave, and it's 5pm on a friday evening, what is a newbie to do?! Choose the weekend!
  

  Posted by: evanx on May 15, 2006 at 04:30 AM

• Shell scripting fro Java using Runtime.exec? Why not use ant's exec task for it, while you're at it? :)

  shuddering,
  dalibor topic

  Posted by: robilad on May 15, 2006 at 05:55 AM

• 
  Dalibor, don't Python and Perl (and bash) use libc's exec() just like java's Runtime class does?

  For "automating" a few commands on Linux, I get lazy and write bash scripts - but adding more functionality to them, they get messy, and they aren't portable (eg. to my Windows laptop). So maybe I should be using Python - but I'm a Java programmer, goddamnit! ;) I wanna use Java and Netbeans, not Python and vi.

  It's quite quick and easy (and fun) to roll your own MySuperShell superclass for your MyLatestTask subclasses to make (file)system commands as syntactically sweet as you want them to be, and portable to boot, and fully programmable. More effort in the beginning (and more fun) but less effort in future to implement tasks. (I'll write a follow-up blog with some examples, I promise.)

  Also there are great tools you can use, eg. JavaSSH (altho still work in progress I think), probably a rsync library too? (I haven't got that far myself, so i dunno). And Quartz scheduler. You can use URLConnection to fetch stuff, you can connect to databases via JDBC, send notifications using JavaMail, you got Jakarta FTPClient, you got logging - you got it all!

  If you wanna get very fancy down the line, you can wrap your tasks into remotely-accessible servlets, JMX-enable them, and/or add Swing front-ends eg. using Netbeans Matisse. The support desk and your boss will love you for that, innit. "You in the dog pound, baby!" ;) And yes, wrap them into Ant tasks too :)

  The point is that Java developers should be programming/scripting in Java (or Groovy), for the same reason that we program in Java and not C... "Give me more scripting power, Scotty McNeally!"

  C# programmers are gonna be using that fabulous C# .Net command-line, and make our bash scripts look silly. And make us look silly using Python because Java can't cut it. Lets make Java sharper, not just for big applications, but also for small tasks too.
  

  Posted by: evanx on May 15, 2006 at 06:42 AM

• 
  A shell (and a scripting language) does quite a bit more than just exec system commands on the $PATH. Just comparing the simplicity of using '|' vs. spending lines setting up Java's piped readers/writers (or any kind of IO, really) gives me shudders. :)

  A shell script is portable to quite a few platforms, including Windows, provided you install the shell on the platform, and write portable shell code. Both issues (lack of deployment & taking care to write portable code) exist with Java, as well. :)

  cheers,
  dalibor topic

  Posted by: robilad on May 15, 2006 at 10:06 AM

• Anyone thinking (and claiming) he needs only a single tool and that that tool will be able to do any job he may get is a fool (and if he's a programmer a poor programmer).

  Find the best tool for the job at hand, don't try to fit the job to the tool you have.

  I've seen enough results of the latter way of working, and I'd rather not have to maintain those things.
  

  Posted by: jwenting on May 18, 2006 at 09:37 PM

• Check my blog "A Fool's Errand" which follows on from this, and introduces an upcoming series "Bin Bash Java" inspired by this blog entry.

  Posted by: evanx on May 19, 2006 at 03:30 AM

• 
  C# programmers are gonna be using that fabulous C# .Net command-line, and make our bash scripts look silly. And make us look silly using Python because Java can't cut it. Lets make Java sharper, not just for big applications, but also for small tasks too.

  
  Amen!

  A thought-provoking post Evan. Keep it up. With all the great simplifications Java is undergoing in the high-end Java EE sphere, we must not forget making Java suitable for simpler problems, such as RoR-type problems and even scripting tasks. I look forward to seeing your series develop.

  Too often the saying "use the right-tool for the job" has been used as a excuse for tool-makers who can't make scalable tools.

  I am tired of the needless language proliferation I see happening today. It fragments our work -- partitioning it into incompatible islands. I am a Java programmer. I've spent years mastering the ever growing mountain of Java APIs and have created some myself. Why on earth should I have to learn a new languages' APIs when writing small scripts -- it's crazy! It dilutes our effectiveness. Microsoft knows this and will allow programmers to leverage their API knolwedge investment when scripting. I hope Java community has an answer to this -- inititives such as Groovy, BeanShell gives me hope.

  BTW, do you know about the NailGun project. It is good for developing command line utilities without the JVM start-up delay. It might come in handy, although your idea of wrapping tasks as servlets would eliminate the start-up delay too.
  

  Posted by: ahalsey on May 25, 2006 at 06:08 PM

• 
  Thanks for your post, halsey! I wholy concur with your sentiments.

  Toolmakers should be saying "Let's make the right-tool for the job using Java" rather than "Let's use that other non-Java tool for the job, because it's quick and easy."

  Thanks for the NailGun reference, it looks great.

  I liked this quote from the NailGun background page, that is appropriate to this series.

  Java has an extensive and robust core API and huge number of available open source libraries. It's a great big hammer, making almost any programming project look like a nail.

  I dunno if you caught the blogs following on from this, "A Fool's Errand" and then "Bin Bash Java (Chapter 1)".

  
  

  Posted by: evanx on May 26, 2006 at 01:27 AM

This work is licensed under a Creative Commons License.