We Keep Coding

What should a Scala developer know about Java and/or the JVM?

So up until about 6 months ago, most of my work (big graph processing) consisted of Python and C++. Up to that point, and even now, I had not written any Java whatsoever.. I had seen the language and was familiar with the syntax (having come from a C/C++ background), and liked the idea of the JVM, but never actually written any substantial amount of Java.
When I picked up Scala, I loved it, OOP and functional programming features all in one, and it being on the JVM was great. I've been constantly striving to improve my Scala and have been playing with Akka, and still loving it. However, at times, perhaps it is just me overthinkng it, but I feel I should learn some more about Java and/or the JVM.
I've heard from many that Scala should be considered a separate language from Java, much like C++ to C. Perhaps you may feel the same way, and perhaps learning Java is more or less disjoint from learning Scala, but I'm feeling learning more about the JVM (e.g. JIT compilation, type erasure) would be helpful?
Thoughts?

The JVM executes Bytecode and it is definately helpful to know how this works, just as it is sometimes helpful to know how C/C++ method invocations work or how classes are initialized; because sometimes it matters and cannot be abstracted away.
Java is the prime language for the JVM, and it is helpful to be able to read Java to some extent if you need to use Java classes directly. And this may happen quite often; only a few examples:
you need to use some third party Java library (and there are tons)
working with Properties
you need to do something special in Swing which is not supported by the Scala-Swing wrapper
also sources explaining stuff for 1) will most probably use Java examples
But my advice is not to study it in advance - you'll pick it up when you need it.

Buy this book now: Java Performance. It was only released last October and is a treasure trove of information for anyone who wants to understand the JVM. If you're going to be a Scala developer, you must understand garbage collection and JVM runtime parameters at the very least.

Off top of my head
primitives, autoboxing, and how java arrays are special;
erasure and manifests
how logically tail recursive calls in scala source are compiled
installing -client, -server on your platform and when you want to try 32 bit: e.g. JAVA_HOME and "Java preferences" in OS X. I think openJDK should work anywhere you use same version of Oracle JDK, but IntelliJ warns you to use only official Oracle JDK. I've seen very isolated reports that 3d graphics libs have had problems with openJDK, and also parts of openJDK like the fonts have licensing issues.
setting classpaths in REPL, as compiler option, and in SBT
Hotspot switches, XMX, XMS (heap settings), most common garbage collectors, inlining method calls
java.util.concurrent
possible binary compatibility issues with java and scala code compiled in JDK 6 and 7.

I don't know exactly what you need, but there are several similar questions on SO, look it.
Understanding JVM Better
Understanding the Sun JVM
Also, here good articles for Java Memory Model
Java theory and practice: Fixing the Java Memory Model, Part 1
Java theory and practice: Fixing the Java Memory Model, Part 2
My thought it's better to dig in Java language, write some code, read Java-specific books for better understanding how all things works.

There are a lot of tools surrounding the JVM. If you want to understand how your programs are running (for performance or other reasons) then it's worth being au fait with these. Two useful tools are:
jstack
visualvm
Both are particularly useful for monitoring and interrogating long-running processes.

I think you will know more about JVM when you program Scala. I mean you will have more questions like 'Why this solution is slow and that is fast?' - one way to answer this question is to check the bytecode

What is portability? How is java more portable than other languages? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I wonder how Java is more portable than C, C++ and .NET and any other language. I have read many times about java being portable due to the interpreter and JVM, but the JVM just hides the architectural differences in the hardware, right? We'd still need different JVMs for different machine architectures. What am I missing here? So if someone writes an abstraction layer for C for the most common architectures, let's say the CVM, then any C program will run on those architectures once CVM is installed, isn't it?
What exactly is this portability? Can .NET be called portable?

