I'm not sure what you mean by talking about stuff going into the core with Java as "bloat," unless you're referring to raw download size of the JRE. It's by no means the same situation as with PHP, because Java has packages, while PHP does not. It can be quite maddening for quite a long time to figure out how one accesses one's preferred database in PHP, for example, since mysql_* and pg_* are both in the core (well, if you compile them in, they are).

You can write a reasonably functional (if verbose) program in Java without using anything outside of the java.lang package (although, heh, you can't process a file ...); OTOH, if you need to process XML and you have JDK 1.4 or later, or you want to serialize some expensive-to-construct objects in Java, you can do it without having to download anything new. Yes, the base API documentation is huge, but you can do a heck of a lot with it. It's kinda like shipping a lot of CPAN in the distribution.

It's by no means an official central Java repository of modules, and it's also by no means as comprehensive as CPAN, but the Apache Jakarta project has been developing reusable components, some of which are quite nice. I still prefer CPAN, but my point is that the Java picture is not as bleak as it is sometimes made out to be. Of course, for most textual processing, I still prefer to use Perl, but my view of Java is not as jaundiced as it used to be.

I probably should not use word "bloat", I'd better say lack of modularization (on the other hand don't they come together often?). It irritates me as hell that when, say, I need a certain feature of Postgres API I have to upgrade to a new version of PHP. I must admit I'm not doing Java programming for quite long time but your phrase if you need to process XML and you have JDK 1.4 or later, or you want to serialize some expensive-to-construct objects in Java, you can do it without having to download anything new sounds like indication of same problem.

CPAN frees me from dependancy on core libs. I don't have to wait for a new release of Perl to get new features and/or bug fixes, I don't have to upgrade to a new release of Perl to use features and/or bug fixes. CPAN makes me free from release schedule for Perl.

It appears to my clouded lens that Perl's lack of strong typing and contract enforcement has
allowed it to be as backwards-compatible as it is (arguably moreso than Java),
although it seems you hold Java to a double standard since there are quite a
few modules out there that require, for whatever reasons, versions of Perl more
recent than Perl 1.0 (if it ever existed) - CPAN, great as it is, doesn't
solve the difficulty of adding new language features and having new libraries
dependent on those new language features be backwards compatible. Are you
going to make all your programs Perl 4 compliant? How about Perl 3?

One of the things that's seemed to be an everpresent problem in CS is that
designing for the future is hard. You just can't foresee all the problems
that might crop up. YouArentGonnaNeedIt and YouAreGonnaNeedIt are always
ridin up and down that seesaw of long-term planning, and I think it's
unreasonable to expect to that language specifications shouldn't also evolve
with the programmers using those specifications. It'd be great for them to get it right the first time, but how often does that happen? Why do notions like refactoring have books written about them?

I'd argue that writing programs in a 'foolproof' way is hard to do in Perl,
just as it is in Java or any other language. However, the addition of type safety is sometimes a
GoodThing, since it mitigates the risk of client code (code using any given API) screwing up by having arbitrary functions executing arbitrary things. I want to idiot-proof my code, not because I think other people are idiots, but because I know I _am_ an idiot, and I'll screw things up every chance I can get.

Don't get me wrong, I really like perl a lot (and am still learning!), I was raised
on Scheme and C/C++, but I also respect Java's place in the PL hierarchy
(although they should have at least handled recursive tail calls properly...
that's a different story though ;). It's just that having non-static typing
means that you can't make as strong a guarantee of what you can or can't do
with a symbolic name. It means that my subroutine can return an integer half
the time, or another subroutine as a first class value the other half of the
time. It means that if in my program, if I accidentally re-assign my $shared
variable somewhere (even with lexical scoping), $shared might be a hash
reference instead of an array reference. Of course, I can add a check at
runtime using ref(), but sometimes it's nicer to have that check made for me
at compile-time so I don't have to wait and write a unit test to realize that
I'm bungling something. Perl is great for flexibility, brevity,
expressiveness-in-shortest-number-of-lines, and, in general, becoming a very
'natural' and idiomatic language to speak in, but but it also provides a lot of ways for me or the person coding to my framework to screw up by localizing
the wrong symbolic name at the wrong time or whatever.
To me, one of the biggest strengths of Java is its ability to enforce
contract-based programming. You can ensure that implementors and
client-developers follow the contract that you lay down to some stronger degree
than most other languages... for instance, (example shamelessly lifted from the
way JUnit does things, basically an example of the Template Method from the
GoF):

Granted, this contract is still a little weak, since we have no guarantees as
to what doSomethingThatRequiresSetup() does, but we can guarantee that the
initialization and finalization steps occur, if J. Random Implementor does
decide to extend the Goo class and implement the doSomethingThatRequiresSetup()
method. Of course, it is still possible to screw this guarantee up by
spuriously subclassing the Goo class and overriding the behavior of
doSomething(), or directly invoking doSomethingThatRequiresSetup(). As always,
one should always favor composition and delegation to inheritance, but that's just part of the lingo. It's like getting slapped here for not use strict; or
to turn warnings off or to not untaint user input that's going to be inserted
into invocations of system() or exec() (or even sending user input to system or
exec commands for that matter).

Besides, no language holds a candle up to Scheme ;). Where else can you smash
your brains out with the power of hygienic macros and call/cc? Not until
continuations become first class values in Perl 6 at least :).

I'm replying here at IlyaM's request (we've had a /msg discussion going for a while). I think the charge of lack of modularity in Java is way off the mark, and he thought I should put my thoughts into a post.

Extending the functionality of Java is as simple as getting the relevant .jar file and putting it on your application's classpath. If you want to make certain functionality available to all your applications (à la default @INC in Perl) you can have that, too, by putting the relevant jars in the system's extension directory, although the mechanism doesn't lay out directories à la @INC. In the most recent versions of the JDK, you can even override some of the packages in the java.* and javax.* hierarchies simply by putting jars in the appropriate directory. And, of course, you can set your classpath and other system properties however you want when you execute java, so all this stuff is flexible.

Combined with Java's (mostly) OO roots (AOL keyword: "code reuse"), in particular the ability to define interface classes and different implementations thereof, this makes for mad modularity and upgradeability, even extending in some cases to classes in the core of the language. I'm not saying that Perl doesn't have these features (you can fake the ones that aren't there by default), but that to say Java doesn't have them is based on a serious misconception.

My earlier comment merely referred to the fact that JDK 1.4 implements the JAXP specification ( standardized API for XML processing ) "out of the box", but you had that with earlier versions of the JDK simply by downloading the relevant jars and placing them on your classpath1. Java is, and has since the introduction of jars, been highly modular and upgradeable, outside of the core classes. There is still no CPAN equivalent.

1 JDK 1.4 also makes regexps available out of the box. Wow, it only took about 6 years after Perl5 =)