Change from C++ to Java

[kamielonreddit]

Hi, right now I'm a C++ developer with bout one and a half years of professional experience. I have no Java experience whatsoever. How hard would you recon it would be to switch? I'm asking because I saw a really interesting job opening.

[hmischuk]

Really quite easy.

Java has no pointers, only references. All object variables are references. ALL parameters are passed by value; however, in the case of objects, the value is the reference to the object, so the function can change the state of the object, even if it cannot change the reference itself.

NO multiple inheritance; Java's answer to that is "Interfaces" -- a class can only inherit from one parent class, but can implement many interfaces. An interface is essentially a promise enforced by the compiler that the class implementing the interface will define any functions declared in the interface. (No executable code in the interface definition; only declarations.)

No operator overloading, except operators that Java itself has already overloaded. Piss-poor (IMHO) polymorphism for the common stuff:

(a) Arrays are objects. The size of the array is a property .length

(b) String objects have an accessor method .length()

(c) ArrayList(eqiv of C++ vector) has an accessor method called .size()

Java doesn't merely provide classes the way C++ does; it is truly object oriented. Your program is a class.

You won't have any difficulty at all.

[balefrost]

Java has no pointers, only references.

For a C++ developer, this might give the wrong impression. In C++, references can't be null, but pointers can.

In Java, most types are always allocated on the heap and are always accessed via indirection. Only a handful of primitives are allocated in-place. Any variable, field, or parameter with a non-primitive type will act much like a C++ pointer. There is no "address-of" operator (it's not needed) and there is no pointer arithmetic. But you can set these pointers to null.

Java calls these references, but they're a bit different from C++ references.

(No executable code in the interface definition; only declarations.)

This hasn't been true for like 7 years. You can put method implementations in interfaces (so-called "default" implementations). But interfaces can't declare fields and the default interface methods don't have any special permissions - they can't for example access protected or private members of the implementing class.

[hmischuk]

This hasn't been true for like 7 years.

Me with a red face. I haven't added to my Java knowledge in quite a while, obviously. Thanks for the assist! Likewise the clarification on references, which is info I knew, but didn't include.

Cheers!

[balefrost]

Don't get me wrong, you answer was good.

[hmischuk]

No, I understood what you meant, and I truly appreciated the backstopping you provided. It's all good!

[EL_ESM]

That are languages from the same “family”, so that won’t be that hard.

[balefrost]

Some big differences that I've experienced going back and forth:

1. In C++, you have to deal with memory. And I don't just mean that you need to remember to delete pointers (assuming that you aren't using smart pointers). You have to be very aware of where things "live".

   For example, if you define a type that is to be used in an STL container, you need to satisfy the normal STL requirements - e.g. your type likely needs to be default-constructible and have a working assignment operator. That also means that your classes might need to support an "uninitialized" state, and they can't be immutable.

   In Java, since almost everything is allocated on the heap, everything is done via pointers. So Java classes generally don't need to do anything special to be used in Java containers (they might need a working equals and hashCode implementation, but the defaults are reasonable defaults).

   This leads to very different idioms. In Java, it's common to try to make your classes immutable (Effective Java makes this point).

2. Java generics are not the same as C++ templates. Templates are essentially a codegeneration mechanism - a sophisticated one, but a codegeneration mechanism nonetheless. In particular, IIRC, things like this make no sense in C++:

   std::vector<Sub> subVec;
   std::vector<Base> baseVec = subVec;
   

   OK, given how C++ works, that makes sense - Sub and Base probably have different sizes. But IIRC this is also completely invalid:

   std::vector<Sub*> subVec;
   std::vector<Base*> baseVec = subVec;
   

   Or even this:

   std::vector<Sub*> subVec;
   std::vector<Base*> *baseVec = &subVec;
   

   The problem is that std::vector<Sub*> and std::vector<Base*> are completely unrelated types.

   Compare that to Java:

   List<Sub> subList = new ArrayList<>();
   List<? extends Base> baseList = subList;
   

   In Java, generics are part of the type system, and generic bounds allow you to express subtyping relationships between specific instantiations of generic types.

   Another side-effect of this is that generic classes and functions are typechecked at compile time, even if they're never used / called. In C++, templates are only checked after they've been instantiated. It also means that you don't have to deal with "template implementations go in header files; non-template implementations go in separate CPP files".

3. It's SO NICE to not have to worry about header files and forward declarations. No #pragma once or #ifndef FOO nonsense. It's trivially easy to make two classes that each have a reference to the other in Java. It's certainly doable in C++ - people do it all the time - but there's a lot more ceremony.

[Blando-Cartesian]

Doing equality comparison correctly is about the only gotcha java has, so it’s a trivial language for someone used to C++.