If the reason for compiling is security reasons, you have serious problems - you should really tighten up that security before anything else.

You might, or you might not, want to mention facts like this to your client - either way, you are better off knowing this. The .class files for java is today only a minor hindrance if you don't have the source code. Decompilers like JAD works some insane magic to bring back the original source code, and all you really lose today are some of the variable names and the comments. Now, I am not very proficient in exactly which modules to use in perl, but at a guess, somewhere between B::Disassembler and B::Deparse probably would render that bytecoding useless as a means of concealment. Have not tried it though, but it is perlish to be possible to reverse engineer. :)

The next step is of course, as MZSanford suggested, to compile all the way. Thay way you have a binary file much like any other - too hard to decompile for it to be worth it.

Then again, maybe it is just your client that is concerned about this, due to reading some technical article he/she doesn't actually understand. (Pointy hair: "I think we should build a SQL database." Dilbert: "What color do you want it?" Pointy hair: "I think muave has more RAM."). In this case, you can just take the above suggestions, implement and everybody goes home happy. In either case, I think you are not worse off for knowing about these tools - and knowing that there are no replacement for real security, and of the would-be replacements, security through obfuscation is one of the most unreliable. Avoid at all costs. :)