You are on page 1of 14

Design aims

The differences between the C++ and Java programming languages can be traced to their heritage, as they have different design goals.

C++ was designed for systems and applications programming, extending the C programming language. To this procedural programming language designed for efficient execution, C++ has added support for statically-typed object-oriented programming, exception handling, scoped resource management, and generic programming, in particular. It also added a standard library which includes generic containers and algorithms. Java was created initially as an interpreter for printing systems but grew to support network computing. Sun Microsystems used it for the basis of their "HotJava" thin client system. It relies on a virtual machine to be secure and highly portable. It is bundled with an extensive library designed to provide a complete abstraction of the underlying platform. Java is a statically-typed object-oriented language that uses a syntax similar to C++, but is not compatible with it. It was designed from scratch with the goal of being easy to use and accessible to a wider audience.

The different goals in the development of C++ and Java resulted in different principles and design trade-offs between the languages. The differences are as follows : C++ Compatible with C source code, except for a few corner cases. Write once, compile anywhere (WOCA) Allows procedural programming, functional programming, object-oriented programming, and template metaprogramming. Allows direct calls to native system libraries. Java No backward compatibility with any previous language. The syntax is, however, strongly influenced by C/C++. Write once, run anywhere / everywhere (WORA / WORE) Strongly encourages an object-oriented programming paradigm.

Call through the Java Native Interface and recently Java Native Access Runs in a protected virtual machine. Does not always provide full access to the features and Exposes low-level system facilities. performance of the platform on which the software runs. Is reflective, allowing metaprogramming and Only provides object types and type names. dynamic code generation at runtime. Has multiple binary compatibility standards Has a binary compatibility standard, allowing (commonly Microsoft and Itanium/GNU) runtime check of correctness of libraries. Optional automated bounds checking. (e.g. the Normally performs bounds checking. HotSpot at() method in vector and string containers) can remove bounds checking. Supports native unsigned arithmetic. No native support for unsigned arithmetic.

Standardized minimum limits for all numerical types, but the actual sizes are implementationdefined. Standardized types are available as typedefs (uint8_t, ..., uintptr_t). Pointers, references, and pass-by-value are supported. Explicit memory management. Supports destructors. C++11 replaces the old standard RAII auto_ptr<T> by unique_ptr<T> and adds shared_ptr<T> (smart pointer with reference counter), though third party frameworks exist to provide better garbage collection. Supports classes, structs, and unions, and can allocate them on heap or stack. Allows explicitly overriding types.

Standardized limits and sizes of all primitive types on all platforms. Primitive and reference data types always passed by value.[1] Automatic garbage collection (can be triggered manually). Doesn't have the concept of destructor, and usage of finalize() is not recommended. Only supports classes, and allocates them on the heap. Java SE 6 optimizes with escape analysis to allocate some objects on the stack. Rigid type safety except for widening conversions. Autoboxing/unboxing added in Java 1.5. The standard library has grown with each release. By version 1.6, the library included support for locales, logging, containers and iterators, algorithms, GUI programming (but not using the system GUI), graphics, multithreading, networking, platform security, introspection, dynamic class loading, blocking and non-blocking I/O, and provided interfaces or support classes for XML, XSLT, MIDI, database connectivity, naming services (e.g. LDAP), cryptography, security services (e.g. Kerberos), print services, and web services. SWT offers an abstraction for platform-specific GUIs. The meaning of operators is generally immutable, however the + and += operators have been overloaded for Strings. Single inheritance only from classes, multiple from interfaces. Generics are used to achieve an analogous effect to C++ templates, but they do not translate from source code to byte code due to the use of type erasure by the compiler. No function pointer mechanism. Instead idioms such as Interfaces, Adapters and Listeners are extensively used.

The C++ Standard Library has a much more limited scope and functionality than the Java standard library but includes: language support, diagnostics, general utilities, strings, locales, containers, algorithms, iterators, numerics, input/output, and Standard C Library. The Boost library offers more functionality, including threads and network I/O. Users must choose from a plethora of (mostly mutually incompatible) third-party libraries for GUI and other functionality.

Operator overloading for most operators. Full multiple inheritance, including virtual inheritance. Compile-time templates.

