I hear a lot of people speak poorly of Java, especially the ones coming from C/C++. Is there a historical reason why? Is it because it used to be machines were too slow to run the JVM without lag?
closed as not constructive by BЈовић, Kilian Foth, Morons, Jalayn, yannis Sep 27 '12 at 7:17
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
For every language you will find People who Speak poorly of it. It's just the way it is.
Java is no exception.
Programmers from the 'real programmers code in binary' clan will probably hate Java till the end of time. But for the rest of us, Java helps get the job done fast and with a (slightly) shorter learning curve.
The C/C++ times gave good programmers the fun of being able to play with memory the way they wished. Java made garbage collection automatic, so that fun was lost. Also those languages compiled to machine code, and so was statistically faster because of the absence of the JVM process. But times have changed and with today's hardware this is hardly even noticeable (unless you're trying to encode video or something). Also, i must say, there is a certain added satisfaction when you pull something off (non-trivial) in C/C++ where-in you had to do all the memory management etc the hard way.
Generally speaking Java gets a bad rap because it's essentially relatively weak at both of it's touted strong points:
- "Java is write once, deploy everywhere": Larger programs generally don't work flawlessly across multiple platforms without additional work. EDIT -- After some research it seems that this has actually improved quite a bit since the last time I seriously used Java (good on Java!) - articles I can find are from the 90s ( http://www.mactech.com/articles/mactech/Vol.14/14.05/WritingJavaCross-Platform/index.html ). A non-Java specific issue that may be erroneously called a Java flaw is that different platforms often just have completely different UI paradigms (e.g. mouse vs. touch, keyboard or no keyboard), and it's just downright difficult to design an application that actually works well on all possible platforms through no fault of the language.
- "Java hides a lot of things that you don't have to know": Larger programs often require additional deep knowledge of how the language and VM work to tweak things to make them work fast enough for real use (there's a whole page dedicated to it here: http://www.javaperformancetuning.com/tips/) . This can actually cut the other way theoretically as well - a JIT-compiled Java program and/or an updated VM can have hardware-specific optimizations that weren't available at the original time of writing the program (see e.g. http://en.wikipedia.org/wiki/Java_performance#Program_speed).
There is no inherent fatal flaw with Java except that it's really not much better at anything than other languages.
However, it DOES have an impressive collection of libraries available across platforms, and it's disingenuous to consider the language only without the libraries. As a tool to "get the job done" it's VERY general purpose "out of the box" to cover a lot of bases more than well enough for real-world usage. It's an advanced swiss army knife, if you will (one with a lot of safety features to avoid hurting yourself).
C++ developers specifically may have a dislike for Java for some other reasons as well:
- Java enforces object orientation, and "everything is an object" - multi-paradigm C++ developers are often allergic to being limited in that way (full disclosure: I'm one of that type of C++ developers :)).
- As mentioned above, a hardcore Java developer needs to know the internals as well to get the maximum out of things (as is always the case, in any language), and a C++ developer is used to actually having access to those internals, so they feel (rightly or wrongly) that they might as well work close to the metal if they have to know it anyway.
From the end-user point of view, many older Java programs (actually the JVM) used humongous amounts of memory for the simplest of programs. Often well over 100 MB for a simple FTP client or similar. Especially during times when most systems had 256 MB to 512 MB of RAM, that was simply unacceptable. And as Java programs were quite common in the desktop area, many people came to the same conclusion about memory usage.
Also, the Java Runtime Environment has a long history for severe security issues (even right now), so the reputation has dropped quite sharply with the increasing use of Java in general public.
Java Security Alerts:
http://www.oracle.com/technetwork/topics/security/alerts-086861.html#SecurityAlerts (2009 - 2012) http://www.oracle.com/technetwork/topics/security/beaarchive-159946.html (2006 - 2009) http://www.oracle.com/technetwork/topics/security/alertsarchive-101846.html (pre-2006)
Oracle will issue Security Alerts for vulnerability fixes deemed too critical to wait for distribution in the next Critical Patch Update.
To me, the size of those lists is just horrendous.