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 classpath¹. 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.

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

If not P, what? Q maybe?
"Sidney Morgenbesser"