Portability isn't a black and white, yes or no kind of thing. Portability is how easily one can I take a program and run it on all of the platforms one cares about.
There are a few things that affect this. One is the language itself. The Java language spec generally leaves much less up to "the implementation". For example, "i = i++" is undefined in C and C++, but has a defined meaning in Java. More practically speaking, types like "int" have a specific size in Java (eg: int is always 32-bits), while in C and C++ the size varies depending on platform and compiler. These differences alone don't prevent you from writing portable code in C and C++, but you need to be a lot more diligent.
Another is the libraries. Java has a bunch of standard libraries that C and C++ don't have. For example, threading, networking and GUI libraries. Libraries of these sorts exist for C and C++, but they aren't part of the standard and the corresponding libraries available can vary widely from platform to platform.
Finally, there's the whole question of whether you can just take an executable and drop it on the other platform and have it work there. This generally works with Java, assuming there's a JVM for the target platform. (and there are JVMs for many/most platforms people care about) This is generally not true with C and C++. You're typically going to at least need a recompile, and that's assuming you've already taken care of the previous two points.
Yes, if a "CVM " existed for multiple platforms, that would make C and C++ more portable -- sort of. You'd still need to write your C code either in a portable way (eg: assuming nothing about the size of an int other than what the standard says) or you'd write to the CVM (assuming it has made a uniform decision for all of these sorts of things across all target platforms). You'd also need to forgo the use of non-standard libraries (no networking, threading or GUI) or write to the CVM-specific libraries for those purposes. So then we're not really talking about making C and C++ more portable, but a special CVM-C/C++ that's portable.
Once again, portability isn't a black and white thing. Even with Java there can still be incompatibilities. The GUI libraries (especially AWT) were kind of notorious for having inconsistent behavior, and anything involving threads can behave differently if you get sloppy. In general, however, it's a lot easier to take a non-trivial Java program written on one platform and run it on another than it is to do the same with a program written in C or C++.

As others have already said, portability is somewhat of a fuzzy concept. From a certain perspective, C is actually more portable than Java. C makes very few assumptions about the underlying hardware. It doesn't even assume that there are 8 bits in a byte, or that negative numbers should be represented using two's complement. Theoretically, as long as you have a Von Neumann based machine and a compiler, you're good to go with C.
In fact, a "Hello world" program written in C is going to work on many more platforms than a "Hello world" program written in Java. You could probably get the same "hello world" program to work on a PDP-11 and an iPhone.
However, the reality is that most real-world programs do a lot more than output "Hello world". Java has a reputation for being more portable than C because in practice, it takes a lot more effort to port real-world C programs to different platforms than real-world Java programs.
This is because the C language is really ANSI-C, which is an extremely general-purpose, bare-bones language. It has no support for network programming, threading, or GUI development. Therefore, as soon as you write a program which includes any of those things, you have to fall back on a less-portable extension to C, like Win32 or POSIX or whatever.
But with Java, network programming, threading, and GUI tools are defined by the language and built into each VM implementation.
That said, I think a lot of programmers also underestimate the progress modern C/C++ has made in regard to portability these days. POSIX goes a long way towards providing cross-platform threading, and when it comes to C++, Boost provides networking and threading libraries which are basically just as portable as anything in Java. These libraries have some platform-specific quirks, but so does Java.
Essentially, Java relies on each platform having a VM implementation which will interpret byte code in a predictable way, and C/C++ relies on libraries which incorporate platform specific code using the preprocessor (#ifdefs). Both strategies allow for cross platform threading, networking, and GUI development. It's simply that Java has made faster progress than C/C++ when it comes to portability. The Java language spec had threading, networking and GUI development almost from day one, whereas the Boost networking library only came out around 2005, and it wasn't until 2011 with C++11 that standard portable threading was included in C++.

When you write a Java program, it runs on all platforms that have JVM written for them - Windows, Linux, MacOS, etc.
If you write a C++ program, you'll have to compile it specifically for each platform.
Now, it is said that the motto of Java "write once, run everywhere" is a myth. It's not quite true for desktop apps, which need interaction with many native resources, but each JavaEE application can be run on any platform. Currently I'm working on windows, and other colleagues are working on Linux - without any problem whatsoever.
(Another thing related to portability is JavaEE (enterprise edition). It is said that applications written with JavaEE technologies run in any JavaEE-certified application server. This, however, is not true at least until JavaEE6. (see here))

Portability is a measure for the amount of effort to make a program run on another environment than where it originated.
Now you can debate if a JVM on Linux is a different environment than on Windows (I would argue yes), but the fact remains that in many cases there is zero effort involved if you take care of avoiding a few gotchas.
The CVM you are talking about is very much what the POSIX libraries and the runtime libraries try to provide, however there are big implementation differences which make the hurdles high to cross. Certainly in the case of Microsoft and Apple these are probably intentionally so in order to keep developers from bringing out products on competing platforms.
On the .net front, if you can stick to what mono provides, an open source .Net implementation, you will enjoy roughly the same kind of portability as Java, but since mono is significantly behind the Windows versions, this is not a popular choice. I do not know how popular this is for server based development where I can imagine it is less of an issue.

Java is portable from the perspective of the developer: code written in Java can be executed in any environment without the need to recompile. C is not portable because not only is it tied to a specific OS in many cases, it is also always tied to a specific hardware architecture once it has been compiled. The same is true for C++. .Net is more portable than C/C++, as it also relies on a virtual machine and is therefore not tied to a specific hardware architecture at compile-time, but it is limited to Windows machines (officially).
You are correct, the JVM is platform-specific (it has to be!), but when you say Java is portable, you are talking about it from a developer standpoint and standard Java developers do not write the JVM, they use it :-).
Edit #Raze2Dust To address your question. Yes, you could. In fact, you could make Java platform-specific by writing a compiler that would generate machine code rather than bytecode. But as some of the other comments suggest, why would you do that? You'd have to create an interpreter that maps the compiled code to operations in the same way the JVM works. So the long and short of it is, absolutely, you definitely could, but why would you?

