Does it make sense to rewrite Perl and shell scripts in java?

Question

I have a bunch of scripts - some in perl and some in bash - which are used for:

• Creating a database (tables, indexes, constraints, views)
• Parsing spreadsheets and loading the data into the database
• Getting info about a bunch of files and loading that into the
  database.

These scripts are used in conjunction with a much larger application that is written in java, and my manager has requested that I rewrite the scripts in java. His reasoning is that it is easier to work with, port, manage, understand, and support if it's all in one language, and that too many separate pieces is a design issue.

My initial reaction is that this is a bad idea. The scripts are beautifully concise and fast, and tasks that are trivial in the scripts - such as using regexs to find and replace invalid values - will be so much more verbose and very likely slower when done in java.

The one drawback of the scripts is that when they run on windows they require cygwin in order to run. Therefore I would like to give a counter proposition that I port all the bash scripts to perl so that they can run on windows without cygwin, and that I spend time organizing and documenting the scripts.

The problem is that a "gut reaction" type of response is not going to be enough to convince my manager. I come from a linux background, he from Windows, and we have some of the classic linux vs. windows differences in approaches.

So I have two questions:

1. Is my "gut reaction" correct? Is java slower, more verbose, and harder to maintain for database management, spreadsheet parsing, & file processing tasks?
2. If the answer to the first question is yes, what is the best way to present my case?

---

EDIT: Thanks everyone for the insights. I'd like to make one clarification: the scripts are not full-blown apps hidden away in obfuscated scripts. They are, for the most part, tasks that had been done manually that I automated via scripts and later embellished as the requirements developed. And the reason I used a scripting language instead of java to start with is because these tasks were so much easier to do in scripts. For example, one script runs a bunch of queries, formats the results, and outputs them to a file. How many LOC do you think it would take to do that in java?

Answer 1

The trouble is, your Gut reaction might be right, but that doesn't mean your manager is necessarily wrong - he probably has very good reasons for wanting it all done in java. Not least, if you fall under a bus, finding a replacement who knows java, perl and bash is going to be a lot harder than finding someone who knows java. And that's leaving aside the "they can only be run on a PC with cygwin installed" issue. And in all likelihood, performance isn't as big an issue as you think it is.

Having said that, your best bet is to spend a bit of time estimating the time it will take to port them all to java, so he can make an informed decision. And while you're at it, estimate how long it would take to port the bash scripts to perl and document them. Then let him decide. Remember - he doesn't get to spend the majority of his time coding, like you do, so it's only fair that he gets to make some decisions instead.

If he decides to proceed with the java option, port one of the scripts as well as you can, then report back with the two versions and, if you're right about the concision of the perl/bash scripts, you should be able to get some mileage from examining the two versions side by side.

EDIT: MCS, to be honest, it sounds to me as if those scripts are better implemented in perl and/or bash, rather than java, but that's not really the point - the point is how do you demonstrate that to your manager. If you address that, you address both the "gut reaction" question (btw, here's a tip - start referring to your gut reactions as "judgement, based on experience") and the "best way to present my case" question.

Now, the first thing you have to realise is that your manager is (probably) not going down this path just to piss you off. He almost certainly has genuine concerns about these scripts. Given that they're probably genuine concerns (and there's no point in going any further if they're not - if he's made his mind up to do this thing for some political reason then you're not going to change his mind, no matter what, so just get on with it and add it to your CV) it follows that you need to provide him with information that addresses his concerns if you're going to get anywhere. If you can do that then you're more than halfway to getting your own way.

So, what are his concerns? Based on your post, and on my judgement and experience :-) I'd say they are:

• maintainability
• that's it, just maintainability

I would also guess that his concerns are not:

• performance

I might be wrong about this last one, of course; in the last place I worked we had a SQL Server performance problem to do with replication that impacted the business's ability to provide customer support, so performance was an issue, so we addressed it. But generally speaking performance isn't as much of an issue as programmers think. If he's actually told you that performance is an issue, then factor it in. But if he hasn't mentioned it, forget it - it's probably only you that thinks the fact that these scripts run faster in perl/bash than they probably will in java matters at all.

