11–20 of 327 posts
> if you wanted to store an integer in a collection, you had to manually convert to and from the primitive int type and the Integer “boxed” class I have never worked with Java. What is this? Why would one want to have a class for an Integer?
It's because the collection types (and generics) don't support primitives, only objects. So you been to stuff the primitives into objects to use them with a lot of the standard library.
Can someone explain why developers like var?
> if you wanted to store an integer in a collection, you had to manually convert to and from the primitive int type and the Integer “boxed” class I have never worked with Java. What is this? Why would one want to have a class for an Integer?
If a primitive value must be treated as an object (e.g., when stored in a Java Collection like ArrayList or when passed to a method that requires an object), Java uses a process called `boxing` to wrap the primitive value into an instance of its corresponding Wrapper class (e.g., Integer, Boolean, Double). These Wrapper objects are allocated on the heap and do possess the necessary object header, making them subject to the GC's management.
> if you wanted to store an integer in a collection, you had to manually convert to and from the primitive int type and the Integer “boxed” class I have never worked with Java. What is this? Why would one want to have a class for an Integer?
It's because the collection types (and generics) don't support primitives, only objects. So you been to stuff the primitives into objects to use them with a lot of the standard library.
i.e. something like:
Integer x = 42
highlyQuestionableCode(x);
println(x); // "24" WAT?
Earlier quoted context omitted.
It's because the collection types (and generics) don't support primitives, only objects. So you been to stuff the primitives into objects to use them with a lot of the standard library.
That doesn't sound very pleasant.
// Before autoboxing
list.add(new Integer(42));
// After autoboxing
list.add(42);
I really like the feature, and it's really one of the features I feel Java got right.
The syntax is very expressive, and they can easily be made to generate meaningful exceptions when they fail.
It's also neat that it gives the language a canonical way of adding invariant checks that can be removed in production but run in tests or during testing or debugging (with -da vs -ea).
You could achieve similar things with if statements, and likely get similar performance characteristics eventually out of C2, but this way it would be harder to distinguish business logic from invariant checking. You'd also likely end up with different authors implementing their own toggles for these pseudo-assertions.
Earlier quoted context omitted.
It's because the collection types (and generics) don't support primitives, only objects. So you been to stuff the primitives into objects to use them with a lot of the standard library.
That doesn't sound very pleasant.
Can someone explain why developers like var?