Evan Summers's Blog

Pulp Diction 2: Top Ten Reasons to Choose Java Over C/C++

I really am so IRRITATED by now with all these Top Ten bookmarks, Goddamn! But if you can't squish 'em like a bug then join 'em like a feature?! "Be the change you want to see in the world." I tried that, doesn't work! Heh heh

So I'll start with C++ and then move on to, um, er, whatsit? The other C... No, not Objective-C! The C shh... um... oh frell it, i can't remember!

OK, this is a easy one, i mean C/C++ vs Java, it's not even fair comparing a modern language over a legacy one. Actually compared to FORTRAN and BASIC i think C/C++ is FANTASTIC ;) Actually, to be honest, C is my first love, and if it wasn't for C, NOTHING would even exist, so... We owe so much to so few - Dennis, Brian, Bjarne that certainly includes you, dude!

Notwithstanding that, here are my Top Ten Reasons Why to Choose Java over C/C++.

1. Beauty. Let's face it, Java's the hottest babe in this room!
2. Develop, don't debug! Actually this should be Number One.
3. Don't port, deploy! Mmmmm... WebStart.
4. Netbeans. And Eclipse. Yes, you can use them for C/C++, but don't go ruin my argument!
5. Java Libraries. Sweeet. What would life be without Collections? A boring singleton.
6. Swing. The sweeetest, GUI'est thing!
7. Frameworks. What you want? You got it. Goto Apache, Spring, Google, or the guy sitting next to you in the bus.
8. Enterprise-ready stacks? Take your pick!
9. You always wanted to upgrade to 1Gb RAM - now you have to!
10. java.net, jcp.org. The community's tight, man. Thank goodness they invested so many zillions, otherwise it would be like... Not this good!

So what's your number one reason?

Comments

• Can't agree with 2 - you don't really mean that all your code works the first time, do you? Number 5 is flaky as well, since STL provides pretty much the same stuff as Collections. All in all - i'd say that a lot of points would be irrelevant if you were to compare Java to C#.

  Posted by: kirillcool on October 25, 2006 at 05:07 PM

• I stand by all my points, even if they are a joke! Point 2? Well that was weak reference to pointers, memory management and threading :) Yes C# is another story, and i look forward to that comparison! I think "deploying" a C# WPF application to linux might classify as porting?! ;)

  Posted by: evanx on October 25, 2006 at 05:31 PM

• I don't think that Microsoft is worried about WPF not available on other platforms. I think they're OK with 90%+ market share that they have.

  Posted by: kirillcool on October 25, 2006 at 07:48 PM

• My favourite: #9 :-D (The Beatles?)

  Posted by: cajo on October 25, 2006 at 07:48 PM

• Point no.1 is the most important - I've only ever used Java and I can't use anything else - I see other people's code in C/stuff and it looks so ugly and unreadable- under_scores are painful

  On that note, I hate having to work outside of Java at all. Why do we have to use XML for Ant build scripts & Java Web Start jnlp files!

  Posted by: commanderkeith on October 26, 2006 at 12:45 AM

• 
  Thanks all for your comments :)

  Kirill, you right that Microsoft doesn't care about other platforms like Linux and MacOS, but I DO! I think that software should be designed to be automatically inclusive, like Java is, and not by definition exclusive like C#. Notwithstanding the sturdy efforts of Mono/Novell, the point is those efforts are not coming from the project originator, ie. Microsoft.

  I understand their (business) incentive (the Windows platform), but that doesn't mean i think it's commendable excluding other platforms - and i don't commend them (or criticise them for trying to make money).

  While I understand that Sun's efforts with making Java crossplatform were maybe also to promote their own platform as an alternative to the monopoly, the end result does benefit our industry and freedoms and such, and as such IS commendable.

  Even tho maybe i don't show it, i do care about the freedom that RMS keeps banging on about. If he visited me, i would just have to quickly hide my XP notebook and MacMini, haul out my PC and reinstall Xubuntu over my Kubuntu ;) Actually i had to haul out my PC this week, and i realised my PC days are over. Besides the mangle of cables across my desk, which i really don't like, it's the noise! Besides the constant whirring of fans and drives, which i can filter out, every few minutes the drives start fizzing like a mofo even tho the PC is idle - even if in BIOS with no OS loaded - WTF is that about?!

  Keith, i tend to agree on the issue of XML. It's a terrific machine-readable format for machine-on-machine combat, but why should people have the edit it?! I reckon having configuration objects which are programmable and toolable in our IDE (autocompletion, error highlighting) and persisting those using java.beans.XMLEncoder, or even better JAXB2, is a great option. I guess config files in JavaScript and BeanShell and whatnot are gonna become more popular with those scripting engines included in the JRE (yay!) - that's great if my IDE helps me with these files as well as it does Java, which i doubt...

  BEWARE THE IE7 BEAST. I tried IE7 today, and used the Preview to preview my comment, but when i used Back button to go back to edit it - i lost all the text of my comment! I don't have to say that was a short lived IE7 venture, and that i'm writing this (again) in Firefox :)
  

  Posted by: evanx on October 26, 2006 at 02:43 AM

