Why develop in Java?

From what I can tell, the Linux community has been pretty lukewarm on Java so far. Richard Stallman poo-pooed it initially (though GNU is now sponsoring a free port), and Linus Torvalds says it's dead. So I'll start out with all the reasons why you might not want to, and get those out of the way.

Why not?

• Sun controls the standard. And Sun is, after all, a corporation after its own interests.
• It's not free software. This is a biggie. The current offerings from Sun are free of charge, and often include the source, but are not Open Source (TM) or Free Software (TM). This actually hurts product quality a great deal, since it seriously limits the number of folks who can or will work on the Linux ports of these products.
• Portability, big deal. Hey, some of us write for real operating systems, and our stuff compiles with a simple "configure, make".
• Performance. All this security, garbage collection, and portability comes at the cost of performance. Sometimes this isn't a good trade-off.
• Still in flux. Java is still maturing, and hasn't proven that it will be here, at least in its current spirit, for good.

OK, then why?

• It's just a better language. Java is cleaner, simpler, more fun to write, and just plain better than everything else, especially C++.
• At least it's an open standard. Sun controls the standard, yes, but then who controls the C++ standard? A bunch of jerks on a committee. Sun did a good job of language design, and is carefully managing the language to prevent the kind of bloat that has happened to others. And when you compare Java to a lot of the other single-vendor mainstream alternatives, such as Delphi or VisualBasic, there's no contest on the openness front.
• Write Microsoft Windows products from Linux. This alone would do it for me. I make a living using Linux full-time to develop an application which gets deployed to Windows9x portables for the most part. It works, it's easy, and I don't even have to have a separate test computer. And unlike most cross-platform toolkits, there's not a lot of BS required to make it all work. And when we run into a customer who wants to run our app on, say, a Digital Unix machine running on a DEC Alpha, we just smile and tell them to install a Java VM and it will work fine.
• Better suited for large applications. When I look at the source code for most Linux apps, my head spins with include files and source files and makefiles and configure files and this and that and the other just to keep up with everything and deal with differences in installations. And significant C and C++ apps have a lot of namespace issues - so you end up with function names like this_module_this_submodule_do_such_and_such_to_so_and_so(). Object-orientation helps, but Java also provides packages which by convention are based on the DNS system to provide global uniqueness. A comment standard and documentation utility allows you to automagically generate HTML API documentation from your code base, something I do every night so I come to work with the smell of fresh API wafting through the air. Separate include files are unnecessary, since the signatures for methods etc. can be gleaned from the compiled p-code. And all linking is dynamic, so no separate step is necessary.
• Doesn't crash. Again, who cares under Linux? Nothing crashes, right? But for my pore end users under Win9x, this is a very nice feature. Yes, uncaught exceptions will cause the VM to kill your program, but not the VM. Unless the VM itself has a bug, there is little you can do to bring down a client system. Also, since Java p-code includes more information than standard binaries, you always get a nice stack-trace that helps you find the culprit. Generally our customers can simply do a screen-dump or send us a log file with the trace and we can sort out what happened. I never use a debugger; I've never needed to.
• Network and thread-aware. TCP/IP and Java are a natural, as is threading. Both are simple, supported nicely in the core library. Synchronization is handled by monitors, which you request by simply putting "synchronized" in the method signature.
• Dynamic. So where's your class code? On disk? Fine. At a web site? Fine. In a zip file? Fine. On some custom server, needing to be sent over a socket? Fine. Java can dynamically load and run code in a bewildering number of different ways, and if you don't find one that fits your needs, you can write a custom ClassLoader that does what you want. This makes it uniquely well-suited to autonomous agent technology, web server plug-ins, etc. Since classes aren't loaded unless they're needed, you don't waste memory on unused ones. And since they aren't loaded until they're needed, you don't waste time on startup.
• Secure. The whole applet thing, though just one of many things you can do with Java, is a good example of security. With an applet, you are downloading code from some random place and running it on your machine. This would be insane with any language that didn't support run-time security and access checking. Java does; it is very configurable and lends itself to lots of similar applications. Suppose you had an Internet-based gaming system, where people could program their player's actions, appearance, and motion in Java? Or the Java Web Server, which has to potential to allow random users to write servlets without having to do the extensive code-reviews required for CGI installation.
• Introspective. I haven't kept up with advances in C++, but this is what won my heart with SmallTalk. Say you have some object, perhaps sent over the wire or loaded from a file or who knows what, and you need to find out some stuff about it at run-time. With introspection, you use a standard api to find out what class it is, what methods and properties it supports, etc. This allows you to achieve extraordinary levels of reuse (80% plus) by creating highly data-aware, configurable applications.
• Fast enough and getting faster. For most applications, even the simplist Java interpreter is actually fast enough. Always remember that most graphical apps spend most of their time waiting on people to provide input, and are rarely CPU bound. Performance is a definite area of concern however, especially if Java is to become truly general in applicability. There are some very promising developments:
  • CPUs keep getting faster, and other than realtime 3D rendering, even Microsoft and Intel can't seem to figure out how to spend all those extra computrons
  • JITs, or Just-In-Time compilers, are very common now in Java environments (though not under Linux yet). These compile the p-code into native code in memory and then execute it; thus after initial compilation the app runs as fast as if it were compiled natively.
  • HotSpot, the next-generation VM from JavaSoft, promises dynamic compilation and optimization. Unlike a JIT, which compiles everything regardless of whether it is run once or a million times, HotSpot will supposedly monitor the programs at runtime and compile and optimize where it will make the most impact. This has a definite advantage over traditional native compilation, which can only be done for a specific target and without knowing runtime parameters. HotSpot could, for instance, optimize away loops that are not called because of a command-line setting - no static compiler can do that. It could also optimize for a 386 when running on a 386, or a Pentium II if running on a Pentium II. HotSpot also includes some improvements in garbage collection and synchronization. With this bag of tricks, they are hoping to meet or beat the speed of a compiled C++ program.