× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: learning Java
  • From: dawall@xxxxxxxxxx
  • Date: Tue, 18 Apr 2000 08:40:21 -0500

I can see this thread going two ways.  One is how many String objects are
created.  The other is how can I tell if two sequences of characters are
the same.  Let me add one more thing on the second question.  The String
class has methods (three are .equals(), equalsIgnoreCase(), and
compareTo()) to determine if the content of two strings is the same.  I
tend to use these methods instead of "==" because they deal with the actual
characters of the object instead of looking just at the object.
equalsIgnoreCase() is especially useful since Java is highly case
sensitive.  In Java "Hello" == "hello" is false.

David Wall
AS/400 Toolbox for Java


Timothy Sullivan <TSullivan@computer-guidance.com> on 04/17/2000 08:31:13
PM

Please respond to JAVA400-L@midrange.com

To:   JAVA400-L@midrange.com
cc:
Subject:  RE: learning Java




Hello,
The Java Language Specification talks about String and String Literals
(i.e.
" Something in quotes within the code").   Basically, to meet the
specification a Java compiler must "pool" literal strings.  See String
Literals at http://java.sun.com/docs/books/jls/html/3.doc.html#101083 .

The following test code was pulled from the specification.  Noticed that
concatenated literals are also pooled at compile time.  Also, notice that
pooling is true regardless of whether a String is in the same class or
package.

----- FROM SPECIFICATION  Section 3.10.5  ---
package testPackage;

class Test {
public static void main(String[] args) {
   String hello = "Hello", lo = "lo";
   System.out.print((hello == "Hello") + " ");
   System.out.print((Other.hello == hello) + " ");
   System.out.print((other.Other.hello == hello) + " ");
   System.out.print((hello == ("Hel"+"lo")) + " ");
   System.out.print((hello == ("Hel"+lo)) + " ");
   System.out.println(hello == ("Hel"+lo).intern());
}
}

class Other { static String hello = "Hello"; }
and the compilation unit:

package other;
public class Other { static String hello = "Hello"; }

produces the output:
  true true true true false true

This example illustrates six points:

* Literal strings within the same class in the same package  represent
references to the same String object
* Literal strings within different classes in the same package represent
references to the same String object.
* Literal strings within different classes in different packages likewise
represent references to the same String object.
* Strings computed by constant expressions are computed at compile time and
then treated as if they were literals.
* Strings computed at run time are newly created and therefore distinct.
* The result of explicitly interning a computed string is the same string
as
any pre-existing literal string with the same contents.

Hope, the example clears things up.  The good thing is that the
Specification is detailed enough that you can count on this behavior even
if
you use different compilers or JVMs.

/Tim

> -----Original Message-----
> From:   Mike Perez [SMTP:MPEREZ@grinfire.com]
> Sent:   Monday, April 17, 2000 11:59 AM
> To:     'JAVA400-L@midrange.com'
> Subject:     RE: learning Java
>
> Joe,
> my background is RPG as well, and I too found the String-Pool process
> confusing. What has helped me the most is seeing if the "new" keyword was
> used when the variables were defined. If either or both variables are
> defined with "new", then the "==" test will be false for the reason you
> stated in point#1.
>
> As far as I know(CMA), the string pool is always in effect, regardless of
> where the string is created, and only works for string objects.  If your
> compare can "see" both variables, and neither variable was defined with
> "new", then the "==" test will work.   For a test, create a class and
> subclass it.  Put a static String var in each class, then try comparing
> them
> in your main method.
>
> Here's an example:
>
> class Test {
>    static String s2 = "Test";
> }
>
> public class TestThis extends Test {
>    static String s1 = "Test";
>    public static void main(String[] args) {
>         if(s1.equals(s2)) {
>              System.out.println("String equals");
>         }
>
>         if(s1 == s2) {
>              System.out.println("String == ");
>         }
>    }
> }
>
> Hope this helps,
> Mike
>
>
> -----Original Message-----
> From: Joe Teff [mailto:joeteff@earthlink.net]
> Sent: Saturday, April 15, 2000 10:47 AM
> To: JAVA400-L@midrange.com
> Subject: learning Java
>
>
> I have been spending a lot of time lately learning Java, but have run
> across a couple of things I don't understand. My background is RPG
> and I don't know C or C++.
>
> 1. String x = "100"; String y = "100"; if (x == y) {};
>      In this case I thought x would not equal y since they refer to
> different
>      objects and different memory locations. The book says that they do
>      match because the compiler re-uses the same String object if it sees
>      the contents match. Is this true only for String objects or other
> objects
>      treated the same way? Is this true for only String objects in the
> same
>      class or does this optimization occur across classes?
>
>  2. String x = "abc"; String y = "abc"; x  += "def";
>      I assume that after the first two statements, both x and y point to
> the
>      same memory location. After the third statement, there are actually
>      two objects with different memory locations (x being "abcdef" and y
>      being "abc").
>
> Joe Teff
>
> +---
> | This is the JAVA/400 Mailing List!
> | To submit a new message, send your mail to JAVA400-L@midrange.com.
> | To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> JAVA400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner: joe@zappie.net
> +---
> +---
> | This is the JAVA/400 Mailing List!
> | To submit a new message, send your mail to JAVA400-L@midrange.com.
> | To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> JAVA400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner: joe@zappie.net
> +---
+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---



+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.