• Weakest points, ever. Sorry Evan, try again? :)

  Posted by: olsonje on October 26, 2006 at 05:46 AM

• I guess you are bit too optimistic here ;-)
  1) Well - ok ;-)
  3) Given the aspect "write once, run anywhere" I agree. But when it comes to deployment - this more a weak point in Java. Especially in non-intranet scenarios there are no standard way to verify/install the VM and you app with all its dependencies in a clean, save way with a reasonable user experience! And WebStart: I guess you have never used WebStart in practice (I mean besides playing around with examples).Its current status regarding relaibility and startup times prevents its useage in most scenarios.
  6) Only if you have 1.6 (partly 1.5)
  8) The missing session isolation is in fact a quite weak point: do you call it enterprise ready if a single buggy art of your software can cause an OOM killing you whole system? And you have very little chance to find the cause!

  I love Java too, but I wouldn't take your list as an advertisment...

  Posted by: nalte on October 26, 2006 at 06:17 AM

• I totally agree with #2.
  I've developped with both (C++ and Java) for some years now. I started with C++, then I began working with Java and I told myself that I would never go back to C++'s endless debugging sessions trying to find how could that pointer be null (It had the amazing effect (feature?) of crashing my app also... :)
  I think one of the reasons Java (C#? I don't know...) is so easy to work with is that the tools (aka IDEs) are amazingly efficient at analyzing and giving feedback about our code. They are simply pleasant to *play* with.
  It's been a long time since I've worked with C++, but back then, IDEs (Borland, MS VStudio, etc...) were a real pain in the *you know where*.

  They (IDEs) probably play a great role in our personal favorite language's appreciation.

  Posted by: krakerjaak on October 26, 2006 at 06:29 AM

• 
  Nalte, Surely, WebStart is a hugely strong point for Java deployment vs C/C++?! These days i'm using Java5/6, granted just for examples. But two years ago (1.4) we were using it for production deployment of a large retail Swing app - worked great! Yes, we did make sure all the clients had Java 1.4 installed on their PCs. But i'm sure you can find better testamonials to production use of WebStart than i have at hand - anyone?

  Actually this entry is about C/C++, not C# so i wanna save my views for that followup - but many of the above apply to C#, including WebStart.

  As far as i know, you can't deploy a desktop C# app, or any desktop app (written in any language), to crossplatform clients as transparently as is possible with Java/WebStart? It's web, or webstart - what else is there?

  By web i mean ajax/javascript, applets, flex et al, and good ol' html - but that's not a desktop app written using a traditional mainstream event-driven GUI toolkit programming like GTK, wxWidgets, Qt/KDE, MFC, C#, Cocoa and Swing

  
  

  Posted by: evanx on October 26, 2006 at 08:17 AM

• I fully agree with all the nice things WebStart _could_ offer - therefore I did an evaluation for a project some time ago. Finally the decision was against it - just take the following startup times:
  WS cold (but already downloaded jar): 55s
  WS warm: 5s
  java -jar cold: 10s
  java -jar warm: 1-2s
  How would you rate the user experience if he/she has to wait nearly 1 minute(!) to get the app running? This is just unacceptable!
  And, given the reation on Ask the experts (http://java.sun.com/developer/community/askxprt/2006/jl0410.html; ~half way down) this does not seem to have high priority for sun...

  Posted by: nalte on October 26, 2006 at 10:00 AM

• We've had great success with Webstart in our production environment. It works great and has been a HUGE savings on deployment costs. I do agree that the startup time could be improved considerably compared to commandline execution, though.

  Posted by: evickroy on October 27, 2006 at 06:09 AM

• Let me try (I actually did move from C++ to Java):

  Java has proper error handling: Java exceptions, especially checked exceptions are a great advantage over what C++ had. And there's only 1 true way to handle errors.. no weird error codes and such.. this makes it much easier to write robust code. Java also has good diagnostics tools like logging.
  Java is understandable/predictable: go to any C++ forum and they are still debating on how things work.. You have to be a specification genius to remember all the gotcha's C++ provides.
  Java has libraries: ok.. C++ today has a few cool libraries.. but nothing like the huge community Java has, not to mention what is included out of the box.
  Java is more dynamic: dynamic classloading, dynamic proxies, reflection, etc..
  Java has better defaults (exeption:Swing): by default things have values, by default things are not too public, by default methods are "virtual"
  Java is OO: C++ is ... err... I dunno anymore.. it's multi-paradigm.. ie. every programmer for himself.. welcome to chaos.
  Java compilers understand Java: not necessarily the case for C++.. they don't all understand the latest C++.
  Java handles memory automatically and has finally for robust cleanup: C++ creates memory implicitly often.. but never deletes it implicitly.. getting rid of memory leaks is very difficult. Also there's no finally to guarantee cleanup (though you can do it with destructors.. I miss destructors).
  Java has good Server Side support.. C++ is a nightmare on your server (memory leaks, buffer overflow, crashes your app server, etc..)
  Java is mostly WORA.. also in C++ you don't develop in C++, you develop in the platform you are using.. for example a windows app is a windows app first and foremost.. Java is its own platform.
  Java supports mutlithreading and networks: in C++ you can do the same but it is far more difficult.

  
  I still love programming in C++ though. But I mainly work with Java.
  

  Posted by: dog on October 27, 2006 at 07:09 AM

• The number 1 reason that used to be cited (at least till 1.5) was Java was much simpler compared to C++. After 1.5, I guess the argument no longer holds much water - Generics, Varargs, Enums, Covariant returns - we've got it all! Post 1.5 Java gotchas are comparable to that of C++. Java has lost it's biggest selling point

  
  About #5, Collections framework itself was modelled after STL. Without C++ STL, there wouldn't be Java Collections. Java owes C++ a lot - indebted for most of the features it inherited (and improved). "Closures" is probably the first true major Non-C++ feature Java is attempting to implement.[ on the side note, I believe, there is already a proposal underway to implement Closures in C++ too]

  About #9, be happy you develop for the desktop, and not in the JEE space. I'm getting my RAM upgraded from 1GB to 2GB, so that I can run and test my enterprise app.

  Regarding #3, Try serializing BigDecimal [which is serializable] over EJB ( aka RMI/IIOP) from a Windows m/c to a Unix based Java EE server and then talk WORA to me. We had to change all BDs to Doubles as it simply hangs for 10 minutes (and times out) using Webstart client communicating with Websphere 6 server

  C++ scores over Java in
  1) less memory
  2) faster execution speed ( no non-deterministic Hotspot blackmagic)
  3) no random pauses/delays introduced by the garbage collector ( why people forget it while claiming Java is fast?)
  4) unchecked exceptions ( checked exceptions lead to the ugliest possible code, plus the mother- of- all exception-mishandling anti-patterns)
  5) Easy access to System API when you need them (no JNI cruft)

  Last and most important...

  6) C++ required better programmers, better coding practices and discipline, and more thorough testing. Developers knew exactly what they were doing.

  Java has eliminated all that. Anybody who has read the Java tutorials calls himself/herself a Java programmer. Applications in production produce NPEs, ArrayIndexOutOfBounds and ClassCastExceptions. Most developers act like cats-with- burning-tails, when their favourite library shows some weird behaviour.

  Bottomline - Java hasn't really fixed any C++ issues NPEs, ClassCasts etc. By promising to free programmers from issues like Memoryleaks, NP, array overflow etc., it has just managed to shove these real issues under the carpet. .

  
  

  Posted by: vivekbp on October 27, 2006 at 10:16 AM

