Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

Re: Re: Re: Re: How would you fix Java?

by arturo (Vicar)
on Apr 21, 2003 at 12:21 UTC ( #251981=note: print w/replies, xml ) Need Help??

in reply to Re: Re: Re: How would you fix Java?
in thread How would you fix Java?

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.

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

  • Comment on Re: Re: Re: Re: How would you fix Java?

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: How would you fix Java?
by IlyaM (Parson) on Apr 21, 2003 at 14:22 UTC
    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.

    Ilya Martynov,
    CTO IPonWEB (UK) Ltd
    Quality Perl Programming and Unix Support UK managed @ offshore prices -
    Personal website -

      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):

      public abstract class Goo implements Gooable { protected abstract void doSomethingThatRequiresSetup(); public void doSomething() { setUp(); doSomethingThatRequiresSetup(); tearDown(); } public void setUp() { ... initialize network connections and blah blah blah } public void tearDown() { ... close network connections and any open files } }
      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 :).

      wow, that's a lotta blathering. apologies for the rambling - flames/corrections/thinly-veiled insults are welcome!


      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 =)

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

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://251981]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (6)
As of 2023-03-27 17:13 GMT
Find Nodes?
    Voting Booth?
    Which type of climate do you prefer to live in?

    Results (65 votes). Check out past polls.