What are the things that Java (the language and platform) got categorically right? In other words, what things are more recent programming languages preserving and carrying forward?

Some easy answer are: garbage collection, a VM, lack of pointers, classloaders, reflection(?)

What about language based answers?

Please don't list the things Java did wrong, just right.

(note by Mark Harrison) This is an interesting and useful question, especially for those of us who don't use java regularly. I'm voting for reopening. Please don't close as argumentative, as it doesn't seem to be causing any arguments.

+47  A: 

Garbage collection.

I don't think Java would initially have interested me without GC. When it first came on the scene I had been using Scheme and Oberon (both with GC) and a smattering of C and C++ (both without GC). For me GC (and array bounds checking, and pointer safety, ...) was a clear win.

How can this be a more worthy answer than Robert Fischers ?
Simplicity? Also, there seems to be a strong "the rich get richer" bias in rating SO answers. The highest rated appear first, which gets them higher visibility and more votes. I voted for Robert's answer when it was first posted. I'm sure it'll stay on top once it passes mine.
+36  A: 
  • A googlable name. Try googling for "C"...
  • A standard library that is somewhat consistent.
  • A fast and open standardization process.
change your googling habits - 'c programming' + other search terms works perfectly fine
unfortunately, this has made it impossible to find information about about other flavors of Java... ;)
Some minor behavior of Swing/AWT API do change from time to time.
Dennis Cheung
change your googling habits - 'java coffee' or 'java island' or 'java dance' + other search term works perfectly fine ;-P
damn! too much coffee.
Since when is the JCP "fast" ?
Compare it to the C and C++ standardization processes...C# doesn't count, since the process is "Make it so"...
Library seems so great until you get to java.util.Date...
+5  A: 

Garbage collection - I use C++ and know the pain of releasing the memory myself

Clear distinction between interfaces and classes - Clearly separates two different concepts

C++ had pure virtual base classes (i.e., interfaces) first, and C++ now has garbage collection (std::tr1::shared_ptr<>).
David Thornley
Yes, it C++ has pure virtual functions, but still it is a class and there is nothing there which prevents you from writing some methods in the pure virtual base class itself. On the garbage collection front, the language itself has no provisions for it, of course we can use ref counting to do it.
Why is it important that something be called an interface rather than just having a "= 0" after all function definitions? As far as GC goes, reference counting is in the latest TR, and will be in C++0x. You almost never have to write "delete" yourself.
David Thornley
@David: Reference counting sucks as a mechanism for GC.
Software Monkey
+25  A: 

Apart from the technical and the language related features, one of the most important things that Java (and Sun) got right was the evolution of a vibrant and active community around which the language grew and continues to grow.

Nikhil Kashyap
+13  A: 

Package and class naming conventions that follow the directory layout.

+29  A: 
  • Platform independence, in both theory and practice.
  • Garbage collection.
  • Meaty APIs for the time.
  • Strictness of the language - easy to get into the OO mindset when developing in.
Meaty APIs for the time... is that 'time' as in '1995' or as in 'java.util.Date'? ;-) couldn't resist
Java's platform independence in practice has always been questionable. When you get into some of the implementations for mobile devices, it fails epically, and because the language design itself assumes platform independence you end up with a nightmare. Note that some of the largest, most successful Java apps (Eclipse for example) actually depend on platform-specific implementations of various components.
+8  A: 

Checking bounds of all array accesses and validity of all casts.

Tom Hawtin - tackline
+19  A: 


Matt Briggs
It took Java long time for them to introduce this package. It was popular long before it arrived. (though I do love it)
The question was "What did Java do right?" not "Why is Java a popular language".
Matt Briggs
super awesome..
+13  A: 

Backward compatibility between versions.

Nemanja Trifunovic
This is a double-edged sword. It's been useful in building up Java, but it will eventually cause Java to stagnate and die.
Dan Dyer
And it isn't always that compatible. Take the changes 1.6 made to JComboBox. http://schinckel.net/2008/05/15/java-6-breaks-jcombobox-events/
Matthew Schinckel
Stagnate maybe.... but probably won't die. We will be stuck maintaining Java applications for the next 50 years at least.
Mario Ortegón
All hail backward combatibility!
Martinho Fernandes
+2  A: 

A syntax that was based on C/C++.

They may not be the perfectly designed languages, but I think it really helped javas popularity since it is easy for old C/C++ coders to get started.