So, maintainability. This comes down to answering the question "who will maintain these scripts if MCS falls under a bus?" and the supplementary question "will that cause me (i.e. your manager) problems?" (Aside: don't get hung up on the whole bus thing. "Falling under a bus" is a useful and diplomatic shorthand for all sorts of risks, e.g. "what happens if someone lures him away with a salary my company can't match?", "what happens if he decides to emigrate to Bermuda?", "what happens if I want to fire him?", "what happens if I want to promote him?", and, of course, "what happens if just he stops turning up for work one day for some unknown, possibly bus-related, reason?")

Remember, it's your manager's job to consider and mitigate these risks.

So, how to do that?

First, demonstrate how maintainable these scripts actually are. Or at least how maintainable they can be. Document them (in proper documents, not in the code). Train a colleague to maintain them (pick someone who would like to acquire/improve their perl and bash skills, and who your manager trusts). Refactor them to make them more readable (sacrificing performance and clever scripting tricks if necessary). If you want to continue using bash, create a document that provides step-by-step instructions for installing cygwin and bash. Regardless, document the process of installing perl, and running the scripts.

Second, pick one of the scripts and port it to java. Feel free to pick the script that best demonstrates the advantages of perl/bash over java, but do the best job you can of porting it. Use java.util.regex to do the same clever things you do in your perl. Document it to the standard that other in-house java utilities are documented. If performance is actually a factor, measure its performance relative to the perl/bash script.

Third, having been through that exercise, be honest with yourself about their relative maintainability. Ask the guy you trained what he thinks. If you still think the perl/bash scripts are more or less as maintainable as java versions would be, estimate the work involved in porting the remaining scripts to java as accurately as you can (you'll be able to do this pretty accurately now, because you'll have actually ported one). Then take the comparative scripts and the documentation and the estimates (and the performance figures, if appropriate) to your manager and go through them with him. Present your counter-proposals (a. leave them in perl and bash but document them and train a colleague, and b. port the bash scripts to perl, document them and train a colleague).

Finally, let your manager weigh up all the information and decide, and abide by his decision. In fact, don't just abide by his decision, accept the fact that he might be right. Just because you know more about perl/bash/java than him doesn't mean you necessarily know more about managing the team/department than he does. And if his decision is to stick with perl/bash, or port to perl, rejoice! Because you have not only got your own way, you have gone up in your manager's estimation and learned an invaluable lesson along the way.

Answer 2

It depends. I've found that text processing in Java can take up to 8 or 9 times the amount of code as in Perl. If these scripts need to be tightly integrated into the application then I would agree with your manager but if there just background tasks I'd look into using ActiveState on windows and rewriting the bash scripts in Perl.

Answer 3

Personally I find db, file management harder to do with java, but it may be easier to maintain once they are written.

But is it worth it? If it works, don't 'fix' it.

Personally I don't care - If I get work to do, I debate pros and cons with my manager and if she insists, I do it and get payed. Usually she comes to her senses though, and gives me more important work to do.

Answer 4

I think your first reaction is right. One argument is If it works, don't 'fix' it. Another argument is that one developer can write almost same amount of SLOC independently of language which used. It sounds strange if you know how is Java verbose but think about how carefully you must design your Java code to get same result using perl features as closures, dynamic generated code, instant regexps and other. And now when Java to Perl SLOC ratio to same result is more than 10:1. Each line of code you must read, understand and maintain. Java is faster. Yes. Java is faster for some thinks as number crunching and some sort of text processing. Perl is faster for regexps and some other text processing and far far more productive than Java generally. Perl is worse maintainable if compared by SLOC but same or better than Java if compared by feature. If Perl is written using best practices and keep coding style than can beat Java in maintainability especially if used for short scripts.