Java Discussion

[This page should be renamed JavaCons?, I think...]

[EditHint: This page needs some very, very careful reworking and tidying. There are a lot of real concerns and useful conversations - can the information be distilled in an objective manner? Perhaps Java is forever destined to provoke HolyWars.] I'll take a first stab.

Pros

Java (the platform) has a very complete ClassLibrary?. Sun seems to have put a lot of thought into abstracting interfaces that will be implemented by third party providers (i.e. JDBC, JNDI), meaning you don't spend a lot of time (note I did not say no time) hashing out implementation nits. There are a lot of extension APIs for things not part of the core library.

Java provides a platform for behavioral transfer from one address space to another. This is particularly evident in the dynamic class loading mechanisms of RMI. -- BrandonTaylor

Cons

Java is object-oriented Cobol. For the curious, what are the similarities between Java and Cobol?

Some experienced coders get bored by the amount of boilerplate code they find themselves writing. In particular, this detractor bemoans that methods must be contained by classes.

Readability seems to me to be a con of Java. It is just me ? I have a real hard time reading C, C++ and hence Java (and soon C#). I want a viable modern language that embraces the concept of opening and closing control structures. This brace stuff is awful. There is a languages I use that is more readable and is an ObjectOrientedLanguage (not VB!). I still wish it didn't have those begins and ends as they are superfluous (gave something away didn't I. Ok it's ObjectPascal). -- TobyFarley

Biggest Java Cons for me: CheckedExceptionsAreOfDubiousValue, no keyword or default arguments to functions, no closures (although BlocksInJava is a good fallback). Also the fact that destructors may never be called.

Moved from JavaIsDead

Java contains good design decisions that place it above most of its competitors. Nonetheless, many people dislike Java violently. Let's list the good and bad points of the Java system (language, virtual machine, and class libraries) for fun:

Good Features

I would argue that the real feature is Automatic Memory Management, which happens to be implemented by Garbage Collection and No Explicit Pointers (which I think is the real win). Bad Features If you want self-contained apps in Java, you can use ExecutableJars, but they are not very reliable, as the user may have changed the default action for Jar files. For applications deployed via internet / intranet, you can use webstart.

Sure there are a few bugs. Not very many, and I've never had a problem with one. DaveW
I've been bitten by bugs more times than I want to remember. The non-flushable In/Deflater strems are particularly annoying; we had to scrap a large piece of functionality in a program because of that. The library not conforming to specs, bug reported since 1997, still not fixed in java 1.4 -- all too common I'm afraid. And forget trying to fix it when the bug is in the core library: even if it was legally possible, why bother when the target environment won't have the patch?

Sure, Sun has a lot of influence, but visit http://jcp.org/ DaveW

How many of these points, positive and negative have to do with JavaLanguage, and how many with the implementation? Of course, poor implementation is one of the more fatal things that can happen to a design, even a good design. -- RaphLevien

A couple points:

Actually, it completely misses the point if you think Java is just "a language." Java is so very much the Sun implementation. It includes the language, the VM, the bytecode, the class libraries, and the logo (and probably more). So, yes, it is valid to complain that Java is broken if the JDK is broken, just like it would be valid to complain that VisualBasic is broken if Microsoft's implementation is broken. IBM and others may be cloning it, but they are always behind Sun because the Java Compliance Tests and the JDK implementation have a habit of randomly changing yet remaining in lock step--as if the tests were made to work against the codebase instead of the other way around. (Of course, I'm being overly cynical here.) This is unfortunately why some say that Java is write once, run nowhere. Sun wants to keep too much control over it, which means that different Java implementations - even those from Sun - aren't compatible. -- SunirShah

Suppose you don't like Java and you have the luxury of choosing any language for your next project. What would you choose?

This question is rather boringly open-ended, ala LanguagePissingMatch. And kind of useless too. Obviously the right language for the job, whatever that job might be. It's a big mistake to pick your language before you get your problem. BigDesignUpFront, but even more so.

I really find the 'hello world' example to be disturbing: 

 public class hello {
     public static void main(String args[]) {
     System.out.print("hello world\n");
     }
 }
or 5 rows of useless stuff... public static void main?! are we joking or what?! to make a white "hello word" appear on the screen?! any plain language should handle this with a single line of code as similar as possible to: 
 print "hello world"
any single word more than this is a waste of time for the programmer.

Well, if all you want to write is "hello world" then HQ9+ is your ideal programming language: http://www.cliff.biffle.org/esoterica/hq9plus.html.

All of that "useless stuff" has meaning. If you want to imply a "main" function, and imply that it is static, and imply that it has no return, and imply that it has no arguments, but that arguments are nonetheless available (under some other context, to be described elsewhere) and imply that your code is in an unnamed class, or perhaps that single-lined code is an exception to OO standards, etc...then, sure, you can get rid of the boilerplate. But you offload all of the explicit declarations into what will likely become half-winking, half-documented context-based implicit rules. Arcana, really--something that will hide the real organization of software.

What is wrong with not having to wrap the program in a function and not having to wrap everything in a class?

Nothing per se, but then it wouldn't be Java. It would be a mixed procedural/OO language like PhpLanguage or CeePlusPlus. Java is designed to encourage an everything-is-an-object approach; whether this is bad or good is a separate argument. Although OO-ness can be subverted via excessive use of the 'static' modifier, requiring functions to be defined inside classes forces a degree of class-based modularity that might not be present otherwise. This makes it somewhat easier to refactor static-laden pathological code so that it is object oriented. Following the intended approach, 'main' is often the only public static method in an entire application, and simply follows the syntax that is consistent with the rest of the language.

You're assuming that the everything-is-an-object-approach requires the exhibited boilerplate. I reject that assumption. As a counterexample, consider RubyLanguage. Everything in Ruby is an object (no exceptions, unlike Java). Still, the HelloWorld program is just 

 puts 'hello world'
It's exactly as above - mixed procedural / OO. Entry point in ruby doesn't belong to some addressable object, even if sting and int are objects. Java just doesn't have global code scope.

Still, this program is an object (specifically, an instance of Object). There's no need for a main method. As you can see, all the boilerplate is gone, and yet, Ruby more purely reflects the everything-is-an-object mantra than Java does.

In Smalltalk: 
     Transcript show: "hello world"
Type the above into any window or text pane, select it, and invoke "doit" from a menu. Or select it and use a keyboard shortcut. No boilerplate. All objects.

CategoryJava

EditText of this page (last edited November 17, 2009) or FindPage with title or text search