Function pointers, function objects, lambdas (in C++11, formerly named C++0x) and interfaces.

No standard inline documentation mechanism. 3rd party software (e.g. Doxygen) exists.
const

Javadoc standard documentation.


final

keyword for defining immutable variables and member functions that do not change the object. Supports the goto statement. Source code can be written to be platform independent (can be compiled for Windows, BSD, Linux, Mac OS X, Solaris etc. without needing modification) and written to take advantage of platform specific features. Is typically compiled into native machine code.

provides a limited version of const, equivalent to type* const pointers for objects and plain const for primitive types only. No const member functions, nor any equivalent to const type* pointers. Supports labels with loops and statement blocks. Is compiled into byte code for the JVM. Is dependent on the Java platform, but the source code is typically written to be independent of operating system specific features.

[edit] Language features


[edit] Syntax

Java syntax has a context-free grammar that can be parsed by a simple LALR parser. Parsing C++ is more complicated; for example, Foo<1>(3); is a sequence of comparisons if Foo is a variable, but it creates an object if Foo is the name of a class template. C++ allows namespace-level constants, variables, and functions. In Java, such entities must belong to some given type, and therefore must be defined inside a type definition either a class, or an interface. In C++, objects are values, while in Java they are not. C++ uses value semantics by default, while Java always uses reference semantics. To achieve reference semantics in C++, either a pointer or a reference can be used. C++ Java
// Declares // Member class Foo { class Foo public int x; variable, to 0 by default // Defines // Member //initialized