Too much so. If I was going to have to unlearn anything, I wanted to be able to unlearn that stupid switch statement.
David Thornley
Totally agree switch is almost useless. You can only switch on int, not even an Integer (doesn't auto-unbox). A quarter century ago Cobol-85 added a powerful CASE statement that Java 6 doesn't come close to touching. Pitiful.
Jim Ferrans
+7  A: 

Everything C# took from Java was the part they got right. Everything C# left behind, was the part Java got wrong.

By learning from other languages, the next implementation can fix and improve the previous language.

You can say the same from C++. Whatever Java borrowed was the right thing from java, whatever they put apart, was what C++ got wrong ( from Sun's perspective of course )


I have to make a note on my own sentence. When I said "Everything" I mean it in the most subjective sense of the word. In this case it was everything Microsoft felt was wrong about Java. They wanted to implement Java on MS platform, but when they incurred in license violation, they simply took most of the architecture and the main concepts, and created .NET, CLR and C#.

I think this was a very big step. Otherwise all C# developers will still be programming in VB or C++ ( which not necessarily is a bad thing, just not their favorite language I guess )

I disagree. Why doesn't C# make you define which Exceptions will be thrown? That's always a huge help to me in java.
Joe Philllips
Me too, but there is a very large number of programmers out there that think different. See: http://stackoverflow.com/questions/385913/why-wasnt-the-java-throws-clause-in-method-declaration-included-in-c
Although I generally agree with the idea that new languages learn from older languages, I completely disagree when it comes to C#. I think Java made sensible choices by removing some stuff from C++ for the sake of simplicity (such as operator overloading)... and C# added them back.
I think it was a really trollish answer in the first place, but I cant help biting. @MiniQuark limiting yourself to the default behavior of == when it comes to objects (which is useful about 5% of the time) can keep you from implementing elegant solutions. @d03boy: Checked exceptions are just noise.
Matt Briggs
I do like the java implementation of enums alot more then C#
Matt Briggs
One thing that wasn't copied is the naming of interfaces.e.g IList list = new List(); -> ugly naming
Ludwig Wensauer
@Ludwig: it helps knowing that your casting to an abstract data type without having to check references, opening files, etc.
+3  A: 

1.Garbage collection
2.Platform independent
3.Directory and package structure
4.Follows OOPS

+1  A: 

The API is something that is unmatched in my opinion. The fact that it tells you (because the language makes you define...) which Exceptions are thrown and things like that. It really makes development easier.

Also, the libraries are open source.

Edit: I just read the explanation of why forced Exception handling wasn't implemented in C# and I still think that I like them to be forced.

Joe Philllips
It's a double-edged sword. I personally prefer the unchecked edge.
Martinho Fernandes
I don't like it when I override some method without a throws clause and I can't add a new clause.
Martinho Fernandes
Checked exceptions are unpopular because they remind you constantly that you need to write exception-safe code, something people like to forget about.
+2  A: 
  1. Platform Independent.
  2. Great Unix/Linux support
  3. Great varied Standard Libraries
  4. GC
  5. static typed

For some projects I still had my doubts a few years ago because of the license Java was under, but now under the GPL it's unstoppable.


Static exception checking is the feature that I miss the most in other languages. It makes me a lot more confident that the code will not blow up if something unforeseen happens.

Morten Holdflod Møller
Ugh. It's IMO one of the most obvious wrong decisions in Java's design. It doesn't really gain you anything other than ugly code.
Michael Borgwardt
I guess it is a matter of preference; I do wish that C# had checked exceptions, or at least a pragma to turn them on. Otherwise, you're at the mercy of the documentation writer. Several times I've gone "Oh, I didn't know it could throw IOException" there.
Nicholas Piasecki
+4  A: 

I would say that its support for runtime class loading. Despite occasional situations of classpath hell, it is years beyond what we had to suffer with DLLs or with COM. I'm not sure how C# handles this issue, but at least Java does it well on all platforms.

I'm also fairly impressed with Java's portability; it worked better and more efficiently than I expected, with the exception of things like different JDK releases on the Mac which are mostly Apple's fault.

+2  A: 

I like the concept of try - finally blocks, even if the syntax to absolutely definitely do some cleanup in all situations without swallowing exceptions is ridiculously clunky (closures would hopefully go a long way to redeeming this).

Also, as noted above, the java.util.concurrent library is excellent. Concurrent programming is hard to get right from a developer's point of view, but I have found that the tools let me do what I need once I know what that is (and you can often get some elegant code out of it, which in my book must be worth something).

Finally - this is probably controversial, but I do like generics. Vastly better than instanceof check and casting in 1.4, and compile time checking is excellent. Once you get a hang of the couple of gotchas, it's a pretty powerful way to communicate your intentions to the compiler and have them asserted.

Andrzej Doyle
I'm not sure I'm willing to say "Java got generics right" -- although I definitely agree that Java was right to adopt parametrized types.
Robert Fischer
+72  A: 

1. A continuity of syntax with a previously popular language. Even when Java was written, there were many technically better languages out there. Yet Java offered a syntax which was familiar enough to existing coders that they weren't frightened by it.

2. An understanding of what business code needs, and an API to address it. Java -- at least at one time -- managed to stay one step ahead of the curve of business needs. As implementation of Java applications became more complex, the architectural pieces needing to underpin it rolled out in step. Key examples here are JMS, Javamail, java.util.concurrent.

3. A consistent and supportive approach to open source and community dialog. This is where C# falls down and Java still consistently exceeds. Whereas MSFT has had a schizoid approach to people extending their language (case in point), Java has consistently been more than supportive of community discussion and language extension.

4. A full-featured, reliable, consistent standard library. Unlike some other popular languages, if you see something in the Java core API, it's going to work pretty well. It may not be a perfect implementation, but it's a good enough implementation that it's not worth reworking. And the standard library is HUGE and consistently growing.

5. No need to compile the code for your particular machine. One of my pet peeves of non-VM languages, because having to compile code for my particular machine means I have to pull down your code and figure out how to compile it. Usually this just consists of "./configure; make", but the very fact I have to think about it annoys me: it's much, much nicer to just drop a JAR onto the classpath.

6. The "bean" concept. Yeah, I know this one is kinda weird, but the concept of a "bean" in Java and the associated concept of "properties" is huge for Java's meta-programming capabilities. That concept is so powerful that if it didn't exist, we'd be forced to invent it -- think about tools like Hibernate, libraries like BeanUtils, or language structures like Groovy's GPath. All of these came from the "bean" concept.

7. Garbage collection. Having a non-optional memory management system was undoubtably the best technical innovation of Java. Which is funny, because it was the reason all the C++ coders were certain Java would be unacceptably slow and eventually fail.

8. A solid balance between performance and functionality. Keying off the previous idea, Java has done a good job maintaining a "fast enough" language while keeping it full-featured. With the exception of start-up time, the Sun JVM (with some help from IBM and the wider community) keeps pace or exceeds the other business languages on the market for working with large projects. Things like the garbage collector, HotSpot optimizer, and JIT are good examples of where Sun's Java impl went very, very right. And it's the reason why many languages are flocking over to the JVM.

Robert Fischer
Do you have a concise explanation of the bean concept I can read?
Joe Philllips
http://en.wikipedia.org/wiki/JavaBean -- see also http://www.ibm.com/developerworks/java/library/j-pg09196.html
Robert Fischer
+1 for the bean concept
Joshua McKinnon
Garbage collection doesn't have to make things slower. Actually, but delaying the release of memory until the program is idle, you can actually increase the speed of the program. The downside is that you end up using up more memory by not releasing it right away.
Good points, though I think the "bean" concept should have first-class support in the language instead of just being just convention. (First class properties FTW!)
-1 for the bean concept. But I agree with everything else, so no downvote :o)
I agree with all but one. The bean concept. It never really took of ( as expected ) and it is more a convention than a language feature. Still one of the most useful.
It's amazing how Java make all these things to work together ( not that they didn't exist before, but they never become mainstream ) It create a paradigm shift sooo big in the industry that even those who previously criticized JVM came after with exactly the SAME!! concept ( bytecode + runtime )
How can someone believe that Java's memory management is a “technical innovation”?
Bastien Léonard
I personally think Beans for end-user consumption are a horrible idea. They're great for what they were originally designed for (being processed by machines) but if you apply them to user-visible APIs they lead to design anti-patterns such as http://martinfowler.com/bliki/AnemicDomainModel.html
The whole "bean" thing (the whole mandatory nil-constructor simplification of class factories) is a design pattern that is in no way attributable to Java.
Peter Wone
@Peter: Production languages tend not to (probably shouldn't) do innovative things--but they need to do the known things well/right. Most answers probably aren't assuming Java was the first to do it.
Kimball Robinson
-1 for the bean concept. The whole point of beans is to address a shortcoming in Java. If Java had properties and annotations to begin with, they wouldn't have had to invent the "bean".
+2  A: 

I think that finding a way to make a language that high level in general that also has decent performance is quite an achievement. Though technically it's a property of the implementation, not the language, I'd say JIT compilation.

+3  A: 

A good fast implementation of a virtual machine + interoperability with other languages that produce compatible bytecodes (Groovy, Jython, JRuby, etc).

Jason S

A simple build and package management system. Packages enforce consistent directory structure and avoid name collisions. javac and jar make building Java code dead-simple (heck, I don't even use Ant, since I'm already familiar with GNU Make - I just use the Java toolchain from a Makefile and it still works great). jar uses a common file-format (zip file) and plain-text indexing information, making it very easy to inspect a Java JAR with existing utilities. It's easy to distribute a single JAR file to someone that includes all of the sources, so distribution is a breeze as well.

Compare that to C and C++ projects - there are so many ways that people build software (scons? cmake? autotools?), and everyone has their own favorite directory structure. Distribution is usually source-only, and tends to require a lot of extra packages available on the destination system due to the arbitrary build systems.


The most important thing after GC is reflection. It isn't new, but sould be everywhere from now on.

+2  A: 

Java re-popularised the practice of process virtualisation using virtual machines. I say RE-popularised because this damage-containment mechanism has been the norm on mainframes for thirty years. Use of VMs also solves DLL hell because the process can load whatever it needs in the privacy of its VM without conflicting with the incompatible needs of other processes.

Recently I have suffered DLL hell with Silverlight, which is based on .NET4, however this was with the frameworks, not the software running within them.

Peter Wone
+1  A: 

I think doing away with pointers.

Now I know pointers are useful for many things, but if you really need them, then it's easy enough to just use another language.

Its almost impossible to write a non-trivial c++ program without a whole lot of *'s and &'s all over the place.

Java has pointers... They just call them by a different name ("references"). C/C++ don't own the concept of a pointer, and just because the implementation is slightly different doesn't mean it's not a pointer.See http://javadude.com/articles/passbyvalue.htm
Scott Stanchfield
+21  A: 


The existence of excellent apis is great; the existence of documented excellent apis is awesome (especially when this requires little extra work).

Ellery Newcomer
I don't consider one-liners to be proper documentation.
Martinho Fernandes
Which should obviously be blamed on the documentation engine.
Ellery Newcomer
+1 this was/is my #1 favorite feature about Java
David Zaslavsky
+10  A: 


it is a nice language, and your boss lets you use it!

I remember a time when Java was hard to sell to the boss.
+1  A: 

On JVM side: Memory Model (JMM) - soon it'll be essential for every language/runtime. Only having standard memory model you can write efficient portable concurrent code.

  1. Platform independence
  2. A sane versioning system- basically 6 well documented and relatively backwards-compatible iterations (1.0 - 1.6).
  3. A Pretty decent command line interface
+13  A: 
  1. All Strings are Unicode. I can't believe how painful character encoding issues still are in many languages/technologies. Java is the first language I came across where Unicode is a first-class citizen. Finally!

  2. I find the Java "ecosystem" very rich: plenty of open source projects, tons of libraries, good information on the web, and the documentation for the standard API is an excellent resource.

+1, both are excellent points


+2  A: 

Java did not carry forward the biggest mistake in 'C' - the size of integer types being platform-dependent. Every chunk of C has three feet of bletch at the start that tries to work out the correct declaration for a 16-bit int.

No multiple inheritance of implementation. It's just too difficult.

Classes in the java.lang package are part of the language, not simply a bolt-on (as they are in C++).

The language weenies were kept away from java in the early days, meaning that java was a small language. Regrettably, now all the lisp programmers who realise that they will never actually earn a living coding lisp want to add "closures" and Bog knows what else.

Having said that - I though generics were a bad idea, too - but now I wouldn't live without 'em.

+6  A: 

Nobody seems to have mentioned Enumerations. They've done quite a nice job on those.

Agreed... it's about the only thing I can think of that Java has on C#.
+1  A: 

I can't believe no-one else has mentioned:

  1. It is FREE (as in beer) to develop programs (JDK) and run them (JRE)

But then also...

  1. Making interfaces first class citizens
  2. Javadoc
  3. Ensuring the language was not forked by J++.
So is C#. Which I guess vindicates Sun, and Sun certainly did it first.
Peter Wone

Good harmony with IDE tools such as Eclipse, NetBeans, or IntelliJ.

  • Reflection
  • Application Deployment/Packaging
  • Documentation & the documentation system
A reflection mechanism is certainly useful, but check out Gilad Bracha's Mirrors based reflection in Newspeak and (i believe) Self. Paper is on Gilad's site.
Hamlet D'Arcy
+1  A: 

Ease of debugging!!

Checked exceptions: because they force me to write more-exception-safe code.


Ease of modularizing code (JARs).

Garbage collection.

  • platform-independency (yeah, it matters)
  • clean and safe OO approach (except for primitive types)
  • the concept of interfaces (nice architectural paradigm, though mixins/traits are missing)
  • type-safe enums
  • convenient GC

Being both open source and allowed in almost all large corporate environments is no small feat.

Dean J
Dean, initially Java was not open source. It was until version 1.6 when it became Open Source. By then Java had already taken over the world.
Having open source implementations and being allowed in almost all large corporate environments is no small feat. OpenJDK, maybe. :)
Dean J

wide acceptance, huge and active community and open source frameworks for almost every possible thing


Dynamic dispatch, aka virtual functions, are the default.

This is one of the key pieces to implementing polymorphism in an object-oriented language. And if you're used to duck-typed languages like Python, you might not believe that a language claiming to be OO could get away without it. But C++ did: it will dispatch based on the static type of the variable, unless the method is explicitly marked as virtual (and yes, I understand the reasons for that choice).