Java provides three distinct types of portability:
Source code portability: A given Java program should produce identical results regardless of the underlying CPU, operating system, or Java compiler.
CPU architecture portability: the current Java compilers produce object code (called byte-code) for a CPU that does not yet exist. For each real CPU on which Java programs are intended to run, a Java interpreter, or virtual machine, "executes" the J-code. This non-existent CPU allows the same object code to run on any CPU for which a Java interpreter exists.
OS/GUI portability: Java solves this problem by providing a set of library functions (contained in Java-supplied libraries such as awt, util, and lang) that talk to an imaginary OS and imaginary GUI. Just like the JVM presents a virtual CPU, the Java libraries present a virtual OS/GUI. Every Java implementation provides libraries implementing this virtual OS/GUI. Java programs that use these libraries to provide needed OS and GUI functionality port fairly easily.
See this link

You ask if one could write a "C VM". Not exactly. "Java" is a big term used by Sun to mean a lot of things, including both the programming language, and the virtual machine. "C" is just a programming language: it's up to the compiler and OS and CPU to decide what format the resulting binary should be.
C is sometimes said to be portable because it doesn't specify the runtime. The people who wrote your compiler were able to pick things that make sense for that platform. The downside is that C is low-level enough, and platforms are different enough, that it's common for C programs to work fine on one system and not at all on another.
If you combine the C language with a specific ABI, you could define a VM for it, analogous to the JVM. There are a few things like this already, for example:
The "Intel Binary Compatibility Specification" is an example of such an ABI (which almost nobody uses today)
"Microsoft Windows" could also be such an ABI (though a huge and underspecified one), for which Wine is one VM that runs programs written for it
"MS-DOS", for which dosemu is one VM
"Linux" is one of the more popular ones today, whose programs can be run by Linux itself, NetBSD, or FreeBSD
"PA-RISC", for which HP's Dynamo was a JIT-like VM
All of these C VMs are in fact a real machine -- nobody, AFAIK, has ever made a C VM that was purely virtual. This isn't surprising, since C was designed to run efficiently on hardware, so you might as well make it run normally on one system. As HP showed, you can still make a JIT to run the code more efficiently, even on the same platform.

You need the JVM for different architectures, but of course your Java programs run on that JVM. So once you have a JVM for an architecture, then your Java programs are available for that architecture.
So I can write a Java program, compile it down to Java bytecode (which is architecture-agnostic), and that means I can run it on any JVM on any architecture. The JVM abstracts away the underlying architecture and my program runs on a virtual machine.

The idea is that the Java language is portable (or more accurately, the compiled byte-code is portable). You are correct that each VM requires a specific implementation for a given hardware profile. However, once that effort has been made, all java bytecode will run on that platform. You write the java/bytecode once, and it runs on any JVM.
.NET is quite similar, but with a far lower emphasis on the principle. The CLR is analogous to the JVM and it has its own bytecode. Mono exists on *nix, but you are correct that it is not "official".