class Foo { class Foo public: int x; variable

Foo(): x(0) {} // Constructor for Foo; initializes public Foo() { // Constructor // x to 0. If for Foo the initializer were } // omitted, the variable would not public int bar(int i) {// Member // be method bar() initialized to a specific return 3*i + x; // value. }

} int bar(int i) { // Member function bar() return 3*i + x; } }; Foo a; // declares a to be a reference to a Foo object a = new Foo(); // initializes using the default constructor // Another constructor can be used as // "Foo a = new Foo(args);" Foo b = (Foo) a.clone(); Foo b = a; // copies the values of all members // copies the contents of a to a new // of this instance if, and only if, Foo object b; // Foo implements a public method called // alternative syntax is "Foo b(a)" // clone() which returns a new copy of the object a.x = 5; // modifies the object a.x = 5; // modifies the object a referenced by a cout << b.x << endl; System.out.println(b.x); // outputs 0, because b is // outputs 0, because b points to // a different object than a // a different object than a Foo c; // declares c to be a reference to a Foo Foo *c; // object (initially null if c is a // declares c to be a pointer to a class member; // Foo object (initially // it is necessary to initialize c // undefined; could point anywhere) before use // if it is a local variable) c = new Foo; c = new Foo(); // binds c to reference a new Foo // binds c to reference a new Foo object object Foo *d = c; Foo d = c; // binds d to reference the same // binds d to reference the same object object as c as c c->x = 5; c.x = 5; // modifies the object referenced by // modifies the object referenced by c c a.bar(5); // invokes Foo::bar() for a a.bar(5); // invokes Foo.bar() for a c->bar(5); // invokes Foo::bar() for c.bar(5); // invokes Foo.bar() for c *c cout << d->x << endl; System.out.println(d.x); // outputs 5, because d references // outputs 5, because the // d references // same object as c // the same object as c Foo a; // declares a to be a Foo object value, // initialized using the default constructor. // Another constructor can be used as "Foo a(args);"

In C++, it is possible to declare a pointer to a const type in order to prevent client code from modifying the object pointed to by that pointer. Functions and methods can also

guarantee that they will not modify the object pointed to by a pointer by using the "const" keyword. This enforces const-correctness. In Java, const-correctness is enforced by the semantics of the class of which a given object is an instance. Client code is prevented from changing the internal state of an object if and only if every accessible member of the class is labeled final. C++ Java

const Foo *a; // it is not possible to modify the object final Foo a; // it is possible to // pointed to by a through modify the object a a = new Foo(); a = new Foo(); // Only in constructor a.x = 5; a->x = 5; // LEGAL, the object can still be // ILLEGAL modified final Foo b = new Foo(); Foo *const b = new Foo(); // a declaration of a "final" // a declaration of a "const" pointer reference b = new Foo(); b = new Foo(); //ILLEGAL, it is not allowed to re-bind // ILLEGAL, it is not allowed to reit bind it b->x = 5; b.x = 5; // LEGAL, the object can still be // LEGAL, the object can still be modified modified

C++ supports goto statements; Java enforces structured control flow, and relies on labelled break and labelled continue statements to provide some goto-like functionality. Some commenters point out that these labelled flow control statements break the single point-of-exit property of structured programming.[2] C++ provides low-level features which Java lacks. In C++, pointers can be used to manipulate specific memory locations, a task necessary for writing low-level operating system components. Similarly, many C++ compilers support inline assembler. In Java, such code must reside in external libraries, and can only be accessed through the Java Native Interface with a significant overhead for each call.

[edit] Semantics

C++ allows default values for arguments of a function/method. Java does not. However, method overloading can be used to obtain similar results in Java. The minimal compilation unit in C++ is a function; the compilation unit in Java is a class. In C++, functions can be compiled separately. In Java, to compile and maintain methods separately requires moving them into super and extended classes or using some other code refactoring technique. C++ allows a range of implicit conversions between native types, and also allows the programmer to define implicit conversions involving user-defined types. In Java, only widening conversions between native types are implicit; other conversions require explicit cast syntax.

A consequence of this is that although loop conditions (if, while and the exit condition in for) in Java and C++ both expect a boolean expression, code such as if(a = 5) will cause a compile error in Java because there is no implicit narrowing conversion from int to boolean. This is handy if the code was a typo for if(a == 5). Yet current C++ compilers usually generate a warning when such an assignment is performed within a conditional expression. For passing parameters to functions, C++ supports both pass-by-reference and pass-byvalue. In Java, primitive parameters are always passed by value. Class types, interface types, and array types are collectively called reference types in Java and object references are passed by value.[3][4][5] Java built-in types are of a specified size and range defined by the language specification. In C++, a minimal range of values is defined for built-in types, but the exact representation (number of bits) can be mapped to whatever native types are supported on a given platform. o For instance, Java characters are 16-bit Unicode characters, and strings are composed of a sequence of such characters. C++ offers both narrow and wide characters, but the actual size of each is platform dependent, as is the character set used. Strings can be formed from either type. The rounding and precision of floating point values and operations in C++ is platform dependent. Java provides an optional strict floating-point model that guarantees consistent results across platforms, though possibly at the cost of slower run-time performance. In C++, pointers can be manipulated directly as memory address values. Java references are pointers[6] but these references can refer only to objects and arrays. Java references do not allow direct access to memory addresses or allow memory addresses to be manipulated with pointer arithmetic. In C++ one can construct pointers to pointers, pointers to ints and doubles, and pointers to arbitrary memory locations. Java references only access objects and arrays, never primitives, other references, or arbitrary memory locations. In C++, pointers can point to functions or methods (function pointers or functors). The equivalent mechanism in Java uses object or interface references. Through the use of stack-allocated objects, C++ supports scoped resource management, a technique used to automatically manage memory and other system resources that supports deterministic object destruction. Yet, scoped resource management in C++ cannot be guaranteed; it is only a design pattern, and hence relies on programmers' adherence. Java supports automatic memory management using garbage collection, but other system resources (windows, communication ports, threads) often must be explicitly released if the garbage collector cannot determine they are no longer used. C++ features programmer-defined operator overloading which is not supported in Java. The only overloaded operators in Java are the "+" and "+=" operators, which concatenate strings as well as performing addition. Java features standard API support for reflection and dynamic loading of arbitrary new code. C++ supports static and dynamic linking of binaries. Java has generics, whose main purpose is to provide type-safe containers. C++ has templates, which provide more extensive support for generic programming.

Both Java and C++ distinguish between native types (these are also known as "fundamental" or "built-in" types) and user-defined types (these are also known as "compound" types). In Java, native types have value semantics only, and compound types have reference semantics only. In C++ all types have value semantics, but a reference can be created to any type, which will allow the object to be manipulated via reference semantics. C++ supports multiple inheritance of arbitrary classes. In Java a class can derive from only one class, but a class can implement multiple interfaces (in other words, it supports multiple inheritance of types, but only single inheritance of implementation). Java explicitly distinguishes between interfaces and classes. In C++, multiple inheritance and pure virtual functions make it possible to define classes that function almost like Java interfaces do, with a few small differences. Java has both language and standard library support for multi-threading. The synchronized keyword in Java provides simple and secure mutex locks to support multithreaded applications, though synchronized sections must be left in LIFO order. Java also provides robust and complex libraries for more advanced multi-threading synchronization. Only as of C++11 is there a defined memory model for multi-threading in C++. There are also third-party libraries to provide support roughly equivalent to that of Java. C++ methods can be declared as virtual functions, which means the method to be called is determined by the run-time type of the object. By default, methods in C++ are not virtual. In Java, methods are virtual by default, but can be made non-virtual by using the final keyword. C++ enumerations are primitive types and support conversion to and comparison with other integer types. Java enumerations are actually instances of a class (they extend java.lang.Enum<E>) and may therefore define constructors, fields, and methods as any other class.

[edit] Resource management

Java offers automatic garbage collection. Memory management in C++ is usually done through constructors, destructors, and smart pointers. The C++ standard permits garbage collection, but does not require it; garbage collection is rarely used in practice. The enforced use of automatic garbage collection means that writing real-time software can be difficult in Java.[2] C++ can allocate arbitrary blocks of memory. Java only allocates memory through object instantiation. (Note that in Java, the programmer can simulate allocation of arbitrary memory blocks by creating an array of bytes. Still, Java arrays are objects.) Java and C++ use different idioms for resource management. Java relies mainly on garbage collection, which can only reclaim memory and may be a last shot at other resources, while C++ relies mainly on the RAII (Resource Acquisition Is Initialization) idiom. This is reflected in several differences between the two languages: o In C++ it is common to allocate objects of compound types as local stack-bound variables which are destroyed when they go out of scope. In Java compound types are always allocated on the heap and collected by the garbage collector (except in

o o

virtual machines that use escape analysis to convert heap allocations to stack allocations). C++ has destructors, while Java has finalizers. Both are invoked prior to an object's deallocation, but they differ significantly. A C++ object's destructor must be implicitly (in the case of stack-bound variables) or explicitly invoked to deallocate the object. The destructor executes synchronously just prior to the point in the program at which the object is deallocated. Synchronous, coordinated uninitialization and deallocation in C++ thus satisfy the RAII idiom. In Java, object deallocation is implicitly handled by the garbage collector. A Java object's finalizer is invoked asynchronously some time after it has been accessed for the last time and before it is actually deallocated, which may never happen. Very few objects require finalizers; a finalizer is only required by objects that must guarantee some clean up of the object state prior to deallocation typically releasing resources external to the JVM. In Java, safe synchronous deallocation of resources must be performed explicitly using the try/finally construct. In C++, it is possible to have a dangling pointer a stale reference to an object that has already been deallocated. Attempting to use a dangling pointer typically results in program failure. In Java, the garbage collector will not destroy a referenced object. In C++, it is possible to have uninitialized primitive objects. Java enforces default initialization. In C++, it is possible to have an allocated object to which there is no valid reference. Such an unreachable object cannot be destroyed (deallocated), and results in a memory leak. In contrast, in Java an object will not be deallocated by the garbage collector until it becomes unreachable (by the user program). (Note: weak references are supported, which work with the Java garbage collector to allow for different strengths of reachability.) Garbage collection in Java prevents many memory leaks, but leaks are still possible under some circumstances.[7] Java is more prone to leaking non-memory resources than idiomatic C++ is.

[edit] Libraries

C++ provides cross-platform access to many features typically available in platformspecific libraries. Direct access from Java to native operating system and hardware functions requires the use of the Java Native Interface.

[edit] Runtime

C++ is normally compiled directly to machine code which is then executed directly by the operating system. Java is normally compiled to byte-code which the Java virtual machine (JVM) then either interprets or JIT compiles to machine code and then executes. Due to its unconstrained expressiveness, low level C++ language features (e.g. unchecked array access, raw pointers, type punning) cannot be reliably checked at compile-time or without overhead at run-time. Related programming errors can lead to low-level buffer overflows and segmentation faults. The Standard Template Library provides higher-level abstractions (like vector, list and map) to help avoid such errors. In

Java, low level errors either cannot occur or are detected by the JVM and reported to the application in the form of an exception. The Java language requires specific behavior in the case of an out-of-bounds array access, which generally requires bounds checking of array accesses. This eliminates a possible source of instability but usually at the cost of slowing down execution. In some cases, compiler analysis can prove a bounds check unnecessary and eliminate it. C++ has no required behavior for out-of-bounds access of native arrays, thus requiring no bounds checking for native arrays. C++ standard library collections like std::vector, however, offer optional bounds checking. In summary, Java arrays are "always safe; severely constrained; always have overhead" while C++ native arrays "have optional overhead; are completely unconstrained; are potentially unsafe."

[edit] Templates vs. Generics


Both C++ and Java provide facilities for generic programming, templates and generics, respectively. Although they were created to solve similar kinds of problems, and have similar syntax, they are actually quite different. C++ Templates Classes and functions can be templated. Parameters can be any type, integral value, or character literal. Separate copies of the class or function are likely to be generated for each type parameter when compiled. Objects of a class with different type parameters are different types at run time. Implementation source code of the templated class or function must be included in order to use it (declaration insufficient). Templates can be specialized -- a separate implementation could be provided for a particular template parameter. Template parameters can have default arguments. (Prior to C+11, this was allowed only for template classes, not functions.) Does not support wildcards. Instead, return types are often available as nested typedefs. (Also, C++11 added keyword auto, which acts as a wildcard for any type that can be determined at compile time.) Does not directly support bounding of type Java Generics Classes and methods can be genericized. Parameters can only be reference types (not primitive types). One version of the class or function is compiled, works for all type parameters. Type parameters are erased when compiled; objects of a class with different type parameters are the same type at run time. Signature of the class or function from a compiled class file is sufficient to use it. Generics cannot be specialized. Generic type parameters cannot have default arguments.

Supports wildcard as type parameter if it is only used once. Supports bounding of type parameters

parameters, but metaprogramming provides this[8]

Allows instantiation of an object with the type of the parameter type. Type parameter of templated class can be used for static methods and variables. Static variables are not shared between classes of different type parameters.

Templated classes and functions do not enforce type relations for type parameters in their declaration. Use of an incorrect type parameter results in compilation failure, often generating an error message within the template code rather than in the user's code that invokes it. Proper use of templated classes and functions is dependent on proper documentation. Metaprogramming provides these features at the cost of additional effort. Templates are Turing-complete (see template Generics are not Turing-complete. metaprogramming).

with "extends" and "super" for upper and lower bounds, respectively; allows enforcement of relationships between type parameters. Does not allow instantiation of an object with the type of the parameter type (except through reflection). Type parameter of templated class cannot be used for static methods and variables. Static variables are shared between instances of classes of different type parameters. Generic classes and functions can enforce type relationships for type parameters in their declaration. Use of an incorrect type parameter results in a type error within the code that uses it. Operations on parametrized types in generic code are only allowed in ways that can be guaranteed to be safe by the declaration. This results in greater type safety at the cost of flexibility.

[edit] Miscellaneous

Java and C++ use different techniques for splitting up code in multiple source files. Java uses a package system that dictates the file name and path for all program definitions. In Java, the compiler imports the executable class files. C++ uses a header file source code inclusion system for sharing declarations between source files. Compiled Java code files are generally smaller than code files in C++ as Java bytecode is usually more compact than native machine code[citation needed] and Java programs are never statically linked. C++ compilation features an additional textual preprocessing phase, while Java does not. Thus some users add a preprocessing phase to their build process for better support of conditional compilation. In both languages, arrays have a fixed size. In Java, arrays are first-class objects, while in C++ they are merely a continuous run of their base objects, often referred to using a pointer to their first element and an optional length. In Java, array objects are boundschecked and contain information about their own length, while in C++ any subsequence can be treated as an array in its own right. Both C++ and Java provide container classes (std::vector and java.util.ArrayList respectively) which are resizable and store their size.

Java's division and modulus operators are well defined to truncate to zero. C++ does not specify whether or not these operators truncate to zero or "truncate to -infinity". -3/2 will always be -1 in Java, but a C++ compiler may return either -1 or -2, depending on the platform. C99 defines division in the same fashion as Java. Both languages guarantee (where a and b are integer types) that (a/b)*b + (a%b) == a for all a and b (b != 0). The C++ version will sometimes be faster, as it is allowed to pick whichever truncation mode is native to the processor. The sizes of integer types is defined in Java (int is 32-bit, long is 64-bit), while in C++ the size of integers and pointers is compiler and ABI dependent within given constraints. Thus, carefully written C++ code can take advantage of the 64-bit processor's capabilities while still functioning properly on 32-bit processors. However, this requires care and effort to ensure that the C++ source code is written in a portable manner. In contrast, Java's fixed integer sizes mean that programmer error in this regard are not possible, although this may incur a performance penalty since Java code cannot run using an arbitrary processor's word size.

[edit] Performance
This section needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (September 2010) In addition to running a compiled Java program, computers running Java applications generally must also run the Java virtual machine (JVM), while compiled C++ programs can be run without external applications. Early versions of Java were significantly outperformed by statically compiled languages such as C++. This is because the program statements of these two closely related languages may compile to a few machine instructions with C++, while compiling into several byte codes involving several machine instructions each when interpreted by a JVM. For example: Java/C++ statement C++ generated code (x86) Java generated byte code aload_1 mov edx,[ebp+4h] vector[i]++; iload_2 dup2 iaload mov eax,[ebp+1Ch] inc dword ptr [edx+eax*4] iconst_1 iadd iastore

Certain inefficiencies are inherent to the Java language itself, primarily:

All objects are allocated on the heap. For functions using small objects this can result in performance degradation as stack allocation, in contrast, costs essentially zero. However, this advantage is obsoleted by modern JIT compilers utilising escape analysis or escape

detection to allocate objects on the stack. Escape analysis was introduced in Oracle JDK 6. Methods are virtual by default. This slightly increases memory usage by adding a single pointer to a virtual table per each object. It also induces a startup performance penalty, since a JIT compiler must perform additional optimization passes even for devirtualization of small functions. A lot of casting required even using standard containers induces a performance penalty. However, most of these casts are statically eliminated by the JIT compiler, and the casts that remain in the code usually do not cost more than a single CPU cycle on modern processors, thanks to branch prediction. Array access must be safe. The compiler is required to put appropriate range checks in the code. The naive approach of guarding each array access with a range check is not efficient, so most JIT compilers generate range check instructions only if they cannot statically prove the array access is safe. Even if all runtime range checks cannot be statically elided, JIT compilers try to move them out of inner loops to make the performance degradation as low as possible. Lack of access to low-level details prevents the developer from improving the program where the compiler is unable to do so.[9] Programmers can interface with the OS directly by providing code in C or C++ and calling that code from Java by means of JNI.

In contrast, various optimizations in C++ are either too difficult or impractical to implement:

Pointers make optimization difficult since they may point to arbitrary data. However, in some cases this is obsoleted as new compilers introduced a strict-aliasing rule[10] and because of support of the C99 keyword restrict.[11] Java garbage collection may have better cache coherence than the usual usage of malloc/new for memory allocation, as its allocations are generally made sequentially. Nevertheless, arguments exist that both allocators equally fragment the heap and neither exhibits better cache locality. Due to the lack of garbage collection in C++, programmers must supply their own memory management code, often in the form of reference-counted smart pointers. Since the code generated from various concretisations of the same templated class in C++ is not shared, excessive use of templates may lead to significant increase of the executable code size. Run-time compilation can potentially use additional information available at run-time to improve code more effectively, such as the processor on which the code will be executed. However, this claim is effectively made obsolete as most state-of-the-art C++ compilers generate multiple code paths to employ the full computational abilities of the given system[12] Run-time compilation allows for more aggressive virtual function inlining than is possible for a static compiler, because the JIT compiler has complete information about all possible targets of the virtual call, even if they are in different dynamically loaded modules. Currently available JVM implementations have no problem in inlining most of the monomorphic, mostly monomorphic and dimorphic calls, and a research is in progress to inline also megamorphic calls, thanks to the recent invoke dynamic

enhancements added in Java 7.[13] Inlining can allow for further optimisations like loop vectorisation or loop unrolling, resulting in a huge overall performance increase. Because dynamic linking is performed after code generation and optimisation in C++, function calls spanning different dynamic modules cannot be inlined. Because thread support is provided by libraries in C++, C++ compilers have no chance to perform thread-related optimisations. In Java, thread synchronisation is built into the language, so the JIT compiler can, with the help of escape analysis, easily elide or coarse locks,[clarification needed] significantly improving performance of multithreaded code. This technique was introduced in Sun JDK 6 update 10 and is named biased locking.[14]

[edit] Official standard and reference of the language


Language specification The C++ language is defined by ISO/IEC 14882, an ISO standard, which is published by the ISO/IEC JTC1/SC22/WG21 committee. The Java language is defined by the Java Language Specification,[15] a book which is published by Sun (now Oracle). The Java language continuously evolves through a process called the Java Community Process, and the world's programming community is represented by a group of people and organizations the Java Community members[16] - which is actively engaged into the enhancement of the language, by sending public requests - the Java Specification Requests - which must pass formal and public reviews before they get integrated into the language. In contrast, the C++ programming community does not have this power, because the C++ language specification was statically defined by ISO. Trademarks "C++" is not a trademark of any company or organization and is not owned by any individual.[17] "Java" is a trademark of Sun Microsystems (now Oracle).[18]

[edit] References
1. ^ "The Java Tutorials: Passing Information to a Method or a Constructor". Oracle. Retrieved 7 December 2010. 2. ^ a b Robert C. Martin (January 1997). "Java vs. C++: A Critical Comparison" (PDF). 3. ^ "Reference Types and Values". The Java Language Specification, Third Edition. Retrieved 9 December 2010. 4. ^ Horstmann, Cay; Cornell, Gary (2008). Core Java. I (Eighth ed.). Sun Microsystems. pp. 140141. ISBN 978-0-13-235476-9. "Some programmers (and unfortunately even some book authors) claim that the Java programming language uses call by reference for objects. However, that is false. Because this is such a common misunderstanding, it is worth examining a counterexample in some detail... This discussion demonstrates that the Java programming language does not use call by reference for objects. Instead object references are passed by value."

5. ^ Deitel, Paul; Deitel, Harvey (2009). Java for Programmers. Prentice Hall. p. 223. ISBN 978-0-13-700129-3. "Unlike some other languages, Java does not allow programmers to choose pass-by-value or pass-by-referenceall arguments are passed by value. A method call can pass two types of values to a methodcopies of primitive values (e.g., values of type int and double) and copies of references to objects (including references to arrays). Objects themselves cannot be passed to methods." 6. ^ "Java Language Specification 4.3.1: Objects". Sun Microsystems. Retrieved 9 December 2010. 7. ^ "Java memory leaks -- Catch me if you can" by Satish Chandra Gupta, Rajeev Palanki, IBM DeveloperWorks, 16 August 2005 8. ^ Boost type traits library 9. ^ Clark, Nathan; Amir Hormati, Sami Yehia, Scott Mahlke (2007). "Liquid SIMD: Abstracting SIMD hardware using lightweight dynamic mapping". HPCA07: 216227. 10. ^ http://cellperformance.beyond3d.com/articles/2006/06/understanding-strictaliasing.html 11. ^ Demystifying the Restrict Keyword 12. ^ Targeting IA-32 Architecture Processors for Run-time Performance Checking 13. ^ http://www.azulsystems.com/blog/cliff/2011-04-04-fixing-the-inlining-problem 14. ^ http://java.sun.com/performance/reference/whitepapers/6_performance.html#2.1.1 15. ^ The Java Language Specification 16. ^ http://www.jcp.org/en/participation/members 17. ^ Bjarne Stroustrup's FAQ: Do you own C++? 18. ^ ZDNet: Oracle buys Sun; Now owns Java.

You might also like