Class casting, creating an image and decompiling...

Question

Hi, I've got a couple of questions:
1)
How can I fully decompile classes, so with the implementation of the methods? Is it always possible to fully decompile a class file? When is it and when not?
2)
I aks this questions before, but I still haven't got it working, so sorry, but I ask it again :) :
I want to create my own class, for example cMyClass which extends the java.awt.Image class, which has abstract methods. How do these methods(for example getGraphics etc) have to be implemented?
3)
I can't cast a Image to cMyClass... why not?
Someone told me he did the following:
Canvas c = new Canvas()
cMyClass oImage = (cMyClass) c.createImage (100, 100);
and that this worked... I tried to do this too, and it seemed to work, but it actually didn't!!
I found out that c.createImage returns a null reference!!! That's why Java was able to cast it to my own cMyClass (not a problem to cast a null to something else), but when I created a Image (by doing a lot of unnessacary difficult stuff), and then tried to cast this Image to cMyClass it throw a ClassCastException or something like that...
How can I cast the java.awt.Image class to my class anyway?
3)
Why can't you create a image like i've done above or even like below:
Canvas c = new Canvas()
Image oImage = c.createImage (100, 100);
Why does this return a null reference?
Isn't there a better way to create an image?
4)
The getWidth and getHeight need a I thought observer...? Why is this? I just want the width and height and don't have an observer or something like that. Is there a way around this?
I tried getWidth(null) but this returns -1
Please help! :)

Answer 1

Hi, I've got a couple of questions:
1)
How can I fully decompile classes, so with the
implementation of the methods? Is it always possible
to fully decompile a class file? When is it and when
not?You can always get a dump of the bytecode with 'javap -c'. If you don't want to figure things out yourself, try searching google for a class file decompiler, possibly a de-obfuscator.
De-compilation is completely possible if the original author wanted that, by including debugging information. Depending on the degree of such information and the amount of code obfuscation, the decompiled code may lack variable names, line numbers, field and method names, class names, and even code structure. Names and line numbers are usually not re-creatable automatically, since the information is simply lost, but you can replace them with your own strings when analyzing an unknown class file (using the correct tools). Re-creating the original code structure may work in some cases, but to me the general case looks rather close to the halt problem (i.e. not solvable).
Use a de-obfuscator, hope you've got good luck, and analyze the bytecode manually if that doesn't work.
2)
I aks this questions before, but I still haven't got
it working, so sorry, but I ask it again :) :
I want to create my own class, for example cMyClass
which extends the java.awt.Image class, which has
abstract methods. How do these methods(for example
getGraphics etc) have to be implemented?I don't really understand the problem. 'abstract' means on the language level that your subclass must provide an implementation, i.e. a method body. What that method is expected to do is explained in the javadocs for Image. But in fact you're free to do anything. You could play a sound in the getWidth() method (replace with any method name if you want). Just consider the fact that a lot of code calls getWidth in the hope of getting the width of the image, not playing a sound. So much about the language level.
On a higher level, a subclass of Image should implement a certain way to describe an image. AFAIK this means that your code must know the size of the image and know how to produce the pixels of the image. I can't tell you in general how you must do this, because it depends on your special case. This boils down to the question, why do you want to write a subclass of 'Image'? What new way of describing and image have you come up with?
3)
I can't cast a Image to cMyClass... why not?Simple, and that's certainly not an ALT. Because that specific Image is not a cMyClass. It's probably a BufferedImage or similar that was produced by AWT.
Please read the specs carefully what casting is about.
Someone told me he did the following:
Canvas c = new Canvas()
cMyClass oImage = (cMyClass) c.createImage (100,
100);
and that this worked... I tried to do this too, and it
seemed to work, but it actually didn't!!
I found out that c.createImage returns a null
reference!!! That's why Java was able to cast it to my
own cMyClass (not a problem to cast a null to
something else), but when I created a Image (by doing
a lot of unnessacary difficult stuff), and then tried
to cast this Image to cMyClass it throw a
ClassCastException or something like that...
How can I cast the java.awt.Image class to my class
anyway?You can't, and if you understood casting then you'd understand that it wouldn't make sense.
3, 4(don't know)
Maybe stupid question, but for example the BufferedImage, is this
completly written in Java?
How is the link made between the OS+hardware and the Java code? I
mean, displaying images etc. is very platform dependend not?Look for JNI (Java Native Interface). It's a way to link native (e.g. C) code with Java code.