Hogwash. The problem presented is one of an experienced programmer in language X starting a new project in language Y. This is entirely different from the problem of a language designer, expert in both languages X and Y, creating a new language Z.

Neither of us know how many languages the querent is familiar with (as opposed to fluent). If he has already written programs in 10+ languages (like me), it is fully legitimate to consider starting a new project in language Y to be a variant of creating a new language Z based in both languages X and Y. Besides, he needs something to analogize from. Since he's Perl-dominant, he should analogize from Perl.

... However, for a Perl geek trying to swim in the Java swamp, these imported idioms will essentially act as a crutch. Worse, they will render his code unmaintainable by normal Java programmers. All in all, I think this is best avoided.

After learning Java. Not now: don't "put the cart before the horse". It might be wise for the querent to review the Java and C/C++ sections of the perltrap doc "in reverse".

Since his employers dragged him into a Java project, they implicitly asked for these imported idioms. Furthermore, the project may be assumed to either be very well planned (in which case this should be anticipated), or very behind schedule (in which case they won't care).

Assuming both adequate comments and compliance to corporate style guidelines, Java programmers that cannot maintain the resulting code probably can't write code, either. Interpreting Perl idioms in Java is easy, compared to interpreting them in ML. (Ever try emulating a grep or map with no loop control structures, only recursion and branching?)

He will have to Java-ize these idioms for performance reasons, anyway. Think of it as rapid code prototyping followed by conversion of performance bottlenecks.