Talk:Comparison of Java and C++

"neutrality" is counter to the point

Trying to avoid favoring one these languages over the others is to miss the point, or bury the lead. The one-sentence summary of this article should be that Java is an improvement upon C++; that it is more or less an improved version of C++. That's only to be expected since Java's design had the advantage of the lessons learned from years of using C++ and other OO languages, and furthermore, C++ was handicapped by being designed as an afterthought to a non-OO, low-level language. The programming language community was able to learn a long list of lessons from C++ and and subsequent languages before the design of Java. In short, Java stands on C++'s shoulders.

Therefore, I suggest that the way to organize this page is NOT as a "C++ does this, Java does that" table that fails to show the progression from one to the other. Rather, it should be "C++ did this; Java changed it to that, and here's why... ."

Even if folks don't want the article to say that Java is an advance over C++, it is still important for the article to give the rationale behind the design choices. (And that doesn't mean giving, for each feature F, some scenarios S1..Sn where F is useful -- we can all agree that the existence of such scenarios does not constitute, by itself, sufficient reason to include feature F in a particular language, right?)

MarkAb 00:50, 11 June 2007 (UTC)

Having used and studied both languages extensively I very much disagree. While Java does clean up some warts in C++ (the static keyword comes to mind), Java is more of a dumped-down version of C++ than an advance (very limited static polymorphism, little metaprogramming, no RAII, no unsigned arimetric, no const, no operator overloading and so on and on) plus a few extra features (e.g. platform independent bytecode, reflection) and a huge standard library (including 2 different GUI toolkits, encryption, 2D and 3D graphics and much more) rather than a the very small and flexible library that C++ carries. It is much more fruitful to consider Java a successor to COBOL and perhaps Pascal than C++. With this in mind, either language is better suited for different tasks. E.g., writing a somewhat efficient parser in Java is tedious or requires an code generator, while boost::spirit demonstrates how easy it can be with the right language features. On the other hand, Java is much more suited to novice programmers and students, for exactly the same reasons. (I really wish I could come up with a reflection example that isn't silly, I must be tired). Esben 21:29, 11 August 2007 (UTC)

The "huge standard library" is precisely what makes java so productive. The implication that java is more suited for novice programmers contradicts reality; there are plenty of smart, expert level programmers involved in large open source java-based projects. I think it's more precise to say that java is suited not only for expert programmers, but for novice ones as well. One important goal which has been explicitly stated somewhere is that a top goal for java is readability. In light of this, operator overloading is can be considered a negative (however a good ide can mitigate this problem). Java is smaller than C++. Yes, the java libraries are more extensive, but they are not visible if you don't use them; and the libraries that are most commonly used, such as java.lang.Collections are relatively small. The point is it's a lot easier to learn the fundamentals of java than C++ (though both languages take a long time to master). As for reflection: it's used everywhere in modern frameworks to great effect. —Preceding unsigned comment added by 128.107.248.220 (talk) 19:51, 15 September 2007 (UTC)

It is indeed well known that when Sun started working on Java they borrowed a lot from C++, as you said, and tried to remedy to various of its issues which were detrimental for productivity or security in specific application domains. I can certainly agree with you on that. However, Java is a higher-level language and should be seen as such; it has advantages for application programming and productivity. This can be seen as an advancement for a particular type of applications. However it would be wrong to state that C++ is not better suited for other types of applications, i.e. those more closely tied with systems programming, or those more resource constrained. Java was never intended to generally deprecate C++ and such a belief would be a false impression. Similarily, C, a predecessor of C++ still remains widely used for certain domains such as low-level kernel programming and is not about to die. 66.11.179.30 00:52, 18 June 2007 (UTC)

It is a myth that C++ fits as a low level language than High level language or JAVA is still a higher level language than C++. JAVA is a language which sticks only to Object Oriented Model. C++ is a general purpose language which is suitable for a superset of programming models. If you compare C++ and JAVA language features for OOP programming you can find a 1 to 1 mapping for the features. Actually in C++ better OOP is possible. The key difference is JAVA don't allow non-OOP programming where as C++ allows. In that way JAVA defences the programmer but the cost is paid by real good programmers is the flexibility.

Note that Java is NOT a pure OO language. By allowing public static methods it allows writing functions related to no object, like Math.sin(x). By allowing public static fields it effectively allows globals. Both are counter to OO paradigms. Wikipedia lists Java as non-pure OO language. See the link.

Indeed, had Java been a pure object orient language would write x.sin(), possibly with "sin(x)" as syntatic sugar. Java is a multi-paradigm language moderate support for OO (very limited multiple inherited, not even mixins), moderate support for procedural programming, very weak for functional (anonymous inline classes) and weak support for generic programming (Generics) Esben (talk) 12:37, 9 November 2009 (UTC)

As a language C++ needs lesser number of code to do a logic than JAVA. The productivity of JAVA comes from the IDE and the JSDK API. But the same library is ported to C++ the number of lines required will be less. Please note the multiple inheritance where code can be shared. There the common argument is diamond of death. But a good designer will store the data smartly inside those classes which inherit from the common ancestor. So as language C++ is a superset of JAVA for me. As of today many open source libraries are available for C++ for multithreading, cryptography etc which are provided in JSDK. The only point is they are not from a single vendor. May be a vendor like SUN can provide CPPSDK. C++ language is still evolving and the version C++ 0X is awaited. If you compare JAVA EJB's with C++ equivalents, you have Tuxedo ATMI and CORBA from BEA systems. You have to pay for that, which is rock solid. Here the inout parameters are allowed. But in EJB if you want to return multiple objects then you have to pack them inside a vector. See it is still not matuared and the additional overload. If microsoft extends support to their COM/COM++/DCOM to Unix platforms that will literally be a revelution the industry. As you can see the clock speeds of CPU are not getting increased. Now multi core systems are available but the scalability is not linear. The huge business systems which are built and runs on multiple geogrphic regions will impose strict time lines. Also the volume of business increase is faster than the speed with which hardware speed increase Jayaram Ganapathy

Usage metrics

One thing that seems to be missing from this article is anything objectively measuring the relative market share and/or developer use of these two languages. Does anybody know of any studies that could be cited that indicate whether Java is really replacing C++? 69.81.190.216 22:16, 18 June 2007 (UTC)

Yes, that would be interesting. I don't know if there are any statistics available and what they cover. One possibility to create such statistics is to mine data bases, basically searching for occurrences of java or C++ code. My first idea was google code search, however the problem with google is that every time the number varies. A more realistic possibility would be to search academic articles for java and c++ the idea being to count references from research to one of the two languages. This search could even allow charting references by years. Ben ^T/_C 12:49, 16 April 2009 (UTC)

Default parameters in Java

This turned up in the article today. "Starting with Java version 1.5 default values for functions is allowed." I have never heard this is possible, nor can I find anything that indicates that it can. So I will delete it in a few days unless a reference turns up. Esben (talk) 15:00, 19 December 2007 (UTC)

Generic programming: important parts missing

One of C++'s greatest features is generic programming, and is underdocumented here. The article makes it look as if Java is just slightly less powerful in this regard, but actually it is VASTLY underpowered. Concepts - the bread and butter of generic programming - can only be approximated with bound generics, which put some serious constraints on the genericity (all generics parameters have to inherit from the bound type). Otherwise, things like:

class test < T >
{
  void foo(T t)
  {
    t.do_something();
  }
}

just won't work in a type-safe manner. Generic programming is also the area where operator overloading really starts to make sense. There are many examples available from Boost that could highlight this. --80.121.69.21 (talk) 10:46, 12 May 2008 (UTC)

Except that Concepts do not exist in the current version of C++. --Spoon! (talk) 11:47, 12 May 2008 (UTC)

Actually, the above would work today. You might be confusing the above with the Concept proposal for C++0x, which is meant for better compiler error messages. But concepts will not change what is possible to do safely. I would encourage a section where generics are compared to templates, but well down as it is an advanced subject. Esben (talk) 09:40, 13 May 2008 (UTC)

It will "work" today if you somehow figure out how to use it correctly. There is nothing in the signature of the class or function that tells you what kind of types T can be. When you use it with a type that doesn't have a "do_something" method, then it will blindly try to instantiate the template, and then fail halfway through, giving some convoluted message about a line inside the foo() method. That is about as "safe" as C macros are "safe". Your code example above shows what is fundamentally "unsafe" about C++ templates. A "type-safe" language should not allow the above code, because its type declaration does not by itself guarantee that it will work. In Java, that code would not be allowed, and the compiler would force you to bound the type parameter in a way that makes sure it has such a method, which guarantees that it will work, completely independently of any other code. Any other code (which can be compiled separately) will have to follow the type restrictions (if they do not follow it it gives an error on their end). That is the whole point of safety - the restrictions you place on it must convince the compiler that it will work. With Concepts in C++0x, you would bound the type T by some concept, which also achieves safety (which is important in its own right, not just for better compiler messages); but this is not currently in C++. --Spoon! (talk) 10:43, 13 May 2008 (UTC)

First of, what you get from Java with those bound are available in C++, as a (boost) library. Secondly, the safe typing is what is sometimes referred to as duck typing, which is considered by many to be just as safe as the hieraki. But I don't care to bicker with you, not here :) Esben (talk) 21:08, 19 May 2008 (UTC)

Reference to Compromised URL

Is it just me, or has this site been hacked?

http://www.cellperformance.com/

It redirects to a fraudulent (viral) site:

http://anti-virus-secure-scanner.com/

Also, it seems the site's lease is going to expire soon anyways:

http://whois.domaintools.com/cellperformance.com

This will be posted in each of the following discussions at: http://en.wikipedia.org/wiki/Comparison_of_Java_and_C++ http://en.wikipedia.org/wiki/Aliasing_(computing) http://en.wikipedia.org/wiki/Restrict

76.64.33.246 (talk) 06:20, 2 January 2009 (UTC)

Organization?

I think this article's organization is unwieldy. • Some differences' placements are confusing. Why are unsigned arithmetic, operator overloading, and bounds checking considered "design goals"? Also, the difference between semantics and syntax here is unclear. Shouldn't pointers be in syntax? And shouldn't generics, templates, multiple inheritance, and multithreading support only be in language features? Differences like built-in support might be hard to place properly since they're language features in Java but library features in C++. • Why does the article switch between bullet points and a table format? Was this intentional? If not, I'd be happy to move the bullet points into a table format. If someone could explain this organization to me, then that would be great, and perhaps we could explain it in the intro. Otherwise, does anyone object to me trying to reorganize it? I can place my suggestions for difference categorization here first.  dmyersturnbull  ⇒ talk 21:42, 22 May 2009 (UTC)

Some missing points

I think there are a few points that are either glossed over or not discussed thoroughly enough in this article. Here's a list of what I think could be covered better:

• Java is a typesafe language. Many errors that can happen in C++ are either disallowed by Java's bytecode verifier or trapped at runtime. Buffer overflow problems are just one example. On the other hand, this can allow C++ to have better performance (reference).
• Java does not have the fragile binary interface problem problem that C++ does. This is glossed over by the general term "binary compatibility", but the article doesn't seem to explain the repercussions of binary compatibility or the lack of it.
• Java does not have separate header files as C++ does. This could be consider a strength or weakness, but some advantages are that makefile dependencies do not need to be updated in Java, and Javadoc comments allow documentation for classes and interfaces separate from the source code.
• C++ must be recompiled for each different platform.

I'm not trying to advocate Java over C++. I like both languages, and each has its strengths and weaknesses, but Java's main strengths seem to be mentioned only in passing in this article. -- Schapel (talk) 13:56, 13 May 2011 (UTC)

Reading this article gave me quite a bit of pleasure, imagining how passionate some people can be about programming languages. The article itself is like a magnifying glass left on the top of a table filled with the history of programming languages - without the big picture it is hard to understand the details. There is no point in making a comparison between C++ and Java because the languages are not in competition, only people can do this silliness. A more neutral way to present the whole topic is by language feature, say, how do I declare objects, initialize them, pass them to methods, manage their allocation details and performance characteristics, etc. And not talk just about C++ and Java. Talk about SNOBOL, talk about Ada, talk about PROLOG. Stop living in the 21st century. Talk about the PDP/11, about Multics, about VAX/VMS, about the z80. Get serious. And take that object out of your pocket. 72.195.132.8 (talk) 01:12, 1 July 2012 (UTC)jcb

Bias and citing sources

I have added more info and deleted unneeded statements. There is huge bias on java. — Preceding unsigned comment added by 74.95.9.18 (talk) 01:58, 19 August 2012 (UTC)

The recent statements I have seen demonstrate a much higher bias for one particular side than what was in the article before. The edits are also quite poor. Perhaps you should start slowly in Wikipedia, in a topic you are more familiar with. -- Schapel (talk) 02:05, 19 August 2012 (UTC)

You should also cite sources — content without citations may be removed if challenged. As you're doing that, you might realize why I suggested for you to start slowly and in an area you're more familiar with. -- Schapel (talk) 04:12, 19 August 2012 (UTC)

Stupid stuff in the performance section

It says "* All objects are allocated on the heap." Only to then backtrack a few sentences later to explain how this is actually not true. The whole section is actually quite sad, and does not reflect the massive care that must have gone into it, judging from the size of the discussion page. 2620:0:1046:0:BE30:5BFF:FEE2:AFCF (talk) 19:35, 4 October 2012 (UTC)

remove bounds checking

It is said that "HotSpot can remove bounds checking". But as far as I understand it's only an optimization technique which sometimes remove bound checking but not suppress it totally. Xavier Combelle (talk) 17:33, 22 July 2013 (UTC)

Copyrights and patents

If we're going to say that "Various aspects of the language are covered by patents and copyrights held by Oracle.", then we need a cite to back it up. Oracle_v._Google says the opposite, that provided they avoid copying code, Google can implement Java (and all its APIs) even over Oracle's objections. http://www.javaworld.com/jw-10-1997/jw-10-lawsuit.html says "the complaint charges Microsoft with trademark infringement, false advertising, breach of contract, unfair competition, interference with prospective economic advantage, and inducing breach of contract." That long list does not include copyrights or patents. If we're wildly speculating, http://communities.mentor.com/community/cs/archives/cxx-abi-dev/msg01295.html is a list of possible patents over C++ implementations (not really from a reliable source) and if GCC's C++ implementation violates any of them, so almost certainly does GCC's Java implementation, as they share an ABI... and IBM and Microsoft are the corporate names on those patents, not Oracle.--Prosfilaes (talk) 08:24, 27 October 2013 (UTC)

Your last observation is interesting, but irrelevant here. The point is, Oracle may at any time assert it's intellectual rights over various aspects of the Java language. Moreover, the verdict in the Oracle/Google lawsuit does not in any way affect their right to sue even on the very same grounds laid out in that particular lawsuit, and however unlikely, they could still win such a lawsuit. And please note that a large part of that lawsuit was simply an objection to Google duplicating the Java API of all things! Which means, of course, that the types of complaints filed in any future lawsuit are only limited by the creativity of Oracle's legal department. Sebastian Garth (talk) 13:45, 27 October 2013 (UTC)

The point is, Microsoft may at any time assert its intellectual rights over various aspects of the Java and C++ languages. So might IBM. So might any other huge patent holder. So might any designer of a pre-Java API who wanted to claim that Java's API is a copyright infringement of theirs. Looking at the results of the SCO trial, it's not at all improbable that somewhere BSD-licensed code snuck its way into Oracle's Java implementation sans proper copyright notice. All of this might happen, and all of it is crystal-balling.

Yes, Oracle could sue on the same grounds. There's very few limitations on what people can sue on. Speculating that they could win such a lawsuit is, again, crystal-balling, and again, Oracle is not unique in having a creative legal department.

Going back to the original statement, nobody has ever shown that a language can be covered by copyrights, and Oracle v. Google said they couldn't, or at least Java wasn't. Neither 6061520 or RE38104, the two patents brought up in the Oracle trial, seem to be about Java as much as ways to implement Java. If we want to make the claim under question, we should speak with specificity and with cites. (And we should avoid saying anything about Oracle's "intellectual rights" over Java. That's not a clear term. We should speak specifically of copyrights, patents or trademarks, each of which has very different extents and limitations.)--Prosfilaes (talk) 17:40, 27 October 2013 (UTC)

I do understand your point but I still must disagree here. At any rate, I'm not going to press the issue any further. Perhaps we'll revisit the discussion sometime in the future. For now, at least, we can leave the wording as it is. Sebastian Garth (talk) 19:36, 27 October 2013 (UTC)

Multiple Inheritance in Java

Guys/Gals,

Java does not support multiple inheritance. <---- note that there's a period at the end of that sentence

I call your attention to: http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

Specifically, the fact that that article begins by stating that *implementation* is what is being inherited, NOT TO BE CONFUSED with subtyping:

http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Inheritance_vs_subtyping

Anyone who understands multiple inheritance and its problem(s) would know quite well that Java does not support multiple inheritance, and the creators of Java were very vocal and open about their reasons for excluding multiple inheritance from the Java language spec.

Aquishix (talk) 12:19, 10 February 2014 (UTC)

Java Generics Inaccuracy

I believe there is an error in the generics vs. templates comparison section.

It says (as of 11/18/2015):

C++ Templates	Java Generics
Templates can be specialized—a separate implementation could be provided for a particular template parameter.	Generics cannot be specialized.

The below program shows an example of specializing a generic method for a specific template parameter. The "myCount" method is specialized for subclasses (inclusive) of Character. Is this not "providing a separate implementation for a particular template parameter"? It seems to precisely match the definition of "Explicit template specialization" given here: Template (programming)#Explicit template specialization

import java.util.*;

public class Test {

    static <T> int myCount (Iterator<T> iterator, T val)
    {
        int ret = 0;
        while (iterator.hasNext()) {
            T entry = iterator.next();
            if (entry.equals(val)) ++ret;
        }
        return ret;
    }

    static <T extends Character> int myCount (Iterator<T> iterator, T val)
    {
        System.out.println("weirdcount");
        int ret = 0;
        while (iterator.hasNext()) {
            T entry = iterator.next();
            if (entry.equals(val)) ++ret;
        }
        return ret*3;
    }

    public static void main (String[] args) {
        List<Integer> nums = new ArrayList<>(Arrays.asList(1,2,3,3,3,4,5,2,1));
        int count = myCount(nums.iterator(), 3);
        System.out.println(count);

        List<Character> characters =
            new ArrayList<>(Arrays.asList('a','b','c','d','e','a','b'));
        int count2 = myCount(characters.iterator(), 'a');
        System.out.println(count2);
    }
}

Thanks, Vancan1ty (talk) 04:35, 19 November 2015 (UTC)

nested/inner classes

I think the article should also state that C++ nested classes differ from Java inner classes. C++ nested classes are kinda like a static class in Java and can not access fields in the outer class unless they are static (C++11) Peter.quiring (talk) 22:42, 4 April 2016 (UTC)