share
Stack OverflowWhat are the things Java got right?
[+62] [41] Hamlet D'Arcy
[2009-01-19 14:50:56]
[ java language ]
[ http://stackoverflow.com/questions/457822] [DELETED]

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 [1], 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.

I think this should be a community wiki question. - Spoike
2nd for Comm. Wiki - Software Monkey
Nice question, no doubt. but m wondering why the refereed question "the things Java did wrong" was closed. There is something wrong within the process to close the questions. - Nrj
I agree that some people have a (to me) strange idea of what questions deserve to be on SO. - Software Monkey
[+82] [2009-01-19 15:47:19] Robert Fischer

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 [1]), 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 [2], 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.

[1] http://enfranchisedmind.com/blog/posts/testdrivennet-for-visual-studio-express-get-it-while-its-hot/
[2] http://enfranchisedmind.com/blog/2008/03/24/rexml-dynamic-typing-lose/

Do you have a concise explanation of the bean concept I can read? - Joe Philllips
(4) +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. - Kibbee
(1) 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!) - bendin
(6) -1 for the bean concept. But I agree with everything else, so no downvote :o) - benjismith
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. - OscarRyz
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 ) - OscarRyz
(1) 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 martinfowler.com/bliki/AnemicDomainModel.html - Gili
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
(1) @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) -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". - Gabe
1
[+50] [2009-01-19 14:59:31] bendin

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 ? - mP.
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. - bendin
2
[+41] [2009-01-19 15:02:22] EricSchaefer
  • 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 - Christoph
unfortunately, this has made it impossible to find information about about other flavors of Java... ;) - roe
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 - EricSchaefer
damn! too much coffee. - kenny
(4) Since when is the JCP "fast" ? - Guillaume
(1) Compare it to the C and C++ standardization processes... C# doesn't count, since the process is "Make it so"... - EricSchaefer
(3) Library seems so great until you get to java.util.Date... - TM.
3
[+32] [2009-01-19 15:12:58] Eek
  • 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.

(1) Meaty APIs for the time... is that 'time' as in '1995' or as in 'java.util.Date'? ;-) couldn't resist - Olaf Kock
(1) 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. - Whatever
4
[+25] [2009-01-19 15:11:10] Nikhil Kashyap

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.


5
[+24] [2009-01-20 03:59:29] Ellery Newcomer

Documentation!

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


(2) I don't consider one-liners to be proper documentation. - R. Martinho Fernandes
(1) Which should obviously be blamed on the documentation engine. - Ellery Newcomer
+1 this was/is my #1 favorite feature about Java - David Zaslavsky
Not just the SDK documentation itself, but also the related Javadoc tools & conventions! There's absolutely nothing hi-tech or special to them, but they do make a difference - even today API docs (or their usability at least) for many other languages plain suck compared to docs of any Java library. - Jonik
6
[+19] [2009-01-19 15:16:06] Matt Briggs

java.util.concurrent [1]

[1] http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/package-summary.html

(1) It took Java long time for them to introduce this package. It was popular long before it arrived. (though I do love it) - Trey
The question was "What did Java do right?" not "Why is Java a popular language". - Matt Briggs
super awesome.. - keshav.veerapaneni
7
[+16] [2009-02-14 23:49:46] KarstenF
  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 - Jonik
8
[+14] [2009-01-19 15:19:27] Nemanja Trifunovic

Backward compatibility between versions.


(1) 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. 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! - R. Martinho Fernandes
9
[+14] [2009-01-19 15:12:05] fbonnet

Package and class naming conventions that follow the directory layout.


I think C# fell down here, java's naming conventions are much better. - Michael
10
[+10] [2009-01-20 08:48:56] Blauohr

marketing!

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. - Apocalisp
11
[+8] [2009-01-19 15:14:25] Tom Hawtin - tackline

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


12
[+7] [2009-02-15 02:16:03] Rik

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#. - cdmckay
13
[+5] [2009-01-19 15:07:43] Naveen

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. - Naveen
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
14
[+4] [2009-01-19 15:41:42] Uri

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.


15
[+4] [2009-01-19 15:24:51] OscarRyz

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 )

EDIT

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: stackoverflow.com/questions/385913/… - OscarRyz
(7) 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. - MiniQuark
(1) 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. - Filip Dupanović
16
[+4] [2009-02-15 01:47:13] paulmurray

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.


17
[+3] [2009-01-19 15:27:09] Dinesh

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


18
[+3] [2009-01-19 15:31:42] Ubersoldat
  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.


19
[+3] [2009-01-19 15:20:05] Laserallan

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
20
[+3] [2009-02-15 17:42:34] oxbow_lakes

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
21
[+3] [2009-01-19 17:11:17] Jason S

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


22
[+3] [2009-01-20 02:09:46] Peter Wone

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.


23
[+2] [2009-01-20 03:46:30] JSmyth

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 javadude.com/articles/passbyvalue.htm - Scott Stanchfield
24
[+2] [2009-01-19 18:17:33] Tom

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.


25
[+2] [2009-01-21 21:33:48] user57697

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.


26
[+2] [2009-01-19 15:42:57] Andrzej Doyle

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.


(1) 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
27
[+2] [2009-01-19 15:52:49] dsimcha

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.


28
[+1] [2009-01-19 15:35:48] Morten Holdflod Møller

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.


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
agree this is a good feature on balance... it tends to add a bit of verbosity but usually does so with a good reason (i.e. it encourages you to write proper error handling code in many of the situations where it is needed!!!) - mikera
29
[+1] [2009-01-19 15:27:13] Joe Philllips

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.


It's a double-edged sword. I personally prefer the unchecked edge. - R. Martinho Fernandes
I don't like it when I override some method without a throws clause and I can't add a new clause. - R. Martinho Fernandes
(3) Checked exceptions are unpopular because they remind you constantly that you need to write exception-safe code, something people like to forget about. - quant_dev
30
[+1] [2009-02-26 00:23:32] quant_dev

Ease of debugging!!

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

Javadoc.

Ease of modularizing code (JARs).

Garbage collection.


31
[+1] [2011-02-08 22:57:10] MarkR

Unicode support. At least, they got it a damn sight better than anyone else had in 1995.

  • Java understands that a byte array is a byte array, and a string is a string. C does not.
  • A surprising number of languages which have been developed / updated / popularised much more recently still get this wrong (Think Ruby, which I had assumed got unicode right, being written by a native Japanese speaker)

32
[0] [2009-02-15 00:34:30] iik

Competition


33
[0] [2009-05-12 00:06:32] thSoft
  • 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

34
[0] [2010-05-05 18:07:55] Dean J

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


(1) 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. - OscarRyz
Having open source implementations and being allowed in almost all large corporate environments is no small feat. OpenJDK, maybe. :) - Dean J
35
[0] [2010-09-20 14:35:59] keshav.veerapaneni

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


36
[0] [2010-09-20 14:55:35] Anon

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).


37
[0] [2009-02-25 16:03:54] grayger

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


38
[0] [2009-02-26 00:11:54] segy
  • 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
39
[0] [2009-01-21 21:38:45] Fergie
  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

40
[0] [2009-01-19 19:40:42] AnSGri

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


41