Learning java, coming from C++

[mark drakos]

Hi,

I am an amateur programmer (currently learning in University) who has had almost all of my experience with C++. I'd like to think I know a lot about C++, but I'm pretty obviously biased. With that in mind, are there any guides which would be suitable for someone such as myself? In particular, I'd like to familiarize myself with the syntax and the basics I know from C++ fast, before moving onto features not present in C++. I ask this question here because, although there are lots of guides, I don't know which are best, and I am looking for one suitable for someone coming from C++.

Additionally, are there any paradigms which are suitable for java programming, besides procedural and object oriented programming?

All advice is appreciated, thanks!

[Maneesh Godbole]

Welcome to the Ranch
Coming from C++ background, I think you will be able to get up to speed pretty fast.

You can start off with http://docs.oracle.com/javase/tutorial/java/nutsandbolts/ which is the "official" documentation.
Lots of people have also found the Head First series by Sierra, Bates to be very useful (Bert Bates is very active on the Ranch)
I personally used and would recommend the Core Java series by Horstmann,Cornell.

And of course you can ask absolutely anything at the Ranch itself to clear your doubts.

[Gokul Osho]

Try reading "Head First Java" by Kathy Sierra & Bert Bates. Incredible book..!! I am on it and personally I feel "there is no better book for a beginner other than this".

Best,
Gokul

[surlac surlacovich]

I would recommend "Thinking in Java" by Bruce Eckel. It's really good.

[Winston Gutkowski]

mark drakos wrote:Additionally, are there any paradigms which are suitable for java programming, besides procedural and object oriented programming?

Well, I don't know if I'd categorise it as a 'paradigm', but the main thing to do is forget about memory - completely (at least at the start).

Forget any assumptions that you might have about what an object looks like, or where it is, or accessing it directly, or remembering to destroy it when you're finished with it, because it simply isn't important.
Java is a memory-managed language, so there's no malloc(), no free() and, above all, no destroy (~). It does have references (pointers to you), but you can't access them directly, and you certainly can't do any arithmetic on them.

Strings are Strings, not char*'s, and ALL methods belong to a class, so you don't have free-floating utility methods like strcmp() lying around (there are utility classes, however; although these are relatively rare). Also: Java source code doesn't have headers.

About the only other thing I can think of is that arrays are objects, and mutli-dimensional arrays are actually arrays of arrays.

Other than that, I have heard good things about the book that surlac suggested; although I've never read it myself. "Head First Java" is also good, but if you're an experienced C++ programmer, you may find it's style a bit 'folksy'.

HIH

Winston

[Ivan Jozsef Balazs]

Sometimes differences lurk under the similar syntax.

C++ templates are different from Java Generics.

Generally speaking Java is more intrusive than C++.

In C++ you can throw anything, in Java only Throwables, but you have automatically access to the stack trace.
In C++ there is multiple inheritance of implementation and you can have "empty" classes with only pure virtual functions: in Java there are interfaces and only

Java and its core libraries cover a waste set of topics including threading/concurrency, serialization, networking, XML processing/DOM, GUI, zip/gzip compression, cryptography, CORBA, whatnot. And there is a tremendous quantity of open-source stuff around Java.

If I felt entitled to do so, I said "Welcome to Java land".

[Ivan Jozsef Balazs]

> and only

and only single inheritance of the implementation.

[Douglas Knapp]

My only input here, as a complete n00b myself, is that Thinking in Java has been released to roam free on the web. You can find it and download it without looking over your shoulder for the copyright police.

[Henry Wong]

Ivan Jozsef Balazs wrote:Sometimes differences lurk under the similar syntax.

C++ templates are different from Java Generics.

Generally speaking Java is more intrusive than C++.

In C++ you can throw anything, in Java only Throwables, but you have automatically access to the stack trace.
In C++ there is multiple inheritance of implementation and you can have "empty" classes with only pure virtual functions: in Java there are interfaces and only

Java and its core libraries cover a waste set of topics including threading/concurrency, serialization, networking, XML processing/DOM, GUI, zip/gzip compression, cryptography, CORBA, whatnot. And there is a tremendous quantity of open-source stuff around Java.

