Confused beginner - 1 != 1
I'm new to Java, and I'm very confused. I'm playing with Tomcat and Beans to try to give myself a flavour of the language.
Basically, I had my jsp page that did this...
<jsp:useBean id="test" class="imc.navbean" scope="page" />
<jsp:setProperty name="test" property="nonav" param="nonav"/>
....
<%= test.internalnav("Products") %>
So I'm creating a bean, and passing a property (nonav) to it, and then calling a function on it (internalnav). Page address will be, for example
http://testserver:8080/x.jsp?nonav=1
I had a test in the bean to check whether to output navigation information - the idea is, if nonav==1 then no navigation is produced, so here was my code:
if(nonav == "1"){
InternalNav = "";
return(InternalNav();
}
InternalNav = "testing navigation, nonav = " + nonav;
return(InternalNav);
BUT, this test did not work! nonav was passed correctly, I consistently got the message:
testing navigation, nonav = 1
via the browser.
So, why does 1 != 1 in this case?
I eventually fixed it by using what looks like a horrible hack to me:
if(nonav.compareTo("1".toString())==0){
This kind of thing is likely to put me off java, if I have to continually do inelegant things like that, just to check if one string matches another.
[1391 byte] By [
BigCalma] at [2007-10-2 2:08:11]
[snip]
>
> This kind of thing is likely to put me off java, if I
> have to continually do inelegant things like that,
> just to check if one string matches another.
Or you could remember that Java is Object Oriented, and wonder if the responsibility for determining equality would be found in the String class, check the javadoc for that class and then hit the "equals" method. To compare String values for equality, useif (myString.equals(yourString))
Good Luck
Lee
tsitha at 2007-7-15 19:49:38 >
When comparing Strings you need to use equals() or compareTo(). The == really just checks the address of the String.
Are you saying that you can't doif("Hello"=="Hello"){in Java then?you have to do if("Hello".equals("Hello")){instead?
> Are you saying that you can't do
>
> if("Hello"=="Hello"){
>
> in Java then?
You can, of course. And in the case you just presented, it would even give you the results you wanted (true). But if you want to check whether one String's value is equal to another, you use the equals() method provided by the String class. If you are interested in whether one reference refers to the same instance as another Object, you use the == operator.
tsitha at 2007-7-15 19:49:38 >
> Are you saying that you can't do
>
> if("Hello"=="Hello"){
>
> in Java then?
>
> you have to do
>
> if("Hello".equals("Hello")){
>
> instead?
Well, its not that simple.
if("Hello"=="Hello")
will be true but only because both the Strings are the same object. String literals are kept in a pool and are shared.
You should always use String.equals() if you want to compare the contents of two String objects.
String s1 = new String("Hello");
String s2 = new String("Hello");
if (s1==s2)
will be false.
You need to research the difference between equality and identity. Two objects can be considered equal even if they are not the same object.
Search these forums for a lot of info on this.
jbisha at 2007-7-15 19:49:38 >
> Are you saying that you can't do
>
> if("Hello"=="Hello"){
>
> in Java then?
>
> you have to do
>
> if("Hello".equals("Hello")){
>
> instead?
Sun has a tech tip article that explains how string equality works in Java:
http://java.sun.com/developer/JDCTechTips/2004/tt0504.html#2
Just read that article, thankyou.
Does anyone use == except for pure object comparison then? I can see myself never using it to compare strings, integers, any sort of primitive type now.
I know Java cured the 'C' problem of a difference between '=' and '==', but surely this creates a whole new range of potential confusions.
> Does anyone use == except for pure object comparison then? I can see myself never using it to compare strings, integers, any sort of primitive type now.
You MUST use "==" to compare primitives.
> I know Java cured the 'C' problem of a difference between '=' and '==', but surely this creates a whole new range of potential confusions.
I don't know what you mean there. In some cases (with booleans for sure, and maybe other types), you can still get errors by mistakenly typing "=" instead of "==" or vice versa.
MLRona at 2007-7-15 19:49:38 >
> Does anyone use == except for pure object comparison
And primative comparison.
And if you want to find out if two objects are the same object. I.e.
class Test {
void process( Test t ) {
if( t == this ) throw new CanNotBeRunOnSelfWobbly();
}
}
> I know Java cured the 'C' problem of a difference
> between '=' and '==', but surely this creates a whole
You sure?
boolean f = true;
boolean x = false;
if( x = f ) { .. }
The difference is if in C takes any value, and uses 0 as false, anything else as true. In Java if HAS to take a boolean.
> new range of potential confusions.
Not really. It you want primatives, or refrence equaility, use ==, if you want to know if two objects are logically equial, use .equals.
mlka at 2007-7-15 19:49:38 >
> I know Java cured the 'C' problem of a difference between '=' and '==',
Nope, Java didn't 'cure' this 'problem' (it's just a notational inconveniece
after all) but it reduced the 'problem' to the boolean domain:boolean flag= false;
if (flag == true)
neverExecuted();
if (flag= true)
alwaysExecuted();
kind regards,
Jos
JosAHa at 2007-7-15 19:49:38 >
> > Does anyone use == except for pure object
> comparison then? I can see myself never using it to
> compare strings, integers, any sort of primitive type
> now.
>
> You MUST use "==" to compare primitives.
Sigh.....except with autoboxing now one might actually end up comparing Integer instead of int and not even know it. So one should at least keep the small possibility of that problem occurring in mind.
> > You MUST use "==" to compare primitives.
>
> Sigh.....except with autoboxing now one might actually end up comparing Integer instead of int and
> not even know it. So one should at least keep the small possibility of that problem occurring in mind.
Just go back to 1.3 like we are stuck at, and you don't get any problems with autoboxing. You just get a lot of other problems, and are missing a lot of enhancements. :(
MLRona at 2007-7-15 19:49:38 >
> Sigh.....except with autoboxing now one might
> actually end up comparing Integer instead of int and
> not even know it. So one should at least keep the
> small possibility of that problem occurring in mind.
Can't you add a @supress("evil_autoboxing") annotation?
mlka at 2007-7-15 19:49:38 >
> > Sigh.....except with autoboxing now one might
> > actually end up comparing Integer instead of int and
> > not even know it. So one should at least keep the
> > small possibility of that problem occurring in
> mind.
>
> Can't you add a @supress("evil_autoboxing")
> annotation?
If only, except annotations weren't supposed to change what code was output, although I seem to recall that that restriction is going away.
