''[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 HolyWar''''''s.]'' 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''' * Garbage Collection ''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).'' * Explicit Interfaces * A very good (and standard) library. ''after the third try it was no longer embarrassing, but it still has lots of junk'' * Improving performance (especially under HotSpot and IbmJava) * Good portability (certainly better than nearly any compiled alternative) * Simplified syntax (compared to C++) * Language design not committee driven * Comprehensive documentation '''Bad Features''' * Poor garbage collection in some implementations, or for some applications * Memory is not the only scarce resource, but emphasis on collecting/reusing memory seems to have blocked thought about how to ensure other resources aren't leaked. * Type system forces programmers to hard-code knowledge of types in multiple places throughout the code - see Conrad Weisert's article on the topic in http://www.idinews.com/casts.html ''This seems to have been fixed with Generics!'' * Large memory footprint ''compared to what?'' * It is still difficult to deliver a self-contained application [If you feel that this has changed, please give us convincing information on "StandaloneJavaApplications" so we can delete this point.] ''If you want self-contained apps in Java, you can use ExecutableJar''''''s, 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.'' * If you aren't careful, you can write slow programs. Of course, you can do this in any language. * Bugs in library implementations (especially Swing) : ''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? * Bugs in JVM implementations (all JVMs are not created equal). This isn't Java's fault, but it has been known to limit Java's usefulness. * Proprietary language (i.e., not committee driven). There have only been a few events that could be construed as Sun abusing this power, the main reason why people dislike this is because of what it "could" lead to. : ''Sure, Sun has a lot of influence, but visit http://jcp.org/'' DaveW * Primitive types don't inherit from Object. This is a decision the language designers made on purpose, and never causes problems that can't be worked around. Still, it robs the less intelligent of us that cozy feeling of consistency. ''And it frequently necessitates special-case code. See java.util.Arrays for example.'' * No generic programming means no StronglyTypedCollection''''''s unless you write 'em yourself one at a time. ''And again: Fixed in Java 1.5 with Generics.'' * Immutable types are a damn poor substitute for restricted references. ---- ''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: * IBM is putting a ''lot'' of work into Java. The IbmJava JVM implementations are impressive and improving steadily. * Much of Java's performance problems can be traced to the unfortunate use of DoubleBufferedGraphicsInJava. -- PrestonBannister 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? * DylanLanguage. Multiple dispatch. Emphasis on performance. Good design decisions. * ObjectiveCaml is what Java should/could have been, but isn't. ''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