Wrapper class are just fine and their purpose is also well understood. But why do we omit the primitive type ?
String is non-primitive because only class can have methods. Primitive can not. And String need many functions to be called upon while processing like substring, indexof, equals, touppercase. It would not have been possible without making it class.
because it's a class and not a primitive data type. String is effectively an array of characters.
Unlike int , char etc which are primitive data types, String is a derived datatype as it is derived from primitives (in this case char ). After all String is an array of characters ( char[] ). A Java String is an object of the class java.
String[] and String... are the same thing internally, i. e., an array of Strings. The difference is that when you use a varargs parameter ( String... ) you can call the method like: public void myMethod( String... foo ) { // do something // foo is an array (String[]) internally System.
"Primitive" in Java is usually taken to mean "value type". However, C# has a string
keyword, which acts exactly the same as Java's String, it's just highlighted differently by the editor. They are aliases for the classes System.String
or java.lang.String
. String is not a value type in either language, so in this way it's not a primitive.
If by "primitive" you mean built into the language, then String is a primitive. It just uses a capital letter. String literals (those things in quotes) are automatically converted to System.String
and + is used for concatenation. So by this token, they (and Arrays) are as primitive as ints, longs, etc.
String is not a wrapper. String is a reference type, while primitive types are value types. The means that if you have:
int x = 5;
int y = x;
The memory of x and y both contain "5". But with:
String x = "a";
String y = x;
The memory of x and y both contain a pointer to the character "a" (and a length, an offset, a ClassInfo pointer, and a monitor). Strings behave like a primitive because they're immutable, so it's usually not an issue, however if you, say, used reflection to change the contents of the string (don't do this!), both x and y would see the change. In fact if you have:
char[] x = "a".toCharArray();
char[] y = x;
x[0] = 'b';
System.out.println(y[0] == 'b'); // prints "true"
So don't just use char[] (unless this is the behavior you want, or you're really trying to reduce memory usage).
Every Object
is a reference type -- that means all classes you write, every class in the framework, and even arrays. The only things that are value types are the simple numeric types (int, long, short, byte, float, double, char, bool, etc.)
There are a couple reasons for this, but it mostly comes down to psychology and implementation details:
Basically, performance and implementation details, as well as the complexity of having 2 different string types. Other value types have a fixed memory footprint. An int is always 32 bits, a long is always 64 bits, a bool is always 1 bit, etc.2 Among other things, this means that they can be stored on the stack, so that all parameters to a function live in one place. Also, making gigantic copies of strings all over the place would kill performance.
See also: In C#, why is String a reference type that behaves like a value type?. Refers to .NET, but this is just as applicable in Java.
1 - In C/C++ and other natively-compiled languages, this is true because they are placed in the code segment of the process, which the OS usually stops you from editing. In Java, this is actually usually untrue, since the JVM loads the class files onto the heap, so you could edit a string there. However, there's no reason a Java program couldn't be compiled natively (there are tools which do this), and some architectures (notably some versions of ARM) do directly execute Java bytecode.
2 - In practice, some of these types are a different size at the machine level. E.x. bools are stored as WORD-size on the stack (32 bits on x86, 64 bits on x64). In classes/arrays they may be treated differently. This is all an implementation detail that's left up to the JVM -- the spec says bools are either true or false and the machine can figure out how to do it.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With