If I felt entitled to do so, I said "Welcome to Java land".

I wouldn't worry about multiple inheritance, in the many years that I have been working with C++ (and still am, but in a lesser extent), I don't think that I have really needed multiple inheritance. The only times that I used is was probably when I was still learning. Quite frankly, you can only miss stuff that you actually use -- and I am willing to bet that most C++ programmers rarely, if ever, use multiple inheritance.

Another interesting feature of C++ is operator overloading -- which BTW, I really really like. However, like multiple inheritance, it too, gets very little usage....but it is still cool nonetheless ...


In terms of features of C++ that I really miss... First, I really like the backward compatibility with C. Having done many many years in C, it is great having the C library, which I knew very well, available whenever I wanted it. And IMO, the feature which I miss most is the preprocessor. Arguably, this too cam from C. Still, I really like the capability to have conditional code. And I don't mean if/then statements that the compiler can optimize out (assuming that it even does), I mean really conditionally compiled code. You can literally control usage, down to the exact datatyoe, with the preprocessor.

Henry

[Jesper de Jong]

One important, basic difference between C++ and Java is that you have to keep in mind that in Java, a variable (of a non-primitive type) does not contain the object itself, but a reference to an object.

In C++, if you declare a variable, for example: MyClass myVariable;, then a new MyClass object is allocated and initialized. In Java, this only declares the variable; no object is created until you explicitly do that and assign it: MyClass myVariable = new MyClass();

As already said, Java has automatic memory management, so you don't have to think about freeing memory or deleting objects; the garbage collector does that automatically. That saves you a lot of time and memory leaks. (It's not impossible to have memory leaks in a Java program, but you don't easily create a memory leak just by forgetting to delete something).

[Ivan Jozsef Balazs]

> the preprocessor.

The features of the preprocessor can be seen as arguments for or against it...

<apage satanas>
A C preprocessor can preprocess Java code as well...
</apage>

[Campbell Ritchie]

Ivan Jozsef Balazs wrote: . . .
<apage satanas>
. . .
</apage>

Satanas??
There are actually all sorts of subtle differences; static and protected, final vs const, etc. Java does not support pass‑by‑reference, as I believe C++ can. You might do well to get a copy of that most excellent book, Horstmann and Cornell, which you can find here under “advanced Java”. It has lots of points of difference between C++ and Java.

[Winston Gutkowski]

Ivan Jozsef Balazs wrote:> the preprocessor.
The features of the preprocessor can be seen as arguments for or against it...

And in fact, Java may well have a pre-processor, it just doesn't tell you (and you certainly can't run it yourself).

Winston

[James Boswell]

I personally used and would recommend the Core Java series by Horstmann,Cornell.

A great set of books for any Java developer.

[Ivan Jozsef Balazs]

Campbell Ritchie wrote: Java does not support pass‑by‑reference, as I believe C++ can.

Yes, C++ does and Java does not support pass by reference. In C++ it is supported through the reference variables, a welcome and useful syntactical sugar coating around pointers.

[Winston Gutkowski]

Ivan Jozsef Balazs wrote:Yes, C++ does and Java does not support pass by reference. In C++ it is supported through the reference variables, a welcome and useful syntactical sugar coating around pointers.

Yeah, the problem for most people coming from C++ is that Java parameter behaviour when it comes to reference types looks like what you'd call "pass by reference" in C/C++, because there is no such thing as passing objects by value in Java (and TBH, it's rarely used in C++ either).

Winston

[Campbell Ritchie]

As you say, you pass the value of the reference, rather than the value of the object, so that confuses a lot of people.

[Jeff Verdegan]

Winston Gutkowski wrote:

Ivan Jozsef Balazs wrote:Yes, C++ does and Java does not support pass by reference. In C++ it is supported through the reference variables, a welcome and useful syntactical sugar coating around pointers.

Yeah, the problem for most people coming from C++ is that Java parameter behaviour when it comes to reference types looks like what you'd call "pass by reference" in C/C++

