Hello,
please point me to the approprate post (or website), if this has answered before - the search function unfortunately did not spill out anything usable.
I wonder if it is better to use primitive types instead of the boxed versions, when possible, and just convert if neccessary, ie. favorint int over Integer.
Or is generally using the boxed versions not that much of an overhead?
This depends a lot on what you’re using them for, but in general:
The primitives are faster and take up less memory. Only used the boxed versions when you absolutely need objects. (Like for storing integers in a hashmap).
As always with programming, there are exceptions. 
I usually let the case “does null make sense as a value” decide.
Then again I hope we get something like @NotNull and vm optimalisations to make primitives obsolete. They are somewhat of a workaround…
Goodness no! Primitives aren’t objects.
Cas 
I don’t think they are.
Without primitives, java would get fairly weird. How would you implement an Integer class without an int?
Would “12” become an Integer literal instead of an int literal? It’d degenerate into the same mess Strings are in where we have to use “if (12.equals(myInt))” instead of “if (myInt==12)”
Primitives are probably more a conscious design decision, both to make the jvm able to run faster by allowing it to make more assumptions, and to make the language easier.
What’s missing in java are both references to primitives and any way to abstract references to different primitives. There’s some casting and (auto)boxing going on, but it’s not really elegant or efficient.
We need proper template support in the compiler!
[disclaimer: I am aware that it’s possible to design a pure OO language with no primitives]
heh ;D
Hmm yeah I did forget about object identity, that would get annoying wouldn’t it… and I don’t mean having to call equals.
var x = 100++; ???
Not sure I get it. Are you saying that you’d like to be able to do that, or that it would be Evil?
To me, the immutability of an object is a separate matter from whether it follows primitive or object semantics, and the immutability of a literal should make that code snippet illegal, not the fact that integers are primitives.
I think Scala pretty much gets it right - everything is an object as far as the language is concerned (even integer literals effectively have methods, for instance 0.until(100) generates a list from 0 to 99), but under the hood optimizations are applied so that there’s not too much autoboxing going on if it’s not necessary.
It’s only comfortable there because operator overloading and infix notation are allowed, though.
My main object vs. primitive gripe in Java is that primitives are “blessed” by the language, in the sense that you can’t define your own, you just have to be thankful for the few that you have (and there are too few - if we can’t define our own, we should at least have complex and arbitrary precision floats/ints, if not vectors and matrices as well). To be fair, this is true in Scala as well, you can’t define your own types and get the performance benefits of primitive types. But at least you can get the same semantics and ease of use, which is a huge win if you ever need to use more complicated number objects.
I learn operator overloading in C++ some months ago and I didn’t really like it. Sure you have more possibility with that but it just make it harder to understand the code…
Ofcourse that’d be evil.
I was just failing to point out that more freedom is not always a good thing.