C++ vs JAVA

[K.I.L.E.R]

This may be silly, but what current advantages does JAVA have over C++?

What is in talks is that next year (where I get my diploma in software development) JAVA may take over C++.
I'm completely against is as C++ is an industry standard and it's the best language to learn.

Not only thay but C++ is faster as it doesn't need to have a Virtual Machine loaded into memory to be able to convert the code into binary.

So what are the advantages/disadvantages of C++ over JAVA and vice versa?

 

[Saem]

Java is a cleaner language -- part of this came from removing certain features.

C++ allows multi-paradigm while Java basically allows OO and structured/data abstraction.

Java docs and the API. It's just plain better documented and that's a big plus.

There is more to it, but I read a study not too long ago comparing many languages -- and I found it to be the case in my experience, unless I use IntelliJ, which is the best IDE EVAR -- that showed that Java doesn't offer much over C++ in terms of time to produce, bugs, etc...

You could call Java, C--.

 

[epicstruggle]

im voting for c++.
I cant stand java.
Biggest reason:
Sun. They have not release java's development to an open body as they said they would a long time ago.

later,
epic

 

[Aquineas]

This may be silly, but what current advantages does JAVA have over C++?

Java benefits over C++:

• Memory management more or less done for you
• Larger "free" code base
• Theoretical platform independence
• As mentioned by someone else, JavaDocs
• Easier to program in and read
• Larger job base

C++ benefits over Java

• More control over Memory management
• templates
• potentially faster
• Closer to "the metal"
• Potential for stronger type checking

 

[K.I.L.E.R]

Thanks.

If JAVA were to be used to create Doom 3, what potential problems will it have?

 

[Dave H]

There is more to it, but I read a study not too long ago comparing many languages -- and I found it to be the case in my experience, unless I use IntelliJ, which is the best IDE EVAR -- that showed that Java doesn't offer much over C++ in terms of time to produce, bugs, etc...

I'd be interested to see that study. Frankly I find it almost impossible to believe that automatic memory management wouldn't lead to significantly fewer bugs and substantially higher programmer productivity for most general purpose projects.

 

[Dave H]

Thanks.

If JAVA were to be used to create Doom 3, what potential problems will it have?

It would have worse performance, due partially to the fact that it would definitely have a higher memory footprint and partially to the fact that it couldn't be written as close to the metal. (And if it ran through JIT compilation it would likely be even slower, but it'd be a no-brainer to pre-compile instead.)

Applications that don't use pointer arithmetic in clever ways to extract extra performance (e.g. sorting an array in place as opposed to sorting to a new location) are generally faster in garbage collected environments, although they have a larger memory footprint. Oh, and framerates would likely stutter significantly, because with garbage collection you incur your memory management all at once (at collection time) instead of spread out throughout your run.

On the other hand, if Java were used to create Windows, Unix, Internet Explorer, IIS, etc., they wouldn't have any buffer overflows, and thus they would avoid probably 95% of their security problems.

Basically, garbage collected runtime environments are unsuitable for anything that requires direct memory management (device drivers and low-level OS functions), for any real-time applications (games would fall into this category), or for anything where memory footprint is at a premium (most embedded stuff). And, if you're smart and your performance bottleneck is in a small piece of code that happens to be amenable to algorithmic tricks enabled by direct memory management, you're better off with an unsafe language.

Safe languages are better for just about everything else, which is why Java is already taking over from C++ and C# will take much of what's left over.

 

[Saem]

The report is a pdf called jccpprt_computer2000.pdf

The problem is that the site isn't responding, but punch that into google and you'll get many links to it. Good luck trying to get it when the site is actually up and if you do get it, save a copy.

 

[Aquineas]

I'm personally wondering what's going to happen to Java when Sun's proprietary hardware and OS revenue base widdles away to nothing. Many would argue that Linux is the logical choice over Solaris going forward, and it's hard to justify the cost/performance ratio of UltraSparcs when there are at least three 64 bit CPUs which outperform them (IBM, HP, AMD). If their proprietary HW/SW marketshare continues to decline, then where are they going to make their money? They will have no choice but to try and start making money from Java. Until now, they'e made money from Java by capitalizing on Java as a means of doing Enterprise Software and other server software. The revenue was derived from selling hardware that could run the software.

