Of course you can do whatever you want, but why might this not be a good idea? Perl is quite large. The entire Perl interpreter is required to run any piece of Perl code. Thus, if your app requires Perl, it will take up a huge amount of storage space. Furthermore, it will probably be quite processor-intensive to run. Java is already expensive to run, and you will be adding the Perl executable on top of that.

Of course, many (most? (all?)) tasks are much easier to accomplish in Perl than Java. That being said, Java can do pretty much anything. It may be more annoying to write it in Java, but it is almost certainly still preferable to stick with one widely available environment for your project. The cost of adding Perl is just too high on a mobile device with limited resources.

Well, I agree with that PerlInterpreter will cause a size overload, but as I read now, Java`s default embed scripting language for end users is Rhino and it`s a javascript written in java. I was interested in Perl as end user script language instead of JS, because Perl is much more powerful and flexible, with CPan and the textual process power, so using Perl is definitely > than JavaScript. I don`t know if size overload is greater in priority than lose of functionality.

Your curiosity is a desirable attribute. But let me make a suggestion. I've embedded Perl interpreters into C and C++ projects before. It's not terribly difficult to get something simple up and running. A basic framework is found in perlembed. However, it can get very complex, very fast.

My suggestion is this: Read perlembed thoroughly, and then get an interpreter embedded in a C program. Put it through its paces with C first, before ever considering moving onto the next step of exposing the C code to Java. In particular (since you mention the power of CPAN), work on getting the embedded interpreter to work with CPAN distributions that you think will be used by your Franken-Java creation.

Interfacing Perl with other languages at an 'internals' level is one of those pursuits where it's best to learn to walk before trying to run. When you look down you'll notice that you're skirting a cliff. ;)

I do have to admit, there is definitely a "cool factor" to using Perl on Android. As long as you are just experiementing, go ahead and have fun!

Still, if you plan to release your app to others, you have to think about the costs. This will add at least several megabytes to your project. You will also be using a build of Perl that is experimental.

This is not about the superiority of Perl to Javascript--I agree 100% that Perl is a better language. This is about the appropriateness of the tool for your task. Perl on Android would almost never be a good choice for a production app.

Point taken, thanks for the advice. It`s definitely a shame that no other script language derivates the ideas of Perl. Since I know JS enough for simple end user scripting, I`ll stick with it... or till Perl-Java hybridization gets further, so I`ll be prepared for that hour. Regards.