Portability or as written in Wikipedia, Software Portability is the ability to reuse the same software (code) across multiple environments (OSes). The java JVM is a JVM that can be run on any operating systems it was designed for: Windows, Linux, Mac OSes, etc.
On .NET, it is possible to port your software to different platforms. From Wikipedia:
The design of the .NET Framework
allows it to theoretically be platform
agnostic, and thus cross-platform
compatible. That is, a program written
to use the framework should run
without change on any type of system
for which the framework is
implemented.
And because Microsoft never implemented the .NET framework outside of Windows and seeing that .NET is platform agnostic, Mono has made it possible to run .NET applications and compile code to run in Linux.
For languages such as C++, Pascal, etc. you will have to go to each OS and build it on that platform in order to run it on that platform. The EXE file in Windows isn't the same as the .so in linux (the machine code) since both uses different libraries to talk to the kernel and each OS has its own kernel.

WORE - Write Once Run Everywhere
In reality, this is limited to the platforms that have a JVM, but this covers off the majority of platforms you would wish to deploy to. It is almost a half-way between an interpreted language, and a compiled language, gaining the benefits of both.

What languages would be a good replacement for Java?

I may be posting a premature question, and maybe I'm just freaking out for no reason, but the way Oracle is handling Java is not very promising. I am a nerd who fell in love with Java from the first sight, and use it all the time in my personal/freelance projects but now I am thinking of a replacement.
I am fluent in C#/VB.NET too but I am looking for something more like:
Open Source
Compiled
Cross-Platform
Object Oriented
Large standard library
Extensive documentation
Web development is a major plus
I was thinking about a compromise: Python/Django for web development (or PHP), and Qt for thick client development. Anyone with better thoughts?

Not so long ago, I decided to explore away from the JVM. I set foot on python, and even though i'm nowhere near the expert/ guru level, I dont regret it. Didn't choose C# (considered it) because I consider it to be more of the same. I alredy know (and like a lot) C++, so python seemed like something new, which is what I was looking for.
It fullfils many of your requirements. Particularly, i'm decided not to learn PHP, so the web frameworks in python came in great.
Not to mention, Python has a large community (also see here), always eager to help and teach, which I consider to be very important.
Just my two cents.

Might be worth loking at the other JVM languages - Clojure and Scala are the two I personally think are most promising.
Yes you are on the JVM, but you're pretty independent from Java the langauage and don't have to use any Sun/Oracle implementations if you don't want to.
Having said that - I think that you are worrying a little too much about Java, too many players (including Oracle!) have too much invested to let it go too far off course.

Try Scala. It looks extremely elegant and promising. Being object oriented and sharing a lot with java in a very concise manner.

Everything you said points to C#, except for the Open Source point.
To fix that, there's Mono.

You could try D. My one-sentence description of why it's an awesome language is that its generic programming/compile-time introspection/template metaprogramming facilities are good enough to give you almost flexibility of a duck-typed language, while its execution speed and static type checking rival or exceed C++ and C#.
I think it meets your requirements quite well.
Open source: The frontend to the reference DMD implementation is open source (the back end isn't due to restrictions beyond the author's control). Work is underway to glue the reference frontend to open source backends such as LLVM (LDC) and GCC (GDC). In the case of D1 (the older version of the language) the LLVM port is fairly mature.
Compiled: D is meant to be compiled to native machine code, i.e. raw, inscrutable hexadecimal numbers.
Cross-platform: The reference DMD compiler supports x86 Windows, Linux, Mac OS X and FreeBSD. GDC and LDC will likely support a lot more CPU architectures.
Object oriented: D isn't a "pure" OO language in the Ruby sense of everything being an object, or in the Java sense of not supporting any other paradigm. It does, however, fully support Java-style OO as a subset of the language, along with procedural and functional style programming.
Large standard library: D1 has Tango, which qualifies. D2 has Phobos, which is not "large" yet by modern standards but is larger than C or C++'s standard lib. However, recently there has been a large interest in contributing and Andrei Alexandrescu (its main designer) has accepted several new contributors, including myself.
Extensive documentation: The standard library and language are reasonably well documented at the Digital Mars website. There's also Andrei Alexandrescu's book "The D Programming Language".
Web development: This is an admitted weakness. D doesn't (yet) have a good web framework, though its native unicode support and excellent generic programming support should make writing one relatively easy.