They will need to find a more direct means of extracting revenue from Java, which won't be easy; especially when you have the IBMs of the world (and a handful of others) with their own independent Java compilers. Perhaps the answer lies in the "free" class libraries. Funny, because in my opinion, it's the large amount of software you get for "free" that comes with a Java SDK installation that makes it attractive.

 

[Aquineas]

<Informative, insightful commentary snipped>

On the other hand, if Java were used to create Windows, Unix, Internet Explorer, IIS, etc., they wouldn't have any buffer overflows, and thus they would avoid probably 95% of their security problems.

If C/C++ programmers would have been more careful to begin with, they wouldn't have these issues to begin with. I *RARELY* made assumptions about incoming buffer lengths in my code. In the cases where I did, there was still no way to exceed the stack allocated buffer length, beecause I would typically do something like this:

int foo( char *incomingBuffer, size_t length )
{
      int    rc=-1;
      char tempBuffer[1000]; 

      try
      {
             if( !incomingBuffer || !*incomingBuffer )
             {
                  throw "Invalid parameter passed into foo";
             }

             memset( tempBuffer, 0, sizeof( tempBuffer ) );
             strncpy( tempBuffer, incomingBuffer, length < sizeof( tempBuffer - 1 ) ? length : sizeof( tempBuffer ) - 1 );
             //  Do your thing here 
             rc=0;  //success if no exceptions thrown
      }
      catch( const char *errorString )
      {
            log( errorString );
      } 
      catch( ... )
      {
            log( "Unknown exception caught in foo" );
      }
      return rc;
}

Of course the true solution is to declare

tempBuffer

as a pointer and dynamically allocate it to begin with, or, even better, pass in

incomingbuffer

as a

const std::string &

.

I'll never forget one time when my company had to interface with a very large software company's product that used MSVC 5.0 (the latest VC compiler at that time). This other company had relied extensively on MFC's Http classes, which at the time were sending an extra cr beyond the message length of their messages. My code was hanging at the time because I'd read the message length and stop, but there was more code in the input stream which would screw up the next reads. I was very adamant about following RFC standards and not playing it "fast and loose". Alas, I lost the battle, because it was the almighty Microsoft which wasn't doing things right to begin with, and since so many people used Microsoft Software at the time, and we were the little guys trying to sell a product, we ended up conforming. I wish I could go back to those same people now and say: "See? THIS is why playing fast and loose with buffers is a bad idea."

Basically, garbage collected runtime environments are unsuitable for anything that requires direct memory management (device drivers and low-level OS functions), for any real-time applications (games would fall into this category), or for anything where memory footprint is at a premium (most embedded stuff).

How ironic that Java is unsuitable for embedded applications and that's the very thing it was designed for in the first place .

 

[BRiT]

C++ benefits over Java

• templates
• Potential for stronger type checking

These two issues are being address with JDK 1.5. Templates are being introduced to the language; they call them Generics. It is already provided for JDK 1.4 as an addon package. Other steps are being taken to introduce typed constants. They're also introducing automatic primative type-class wrappers. Now an "int" can be directly promoted to an Integer object when needed, such as adding to a Collection without having to explicitly do an add of "new Integer(int)". This also works in reverse as well. Together all of this will provide significantly stronger type checking at compile time.

It would have worse performance, due partially to the fact that it would definitely have a higher memory footprint and partially to the fact that it couldn't be written as close to the metal. (And if it ran through JIT compilation it would likely be even slower, but it'd be a no-brainer to pre-compile instead.)

Oh, and framerates would likely stutter significantly, because with garbage collection you incur your memory management all at once (at collection time) instead of spread out throughout your run.

There are some JavaC implementations that can compile down to native code. Other JVMs can perform an initial pass through all classes before-hand to translate down to native instructions.

As for the memory collection, there are many different implementations/settings in the JVM provided by Sun. One of them sets the JVM up for incremental garbage collection as to avoid the all-at-once and another can limit the cpu-% that is used by it.

Java has come a long way. With the proper optimizations and JVM (even without direct compilation to native code) it can be as fast as C++ code in most situations.

 