• Nalte, your WebStart startup experience is rather worse than mine. When starting an application WebStart has to go to the source server to check the date of the jnlp file. Obviously this can take time if that server is hard to reach (or the DNS lookup takes time). If you used explicit versions for all resources, then these can be quickly checked without further net access. On the other hand if you didn't use versions, a further request is required for each resource to check if it is up to date.

  I found that a fairly large application (~ 20MB of resources) would load just as quickly via WebStart (JRE 5) as normally. I used explicit versions for all resources and the standard JNLP servlet on the server. The server was local so no network or DNS issues.

  Posted by: mthornton on October 28, 2006 at 03:20 AM

• 
  I never delete comments - only kindly add paragraphs breaks if someone
  forgets to do that - and i like their post ;) but i have spotted a post above that is messy, loud and arguably abusive ie. directed at another poster, so i'm gonna make an exeCUTive incision and delete it. I hope that's not unreasonable of me? It's so cool being the editor ;)

  To the other posters - thanks so much for your comments and contributions :) I look forward to doing Java vs C# - then the kid gloves come off and the flame retardant gear really comes out :) And my finger will never be far from the delete button... "Good ahead, be abusive, make my day!" ;)

  To Nalte. You got me thinking (thanks) and the result is CookieJar - check it out :)
  

  Posted by: evanx on October 28, 2006 at 05:01 AM

• hey evan also try to compare Smalltalk( Squeak || VW ) with Java.

  Posted by: hithacker on October 29, 2006 at 01:56 AM

• I think you can not compare C++ and Java. C++ is a programming language only, even if you add the STL it is still a programming language.
  Java is a programming language and a runtime environment which defines a common environment containing threads, user interfaces, database interfaces, deployment environments and much much more.
  C++ doesn't even define how to map a C++ name to a library symbol which makes it impossible to share C++ libraries between compilers on the same platform. And it does not define how a library should look like nor how to deploy it.
  If you choos C++ for your problem you need to choose a user interface library, a thredding library, a database interface library, a business library ... and you have to make sure they are all compatible or you end up with a business library that can not use the threads from your threading library. When you are ready with the evaluation the Java guy is probably finished with solving the problem.

  Posted by: pinus on October 29, 2006 at 04:52 AM

• 
  Think, if anyone reads #1 for second time, then it's more than enough to conclude this issue. Thank you and Thanks a lot once again for that LOVELY statement.

  
  

  Posted by: gms on October 30, 2006 at 03:19 AM

This work is licensed under a Creative Commons License.