I too would like another Java-like technology to come along. Lately I've been doing Flex/Actionscript. While I really enjoy it, Actionscript technology seriously lacks the elegance that Java has. Adobe can write some good cross platform APIs, but they just don't have the head capital to build elegant languages and compilers. I've also tried Ruby, but the VM for Ruby is really bad. I've gone back to Java after my flirtation with other technologies and I think it's because the language is good enough, but the JVM is by far the best out there.
So do you want to stay with the JVM or do you really want to the leave the JVM altogether? Staying on the JVM there are lots of options: JRuby, Scala, Groovy, Javascript, Clojure are the big players. However, there are tons of great languages that can take advantage of the JVM's features.
Leaving the JVM there are still good options like python, ruby, and erlang. But you give up some of the nice features of the JVM like performance (big one), and the ability to drop down to a nice language like Java if you need speed. Those others mean using C or nothing at all.
I finally stopped worrying about Java's future. Sun did all it could to screw it up and it still turned out pretty darn good. I think Opensource has a lot more influence over Java's success than Oracle or Sun could ever have had.

I can't post comments yet, so I'm posting an answer related to the Python discussion. Though Python isn't compiled to machine code, there is a Python-to-C compiler called Cython, which can compile nearly all valid Python -- closures are finally (!) in the latest development release. It's have a big impact on some parts of the Python commmunity, e.g., I was at Euroscipy recently, and over half the talks mentioned Cython.

I personally don't like PHP, but it does meet all of your requirements. It doesn't officially support compilation but there is the Hip Hop project which compiles PHP to C code. Facebook is currently heading up this project.
That said, I highly discourage you from using it :)

C# is the only thing that will meet your needs and not feel hopelessly archaic, or frustrate with limited library. For open source/non-windows, use mono. It's a good, mature implementation of most of what's important in the CLR.
Some things (WPF, WCF, etc) are "missing" from mono, but these aren't so much part of the platform as they are windows-specific proprietary toolkits. Some of them are being implemented slowly in mono, some aren't. Coming from java you won't miss them because you're looking for a platform and good standard libraries to build upon, not a gui toolkit or whiz-bang communication framework.
As far as a platform to build stuff with that's "like" java and offers similar levels of functionality, C# + CLR is the clearest option.

Using also Cython you get the best of the two worlds , the ability to code in python , the ability to code in C and C++ and of course compile your code and the ability to use both python a c/c++ libraries out of the box. And if you dont like C++ syntax , cython syntax is python syntax and more.
link text

What is Sun's attitude towards Clojure?

What is their official position towards clojure?

Why should Sun/Oracle (as a whole), empoyees, or any of the millions of users of said Java libraries or JVM care about Clojure except how Clojure is beneficial (or detrimental) to individual tasks?
The question is, well, silly at best.
Clojure will not replace Java -- it was not even designed to -- and, if anything, simply showcases the adaptability of the JVM (and the layers of hacks used to support dynamic languages in relatively efficient ways). Hopefully the JVM will flourish and improve (and will have better support for "non-Java" programming models).

There is no reason at all why sun might be "not too excited" about alternative JVM languages (and there are lots of languages besides Clojure: Groovy, Scala, JRuby, Jython, even JavaFX which is from Sun itself).
I think all those new languages are important for the JVM, and Sun is actively working on adding support in the JVM for alternative programming languages (see JSR 292, for example).
It's not like as if Sun wants everybody to use the Java programming language only...

Sun is not a single mind. You will find opinions on clojure that are all over the map:
http://www.google.com/search?source=ig&hl=en&rlz=&q=site%3Ablogs.oracle.com+clojure&aq=f&oq=&aqi=
And don't forget, a lot of non-Java languages running atop the JVM can take advantage of those vast libraries, both within the JDK and without. I think Sun generally approves of such reuse.

I don't know of any "official" position of Clojure. You may have seen reports of work on supporting dynamic languages on the JVM and hosting JVM language summits at the Santa Clara campus. The general attitude seems to be, if you want to do some programming, please come and do it on the JVM.