[K.I.L.E.R]

Is this supposed to be funny?
http://members.optusnet.com.au/ksaho/comparisonpics/javaProgram.jpg
73Kb pic, I circled the strange area.

The program itself is 56MB in memory so I assume that the couple of line command prompt program is using over 20MB RAM. I'd hate to see a massive program run. I bet my 768MB will run out faster than a lion on steriods.

 

[Aquineas]

How much of that memory is the IDE? What happens if you run it from the command line, and print out the memory from there?

 

[Typedef Enum]

One issue that seems like it has never been addressed by Borland (though it could very well be a Sun issue), as it relates to IDE's, is memory management in JBuilder.

I've been developing 100% in C# for the past 15 months or so, but did Java for the previous 2 years. It used to really drive me nuts when I would have to kill JBuilder because the memory usage would climb up to 500+ MB's afer an extended period of time. This is an issue that has been endlessly talked about on Borland's own NNTP services, and none of the workaround ever seemed to help.

In terms of the topic at hand, the one thing that's very clear (at least to me) in comparing C++ to the like of Java/C# is the speed with which one can develop extremely compelling solutions. With Java/C#, the languages provide a heck of a lot of mechanisms to get the job done in a significantly faster period of time than C++. There are simply fewer "things" you need to concern yourself with once you get to the testing/debug/QA timeframe.

Of course, if you've been developing in C++ for a long time, you're clearly less likely to make as many mistakes...but let's not kid ourselves either: nobody, regardless of experience, is immune to making stupid mistakes

The other thing to think about has more to do with the IDE platform than anything else. With .NET Studio 2003, for example, there are just a ton of tools that simply make doing "things" a breeze. As an example, I'm in the process of developing a module with our software that requires XML schema definition which can then be used to create typed DataSets for use by ADO.NET objects. All the user interface Controls are 100% mapped/binded to the DataSet. In effect, I have killed multiple stones in 1 pass. There is no logic necessary to tie any of the UI to the database...no custom collections needed to store tables...Once you understand how to use ADO.NET, it can save a ton of time. Plus, it makes visualizing the given database extremely easy by way of the Schema designer...

 

[BRiT]

I imagine nearly most of that is due to the IDE.

There are settings you can use for the JVM to set minimum/maximum usage for memory and stack heaps. I believe the default values are 64Meg. I have several Java components running in realtime production environments that make use of JMS/JDBC/JavaMail/XML/LDAP/Log4J. Measuring the memory used by the program itself the low watermark is 1830K, high watermark is 4362K when all threads are busy processing, once processing is complete it returns to the low watermark.

 

[Aquineas]

One issue that seems like it has never been addressed by Borland (though it could very well be a Sun issue), as it relates to IDE's, is memory management in JBuilder.

Borland's tools are always 3 months testing shy of being great. I finally gave up my long-time love-hate affair with C++ Builder. I loved the idea and the RAD, hated the sometimes devastating "gotchas." I'm not sure what will happen to them, though I *do* I hope they survive for competition and nostalgic reasons (my very first C programs were written using Borland C 1.0 back in 1987).

Now after spending months writing my email client in C++ Builder, I'm seriously considering switching to C#/Windows Forms.

 

[BRiT]

I suppose some might consider me a stubborn old nut, but I still don't care for any of the IDEs out there. When I'm coding Java/C++/C/Scripts I still prefer to use GNU Emacs, Bash (Cygwin for WinOS), and ANT/GNU Make. Old habbits die hard...

 

[Saem]

Have you used IntelliJ?

I know folks who still like the old stripped down emac/vi style of doing things. After they used IntelliJ, they haven't looked back. I have yet to encounter an IDE that is that intuitive. When comparing it to say Sun One, which might give you an error "this is wrong". IntelliJ would say "heh, this isn't quite right. Want me to fix that for you?"

 

[BRiT]

Can't say that I have tried it, IntelliJ. My first concern is the obscene price. It looks to have some nice features. But the likely most used features I already have covered with ANT by using PMD/CheckStyle/CleanImport antlets in addition to the JDEE plugin for Emacs.

 

[Saem]

Give the free trial a shot.