For most tasks (basic IO, DB, CGI, GUI, etc), "write once, run anywhere" applies to both languages. However, not all tasks are system-independent. Even some common tasks are system-specific. A language that is truly "write once, run anywhere" would have very limited functionality. The difference between Perl and Java is that Perl realizes this and doesn't shy away from providing access to the system where it's needed.

"Write once, run anywhere" (WORA), or sometimes Write once, run everywhere (WORE), is a slogan created by Sun Microsystems to illustrate the cross-platform benefits of the Java language. Ideally, this means Java can be developed on any device, compiled into a standard bytecode and be expected to run on any device equipped with a Java virtual machine (JVM).

The catch is that since there are multiple JVM implementations, on top of a wide variety of different operating systems such as Windows, Linux, Solaris, NetWare, HP-UX, and Mac OS, there can be subtle differences in how a program may execute, which may require an application to be tested on various target platforms. This has given rise to the joke among Java developers, "Write Once, Debug Everywhere".

I kind of like the color wode.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

It is my understanding that while the Java code would remain the same regardless of platform, the JVM might have differences in it based on the OS and compilers. If the JVM works the same as the Perl executable, then there might not be much difference (from a scripts perspective between OS platforms). There of course would be differences in the underlying exectuble that is invoked.

Please also bear in mind that I Am Not An Expert and could be completely wrong in all my comments :-).

Java takes a "lowest common denominator" approach to portability. That is, it defines a set of basic features that it feels should be available on all platforms, such as files, sockets, threads and so forth, and abstracts them. Features such as the Windows Registry, Unix domain sockets, shared memory, and so on are not available on all platforms, and so do not form part of the Java portable interface. Though you can get at these platform-specific facilities via JNI, you lose "write once, run anywhere" if you do so.

It is somewhat arbitrary what constitutes a "lowest common denominator" set of features, and if you want to port Java to a platform lacking them, you are in trouble. Porting Java to a platform lacking native thread support, for example, is problematic: though you can try a user-level threading library, such libraries tend to behave differently to native threads, leading to subtle portability problems (we had a large Java system that was working nicely on Unix and Windows that took months to port to an OS lacking native threads due to differences in threading behaviour).

Perl (and Ruby and Python) take a different philosphical approach to portability, moulding themselves to the platform they are running on. ActivePerl on Windows, for instance, includes many handy Windows-specific modules out-of-the-box. Though using such platform-specific libraries violates "write once, run anywhere", sometimes that's exactly what you want to do. With discipline, you can create "write once, run anywhere" programs in Perl by sticking to the core language available on all platforms.

"Write once, run anywhere" is a cool motto that can't necessarily be true in practice. There are obvious O/S differences, such as drive letters on Windows, but there are less obvious differences which are hardware based, such as big-endian vs little-endian ordering, the way floating point numbers are represented (not all systems use IEEE arithmetic), basic code sets (EBCDIC vs ASCII; some older systems used 6-bit character sets), etc.

Quite a few languages try to achieve the nirvana of "write once, run anywhere;" it's not trivial for the people who build the underlying compilers|virtual machines|interpreters.