The most optimistic success case for Clojure is probably defined relative to the other Lisp variants. Should Clojure lead the Lisp army (unlikely, BTW, but that's another question) it still would not have much economic effect.
And if it doesn't have much economic effect, then it won't really have a conventional wisdom inside a corporation. Individuals there will like it and dislike it, but as a company, they just won't care one way or another.
Should hell freeze over and then everone starts developing in Clojure, the company probably still wouldn't care, they would just find a way to adapt and live in the new ecosystem. As time went on a story would develop about how it was all their idea to start with.

What is the difference between Java and C++? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
What is the difference between Java and C++? Are both object-oriented?

This is far too general a question to be answered here.
Java is an explicitly object-oriented language, with the harder-to-use bits snipped off.
C++ is a multi-paradigm language with the safety off. You can do object-oriented programming in it, as well as procedural and generic.
If you had a more specific question, we could be of more help. Why did you ask? If you want recommendations for a particular platform, or project, or whatever, we could be more responsive.

A C++ programmer will tell you that Java is rubbish. A Java programmer will tell you that C++ is rubbish. Therefore I conclude that they are indeed the same thing.

Each language designed with different purposes in mind, so IMO it's not fair to compare the two from one perspective, and ignore the other.
Generally speaking, C++ is an open standard, designed for implementing high performance systems where speed and performance and critical, there are lots of impressing projects designed using this language like Phoenix Lander, Adobe Acrobat Reader and others. C++ gives the developer the ability to program using a very high level abstraction -using generics for example, and, when needed, go down deep to the bare metal of the machine -to handle an interrupt for instance.
Java was designed with other purposes in mind, when Sun was planning Oak (later called Java), it focused on web applications so it supported the language with a bunch of heavy libraries of easy-to-use interfaces considering that. and portability (Compile once, run anywhere) using JVM, which prevents the programmer from coding to specific machine, but instead coding to a sandbox which in turn runs the code on the hosting machine, and this has obviously negative reflections on performance/speed.
Comparison of those two language is a popular cause of debate between programmers, and this is due to their different working demands and nature, IMO every language has made mistakes in order to mature, for example, C++'s exported templates, and Java's lack of procedural programming (Big Mistake). plus, each one has its pros and cons regarding different aspects, hence the one that balance productivity/performance issue IS the right language.
For more information Wikipedia's comprehensive article on Comparison of Java and C++
It might be interesting to take a look at what languages are used (and being used) to create major systems (like Google) from here.

One of the most important differences hasn't been mentioned yet - one is compiled to machine code, the other is compiled to bytecode which is interpreted by a virtual machine.

Everything is Object in Java as everything is derived from java.lang.Object But this is not the case in C++
No pointers in Java whereas C++ has provide support for pointers
No destructors in java (Java has automatic garbage collection) but C++ has destructors to do that
Thread support is built in Java but not in C++
No scope resolution operator in Java
No Goto statement in Java
No Multiple Inheritance allowed in Java but C++ allows that
No operator overloading is allowed in Java but C++ allows that
Java is interpreted for most part and hence Platform independent

Both are object oriented but they are very different languages. This probably isn't the best forum to ask for the differences... I would suggest you look both up on Wikipedia and review the descriptions there. You will be able to see the differences very quickly for yourself.

I love c++ but unless you absolutely need to use c++ then use something else. When you need to use c++ then you will know the difference, Grasshopper.
(hint do not write device drivers, video decoders, encryption libraries, 3-d graphics engines or language run-time engines in java).

Yes, both are object oriented programming languages.
C++ is an evolution to C. Which was a system programming language. C++ Added many features to the language to make it object oriented. It became the mainstream programming language for that reason.
Java is an evolution of C++, with different goals ( cross platform for instance ). It remove some of the features that make C++ so hard to learn. Simplify others and remove others.
The main difference is C++ programs are compiled directly to machine code ( understood by the CPU ) while Java programs are compiled to be run in a "Virtual Machine" the JVM most of the cases. For these reasons java programs were interpreted by another program and at the beginning were veeeery slow programs. Nowadays the VM may optimize this code and make it run very very fast.

See this link.http://www.javacoffeebreak.com/articles/thinkinginjava/comparingc++andjava.html

Gross but accurate oversimplification: Java is easier. C++ is faster.

Just a quick addition to what David Thornley posted. C++ is a procedural language that supports Objects and OO design. Java is pure OO. Java does less but on more.