Java is more secure

[sushants]

Why Java is more secure in compare to c++?

[JamesCherrill]

It has no pointers. Pointer errors and related memory managment problems are a major source of security problems in C and C++

[rubberman]

Like C, C++ lets you get very close to the "bare metal" of your processor. Java is typically run through a virtual machine, which puts you one more level above the hardware - until you JIT (Just In Time) compile it to machine code! :-) As for "secure", well that is all relative (common for performance reasons). Java has many known security issues that make it possible (even easy) to subvert for malevolent purposes.

My personal opinion is that Java is really C++ with training wheels. It is easier for newbies to write code that is not directly exploitable, but it comes with a very high price. I write C, C++, and Java code for a living that impacts over 100 million users. I can do the same thing with C++ as Java, but the runtime overhead (memory and system overhead) of C++ (not speaking about performance or throughput - a debatable subject) is a LOT lower, and I don't have to worry about the JVM garbage collection performance impact (which can be mitigated somewhat, but at a very high development cost). If I need automatic heap reclamation of allocated objects, then I can use auto-pointers, or my own garbage-collecting smart-pointer classes. FWIW, I have been doing serious research in reference-counting garbage collectors for 20 years, and algorithms/code I invented and implemented runs most semiconductor manufacturing fabs on a 365x24 basis - over 10 million lines of code with no application-level deletes, and no memory leaks! If your device has a chip in it, an LCD display, or disc drive, then my code probably helped build it... :-)

JamesC, as for Java having no pointers - that is not exactly true. It does, under the covers. Instead of doing a core dump, accessing a null or invalid pointer/object will result in an exception being thrown. If you don't catch it, then what is the difference? The application is still terminated! Given the current state of Java vulnerabilities, I think this is a specious observation/comment.

[stultuske]

rubberman: read any decent (and correct) text on Java, it'll state that Java doesn't use pointers. I can assure you, the official pages and articles about Java do. (and I'm pretty sure the creators of Java were well aware whether or not Java uses pointers when writing those texts)

[JamesCherrill]

Java references are what are sometimes called "opaque pointers" - yes they are references to where to find objects, but they cannot be manipulated (screwed up) by the user. A reference can be null (in which case it will be trapped safely), but I'm not aware of any way to create an "invalid" reference (I'm sure ~s.o.s~ will correct that!)

Rubberman is clearly a serious highly expert developer who knows exactly what he is doing, and surely his code is just as secure as any Java. But IMHO letting the average programmer loose on C pointers and malloc is like giving a box of matches to a child.

[Schol-R-LEA]

No, Rubberman has a point (pun intended). While the client-programmer cannot use pointers in Java itself, the language does use references, and most if not all of the various implementations do use pointers internally to implement references. The Oracle reference implementation (which is closed-source, but known to be written in C last I checked) certainly does. The Java language shields Java programmers from this, and it would in principle be possible to write a Java interpreter without pointers, but as a rule references are implemented using pointers.

As for security, well, as with garbage collection, you are trading off thousands of possible points of failure - the individual references - for a single large point of failure - the underlying implementation. In a language which does not have 'safe' references, there is a risk of error every time a pointer is altered. In a language like Java, that risk is taken in only a few key places, but an error in any one of those could cascade throughout every program written with the flawed implementation. The advantage of Java's approach is that the debugging is done once for all Java programs, rather than by the individual client-programmers. The disadvantage is that a mistake is more costly overall. It is a tradeoff, and for most application programmers, a good one - it allows them to focus on the stucture of the program rather than the needs of the memory system. I have my issues with Java - it carries a lot of 'boilerplate', code that is required by the system rather than the program, at least compared to Python or Ruby or Clojure - but the decision to implement safe references and garbage collection is in general a good one, at least for the majority of coders in the bulk of situations.

[jwenting]

the question makes no sense, the answers therefore are unrelated to the question :)

Java is not intrinsically "more secure" than anything, at most it has been designed to make it easier to program applications to not suffer from things like memory leaks, but that's not security (though it might be part of a secure application).

[sushants]

Thanks to all for your answer.