Discussions

News: "Java Sucks" revisited

  1. "Java Sucks" revisited (2 messages)

    Overview

    An interesting document on Java's short comings (from C developer's perspective) was written some time ago (about 2000? ) but many of the arguments issues are as true (or not) today as they were ten years ago.
    The original Java Sucks posting.

    Review of short comings

    Java doesn't have free().
    The author lists this as a benefit and 99% of the time is a win. There are times when not having it is a downside, when you wish escape analysis
    would eliminate, recycle or free immediately an object you know isn't needed any more (IMHO the JIT / javac should be able to work it out in theory)

    lexically scoped local functions
    The closest Java has is anonymous methods. This is a poor cousin to Closures (coming in Java 8), but it can be made to do the same thing.

    No macro system
    Many of the useful tricks you can do with macros, Java can do for you dynamically. Not needing a macro system is an asset because you don't need to know when Java will give you the same optimisations. There is an application start up cost that macros don't have and you can't do the really obfuscated stuff, but this is probably a good thing.

    Explicitly Inlined functions
    The JIT can inline methods for you. Java can inline methods from shared libraries, even if they are updated dynamically. This does come at a run time cost, but its nicer not to need to worry about this IMHO.

    I find lack of function pointers a huge pain
    Function pointers makes in lining methods more difficult for the compiler. If you are using object orientated programming, I don't believe you need these. For other situations, I believe Closures in Java 8 is likely to be nicer.

    The fact that static methods aren't really class methods is pretty dumb
    I imagine most Java developers have come across this problem at some stage. IMHO: The nicest solution is to move the "static" functionality to its own class and not use static methods if you want polymorphism.

    It's far from obvious how one hints that a method should be inlined, or otherwise go real fast
    Make it small and call it lots of times. ;)

    Two identical byte[] arrays aren't equal and don't hash the same
    I agree that its pretty ugly design choice not to make arrays proper objects. They inherit from Object, but don't have useful implementation for toString, equals, hashCode, compareTo. clone() and getClass() are the most useful methods. You can use helper methods instead, but with many different helper classes called Array, Arrays, ArrayUtil, ArrayUtils in different packages its all a mess for a new developer to deal with.

    Hashtable/HashMap does allow you to provide a hashing function
    This is also a pain if you want to change the behaviour. IMHO, The best solution is to write a wrapper class which implements equals/hashCode, but this adds overhead.

     

    Read the rest of the article at the following URL:

    Java Code Geeks: "Java Sucks" revisited

    Threaded Messages (2)

  2. re: "Java Sucks" revisited[ Go to top ]

    >>Java doesn't have free().

    This is a blessing,writing concurrent code w/ free is just pain in the neck. Most of the times where free would help the cases the allocating is in the TLAB (just a pointer bump) and the objects die trivially in the young gen. According IBM EA doesn't help outside microbenchmarks and I'd concur - it's too rare to need and create objects just to pass them to a method and they die off immediately afterwards.

    >>lexically scoped local functions

    it's anon. classes, not methods (methods do have a real name/signature)

    >>Explicitly Inlined functions

    This is a plus, imo. Developes are often (mostly) wrong where are the performance bottlenecks, JITs tend to inline most private methods and the polymorphic too (via inline caches) as long as they are hot. If they are not hot - there is no point to optimize in the 1st place.

    >>Two identical byte[] arrays aren't equal and don't hash the same

    Use ByteBuffer if you need extra functionality. The direct one maps straight to C's malloc. If you would have said chaining Input/Output Streams adds intermediatery buffers everywhere I'd agree, though.

    >>Hashtable/HashMap does allow you to provide a hashing function

    java.util.HashMap is just bad overall. Not only it's bucket based (i.e. cache unfriendly) but the modCount field is declared volatile - modifying the HashMap leads to a volatile write which is slow on any platform, beside that need for an allocation. Traversing the HashMap via iterator has a volatile read, while actually 'free' on x86 but on weaker models (ARM, Power) it requires an ordered load.

  3. Write once, Run everywhere.[ Go to top ]

    Overview

    An interesting document on Java's short comings (from C developer's perspective) was written some time ago (about 2000? ) but many of the arguments issues are as true (or not) today as they were ten years ago.
    The original Java Sucks posting.

    Review of short comings

    Java doesn't have free().
    The author lists this as a benefit and 99% of the time is a win. There are times when not having it is a downside, when you wish escape analysis
    would eliminate, recycle or free immediately an object you know isn't needed any more (IMHO the JIT / javac should be able to work it out in theory)

    lexically scoped local functions
    The closest Java has is anonymous methods. This is a poor cousin to Closures (coming in Java 8), but it can be made to do the same thing.

    No macro system
    Many of the useful tricks you can do with macros, Java can do for you dynamically. Not needing a macro system is an asset because you don't need to know when Java will give you the same optimisations. There is an application start up cost that macros don't have and you can't do the really obfuscated stuff, but this is probably a good thing.

    Explicitly Inlined functions
    The JIT can inline methods for you. Java can inline methods from shared libraries, even if they are updated dynamically. This does come at a run time cost, but its nicer not to need to worry about this IMHO.

    I find lack of function pointers a huge pain
    Function pointers makes in lining methods more difficult for the compiler. If you are using object orientated programming, I don't believe you need these. For other situations, I believe Closures in Java 8 is likely to be nicer.

    The fact that static methods aren't really class methods is pretty dumb
    I imagine most Java developers have come across this problem at some stage. IMHO: The nicest solution is to move the "static" functionality to its own class and not use static methods if you want polymorphism.

    It's far from obvious how one hints that a method should be inlined, or otherwise go real fast
    Make it small and call it lots of times. ;)

    Two identical byte[] arrays aren't equal and don't hash the same
    I agree that its pretty ugly design choice not to make arrays proper objects. They inherit from Object, but don't have useful implementation for toString, equals, hashCode, compareTo. clone() and getClass() are the most useful methods. You can use helper methods instead, but with many different helper classes called Array, Arrays, ArrayUtil, ArrayUtils in different packages its all a mess for a new developer to deal with.

    Hashtable/HashMap does allow you to provide a hashing function
    This is also a pain if you want to change the behaviour. IMHO, The best solution is to write a wrapper class which implements equals/hashCode, but this adds overhead.

     

    Read the rest of the article at the following URL:

    Java Code Geeks: "Java Sucks" revisited

    "Write once, Run everywhere." was the original marketing for Java some 10+ years ago.

    Cross platform development was the big impetus for a byte-code language like Java in the first place.

    I used to work in cross platform C/C++ development. Huge teams required for cross-platform porting and testing. Too many platforms then, and far too many now.

    Java is not a perfect cross-platform solution, and the "Write once, Run everywhere." marketing turned out to be a forward looking statement. The productive gain is still undeniable.