In this section we'll look at some differences between JApplets and JFrames. In the process, we'll learn a lot about browsers and operating systems. You should also read section14.4 of our textbook, starting on page 544 about applets vs applications.
Fo now let's see what we need to do to make a JFrame that works like the applet above.
Make a new class (still in your lab11 package of course) called MyMouse2. Tell Eclipse you want to extend JFrame and click the box that says you want a main method. Then copy the code from MyMouse1, starting at "// Constants" and finishing just before the last closing brace; and paste it just above the line declaring method main. Notice the errors that Eclipse tags:
These reflect a difference between JApplets (expected to run in a browser, very likely over the internet) and JFrames (expected to run as standalone applications on a single computer). getDocumentBase is all to do with finding out the URL (Universal Resource Locator -- or web-address) where the applet is, and where, presumably, associated resources like the image are sitting. It doesn't make sense for a JFrame to need a URL. Look at the documentation for JApplet where you will find a link to the method Image getImage(URL url, String name) that actually is inherited from the Applet class. Clearly, this getImage method is not appropriate for a JFrame. So how does a JFrame load an image?
Check out the documentation for the JFrame class and you will not find any getImage methods. Not even inherited methods from ancestor classes. The good people at Sun made a design decision that JFrames do not themselves load images. So how do you get images into a JFrame?
The good people at java.sun are pretty smart. Why do you think they made image loading into JApplets different from image loading into JFrames. One reason might be that JApplets run in browsers on the internet and things like browsers and URLs work exactly the same way for Windows, for Unix, for Macs, etc. But file systems on Windows, on Macs and on Linux systems can differ substantially. So Java has an intermediate step for loading images from a file syste. It uses a Toolkit intermediary. The Toolkit provides identical functionality on different platforms from the point of view of the rest of the program. But it may be doing vastly different things in order to work its magic. A Windows Toolkit accesses a differently organized file system from what a Mac Toolkit does.
In short, a Toolkit abstracts the notion of getting stuff from an operating system. Take a look at the documentation for Toolkit and you'll see what I mean.
As a result, here's one way to load images into a JFrame:
Toolkit tk = Toolkit.getDefaultToolkit(); micky = tk.getImage("mighty_mouse.jpg"); mt = new MediaTracker(this); mt.addImage(micky, 1); try { mt.waitForAll(); } catch(InterruptedException ie) {}
Notice that getDefaultToolkit() is a static method in the class Toolkit.
You need to delete a couple lines from your init() method and add a couple.
There are a few more steps:
public MyMouse2() { init(); setVisible(true); setDefaultCloseOperation(EXIT_ON_CLOSE); }
One last thing. You will need a second copy of your .jpg file! That's because the URL of the running JApplet was that bin directory where you placed your jpg file. The place in the operating system's file system from where the JFrame is running is actually one level higher. So copy the image from the bin directory, and paste a copy of it in the parent folder. That folder will now contain folders src and bin as well as the copy of your image.