Dear all: int x=10; How can my code test later on to see if "x" is indeed an int or not? It may be a byte, long, boolean, etc. And this is just testing to see what primitve data type a varible is, not testing to see which of the wrapper types (Integer, etc.) it might be (can you test for that too, now that I think of it ?). This answer is likely simple. I went looking through the Java documentation for a function that might tell me that primitive data type of a given varible but was unsuccessful. Thank you. Edwin (digging out from under 90 cm of snow in 2 days in Halifax, Nova Scotia !)
It's not possible in Java to have direct access to a variable and not know its type at compile time, so the question doesn't really make sense. If, though, you're talking specifically about members of classes, there is an API to investigate these, in the java.lang.reflect package. But I don't think this is what you're asking about. Can you elaborate a bit on your question, telling us in what context this has come up for you?
If your classes or methods are so long and complex that you can't easily find the definition of a given class member or local variable, you probably need to refactor, splitting complex procedures and concepts into smaller pieces that are more manageable. Also, many IDE's such as Eclipse and IntelliJ make it even easier to find the declaration of a given variable - it will be worthwhile in the long run to learn to use one of these. (Though for a beginner, it's generally not the best way to start out.)
What you have to understand about primitives is that they are...well...primitive. In other words, there's no long-lived type stored about that data--the type is completely determined by the way you're accessing it. Example time.
Do x, b, and c all refer to the same data in memory? The answer is no. If I change the value of x by writing x++, for instance, b and c will remain unaltered and still point to the bit pattern that represents 10. If I refer to x, I'm referring to an int. If I refer to b, a byte, and c, a char. That's it. The type of data literally changed when I coerced it into doing so with the type casts. You always know what the type of your primitive data is because Java is strongly typed, and the language forces you to confer type upon a particular bit pattern in memory before you work with it. For instance, if you try to pass a char into a method that takes an int, the compiler will complain. If you typecast that char to an int when you pass it in, then it shows up to that method as an int and it gets treated as an int from there on out. Indeed, there's a new copy of that bit pattern floating around now, and it IS an int in every way. This is vastly different from the way objects are handled. With objects, everything is passed around by reference. Furthermore, there is a distinction between "class" and "type" that it's important for every Java developer to know and understand. The class of an object is determined when that object is instantiated, and that object can never, ever change its class. It's born of a certain class, it lives as that class, and gets garbage collected as that class. It cannot change. Type, on the other hand, is a different matter for objects. Objects themselves may be of a particular class that cannot change, but an object's type can change from moment to moment. The whole concept of "type" is not really an intrinsic part of an object...rather, type is intrinsic to a reference. The kind of reference used to refer to an object is what confers upon that object a "type". Example:
On line 1, an Integer object is created. Because the new operator was called, it created an object on the heap of class Integer. You'll often hear people confuse things by saying it created an object of "type" Integer--which is not true. Well...it is true, but it's not the *whole* story. The whole story is, it created an object of class Integer, but of type Integer, Number, and Object. An object can be of many types at once...but only one class. So we've created an object of class Integer. We immediately store a reference to that object in i, a reference of type Integer. So on that line, we are referring to an object of class Integer and conferring upon it the type Integer by using the reference i. In the next line, we are referring to an object of class Integer with a reference of type Number. This reference, n, confers a different type upon the same object (still of the same class, though). Then we do it again on the next line, except now the same Integer object is playing the type of Object. No matter what reference you use to that object, though, if you were to get the class name, it'd come back "java.lang.Integer" because class doesn't change. This is not the case with primitives, though. When you create a new "reference" (it's not really a reference, of course) to a primitive, you've copied that bit pattern from one part of memory to another and told the JVM and compiler to treat that bit pattern as int, or char, or byte, or float, or whatever. A primitive variable is not really a "reference" because it doesn't "refer" to anything--there's no level of indirection from the variable to the data. The variable is itself both a name and a type for that very bit pattern, and they are locked forever in one-to-one-to-one correspondence (variable-to-name-to-type). sev
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop