Log in

No account? Create an account
Wanted: The Java Haters handbook. - Adventures in Engineering — LiveJournal
The wanderings of a modern ronin.

Ben Cantrick
  Date: 2006-06-24 09:06
  Subject:   Wanted: The Java Haters handbook.
So after looking at Cyclone, and thinking once again about how I would do things differently, (in this case, mostly how I would do things more simply) I'm interested in hearing about the problems with Java.

JWZ's rant "Java Sucks", is an excellent start:

I think Java is the best language going today, which is to say, it's the marginally acceptable one among the set of complete bagbiting loser languages that we have to work with out here in the real world. Java is far, far more pleasant to work with than C or C++ or Perl or Tcl/Tk or even Emacs-Lisp. When I first started using Java, it felt like an old friend: like finally I was back using a real object system, before the blights of C (the PDP-11 assembler that thinks it's a language) and C++ (the PDP-11 assembler that thinks it's an object system) took over the world.

But I know there are others. Though I'm not looking so much for complaints directed against Java Beans or AWT - I think everyone pretty much agrees that you can find crap libraries in any language. (Xlib, anyone?)

http://en.wikipedia.org/wiki/Java_criticisms is nice too, but a bit dry and toothless. I mean, a really good rant should not just make valid points, it should also be fun to read.

Am I remembering right that Gosling fairly recently said that had it to do again, he'd toss interfaces out of Java? (I found that very odd, since I think interfaces are one of the two best ideas in Java, along with built in serialization.)

So how about it? I know at least two good Java coders read my LJ. What are you guys' annoyances, pet peeves, and general sense of flaws in the Java language?

Or, more broadly, what features does a good language have? Off the top of my head, I think my most wanted list is...

- Reasonably simple syntax (If you can't read it, you can't maintain it.)

- Good support for modularity (Nothing specific here; I won't, for example, say that namespaces are a must-have. But some way to separate interface and implementation.)

- Reasonable support for generic programming (But please, NOT the way C++ did templates. Please!)

- Personally, I believe the time for garbage collectors has come (Though GCs are not yet perfect, and work remains to improve them.)

- Better safety than C, even if it means a small performance hit (Cyclone has this right - automatic bounds checks on all pointers unless you specifically tell it otherwise.)

- Compiled (Even if that means compiling in a very minimal VM)

Anything else?
Post A Comment | 8 Comments | | Link

  User: nickhalfasleep
  Date: 2006-06-24 15:54 (UTC)
  Subject:   (no subject)
The creator of the language jerking it around with buzzwords and heaps of different API's to try and stay in control of the language. Lots of things got bundled into the core that would've been better at API's. The lack of a more uniform interpreter install base (like flash) that makes it easier to deploy widely. Seriously, flash is a terrible environment but is popular because it's simple for end users to install, and has a better IDE for developers.
Reply | Thread | Link

(no subject) - (Anonymous)
  User: jigenm4c
  Date: 2006-06-25 21:40 (UTC)
  Subject:   (no subject)
From what I've read, the people working on Java are only taking into consideration the functionality or additions to the language that make the most sense at the time.

Generics, in this case, were a great feature - the ability to specify the types of objects a class can accept, and check them at compile-time. (They are not checked at runtime if I remember correctly, as Java 4 code can still run in the Java 5 VM.)

Java 5 also gives you direct access to the Compiler classes, so you can take a chunk of Java code (source), compile it, and run it inside the already running VM. You can also do dynamic loading, but that requires a class abstraction up the wazoo - which I've done.

Some of the extra features that C# includes don't necessarily need to be put into the system. For instance, the "with" operator above can be useful, however, it's not a totally commonly used thing, if the programmer does things right.

And, Java does include annotations, however, they are not the same (as expected) as C#. They use the "@" (or annotation operator) to identify blocks of code that are annotations, and are both provided for use at compile time, and in runtime through an annotation parser. The only thing that really blows about this, is the fact that there's not a lot of documentation on how to use annotations.

From past experience in garbage collectors, the best one to use is the concurrent garbage collector, since it runs along side your program instead of causing it to hang, garbage collect, then release.

FWIW, Java's direct API - RMI - sucks donkey balls. It is slow, cumbersome, has no garbage collection functionality (left to the mercy of the RMI'd library), and tends to bloat the VM. Java also sucks when it comes to the GUI use on a local system.

I advocate that Java is a better SERVER-SIDE language than a CLIENT-SIDE language. True, some programs run well in it, but not all of them do. The ability to use a GUI in Java is where Java is slower than most. If you really wanted to do that, use a language that has the functionality built-in to it natively, rather than an RMI-based implementation.

I've seen too many "Why you should use C# over Java for your enterprise" arguments, and I consider them to be total and utter bullshit. If this were the case, why are more people using Java (along with PHP and MySQL) in their enterprise environment? Also, for the most part, C# is very Microsoft-platform oriented. Mono helps get around this, but C# is not truly cross platform. Java is, so long as the VM works on the architecture you're using.

Java vs. C# - A Direct Comparsion
Reply | Parent | Thread | Link

Trevor Stone: java logo
  User: flwyd
  Date: 2006-06-26 00:53 (UTC)
  Subject:   (no subject)
Keyword:java logo
I've been writing Java professionally for the last two and a half years. Some things I really like:

* Well-documented clearly-named APIs. I like being able to tell what a class or function does by looking at it's name -- BufferedReader reads stuff using a buffer, compare(Object, Object) compares two objects. Non-Sun APIs are usually well-named too, though not all are well-documented.

* Platform independence. Aside from the places we touch native third-party code, the code I write on my Linux box run perfectly on our client's Windows machines. We even serialize objects between Windows cients and Linux servers without thinking about it. If only I could say that about the upcoming "Everyone in the corporation will use Outlook" move.

* Anonymous inner classes. Interfaces allow for good abstraction with maximal flexibility and anonymous inner classes let me come up with an implementation without having to think very hard.

* Piecemeal compilation and hot code replacement. I would get so much less done if I had to run a two minute build script, launch the application, and navigate to a certain place when all I want to do is correct a copy/paste error.

* Class.forName(). If you break it down, a quarter to a half of the objects in our system get created by Class.forName().newInstance(). It lets us put control logic in a central project with trivial pluggable behavior in more domain-specific projects.

* Built in Threads and locks.

* Exceptions and stack traces. Debugging is usually pretty easy when you can follow code flow post mortem.

* Few exceptions to rules. Other than occasionally forgetting to assign a String or BigDecimal operation back to the variable, our code has been mostly free of "I don't think that method does what you think it does" moments. And most of them have been in uses of our own classes.

* Flexible JVM. I haven't had a chance to use them, but I think AspectJ and hybrid languages like Jython have a lot to offer.

Things I dislike:

* Lack of lambda. Anonymous inner classes are great, but they're often annoyingly bulky, especially when you want to modify variables and objects in local scope.

* Clunky reflection. I think Java 1.5 does this better, but using reflection directly is rather verbose and not type safe. We have utility methods, like extracting a collection of named property values from a collection of objects, but when I changed from one object type to another with a different method name to get the same data my code broke in multiple places. It would be nice to get a reference to Type.method that's checked at compile time.

* Factory methods aren't standard and overridable. In Objective C you can make [Foo alloc] return a singleton or pooled object rather than allocate new memory. You can use the factory pattern in Java, but if Foo.newInstance returns Foo, subclass Bar.newInstance can't return Bar with type safety. If you change your mind and decide that an object pool is better than direct instantiation you have to touch every piece of code which called new Foo().

* It takes a long time to get simple things done. Even though we're a Java shop, when I have text to munge I write a quick and dirty Perl script in way less time than I could in Java, even with 1.4's regex support.
Reply | Thread | Link

Ben Cantrick
  User: mackys
  Date: 2006-06-26 01:23 (UTC)
  Subject:   (no subject)
Ah yeah, I was hoping you'd comment! (G)

anonymous inner classes let me come up with an implementation without having to think very hard.

That's actually really cool to hear, because inner classes were always something that I asked myself, "Why did they include this?" It never made any sense before. Would I be troubling you excessively if I asked for an example of how this works?

* It takes a long time to get simple things done. Even though we're a Java shop, when I have text to munge I write a quick and dirty Perl script in way less time than I could in Java, even with 1.4's regex support.

I'm not sure I'll ever find a language that beats Perl for quick 'n dirty stuff. Larry and crew has just spent so much time making it good at that, and I don't think anyone's going to be able to top it without spending a similiar amount of time. I used to write all my CGI scripts in perl because it made them so unbelievably fast to code. (Though I made sure to never do anything mission-critical, or that needed to be secure.)
Reply | Parent | Thread | Link

Trevor Stone: glowing grad macky auditorium
  User: flwyd
  Date: 2006-06-26 04:32 (UTC)
  Subject:   (no subject)
Keyword:glowing grad macky auditorium
Anonymous inner classes at work:
  • Sorting by an arbitrary property:
    Collections.sort(list, new Comparator() {
      public int compare(Object o1, Object o2) {
        return ((MyObject) o1).getFoo() - ((MyObject) o2).getFoo();
  • Only letting text files be selected in a file chooser dialog (paraphrased):
    JFileChooser chooser = new JFileChooser();
      chooser.setFilenameFilter(new FilenameFilter() {
        public boolean allow(String filename) {
          return filename.toLowerCase().endsWith(".txt");
    File[] files = chooser.show();</pre>
  • Listening for GUI events:
    component.addMouseMotionListener(new MouseMotionAdapter() {
      public void mouseDragged(MouseMotionEvent e) {
        redrawBox(e.getNewX(), e.getNewY());
  • A list wrapper on a string:
    public class MyArrayList implements List {
      String string;
      public Iterator iterator() {
        return new Iterator() {
          int i = 0;
          public Object next() {
            return new Character(string.charAt(i++));
          public boolean hasNext() {
            return i < string.length;
  • Do something at the end of the current event loop (poor-man's no-arg, no-return lambda):
    SwingUtilities.invokeLater(new Runnable() {
      public void run() {
  • You can create an anonymous subclass of a concrete class, too, but I can't think of a good short example using core classes off the top of my head.
Not only do they keep your packages clean by hiding trivial activities they have access to the enclosing object's members (and local final variables) so you can provide interface conformance while maintaining data encapsulation. They also improve readability by putting the code you're passing around in the same place as the code that cares about it. You can also pull it up for reusability, e.g. a Comparators class full of public static final Comparator declarations and implementations.
Reply | Parent | Thread | Link

Ben Cantrick
  User: mackys
  Date: 2006-06-26 06:21 (UTC)
  Subject:   (no subject)
Neat! It really does look like a poor man's lamba, all around.
Reply | Parent | Thread | Link

Trevor Stone: rose silhouette
  User: flwyd
  Date: 2006-06-26 07:24 (UTC)
  Subject:   (no subject)
Keyword:rose silhouette
Well, when you override multiple methods, call multi-arg super-constructors, and create custom GUI components it goes places that lambdas don't (ignoring method-assignment languages like Smalltalk, JavaScript, and Io). But 90% of the time I'd feel better with a lambda.

(Mary had a little lambda, its return value was Color.WHITE...)
Reply | Parent | Thread | Link

  User: triggur
  Date: 2006-06-26 20:48 (UTC)
  Subject:   (no subject)
I have a friend who has been absolutely foaming about the wonders of Ruby on Rails.

I have no direct experience with it, but I keep hearing that C# fixes some of the stupid in Java. (some of which a terrified Sun also fixed in 5.0. Competition is good.)

On the side I've been working on some monstrous Java-based server stuff that involves a custom security context and the ability to sandbox uploaded (java) user code at different security levels based on permissions. The built-in compiler thing is nice, but the inability for one thread to debug another is a bit of a stumbling block. I have no idea why I shared that... >.>
Reply | Thread | Link

May 2015