The application-level safety features of Java make it possible to develop new kinds of applications that were infeasible before now. A web browser that implements the Java runtime system can incorporate Java applets as executable content inside of documents. This means that web pages can contain not only static hypertext information but also full-fledged interactive applications. The added potential for use of the Web is enormous. A user can retrieve and use software simply by navigating with a web browser. Formerly static information can be paired with portable software for interpreting and using the information. Instead of just providing some data for a spreadsheet, for example, a web document might contain a fully functional spreadsheet application embedded within it that allows users to view and manipulate the information.
The term “applet” is used to mean a small, subordinate, or embeddable application. By “embeddable,” we mean it’s designed to be run and used within the context of a larger system. In that sense, most programs are embedded within a computer’s operating system. An operating system manages its native applications in a variety of ways: it starts, stops, suspends, and synchronizes applications; it provides them with certain standard resources; and it protects them from one another by partitioning their environments.
As far as the web browser model is concerned, an applet is just another type of object to display; it’s embedded into an HTML page with a special tag. Browsers make a distinction between items presented inline and items anchored via hypertext links and made available by external means, such as a viewer or helper application. If you download an MPEG video clip, for instance, and your browser doesn’t natively understand MPEG, it will look for a helper application (an MPEG player) to pass the information to. Java-enabled web browsers generally execute applets inline, in the context of a particular document, as shown in Figure 1.4. However, less capable browsers could initially provide some support for Java applets through an external viewer.
A Java applet is a compiled Java program, composed of classes just like any Java program. While a simple applet may consist of only a single class, most large applets should be broken into many classes. Each class is stored in a separate class file. The class files for an applet are retrieved from the network as they are needed. A large applet doesn’t need to retrieve all its parts or all its data before beginning to interact with the user. Well-designed applets can take advantage of multithreading to wait for certain resources in the background, while performing other activities.
An applet has a four-part life cycle. When an applet is initially loaded by a web browser, it’s asked to initialize itself. The applet is then informed each time it’s displayed and each time it’s no longer visible to the user. Finally, the applet is told when it’s no longer needed, so that it can clean up after itself. During its lifetime, an applet may start and suspend itself, do work, communicate with other applications, and interact with the Web browser.
Applets are autonomous programs, but they are confined within the walls of a web browser or applet viewer, and have to play by its rules. We’ll be discussing the details of what applets can and can’t do as we explore features of the Java language. However, under the most conservative security policies, an applet can interact only with the user and can communicate only over the network with the host from which it originated. Other types of activities, like accessing files or interacting directly with outside applications, are typically prevented by the security manager that is part of the web browser or applet viewer. But aside from these restrictions, there is no fundamental difference between a Java applet and a standalone Java application.
When it was first released, Java quickly achieved a reputation for multimedia capabilities. Frankly, this wasn’t really deserved. At that point, Java provided facilities for doing simple animations and playing audio. You could animate and play audio simultaneously, though you couldn’t synchronize the two. Still, this was a significant advance for the Web, and people thought it was pretty impressive.
Java’s multimedia capabilities have now taken shape. Java now has CD-quality sound, 3D animation, media players that synchronize audio and video, speech synthesis and recognition, and more. The Java Media Framework now supports most common audio and video file formats; The Java Sound API (part of the core classes) has the ability to record sound from a computer’s microphone.
For some time now, people have been using visual development environments to develop user interfaces. These environments let you generate applications by moving components around on the screen, connecting components to each other, and so on. In short, designing a user interface is a lot more like drawing a picture than like writing code.
For visual development environments to work well, you need to be able to create reusable software components. That’s what the JavaBeans architecture is all about: it defines a way to package software as reusable building blocks. A graphical development tool can figure out a component’s capabilities, customize the component, and connect it to other components to build applications. JavaBeans takes the idea of graphical development a step further. JavaBeans components, called Beans, aren’t limited to visible, user interface components: you can have Beans that are entirely invisible and whose job is purely computational. For example, you could have a Bean that does database access; you could connect this to a Bean that lets the user request information from the database; and you could use another Bean to display the result. Or you could have a set of Beans that implement the functions in a mathematical library; you could then do numerical analysis by connecting different functions to each other. In either case, you could “write” programs without writing a single line of code. Granted, someone would have to write the Beans in the first place; but that’s a much smaller task, and we expect markets to develop for “off the shelf " Bean collections.
Before it can use a Bean, an application builder must find out the Bean’s capabilities. There are a few ways it can do this; the simplest is called reflection. To write a Bean that uses reflection, all you need to do is follow some well-defined conventions (design patterns) that let the graphical interface builder (or any other tool that wants to do the work) analyze the Bean.
If they need to, Beans can provide additional information using a process called introspection. But even without introspection, a graphical development tool can analyze a Bean, figure out what it can do, and let a user change the Bean’s properties without writing any code.
Of course, once a development tool has customized a Bean and connected it to other Beans, it needs a way to save the result. A process called serialization lets a tool save the Bean’s current state, along with any extra code it has written to stitch Beans together in an application.
Visual development tools that support Java Beans include IBM’s VisualAge, Inprise’s JBuilder (http://www.inprise.com), WebGain’s Visual Cafe (http://www.webgain.com), and Sun’s Forte for Java. By using a “bridge,” Java Beans can function inside ActiveX.
Get Learning Java now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
