If you're the worst student I ever tutor (and you're already not), I'll be a very happy person.
So you seem to understand the concept of casting and just don't understand it's use. Let's do something about that.
// Define the type of the variable, give it a name, set it equal to the original variable with the cast in front of it.
ObjectYouWantItToBecome objectName = (ObjectYouWantItToBecome) theOriginalObject;
// For instance
double myDouble = (double) anInt;
int myInt = (int) aLong;
Ford aCar = (Ford) randomCar;
Now, to make your example work, you need to change two things. First, the second apple (the double) can't have the same name as the first (the int). Second, you need to place the name of the first behind the cast. It'll look like this.
// Set an int with the name "apple" and the value 7
int apple = 7;
// Set a double with the name "apple2" and the casted value of apple, which is 7.0.
double apple2 = (double) apple;
Eclipse should have been yelling at you for duplicate variable names and not completing the double cast.
Casting primitives (usually ints and doubles) is a lot more common in my work. I'm usually only casting Objects unless I have a darn good reason to. Like if I'm overriding equals(Object).
public boolean equals(Object o) {
Integer num = (Integer) o;
boolean result = false;
if(intValue == num.intValue) {
result = true;
}
return result;
}
Note that there is a difference between an int and an Integer. An int is a primitive. An Integer is an Object that acts essentially as a wrapper around an int so that it can be more easily used by things like Lists.
// This is illegal because a List cannot contain a primitive type.
List<int> myList = new ArrayList<int>();
// However, we don't need to pass it a primitive. We have an object wrapper.
List<Integer> myList = new ArrayList<Integer>();
Technically speaking, you have to wrap/unwrap these things. Like I talked about before, there's a lot of things that Java does for you. This is another one of them. If you want to know about wrapping/unwrapping/boxing/unboxing, let me know and I'd be happy to give a quick lesson.
// This is perfectly legal and completely common.
myList.add(15);
// When it should technically be...
myList.add(new Integer(15);
// It's boxing or wrapping for you in the first example.
// Now here, we're getting an Integer object and the system is unboxing or unwrapping for us.
int num = myList.get(0);
// Technically we should do that ourselves.
int num2 = myList.get(0).intValue;
Yes, there is in fact a Java class called
Object. It functions as the root of all classes. At some point, you'll want to start looking at the
Java API. Technically, I linked you to the Java 7 API. If you're using Java 6, you might find some things that didn't exist until Java 7.
You're extending JComponent. What this means is that any method that exists in JComponent is inherited by your Object. If you don't override the method in your object, it'll use the original. In order to override, you must use the exact same signature as the original.
// The Integer class contains these method signatures.
toString();
toString(int i);
toString(int i, int radix);
// Now, if I have an object that extends Integer, I have to override using the same signature as the original.
// For instance, if I want to override toString(int i), I need to implement something like the following
public static String toString(int i) {
return i + "";
}
// The point being that I cannot change what it is I'm passing into the function.
// Incidentally, the idea of having several methods with the same name but different signatures is called Overloading.
What you're doing with paintComponent is overriding the original function. In order to use the method, you have to pass it a parameter of type Graphics. The good news is, you will (probably) never call paintComponent directly. If anything, you're far more likely to call repaint(). The system will call paintComponent for you, it will find the Graphics object, and it will pass it for you.
// Like any function, you may or may not have to pass it parameters.
// It just happens that you have to pass a Graphics object so the system
// knows what it's painting on. Of course, the system will find the Graphics
// object for you. You should never have to call this method yourself
// and will use methods from the Graphics object to do your painting.
public void paintComponent(Graphics g) {
// Draw Some Stuff
}
With the Graphics2D cast, it turns out that the Graphics object the system passes to paintComponent(Graphics) is actually a Graphics2D object that got cast back into a Graphics object at some point. You just need to cast it forward again to get it back.
// ThingWeWant newName = (ThingWeWant) oldName;
Graphics2D g2 = (Graphics2D) g;
Okay, it's like 1:40AM, I think I'm going to lie down. I'm happy to answer any questions you have. You don't learn by not asking. And seriously, at the point you're at, there is no such things as a stupid question. Maybe I'm not the best at explaining if I'm failing to convey details, but I'm certainly willing to try.