Actually, it looks more like passing a pointer by value, whether in C or C++, IMHO. Which is convenient, because that's exactly what's happening

I think one place where people coming from C++ get misled--and this has implications for how they view parameter passing--is that Foo x; in Java is more like Foo* x in C++.

[mark drakos]

I'll be starting to read a lot of the mentioned resources shortly, so thanks for all the advice!

[Winston Gutkowski]

Jeff Verdegan wrote:I think one place where people coming from C++ get misled--and this has implications for how they view parameter passing--is that Foo x; in Java is more like Foo* x in C++.

Hmmm. Not so sure there. I think it has more to do with the fact that, in C++, if I have a Customer object, I can can actually pass IT by value by simply putting 'Customer c' in my parameter list (*). C++ classes are actually mapped to specified (and, I believe, contiguous) memory, which is why there's no problem with this; whereas in Java the way an object is mapped in memory (although probably similar) is NOT specified - at least, as far as I know.

Winston

(*) Of course, it's the equivalent of what, in Java, would be called a "shallow" copy.

[Jeff Verdegan]

Winston Gutkowski wrote:

Jeff Verdegan wrote:I think one place where people coming from C++ get misled--and this has implications for how they view parameter passing--is that Foo x; in Java is more like Foo* x in C++.

Hmmm. Not so sure there. I think it has more to do with the fact that, in C++, if I have a Customer object, I can can actually pass IT by value by simply putting 'Customer c' in my parameter list

Right, because a non-primitive variable can hold an object in C++, or a struct in C, but it can only hold a reference (pointer) in java. Java's Customer c is closer to C/C++'s Customer* c than to any other idiom. In both cases, we are declaring c as a pointer to a Customer. And in both cases, when we pass c to a method, we are passing a pointer by value (unless of course that method is declared to take a reference in C++, but then I don't think we can pass c. although I'm rusty on that).

(*). C++ classes are actually mapped to specified (and, I believe, contiguous) memory, which is why there's no problem with this; whereas in Java the way an object is mapped in memory (although probably similar) is NOT specified - at least, as far as I know.

I don't see what that would have to do with variables holding objects, or passing objects by value.

[surlac surlacovich]

Henry Wong wrote: it is great having the C library, which I knew very well, available whenever I wanted it

Why not to use JNI in this case, big overhead while calling native library code?

[Winston Gutkowski]

Jeff Verdegan wrote:I don't see what that would have to do with variables holding objects, or passing objects by value.

