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.