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:
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.