NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Andrew Donaldson wrote: > I've been comparing RealTypes a bit, and it has just stopped working. > I'm assuming that it's ok to use == on RealTypes as they seem to be > a global sort of thing. I am interested in testing the equality > of the name and units etc, so I'm not using RealType.equals(). > > The problem is that the comparison's behaviour changes after > I create a DefaultFamily. > > The code below shows this (at least for me!), remove the commented > out line to change what it prints. > > Is my assumption bad, or is DefaultFamily doing something bad? The immediate problem is due to the visad.data.netcdf.Plain creating its own version of the Latitude type based on the Quantity class, which lets it add a Unit to the Latitude RealType. (This is actually a *good* thing, because the Quantity-based "Latitude" is has more information than the standard RealType-based "Latitude", but acts the same as the standard "Latitude" for everything except the == operator.) However, as Steve points out, if you use the equals() method rather than ==, things will work as you expect. This isn't strictly a VisAD requirement, it's a truism throughout Java. For example, this program: public class I { public static void main(String[] args) { Integer i = new Integer(1); Integer j = new Integer(1); System.out.println("( " + i + " = " + j + " )= " + (i == j)); System.out.println("( " + i + " eq " + j + " )= " + (i.equals(j))); } } prints out ( 1 = 1 )= false ( 1 eq 1 )= true The == operator is checking whether the two objects are exactly the same (i.e. in the same location in memory). The equals() method typically checks to see if two objects have the same values.
visad
archives: