C++ versus Java

[Ganesh_R_Intel]

I like C and C++ because I like the simplicity of seeing native code when I build my program (and run it). Ofcourse Java is uniquitous and many people know it. On the downside, Java potentially leaves a lot of good performance on the table.

Specific question - Do you use the Intel C++ compilers AND Java in your environment? If so, how so?

[Intel_C_Intel]

Java in our organization is used where rapid applications development is occurring. C++ is used within our technology platforms where reliability, longevity of implementations and adaptability are requirements.

I would argue that using C++ with generative programming techniques actually ends up being far more productive and commerically attractive than Java styles of development. However this is offset by the skill levels required to do C++ development which is very hard to locate, and validate when recruiting.

[Ganesh_R_Intel]

Hi Karlmutch,
Welcome!
I agree with you. Isn't it also the case that the underlying support infrastructure is programmed in C/C++ where reliability and performance is important? And Java is more the frontend...

Cheers!
Ganesh

[Anna_N_]

I don't like doing front-ends anyway. Plug-ins/filters don't require front-ends, and they depend on native hardware speed heavily; and that's what I'm doing.

I think JNI is the answer to the question: C(++)/Asm for speed, Java for portability, GUI and communication. That's the most serious solution considered for a scientific computing project I'm involved in (all hardware IA-32, OSes differ, parallel computing).

On other occasions things may go in favor of Java though, as JIT compilers get better and better; games aside, only multimedia/computing code is still much faster in native.

Regards,

Anna

[Intel_C_Intel]

I don't believe that C++'s real advantage over Java is speed. Rather C++ enables several types of programming techniques that Java just does not offer including for example Traits based programming. These in the right hands can have huge impacts reducing time to market for complex products and increasing robustness above that of Java solutions, opinion of course.

JNI fails however as an option because it tends to be too brittle. Threading issues and marshalling of data across JNI interfaces can really kill JVM performance and is very delicate. For interoperability I feel that using of technology such as CORBA or SOAP creates a much more disciplined environment and avoids platform issues.

Java for portability I think belongs in the same camp as speed for C++. Using applications frameworks such as ACE/TAO can solve portability and communications challenges with just as much ease as JVM and J2EE does for Java officianado's.

The key is the person behind the wheel as always. This is where Java has one primary advantage in the abundance of programmers. And on the flip side where I think the general skill level and experience of the C++ community, is lets say, more matured.

Maybe this is why I keep overhearing java programmers in my office discussing static initializers, while the C++ programmers are silent, for us the problem is already well understood and solved across the entire community.

Will the complete generic but complex, ANSI C++, in software engineering win out over the broad but compromised, Java, who knows? Its all a question of money and time for products being engineered by programmers, their managers, and their businesses.

[one_glen]

for the front end GUI, multimedia and RAD, you can't beat Java. Java is like VB but much slicker, easier, and PORTABLE.

i'm developing more JNI access to C and FORTRAN codz. nothing matches raw number crunching like F77/C.

forget C++, you take your pointers to pointers to pointers to even more pointers and just go away.

[lionelk]

I'm having trouble understanding what problem Java was supposed to fix. If it's RAD you want there are some good,mature products available (VB, Borland C++ Builder). If I recall, Java's selling point was supposed to be "one executable, any OS"...but 95% of the world doesn't want apps that can run on any platform...95% of the world wants apps that can run on Windows.

[Ganesh_R_Intel]

We are taught to divide a problem, in an effort to conquer it. As a result, we create 'parts' that will assemble into a whole.
We have gone from the days of one whole executable (with garbage-in garbage-out)to executables with shared libraries to having parts of the apps spread across many systems.
Somewhere there needs to be a counterbalance. I remember Prof Dijkstra making a statement to the effect of "As the number of parts in a program increase, the chances of getting it right diminishes to zero".
I am not arguing one way or another. There are benefits to breaking up the problems and dealing with it. But you take a hit doing that, I think.

My 2c.