Well, in the latter case, it means that a method call simply needs to copy a contiguous section of memory (which is, I'm pretty sure, what it actually does). If an object could be scattered, it would make the whole business of supplying an object by value darn complicated, since presumably there would then have to be some sort of mapping operation.

Winston

[Henry Wong]

surlac surlacovich wrote:

Henry Wong wrote: it is great having the C library, which I knew very well, available whenever I wanted it

Why not to use JNI in this case, big overhead while calling native library code?

First of all, this is not a comparison on which is better for calling a C library -- this is a discussion snippet from what I missed from C++ when I first started learning Java nearly twenty years ago. So, this question is orthogonal -- when I am working in Java, I rarely miss the C library now. The reverse is still true though, when I work in C, I rarely miss the Java library too. And finally ... these days, when I am working in C++ now, I try to avoid using the C library too. I find that C++ programmers tend to hate it when a C library is used. Probably related to bringing in a functional paradigm into a object oriented paradigm.


But to answer your questions... in C++, if you want to bring in a C library, you have to do an extern C, around the include of the C include files -- and that is it. In Java, if you want to bring in a C library, you have to write another C library. This new C library will have to follow the JNI standard, and act as a wrapper library -- a library that gives me the functionality that I want, and which in turn, uses the original C library that I wanted to use. Then on the Java side, I have to create a class, which loads the library that I just wrote, and provides the native interface to the C wrapper library that I just wrote..... This is not the same thing here. In C++, I can simply use the C library in 10 seconds, and if/when I find a C++ version, undo it easily too. In Java, JNI is a last resort. You have to be sure that there is no other way, as you may waste a half day if you are wrong.

Henry

[Jeff Verdegan]

Winston Gutkowski wrote:

Jeff Verdegan wrote:I don't see what that would have to do with variables holding objects, or passing objects by value.

Well, in the latter case, it means that a method call simply needs to copy a contiguous section of memory (which is, I'm pretty sure, what it actually does). If an object could be scattered, it would make the whole business of supplying an object by value darn complicated, since presumably there would then have to be some sort of mapping operation.

If there needs to be such an operation, it's already there, and used by clone().

[Jayesh A Lalwani]

If you are familiar with the STL smart pointers, then you need to remember that Java's references to objects are very very similar to smart pointers. Instances of smart pointers are objects that wrap C++ pointers. You have an object of smart pointer that you use it like it's a pointer, but it's really not. Many of the operators (->, ==) are overloaded to delegate the call to the real pointer. It also does reference counting and "garbage collection". The instance of smart pointer contains a reference count of how many smart pointers hold the actual pointer. The = operator and copy constructor is overloaded so that copying the smart pointer into another smart pointer copies the pointer and increments the count. THe destructor of the smart pointer decrements the reference count. When the reference count hits 0, the object that the pointer points to is deallocatted. SO, you don;t have to deallocate a smart pointer. You just allocate the real pointer once and give it to the smart pointer, and the smart pointer will "garbage collect" it for you.

For most practical purposes, a STL smart pointer behaves just like a Java reference. Even the specifics of "pass by reference" vs "pas by value" also becomes the same. See, when you pass a smart pointer as variable or copy it, the object of the smart pointer is copied/passed by value. The value itself holds the pointer to the real object. This is very close by how references are passed/copied in Java.

I'm sure that there are a few arcane differrences between the smart pointer and Java references. I'm sure someone is going to point out where they differ and how stupid I am. However, spending about 2 years alternating between Java and C++, smart pointer and Java reference became like the same thing in my mind. For practical purposes, they are the same thing. If you are comfortable with smart pointers, learning Java references is very easy.

[Jeff Verdegan]

Jayesh A Lalwani wrote:
For most practical purposes, a STL smart pointer behaves just like a Java reference. Even the specifics of "pass by reference" vs "pas by value" also becomes the same. See, when you pass a smart pointer as variable or copy it, the object of the smart pointer is copied/passed by value.

When you say "the object of the smart pointer is copied", you mean "the 'real' pointer that is wrapped by the the smart pointer is copied," and not "the object ultimately pointed to through the smart pointer and its target is copied," correct? That is, you're saying a pointer gets copied, not an object. Otherwise, it's most definitely not what happens in Java.

[Jayesh A Lalwani]

The copy constructor and the equal-to operator of the smart pointer are overloaded to copy the real pointer. The object that the real pointer points to doesn't get cloned

[Jeff Verdegan]

Jayesh A Lalwani wrote:The copy constructor and the equal-to operator of the smart pointer are overloaded to copy the real pointer. The object that the real pointer points to doesn't get cloned

Cool. That's what I thought you meant. It was just the "the object of the smart pointer" wording that was a bit confusing.

[Jayesh A Lalwani]

Sorry. it's confusing to describe without drawing it. See, the smart pointer is not a pointer. It is itself a normal object. It just pretends to be a pointer. By "object of smart pointer", I meant object of type smart pointer, not the object that the real pointer is pointing to.

The object of type smart pointer is copied in the equal-to operator and copy constructor. The object that the smart pointer is pointing to is not copied. The pointer to the object that the smart pointer points to is copied

Clear as mud? It's exactly like the Cup Story describes. In C++, the object is the TV, and the pointer is the remote. C++ doesn't natively provide the cup. In STL, the smart pointer is the cup. It's more than the cup actually. It also keeps track of how many other cups have a remote to the same TV, and switches off the TV when no other cups have any remotes.

[Winston Gutkowski]

Jeff Verdegan wrote:If there needs to be such an operation, it's already there, and used by clone().

Maybe we're talking at cross-purposes here. What I was describing is how C/C++ passes objects by value (which doesn't exist in Java). And it most certainly is not by cloning, nor does it mimic Java clone() behaviour - at least not back in Jurassic times when I was using the language, it didn't - it is a simple memcpy() (or equivalent).

Winston

[Jayesh A Lalwani]

The default for pass by value is memcpy, but you can define a copy constructor where you can override the pass by value behavior. You effectively implement "clone" in C++ by implementing the copy constructor

Speaking of which, C++ also has this wierd reference operator(&) that is used for parameters. When you declare a variable as a reference, it passes the object by reference but syntatically it's an object.
So,

class MyObject {
    char getState() {....}
    void foo(MYobject& other) {
           other.getState();
    }
}

is equivalent of

class MyObject {
    char getState() {....}
    void foo(MYobject* pOther) {
           pOther->getState();
    }
}

When you pass an argument where the parameter is passed by value, the copy constructor will be called; if you pass an argument where the parameter is pass by reference, it doesn't call the copy constructor since it's just passing the reference. Actually the copy constructor itself takes the other parameter as a reference.

[Winston Gutkowski]

Jayesh A Lalwani wrote:Speaking of which, C++ also has this wierd reference operator(&) that is used for parameters. When you declare a variable as a reference, it passes the object by reference but syntatically it's an object.

Yeah, I vaguely remember all that (Gawd, it's been an age...), and one of the nice things was being able to say:
foo(const MYobject& other) {
which prevented you from updating the object, even if it was mutable (though exactly how it was done, or how comprehensive it was, I forget).

Now that's one thing I do wish Java had.

Winston

[Jeff Verdegan]

Winston Gutkowski wrote:

Jeff Verdegan wrote:If there needs to be such an operation, it's already there, and used by clone().

Maybe we're talking at cross-purposes here. What I was describing is how C/C++ passes objects by value (which doesn't exist in Java). And it most certainly is not by cloning, nor does it mimic Java clone() behaviour - at least not back in Jurassic times when I was using the language, it didn't - it is a simple memcpy() (or equivalent).

Winston

That sound an awful lot like cloning to me. The only difference is that memcpy() is blind to the semantics of what it's copying and just copies a block of memory, while clone() has to actually copy the fields of an object (although it probably ends up being a memcpy() anyway).

My point was this: C++ passes an object by value by shallow-copying that object's contents, right? You said that passing an object by value would be tricky because Java objects aren't required to be contiguous in memory. I'm saying, that problem is already solved, by clone(). I don't see why you're saying Java copying an objet by clone() is not equivalent to C++ copying an object by memcpy(). As far as the programmer is concerned, the semantics are the same, even though the underlying mechanism may (or may not be) very different.

[Winston Gutkowski]

Jeff Verdegan wrote:I don't see why you're saying Java copying an objet by clone() is not equivalent to C++ copying an object by memcpy(). As far as the programmer is concerned, the semantics are the same.

Because unless you're specifically referring specifically to the action of Object.clone() (and ignoring the fact that it throws an exception), there are - as you've already conceded - semantics to the operation of which memcpy() is totally oblivious.

However, it's probably not worth pursuing. The fact is that Java doesn't have such an animal as passing objects by value; so if you're coming to it from C++ you simply need to be aware of the fact.

Winston

[Campbell Ritchie]

I often find it causes more confusion than anything else when people start saying, “Well, that’s how it works in C/C++.”
The three languages are different, and (unlike C++) Java is not a superset of any of the others.

[Winston Gutkowski]

Campbell Ritchie wrote:I often find it causes more confusion than anything else when people start saying, “Well, that’s how it works in C/C++.”
The three languages are different, and (unlike C++) Java is not a superset of any of the others.

Agreed. It is a particularly pernicious problem for people "making the jump" though, because what looks the same actually behaves very differently.

Winston

[Ivan Jozsef Balazs]

Right, because a non-primitive variable can hold an object in C++,

Actually the distinction between "primitive" and other types is pertinent to Java.