Be sure to ask him to submit all requests as UML diagrams, in triplicate, with TPS cover sheets and circles and arrows and a diagram on the back of each one.

On the other hand, if you want to keep your job, maybe digging a little deeper is the way to go here. Maybe your architect knows what he's doing. Maybe he has solid, concrete reasons for asking you to do this. There's also the possibility that he's just parroting what he knows (I've had to work with such a boss. It's not fun.) Does the architect understand the strengths and weaknesses of Perl? What works well in one is frequently a horrible mistake in the other. The languages do not translate easily into one another.

A classic examples is Lucene. It's Java. It's powerful. It's fast. Then it was ported very faithfully to Perl and called Plucene. In Perl it doesn't scale well because it's so darned slow. Does this mean Perl can't handle stuff like this? No. Search::KinoSearch is a new search engine written in Perl and it doesn't have the same performance problems.

Personally, I am very leery of Perl or Java gurus trying to be the architect on the project written in the other's language. I know Java, but I'd hardly qualify as an architect. I'd be going around asking silly questions like "why don't you just build a bunch of custom closures for callbacks?" And the Java guys would rightfully snear and make posts very similar to yours.

I know that doesn't answer your question (I'm hopeful that someone else can), but I thought it might shed a little light on another way of looking at the situation.