String literal
stef
IMHO the assignment of a literal to a string class (String s =
"Hello";) is... amazing for an strongly oriented object language like
Java. I mean, In opposition to C++ (for example) Java doesn't
implement that kind of constructor (operator =)
On the other side, it seems that String s = <literal> is treated like
a primitive assignment, but... it stills a class :)
This "trick" has been implemented to get better performance (see
Intern() method) ?
thanks...
Joshua Cranmer
> IMHO the assignment of a literal to a string class (String s =
> "Hello";) is... amazing for an strongly oriented object language like
> Java. I mean, In opposition to C++ (for example) Java doesn't
> implement that kind of constructor (operator =)
Not really. You're assigning a String literal to a... String object.
What's "amazing" is that Java doesn't treat int, etc., as subtypes of
Object, which was a really bad idea in retrospect (auto{un}boxing
mitigates this to some degree, though).
Also, the lack of an assignment operator or copy constructor can be
traced probably most closely to the fact that Java treats all objects as
if they were on the heap instead of differentiating between stack-based,
dies-on-scope-close objects and objects on the heap (or statically
initialized). With the fact that Java is more statically-typed than C++
playing a little role, too.
> On the other side, it seems that String s = <literal> is treated like
> a primitive assignment, but... it stills a class :)
Modern OO design tends to agree that the distinction between primitive
types and the inheritance tree is a bad one.
> This "trick" has been implemented to get better performance (see
> Intern() method) ?
What method would you do instead of String s = "Hello"? String s = new
String(new char[] {'S', 't', 'r', 'i', 'n', 'g'})? It's not for better
performance, it's for basic common sense. As I keep reiterating, it's
int and friends that are ultimately broken, not String.
And String.intern() is a different matter altogether whose relationship
to string literals is not its important characteristic.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Mike Schilling
> Hello,
>
> IMHO the assignment of a literal to a string class (String s =
> "Hello";) is... amazing for an strongly oriented object language
> like
> Java. I mean, In opposition to C++ (for example) Java doesn't
> implement that kind of constructor (operator =)
It's precisely the same as C++'s
char *s = "Hello";
>
> On the other side, it seems that String s = <literal> is treated
> like
> a primitive assignment, but... it stills a class :)
In
String s = "Hello":
"s" is a reference and "Hello" and object. The statement makes "s"
refer to "Hello". This is no different from any other assignment
statement in Java where the left-hand side is a reference and the
right-hand side is non-null.
Patricia Shanahan
There is no trick, but something really, really important and basic.
"String s" does not declare a variable that can hold an object. It
declares what Java calls a "reference". A reference is either null or a
pointer to an object of appropriate class for its type.
In your example, s is either null or a pointer to a String object. The
"Hello" initializer makes it a pointer to the interned String object
representing the literal "Hello".
Subsequent assignments to s do not operate on the object representing
the "Hello" object. They can make s point to a different String, or be null.
Patricia
Arne Vajhøj
> IMHO the assignment of a literal to a string class (String s =
> "Hello";) is... amazing for an strongly oriented object language like
> Java. I mean, In opposition to C++ (for example) Java doesn't
> implement that kind of constructor (operator =)
>
> On the other side, it seems that String s = <literal> is treated like
> a primitive assignment, but... it stills a class :)
I do not see the point at all.
In Java you can assign one ref to another ref (if the types
are assignable).
String s is a ref to a String.
"Hello" is a ref to a string.
It seems very obvious to me that:
- they can be assigned
- it is the exact same thing as all other assignments
Arne
Lew
>> IMHO the assignment of a literal to a string class (String s =
>> "Hello";) is... amazing for an strongly oriented object language like
The literal is not assigned to a class but to a variable.
>> Java. I mean, In opposition to C++ (for example) Java doesn't
>> implement that kind of constructor (operator =)
Java doesn't do anything in opposition to C++. It is not useful to compare
the language's syntax that way.
>> On the other side, it seems that String s = <literal> is treated like
>> a primitive assignment, but... it stills a class :)
'String' is a class. 's' is a variable and the "literal" is an object.
What do you mean that it's "treated like a primitive assignment"? As Patricia
and others explained, that really isn't true - it is treated like any other
object reference assignment.
>> This "trick" has been implemented to get better performance (see
>> Intern() method) ?
The 'java.lang.String' class does not have an 'Intern()' method.
Patricia Shanahan wrote:
> There is no trick, but something really, really important and basic.
>
> "String s" does not declare a variable that can hold an object. It
> declares what Java calls a "reference". A reference is either null or a
> pointer to an object of appropriate class for its type.
>
> In your example, s is either null or a pointer to a String object. The
> "Hello" initializer makes it a pointer to the interned String object
> representing the literal "Hello".
>
> Subsequent assignments to s do not operate on the object representing
> the "Hello" object. They can make s point to a different String, or be
> null.
And thus the assignment is just like any other object reference assignment,
and not at all like a primitive assignment.
--
Lew
Roedy Green
<stef.pe...@gmail.com> wrote, quoted or indirectly quoted someone
who said :
I had a heck of a time learning Java because I presumed it worked
under the covers just like C++ because the syntax so resembled C++.
The JVM is much simplified from the C++ world. Logically ALL objects
live on the heap, never embedded in other objects, never on the stack.
Of course the compiler or run time is free to put them whereever it
pleases, but logically they are all heap based. You deal only with
references to objects, never with the objects themselves.
See http://mindprod.com/jgloss/cpp.html
to help you get your head around the Java way of thinking.
"xxxx" is sort of magic constructor that runs at compile time and
arranges for a constant string literal object to be placed in a pool.
The string variable
s = "xxxx"; contains only a pointer to the string (called a reference
in Java and usually 32 bits) not the string itself.
Strings are immutable in Java. Instead of modifying them as you do in
C++, you allocate/create new ones, and point to them, usually using a
StringBuilder, which behaves much more like a traditional C++ string.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
stef
My way of thinking was wrong (I'm a stubborn C++ programmer)
I just didn't really think about "Hello world" as an object.
thanks...
Chronic Philharmonic
"stef" <stef.pe...@gmail.com> wrote in message
news:6f9e3508-e3c5-4a0b...@d45g2000hsc.googlegroups.com...
> Ok,
> My way of thinking was wrong (I'm a stubborn C++ programmer)
> I just didn't really think about "Hello world" as an object.
Which means you can say:
boolean isEqual = "Hello world".equals(args[0]);
where isEqual will be true if the first argument on the command line happens
to be "Hello world".
Lew
String is a reference type and is clearly documented as such.
Javadocs:
> public final class String
> extends Object
> implements Serializable, Comparable<String>, CharSequence
<http://java.sun.com/javase/6/docs/api/java/lang/String.html>
JLS:
> A string literal is always of type String (§4.3.3).
> A string literal always refers to the same instance (§4.3.1) of class String.
<http://java.sun.com/docs/books/jls/third_edition/html/
lexical.html#3.10.5>
and
"4.3 Reference Types and Values"
<http://java.sun.com/docs/books/jls/third_edition/html/
typesValues.html#4.3>
includes
"4.3.3 The Class String"
<http://java.sun.com/docs/books/jls/third_edition/html/
typesValues.html#4.3.3>
Then of course there's the Java tutorial:
> The String class is not technically a primitive data type,
and
<http://java.sun.com/docs/books/tutorial/java/data/index.html>
> In the Java programming language, strings are objects.
with a link to more detail:
> In this case, "Hello world!" is a string literal
> — a series of characters in your code that is enclosed in double quotes.
> Whenever it encounters a string literal in your code, the compiler
> creates a String object with its value—in this case, Hello world!.
With all that information provided at the very beginning of the Java
learning curve, one should never make the mistake that they 'just
didn't really think about "Hello world" as an object.'
--
Lew
Arne Vajhøj
Practically no beginners reads the API docs & tutorial
so carefully that they will note that type of details
or read JLS at all.
Arne
Lew
> Practically no beginners reads the API docs & tutorial
> so carefully that they will note that type of details
> or read JLS at all.
I beg to differ. First of all, the nature of Strings as objects is
fundamental and brought up in absolutely every tutorial and introduction to
Java that I've encountered. If a beginner does any research whatsoever into
Java, it must be one of the very first factoids they encounter, just as it is
in the section of the Sun tutorial devoted to the nature of Strings. They
also mention it promptly in the section on primitives, just so you won't be
led astray.
Now if you said, "Practically no beginners read the API docs and tutorial,"
and left it at that, we'd be on to something.
Perhaps any beginners reading this should take all this brouhaha as a strong
hint to read the tutorials, the API docs, the JLS (yes, it's thick, but it's
informative) along with the plethora of free articles on IBM DeveloperWorks,
Sun's java.sun.com, and elsewhere.
Making excuses for them not to is hardly empowering.
--
Lew
stef
As I said before, it's my fault !
I'm not as smart as you. :(
Lew
> I'm not as smart as you. :(
Likely you are smarter than I.
--
Lew
Eric Sosman
Stef, you've been fooled by the Dubious Dweeby Doppelgänger,
a person for whom the act of forging an address on a Usenet posting
seems endlessly entertaining. The thrill of address forgery is a
brief phase for most children, but DDD seems stuck in emotional
infancy and may remain there until the onset of puberty, perhaps
even beyond. We'll have to wait and see.
In the meantime, when you see a message that seems out of
character for its supposed author, you'd be well-advised to check
the headers before taking offense. Chances are it's just DDD.
Patricia Shanahan
...
> In the meantime, when you see a message that seems out of
> character for its supposed author, you'd be well-advised to check
> the headers before taking offense. Chances are it's just DDD.
I've also noticed that these messages have times that are inconsistent
with the order in which they were received. Once I hit one fake message,
I ignore a block of messages, beginning with it, with the same author
and suspicious posting times.
Patricia
Lew
> > Ok Lew, Calm down...
> > As I said before, it's my fault !
>
> > I'm not as smart as you. :(
Eric Sosman wrote:
> Stef, you've been fooled by the Dubious Dweeby Doppelgänger,
> a person for whom the act of forging an address on a Usenet posting
> seems endlessly entertaining. The thrill of address forgery is a
> brief phase for most children, but DDD seems stuck in emotional
> infancy and may remain there until the onset of puberty, perhaps
> even beyond. We'll have to wait and see.
>
> In the meantime, when you see a message that seems out of
> character for its supposed author, you'd be well-advised to check
> the headers before taking offense. Chances are it's just DDD.
Not having seen the fake post myself which apparently you have seen, I
had assumed stef was responding to my actual post. I could see how
someone might have sought to avoid the lesson by objecting to the tone
of it. The real message is to actually read the documentation.
There's no need for self-deprecating remarks about intelligence or
having been a C++ programmer - the point is that the tutorials and API
docs blatantly reveal the answer to the OP's question and many
others. One is not a bad person for not having read them, so there is
no need for defense unless one is also refusing to rectify the error.
--
Lew
stef
> > Stef, you've been fooled by the Dubious Dweeby Doppelgänger,
Yes Eric, I think so ;)
> > a person for whom the act of forging an address on a Usenet posting
> > seems endlessly entertaining. The thrill of address forgery is a
> > brief phase for most children, but DDD seems stuck in emotional
> > infancy and may remain there until the onset of puberty, perhaps
> > even beyond. We'll have to wait and see.
>
> > In the meantime, when you see a message that seems out of
> > character for its supposed author, you'd be well-advised to check
> > the headers before taking offense. Chances are it's just DDD.
>
> Not having seen the fake post myself which apparently you have seen, I
> had assumed stef was responding to my actual post. I could see how
> someone might have sought to avoid the lesson by objecting to the tone
> of it. The real message is to actually read the documentation.
Ok Lew, so a simple "read the doc" was enough ;)
> There's no need for self-deprecating remarks about intelligence or
> having been a C++ programmer - the point is that the tutorials and API
> docs blatantly reveal the answer to the OP's question and many
> others. One is not a bad person for not having read them, so there is
> no need for defense unless one is also refusing to rectify the error.
You do it again :)
see ya...
Lew
> You do it again :)
No harm offered.
--
Lew
Arne Vajhøj
A beginner spend his/her time trying to get the compiler working,
figuring out how to write hello world program, data types in Java,
control structures in Java. All the language lawyer stuff comes
after N years.
Arne
Lew
> A beginner spend his/her time trying to get the compiler working,
> figuring out how to write hello world program, data types in Java,
> control structures in Java. All the language lawyer stuff comes
> after N years.
That String is a class and its instances objects is pretty fundamental and
introductory to be calling it "language lawyer stuff". A pejorative
appellation does not diminish the importance of the distinction.
--
Lew
Chronic Philharmonic
"Eric Sosman" <Eric....@sun.com> wrote in message
news:1216998569.970902@news1nwk...
And from what I can see, the DDD dork is using an automated mad-lib program
of sorts. I am not even sure he/she/it is actively aware of the messages
being sent. I wonder if the dorkbot was written in Java, or if he/she/it is
just a stupid script kiddie.