UNIX Networking : Sockets TCP Transmitter and Reciever
Intro
Networking in UNIX or Linux is done with sockets. The following are 2 programs I made up.
1. Sends messages in TCP, Client
2. Listens and Recieves messages from TCP, Server
TCP or Transmission Control Protocol is a 2way connection which is more like a stream or a pipe. Both the ends must be connected.
The Transmitter
Reads messages from input and sends it to localhost:34000.
To Setup a transmitter following must be done:
1. Setup a port address and open a socket and bind to it.
2. Connect to server
3. Send messages
4. Close connection when done
#include
#include #include #include #include #include #include #include #include #include #include #include /*Some are unused, But I read these are general headers used in a network program:)*/int main(void){ struct sockaddr_in sin; int s; s = socket(AF_INET, SOCK_STREAM, 0); if(!s) { perror("socket()"); return 1; } sin.sin_family = AF_INET; sin.sin_port = htons(9999); sin.sin_addr.s_addr = INADDR_ANY;//Just any would do if(bind(s, (struct sockaddr *)&sin, sizeof(sin))) { perror("bind()"); return 1; } struct sockaddr_in sout; sout.sin_family = AF_INET; sout.sin_port = htons(34000);//Destination PORT! sout.sin_addr.s_addr = inet_addr("127.0.0.1");//Destination IP Address, here localhost. connect(s,(struct sockaddr *)&sout, sizeof(sout));//Connect to Server char msg[1000];//Buffer do { printf("Message: "); scanf("%s",msg); sendto(s, msg, strlen(msg)+1, 0,NULL,0);//Sends the message }while(*msg!='0'); /*Just an exit condition*/ close(s);//Close Socket return 0;}
The Reciever
This program listens to localhost:34000 and accepts first connection and prints the messages whenever it recieves one.
To Setup a reciever following must be done:
1. Setup a port address and open a socket and bind to it.
2. Listens for Clients to connect.
3. Accept connections
4. Recieve data
5. Close connection
#include #include #include #include #include #include #include #include #include #include #include #include int main(void){ struct sockaddr_in sin; char msg[10000]; int ret; int sin_length; int s,s2; s = socket(AF_INET, SOCK_DGRAM, 0); if(!s) { perror("socket()"); return; } sin.sin_family = AF_INET; sin.sin_port = htons(34000); sin.sin_addr.s_addr = inet_addr("127.0.0.1"); if(bind(s, (struct sockaddr *)&sin, sizeof(sin))) { perror("bind()"); return 1; } if(listen(s,10))//Listen for connections { perror("listen()"); return 1; } int size=sizeof(sin); if((s2=accept(s,(struct sockaddr *)&sin, &size) < 0)//Accept connections { perror("accept()"); return 1; } printf("\nConnected to %s[%d]",inet_ntoa(sin.sin_addr),sin.sin_port)l do { ret = recv(s2, msg, 10000, 0);//Waits until a message is recieved... printf("Message : %s\n", msg); } while(msg[0]!='0'); close(s);//Close Socket return 0;}
Thats all
Tested and proved working on Fedora Core 6.
Do let me know your results and comments.....
To know more about the functions check the Linux Manual for each function.
Working of The Java Virtual Machine
Summary
The Java Virtual Machine provides a platform-independent way of executing code, by abstracting the differences between operating systems and CPU architectures. Java Runtime Environments are available for a wide variety of hardware and software combinations, making Java a very portable language. Programmers can concentrate on writing software, without having to be concerned with how or where it will run. The idea of virtual machines is nothing new, but Java is the most widely used virtual machine used today. Thanks to the JVM, the dream of Write Once-Run Anywhere (WORA) software has become a reality.
At the heart of the Java platform lies the Java Virtual Machine, or JVM. Most programming languages compile source code directly into machine code, suitable for execution on a particular microprocessor architecture. The difference with Java is that it uses bytecode - a special type of machine code.
Java bytecode executes on a special type of microprocessor. Strangely enough, there wasn't a hardware implementation of this microprocessor available when Java was first released. Instead, the processor architecture is emulated by what is known as a "virtual machine". This virtual machine is an emulation of a real Java processor - a machine within a machine (Figure One). The only difference is that the virtual machine isn't running on a CPU - it is being emulated on the CPU of the host machine.
The Java Virtual Machine is responsible for interpreting Java bytecode, and translating this into actions or operating system calls. For example, a request to establish a socket connection to a remote machine will involve an operating system call. Different operating systems handle sockets in different ways - but the programmer doesn't need to worry about such details. It is the responsibility of the JVM to handle these translations, so that the operating system and CPU architecture on which Java software is running is completely irrelevant to the developer.
The Java Virtual Machine forms part of a large system, the Java Runtime Environment (JRE). Each operating system and CPU architecture requires a different JRE. The JRE comprises a set of base classes, which are an implementation of the base Java API, as well as a JVM. The portability of Java comes from implementations on a variety of CPUs and architectures. Without an available JRE for a given environment, it is impossible to run Java software.
Differences between JVM implementations
Though implementations of Java Virtual Machines are designed to be compatible, no two JVMs are exactly alike. For example, garbage collection algorithms vary between one JVM and another, so it becomes impossible to know exactly when memory will be reclaimed. The thread scheduling algorithms are different between one JVM and another (based in part on the underlying operating system), so that it is impossible to accurately predict when one thread will be executed over another.
Initially, this is a cause for concern from programmers new to the Java language. However, it actually has very little practical bearing on Java development. Such predictions are often dangerous to make, as thread scheduling and memory usage will vary between different hardware environments anyway. The power of Java comes from not being specific about the operating system and CPU architecture - to do so reduces the portability of software.
Multi-Dispatch in the Java Virtual Machine part 1
Mainstream object-oriented languages, such as C++and Java1, provide only a restricted form of polymor-phic methods, namely uni-receiver dispatch. In com-mon programming situations, developers must workaround this limitation. We describe how to extend theJava Virtual Machine to support multi-dispatch and ex-amine the complications that Java imposes on multi-dispatch in practice. Our technique avoids changes tothe Java programming language itself, maintains sourcecode and library compatibility, and isolates the perfor-mance penalty and semantic changes of multi-methoddispatch to the program sections which use it. We havemicro-benchmark and application-level performance re-sults for a dynamic Most Specific Applicable (MSA)dispatcher, a framework-based Single Receiver Projec-tions (SRP) dispatcher, and a tuned SRP dispatcher. Ourgeneral-purpose technique provides smaller dispatch la-tency than programmer-written double-dispatch codewith equivalent functionality.
1 IntroductionObject-oriented (OO) languages provide powerful toolsfor expressing computations. One key abstraction is theconcept of a type hierarchy which describes the relation-ships among types. Objects represent instances of thesedifferent types. Most existing object-oriented languagesrequire each object variable to have a programmer-assigned static type. The compiler uses this informationto recognize some coding errors. The principle of sub-stitutability mandates that in any location where type Tis expected, any sub-type of T is acceptable. But, substi-tutability allows that object variable to have a different(but related) dynamic type at runtime.Another key facility found in OO languages is method.
selection based upon the types of the arguments. Thismethod selection process is known as dispatch. It canoccur at compile-time or at execution-time. In the for-mer case, where only the static type information isavailable, we have static dispatch (method overload-ing). The latter case is known as dynamic dispatch(dynamic method overriding or virtual functions) andobject-oriented languages leverage it to provide poly-morphism — the execution of type-specific programcode.We can divide OO languages into two broad categoriesbased upon how many arguments are considered dur-ing dispatch. Uni-dispatch languages select a methodbased upon the type of one distinguished argument;multi-dispatch languages consider more than one, andpotentially all, of the arguments at dispatch time. Forexample, Smalltalk [14] is a uni-dispatch language.
CLOS [23] and Cecil [6] are multi-dispatch languages.Other terms, like multiple dispatch, are used in the liter-ature. However, the term multiple dispatch is confusingsince it can mean either successive uni-dispatches or asingle multi-dispatch. In fact, in this paper, we comparemulti-dispatch to double dispatch, which uses two uni-dispatches.C++ [24] and Java [15] are dynamic uni-dispatch lan-guages. However, for both languages, the compilerconsiders the static types of all arguments when com-piling method invocations.
Therefore, we can regardthese languages as supporting static multi-dispatch। Fig-ure 1 depicts both dynamic uni-dispatch and static multi-dispatch in Java.Uni-dispatch limits the method selection process to con-sider only a single argument, usually the receiver. Thisis a substantial limitation and standard programming id-ioms exist to overcome this restriction. As a motivationfor multi-dispatch, we describe one programming idiomthat demonstrates the need for multi-dispatch, describe.
class Point
¤
int x, y;
void draw(Canvas c)
¤
// Point-specific code
¥
void translate(int t)
¤
x+=t; y+=t;
¥
void translate(int tX,int tY)
¤
x+=tX; y+=tY;
¥
¥
class ColorPoint extends Point
¤
Color c;
void draw(Canvas C)
¤
// ColorPoint code
¥
¥
// same static type, different dynamic types
Point Pp = new Point();
Point Pc = new ColorPoint();
// static multi-dispatch
Pp.translate(5); // one int version
Pp.translate(1,2); // two int version
// dynamic uni-dispatch
Pp.draw(aCanvas); // Point::draw()
Pc.draw(aCanvas); // ColorPoint::draw()
Figure 1: Dispatch Techniques in जावा
how it can be replaced by multi-dispatch, list the ad-vantages of using multi-dispatch to replace the idiomaticcode, and measure the cost of using multi-dispatch withone of our current multi-dispatch algorithms.1.1 Double DispatchDouble dispatch occurs when a method explicitly checksan argument type and executes different code as a re-sult of this check. Double dispatch is illustrated in Fig-ure 2(a) (from Sun’s AWT classes) where theprocess-Event(AWTEvent)method must process events in dif-ferent ways, since event objects are instances of differ-ent classes. Since all of the events are placed in a queuewhose static element type isAWTEvent, the compilerloses the more specific dynamic type information. Whenan element is removed from the queue for processing, itsdynamic type must be explicitly checked to pick the ap-propriate action. This is an example of the well-knowncontainer problem.
Double dispatch suffers from a number of disadvan-tages. First, double dispatch has the overhead of in-voking a second method. Second, the double-dispatchprogram is longer and more complex; this providesmore opportunity for coding errors. Third, the double-dispatch program is more difficult to maintain sinceadding a new event type requires not only the code tohandle the new event, but another cascadedelse ifstatement.The need for double dispatch develops naturally in sev-eral common situations. Consider binary operations [4],such as thecompareTo(Object)method defined in in-terfaceComparable. The programmer must ascertain
Regarding computer screens, What does XGA, SXGA and TFT mean?
XGA ==>
eXtended Graphics Array
(XGA) An IBM display standard introduced in 1990.
XGA supports a resolution of 1024 x 768 pixels with a palette of 256
colours, or 640 x 480 with high colour (16 bits per pixel).
XGA-2 added 1024 x 768 support for high colour and higher refresh rates,
improved performance, and supports 1360 x 1024 in 16 colours. http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?XGA (source)
XGA (Extended Graphics Array)
A Display Standard referring to a video adapter capable of a resolution of
up to 1024 by 768 pixels.
SXGA (Super XGA)
A Display Standard referring to a video adapter capable of a resolution of
up to 1280 by 1024 pixels.
SXGA+ (Super XGA+)
A Display Standard referring to a video adapter capable of a resolution of
up to 1400 by 1050 pixels.
TFT (Thin Film Transistor) http://dret.net/glossary/ (source)
http://www.cs.ndsu.nodak.
edu/~revie/amlcd/ is a good explanation for the
TFT display details.
what is psp in assembly language
I assume you are writing a program for a computer using a Microsoft DOS operating system.
If not, you will need to ask your question again, and specify the processor and operating system.The Program Segment Prefix, or PSP, isn't really an assembly language instruction, it's a header built by DOS when your program runs.
It occupies the first 256 bytes of memory, and contains information like the amount of available memory, where the available memory starts, the command line arguments, and so forth. You can find one description at http://iserver.ivc.cc.ca.us/faculty/dehrlich/ASMGUIDE/ng6911b.htm.
There is a lot of information available online, including numerous tutorials written at various levels. You'll get over 7000 hits with a search for "psp assembly language" on Google (www.google.com). A little searching there should turn up all of the additional information you need.
First, let's add one more definition of temperature, the gas temperature. This is the temperature you would measure if you stuck a thermometer in the
The migration of popular computing applications to the Web has changed the way we view the web browser. Some of our most frequently used applications now exist within a tab of Firefox or Internet Explorer, constantly polling a remote server on our behalf and presenting the results in a rich interface powered by the latest features of JavaScript and/or the Flash Player plugin. These "live" web applications have pushed the browser to its limits (and sometimes beyond), consuming increasing amounts of memory and network bandwidth as our browser terminal remains connected to the data cloud. Storing data and preferences directly on the user's machine is one way to speed up a web application and even offer some offline capabilities, connecting to data stored on a local hard drive instead of relying on a remote server. In this post I'll walk through some of the ways web application developers take advantage of local storage to speed up applications, persist user preferences, and enable features for "occasionally connected" users.
Storing web application data within a local cache opens up new possibilities for a future class of web applications by storing and loading user data directly on a user's hard drive. The future of asynchronous JavaScript and XML (Ajax) will extend its reach beyond client-server interactions and into local XML storage addressed from any web page and interpreted by the client web browser. A web application can rely on local storage options when disconnected from the Internet, saving changes locally and synchronizing results whenever an active Internet connection is available.
Imagine a personal finance site storing your stock portfolio and historical prices locally, creating quick access to charting and planning tools powered by pre-loaded data. Your favorite blogging tool might already use local storage to automatically save drafts of your blog posts, checking for spelling and grammar mistakes based on locally stored individual preferences. A personalized homepage might store your selected widgets and their content locally, quickly loading your information dashboard with or without an available Internet connection.
Local storage of client preferences and data is nothing new but, like DHTML, is being rediscovered as web applications squeeze as much as they can out of currently deployed browsers and popular plugins. Just like other web technologies such as JavaScript and CSS, support for local data files addressable from a web page varies by browser. JavaScript libraries such as Dojo Storage abstract each storage method into a single JavaScript call with appropriate storage based on available resources (thanks Brad Neuberg!), but it's useful to take a look at the low-level options and their respective limitations.
Web browser local storage options Browser Storage Max Size
Any Cookies 4 KB
Flash Player 6 and above Flash local Shared Object 100 KB
Internet Explorer 5 and above userData 1 MB
Firefox 2 and above DOM Storage 5 MB
Cookies
A HTTP cookie persists user data in a single browser across multiple browsing sessions, allowing a website to track items placed in a shopping cart, recognize a logged-on user, save a site preference, and more.
Cookies are limited to 4 KB of storage per domain and are a good way to persist user data for convenience or tracking. Modern web browsers contain cookie and privacy management features to wipe away stored cookies and their stored data and therefore have limited utility for continued persistence. Cookies are sent along with every request on a given domain, adding extra weight to every message exchanged between an end-user's browser and your site, even if the cookie data is only occasionally utilized.
Browser cookies are the most common form of persisting data across multiple website visits but their limited size, common deletion, and added weight limit the usefulness of this time-tested storage method.
what is infrared hardware, software. and how does it work?
Infrared (IR) waves are a part of the electromagnetic spectrum and, depending
on their wavelength, we have given different waves in the electromagnetic spectrum
different names. All electromagnetic waves travel at the speed of light. The very
longest electromagnetic waves that man uses are those in our electric power lines.
The frequency is usually between 50 to 60 cycles per second and have wavelengths
have of 5,000 kilometers (km) or 3,100 miles long. We then have radio wavelengths
that range from 100 km down to 1 meter (620 miles down to 39 inches). As
the electromagnetic wavelengths become shorter we have the following:
Note that
one millimeter (mm) is one thousandth of a meter
one micrometer is one millionth of a meter
one nanometer (nm) is one billionth of a meter
one femtometer(fm) is one millionth of a nanometer
WAVELENGTH TABLE
Wave name______Wavelength
Power lines ___5000 kilometers (km) or 3100 miles
Radio waves__ 100 km down to 1 meter (620 miles down to 39 inches)
Microwaves__1 meter to one millimeter (39 inches to 0.04 inches)
Infrared waves (heat)_1mm to about 0.6 micrometer (0.04 inches to 0.015 microinches)
Visible light___600 nm (red) to 400 nm (violet) (.015 microinches to 0.01 microinches).
Ultraviolet waves_400 nm to 1 nm (0.01 microinch and much smaller)
X-rays________1 nm to 0.01 nm
Gamma rays____0.01 nm to 1 fm
There are electromagnetic waves that are longer and shorter than those listed above;
however, man does not use them and has difficulty in detecting them.
Reference 1. at NASA presents much more detail about infrared waves and the
electromagnetic spectrum.
IR waves are used to see hot targets such as people and vehicles at night.
Weather satellites also use infrared detectors to view the weather on the dark
side of the earth. Because human eyes cannot see IR energy we have to use
special electro-optical devices to detect the IR energy radiated
or reflected by objects.
The hardware in IR systems is the IR detectors and electronics
in an IR camera system.
Software has been developed to take the images detected by IR cameras and
to present them in false colors (infrared light has no color) with each computer
generated color representing different temperatures of an object such as the
earth or the human body. Medical doctors are now using IR cameras to detect
various medical conditions that change the temperature of different parts of the
human body. You can see a false color IR satellite temperature map of the earth at
Reference 2.
IR radiation is used in many communications systems. By sending pulses of
IR energy, the ones and zeros that are used in digital communications systems
can be transmitted. The remote controls for your television or HiFi system send
pulses of IR radiation from your hand set to an IR detector in the set which is
usually located behind a small black colored glass window that blocks out visible
light. The IR detector converts the IR pulses into electrical pulses that are sent to small
microcomputers in the set to control the sets channel selection, volume etc.
The most extensive use of IR energy in communications is in the fiber optic
systems used by the telephone and cable TV companies. The glass used in optical
fibers is most transparent at 1.5 micrometer IR wave lengths. While visible
light can be transmitted in fiber optic cables, IR energy can communicate over
distances 5 to 10 times longer than if visible light pulses are used
tell me the name of the program to get the unknown password of any folder
Well, this is an interesting situation, because although I'm by profession a computer security expert, and know several ways to attack the problem, there are good and proper reasons for me to not answer the question directly. The most obvious and difficult problem is that I have no real assurance that in fact the problem folder is indeed yours (and not a professor's or classmate's). So even if there was a way to "get the password of any folder", I'd most probably not be sharing it with everybody (and I'd probably be getting in touch with the vendor to explain to them that the fact that such a program can be written is a severe security flaw in their system)...
The second biggest problem is that there are multiple different software packages out there that claim to provide password locking or encryption of files, and they all have different methods of doing their work. So there really isn't any "one way" to do it. (Incidentally, the vast majority of these tools are worse than useless - a few minutes with Google will often find pre-built tools to break the particular software package.)
So let's proceed on the idea that "Instant Access" is in fact the name of the problem software. There's many Google hits for +"instant access" +folder. The vast majority of these are merely hints for setting up easy-to-access shortcuts. However, two things stand out:
Perhaps what you're asking is "How do I get this 'Instant Access' off my system?". If so, you might want to read Symantec's description of how to remove the Instant Access Dialer and see if that matches what you're seeing.
If it's some other "Instant Access", your best bet is to either contact the technical support team at the site you downloaded it from.
And I almost never manage to answer one of these security questions without suggesting that everybody make sure they have the latest software patches on their system, and anti-virus and anti-spyware software if appropriate for your system, and back up your system on a regular basis. Be careful - it's dangerous out there.
java RMI ,BEANS
A little over a year ago the world discovered Java, a new language and runtime environment that was untested, unreliable, limited in function, slower than just about anything on the planet and at the same time the solution to all of the world's programming problems and ready to replace everything from assembly language to Visual Basic. A year later the news is good and not quite so good (but far from bad): people are demonstrating some interesting successes and learning a lot in the process; some of the hype has been replaced by more rational discourse on Java's value today and potential for the future (a lot fewer people are claiming the imminent demise of C++, Fortran or Cobol, although some are now predicting the demise of CORBA); and Java has experienced its first major update. JavaSoft's release of version 1.1 of its Java Development Kit offers new interfaces for programmers to exploit, new facilities for users and tool builders and a better implementation of a lot of the machinery that lies under Java's hood.
New Classes & Better Classes
JDK 1.1 introduces a whole alphabet soup of new acronyms and terminology:
JDBC (Java Database Connectivity): a set of classes that let Java applications and applets open connections to relational databases and then run SQL-based queries against them.
RMI (Remote Method Invocation): a mechanism that permits Java objects to invoke methods on objects that exist in a server process that may reside on a different computer. RMI includes facilities for registering remote objects and mapping a requester to the desired remote object on the appropriate server. It might be thought of as a lightweight Java-only version of of the distributed object facilities provided by CORBA, the Common Object Request Broker Architecture defined by the Object Management Group.
Object Serialization (sorry, they didn't define an acronym for this one): a facility for translating an object into a series of bits that can be stored in a file and recreated at a later date (a form of persistence for objects) or sent across a communication channel, perhaps as an argument to an RMI request, and recreated at the other end of the wire.
Reflection: the ability for Java code to ask a loaded class for lists of its data fields, constructors and other methods and, where security permits, to manipulate those fields or invoke those methods. The reflection API is an essential part of JavaBeans, which we'll discuss in more detail later.
In addition to these new interfaces, JDK 1.1 makes some significant changes to some old favorites. One of the many complaints about AWT, JavaSoft's window toolkit for Java, is that it promotes a distinctly non-object-oriented and unmaintainable coding style. Most user interface events are channeled through a single method called handleEvent. This method is where we put the code that identifies which event occurred and which UI component (button, scroll bar, etc.) was involved. Inevitably, our handleEvent method ends up as a long string of event-dispatching if statements like this:
if (event.target == textfield && event.id == Event.ACTION_EVENT) {
itemList.addItem(arg.toString());
eventHandled = true;
}
if (event.target == addButton && event.id == Event.ACTION_EVENT) {
itemList.addItem(String.valueOf(textfield.getText()));
eventHandled = true;
}
if (event.target == removeButton && event.id == Event.ACTION_EVENT) {
removeItem(event);
eventHandled = true;
}
For an interface with two buttons and one text field, such a structure isn't so bad. But imagine a UI with dozens of buttons, dials, scroll bars, text fields and more. You can see that the effort maintaining such a lengthy series of tests against the type and target of an event would quickly get out of hand.
Enhancements to AWT eliminate the need for this kind of code by defining a new mechanism for writing event listeners. Listener classes can be defined to listen to and process specific classes of events, with individual listener objects being assigned to specific UI objects. Instead of having to write event dispatchers like the one above, we simply associate an instance of a listener to the object that generates the events. In this case, we create this association as we create each UI element:
CmdHandler addCmd = new CmdHandler (CmdHandler.ADD, app);
CmdHandler removeCmd = new CmdHandler (CmdHandler.REMOVE, app);
add(textfield = new java.awt.TextField());
textfield.addActionListener(addCmd);
add(addButton = new java.awt.Button("Add Item"));
addButton.addActionListener (addCmd);
add(removeButton = new java.awt.Button("Remove"));
removeButton.addActionListener (removeCmd);
The CmdHandler class in the code above would inherit from the AWT ActionListener class. When an action event is generated (clicking on a button, typing Enter in a text field), the actionPerformed method is invoked on the appropriate CmdHandler object. That method would contain the code to process the event.
Another important change in AWT concerns the definition of event types. In JDK 1.0 there was a single Event class which used an id field to specify the type of event which took place. There was no ability for programmers to define their own event types (extend the list of valid event ids) or to create event-generating objects outside the AWT class hierarchy. This made it difficult to write new non-graphical components like timers and have them behave like and interact with event-based objects. In JDK 1.1, there is an extensible hierarchy of event classes. User-written components can define new events and can signal events, permitting them to be treated in our code in the same way as AWT components.
An important concern for Java pioneers is that these improvements to the Java environment not break all of their existing code. For this reason, Java continues to support the old handleEvent mechanism for capturing and processing UI events. Despite the presence of the old model (and all of the not-yet-updated books that describe it as the One True Way of handling events), programmers are well advised to take advantage of the new approach as quickly as they can. (Which, as we'll discuss at the end, may not be all that quick.)
What's a JavaBean? (And when will we stop with all the coffee puns?)
Of all of the features of JDK 1.1, JavaBeans has probably received the most attention and is the source of the most confusion. Beans began in response to the problems of writing a visual application builder for Java, like the one in SGI's own Cosmo Code. Builders work with object classes, presenting users with properties they can modify and events on one object that they can tie to methods on another object. Ideally, a builder should be able to import new classes, glean all of the property, event and method information and then allow them to be manipulated in the same way as built-in classes.
It turns out that much of the information needed by the builder is available in the class file. It is relatively easy to determine the methods a class supports and to distinguish methods that retrieve state from those that modify state: Does the method accept arguments? It's a set method. Does it return a value? It's a get method. (Does it do both? Ignore it and maybe it'll go away.)
We can identify set and get methods by inspection of the class file. But one thing we can't always do is match up set methods with their corresponding get methods. For example, in JDK 1.0 an AWT component implements a get method called location which returns the component's position as a Point object. But the corresponding set method is called move. And instead of taking a Point, move represents the new position as a pair of ints. If people would be consistent in their naming (a setLocation method that accepts a Point; a getLocation method that returns one), it would make life a lot easier for builders and the people who write them.
JavaBeans contains just such a method naming convention as part of its specification. It defines a concept called a property; if a class defines both setLocation and getLocation methods that accept and return a Point, then that class can be said to have a property called Location whose type is Point. A builder would be able to learn all this not by reading the class file, but instead by using the Beans API to ask the class for the information. It can get the list of properties, data fields, constructors and other methods, along with their argument lists and return types. It can also get a list of event types generated by a class, so it can provide linkage between an object's events and the object that should respond to it.
A class can also define a customizer. A customizer provides a UI for changing an object's value. For example, a customizer for the Point class might present a pair of text fields where we could type integer values for X and Y. Or it might present a pair of scroll bars or a canvas in which we would click the mouse to specify a position. The Customizer interface frees the builder from having to define editors for all of the possible objects that might be imported into it. New object classes define their own editors, which the builder can embed in its property sheets. Inside the builder, any object that contains a Point would use the Point's customizer to edit it.
Although JavaBeans' most immediate value is in integrating new components into application builders, its designers have much more in mind for the technology. They are also touting Beans as an architecture for linking components dynamically. Instead of a class learning about and binding to another class's interface at compile time, it could query the class at run time, learn about the supported methods and decide how to integrate with it. In this way, Beans becomes a partner with and a competitor to technologies like Microsoft's COM/OLE/ActiveX or Apple's OpenDoc.
How serious a player Beans will be in the component architecture arena remains to be seen. But it is already being integrated into environments based on distributed components. JavaSoft has already discussed integration of JavaBeans with CORBA. Can Microsoft's DCOM (Distributed Component Object Model) be far behind?
JNI: You've got Java in my C++! Well, you've got C++ in my Java!
The visual application builder represents a major advance in software development tools. A builder provides the programmer with a collection of program elements that can be selected, organized and linked together to provide the basic structure of the application. A good builder has to go further than merely generating code; it has to permit the programmer to simulate the behavior of the program and the interaction of the elements during the design stage, long before the button is pressed to generate the source. And it would be far better if the list of elements available in the builder can be augmented with new components acquired or personally developed by the programmer.
An application builder for Java would be expected to work with and duplicate the behavior of the real Java objects that will exist in the completed application. Doing this properly almost demands that the builder itself either be written in Java or able to interact with the Java virtual machine (JVM). After all, how else can we duplicate the behavior of all those Java components, including new components, without duplicating the entire Java virtual environment? But this presented a problem in JDK 1.0. JDK 1.0 did define a Java Native Interface (JNI) that the JVM could use to invoke native (non-Java) methods. What was missing was a way for a native application to start up and work with a JVM.
This inability to embed the JVM in an application was a problem not just for builders but for the many programs that would benefit from having a Java-based scripting mechanism. The only way around the problem was to write the main program in Java and have it call out to a native method which is the real main. Since the JVM is now initialized and running, the native code can create new Java objects and invoke Java methods as it likes. This is how the builder in Cosmo Code 2.0 works: it's really a skeletal Java program that invokes the real C++-based builder. When the builder wants to manipulate Java objects from AWT or other sources, it calls back into the JVM to initiate their behavior.
JDK 1.1 addresses this problem by enhancing the JNI to support both the use of native code from Java applications and the use of Java code from native applications. It makes it possible for programmers who want to integrate Java into their applications to do so without having to rearchitect them. It also does a better job of supporting authors of native methods. Native methods for JDK 1.0 inevitably had to work around machine dependencies like data sizes, which means changing the code at least a little to move it to a different kind of system. JDK 1.1 shields native method programmers from the most common machine-level details.
Suffice it to say that native methods written for JDK 1.1 are far more likely to port to a new platform without source level changes. The new native interface is not backward compatible. Fortunately, JDK 1.1 continues to support the old interface, so existing native methods will work without modification.
JARs (Coffee JARs? Sheesh!)
There are many other changes and enhancements in JDK 1.1. One important addition is the Java archive (JAR) specification. JAR files are designed to reduce the network overhead of applets coming from a web server. Each Java class is stored in a separate file and is retrieved with a separate HTTP request. The first time it tries to use a new class, another HTTP request is issued to retrieve it. The more classes, the greater the overhead and the longer everything takes.
A JAR file uses the popular ZIP archive format to collect a group of Java class files and other information into a single compressed file. Instead of a series of HTTP transactions, everything can be retrieved in a single operation. Note that there is no requirement that all of an applet's classes be in the archive. Applets can still request that additional classes be retrieved as they're needed. But it does shorten the time to load and start a Java applet, reducing the number of HTTP requests and shrinking the file that needs to be retrieved.
A Java archive contains a special manifest file which describes the rest of the files in the archive. These may include class files, serialized object information and digital signature information. JDK 1.1 includes a special jar utility to create an archive for a set of files, using either a user-supplied or an automatically-generated manifest.
Using a JAR file is simpler than creating one. The < APPLET > tag has a new ARCHIVE attribute which specifies a comma-separated list of filenames. These filenames are combined with the CODEBASE attribute to create URLs of the archives to load. The CODE attribute must still be present. It specifies the Applet-derived class that should run.
Sounds Good. When Can I Get Started?
This is a good news/bad news situation. JavaSoft released JDK 1.1.1 (1.1 with fixes to some unfortunate bugs) in March of 1997. As of this writing, the SGI version is expected to release by the end of April, along with a new version of Cosmo Code that supports it. That's the good news.
So what's the not-so-good news? For people writing Java applications there isn't any. Feel free to start writing code that takes advantage of the new features. Of course, you'll need to make sure that all of your users are running the 1.1 version of the JVM before you can take advantage of any of the new features.
Applets are a somewhat messier story. We can expect both Netscape and Microsoft to release versions of their web browsers that support the new JVM before very long. How long it will take for the majority of users to upgrade is, as always, harder to predict. If you are concerned about having the widest possible acceptance of your applet you'll need to stay away from the wonderful new features of JDK 1.1. Fortunately, Java does a good job of both upward and downward compatibility. Stay within the limits of what was available with JDK 1.0 and your code built with 1.1 will be usable by everyone.
More information on the topics discussed in this article is available from JavaSoft's web site. Information on the latest version of the JDK and Cosmo Code for IRIX are available at SGI's own Silicon Surf.
--------------------------------------------------------------------------------
Visual Basics Searcher Programme
Here Is A Simple Code Im Using
Shell "C:\Program Files\Mozilla Firefox\firefox.exe http://www.google.com/search?q=-inurl%3A(htm%7Chtml%7Cphp)+intitle%3A%22index+of%22+%2B%22last+modified%22+%2B%22parent+directory%22+%2Bdescription+%2Bsize+%2B(exe%7Crar%7)+" & Text1.Text
But When Typing Out If I Include Spaces In My Search In Textbox1.text And Hit Search Button It Goes To Diffrent Tabs Aswell As The Tab I Want It To Go To But If I Dont Include Spaces It Goes Directly To The Wanted Tab In Mozilla Firefox ?? Please Could I Have Guidence
Example:
Magic Iso << Would Go To Wanted Tab And Magic.com and Iso.com
But
MagicIso << Would Go To Wanted Tab ??
replace " " with "%22" before sending the string.
Here is one I did, not fully completed but works very good, also can save results and results are returned back to the app instead of google site
Making Driver Code
Detecting Code That Can Be Pageable
To detect code that runs at IRQL >= DISPATCH_LEVEL, use the PAGED_CODE() macro. In debug mode, this macro generates a message if the code runs at IRQL >= DISPATCH_LEVEL. Add the macro as the first statement in a routine to mark the whole routine as paged code, as the following example shows:
NTSTATUS
MyDriverXxx(
IN OUT PVOID ParseContext OPTIONAL,
OUT PHANDLE Handle
)
{
NTSTATUS Status;
PAGED_CODE();
.
.
.
}
To make sure that you are doing this correctly, run the Driver Verifier against your finished driver with the Force IRQL Checking option enabled. This option causes the system to automatically page out all pageable code every time that the driver raises IRQL to DISPATCH_LEVEL or above. Using the Driver Verifier, you can quickly find any driver bugs in this area. Otherwise, these bugs will typically be found only by customers and they can frequently be very hard for you to reproduce.
Isolating Pageable Code
A routine that uses a spin lock cannot be paged. However, in some cases you can isolate the operations that require a spin lock in a separate routine that will not be included in the pageable section.
For example, consider the following fragment:
// PAGED_CODE();
KeInitializeEvent( &event, NotificationEvent, FALSE );
irp = IoBuildDeviceIoControlRequest( IRP_MJ_DEVICE_CONTROL,
DeviceObject,
(PVOID) NULL,
0,
(PVOID) NULL,
0,
FALSE,
&event,
&ioStatus );
if (irp) {
irpSp = IoGetNextIrpStackLocation( irp );
irpSp->MajorFunction = IRP_MJ_FILE_SYSTEM_CONTROL;
irpSp->MinorFunction = IRP_MN_LOAD_FILE_SYSTEM;
status = IoCallDriver( DeviceObject, irp );
if (status == STATUS_PENDING) {
(VOID) KeWaitForSingleObject( &event,
Executive,
KernelMode,
FALSE,
(PLARGE_INTEGER) NULL );
}
}
SPINLOCKUSE !
KeAcquireSpinLock( &IopDatabaseLock, &irql );
// Code inside spin lock …
DeviceObject->ReferenceCount--;
if (!DeviceObject->ReferenceCount && !DeviceObject->AttachedDevice) {
//Unload the driver
.
.
.
} else {
KeReleaseSpinLock( &IopDatabaseLock, irql );
}
The preceding routine could be made pageable (saving about 160 bytes) by moving the few lines of code that reference a spin lock into a separate routine.
In addition, remember that driver code must not be marked as pageable if it calls any KeXxx support routines, such as KeReleaseMutex or KeReleaseSemaphore, in which the Wait parameter is set to TRUE. Such a call returns with IRQL at DISPATCH_LEVEL and the dispatcher database locked.
Locking Pageable Code or Data
Certain drivers, such as the serial and parallel drivers, do not have to be resident unless the devices they manage are open. However, as long as there is an active connection or port, some part of the driver code that manages that port must be resident to service the device. When the port or connection is not being used, the driver code is not required. In contrast, a driver for a disk that contains system code, application code, or the system paging file must always be memory-resident because the driver constantly transfers data between its device and the system.
A driver for a sporadically used device (such as a modem) can free system space when the device it manages is not active. If you place in a single section the code that must be resident to service an active device, and if your driver locks the code in memory while the device is being used, that section can be designated as pageable. When the driver's device is opened, the operating system brings the pageable section into memory and the driver locks it there until no longer needed.
The system CD audio driver code uses this technique. Code for the driver is grouped into pageable sections according to the manufacturer of CD device. Certain brands might never be present on a given system. Also, even if a CD-ROM exists on a system, it might be accessed infrequently, so grouping code into pageable sections by CD type makes sure that code for devices that do not exist on a particular computer will never be loaded. However, when the device is accessed, the system loads the code for the appropriate CD device. Then the driver calls MmLockPagableCodeSection, as described below, to lock its code into memory while its device is being used.
To isolate the pageable code into a named section, mark it with the following compiler directive:
#pragma alloc_text(PAGEXxxx, RoutineName)
The section name must start with PAGE and must be followed by one to four characters that uniquely identify the driver's pageable section. The section name is case sensitive; that is, PAGE must be capitalized. The RoutineName identifies an entry point to be included in the pageable section.
For example, the following identifies RdrCreateConnection as an entry point within the PAGELK section:
#ifdef ALLOC_PRAGMA
#pragma alloc_text(PAGELK, RdrCreateConnection)
#endif
To make pageable driver code resident and locked, a driver calls MmLockPagableCodeSection, passing an address (typically the entry point of a driver routine) that is in the pageable code section. MmLockPagableCodeSection locks in the whole contents of the section that contains the routine referenced in the call. In other words, it makes resident and locks every routine associated with the same PAGEXxxx identifier.
MmLockPagableCodeSection returns a handle to be used when unlocking the section (MmUnlockPagableImageSection) or when the driver must lock the section from additional locations in its code.
A driver can also treat seldom-used data as pageable so that it, too, can be paged out until the device it supports is active. For example, the system mixer driver uses pageable data. The mixer device has no asynchronous I/O associated with it, so this driver can make its data pageable.
To create a pageable data section, use the following compiler directive at the beginning of the data module:
#pragma data_seg ("PAGE")
At the end of the module, use the following directive:
#pragma data_seg ()
The keyword PAGE is case sensitive, so it must be capitalized.
To make resident and lock the data section, a driver calls MmLockPagableDataSection, passing a data item that appears in the pageable data section. MmLockPagableDataSection returns a handle to be used in subsequent locking or unlocking requests.
To restore a locked section's pageable status, call MmUnlockPagableImageSection, passing the handle value returned by MmLockPagableCodeSection or MmLockPagableDataSection, as appropriate. A driver's Unload routine must call MmUnlockPagableImageSection to release each handle it has obtained for lockable code and data sections.
Locking a section is an expensive operation because the memory manager must search its loaded module list before locking the pages into memory. If a driver locks a section from many locations in its code, it should use the more efficient MmLockPagableSectionByHandle after its initial call to MmLockPagableXxxxSection.
The handle passed to MmLockPagableSectionByHandle is the handle returned by the earlier call to MmLockPagableCodeSection or MmLockPagableDataSection.
The memory manager maintains a count for each section handle and increments this count every time that a driver calls MmLockPagableXxx for that section. A call to MmUnlockPagableImageSection decrements the count. While the counter for any section handle is nonzero, that section remains locked in memory.
The handle to a section is valid as long as its driver is loaded. Therefore, a driver should call MmLockPagableXxxxSection only one time. If the driver requires additional locking calls, it should use MmLockPagableSectionByHandle.
If a driver calls any MmLockPagableXxxx routine for a section that is already locked, the memory manager increments the reference count for the section. If the section is paged out when the lock routine is called, the memory manager pages in the section and sets its reference count to one.
Using this technique minimizes the driver's effect on system resources. When the driver runs, it can lock into memory the code and data that must be resident. When there are no outstanding I/O requests for its device, (that is, when the device is closed or if the device was never opened), the driver can unlock the same code or data, making it available to be paged out.
However, after a driver has connected interrupts, any driver code that can be called during interrupt processing always must be memory resident. While some device drivers can be made pageable or locked into memory on demand, some core set of such a driver's code and data must be permanently resident in system space.
Consider the following implementation guidelines for locking a code or data section.
The primary use of the Mm(Un)LockXxx routines is to enable normally nonpaged code or data to be made pageable and brought in as nonpaged code or data. Drivers such as the serial driver and the parallel driver are good examples: if there are no open handles to a device such a driver manages, parts of code are not needed and can remain paged out. The redirector and server are also good examples of drivers that can use this technique. When there are no active connections, both of these components can be paged out.
The whole pageable section is locked into memory.
One section for code and one for data per driver is efficient. Many named, pageable sections are generally inefficient.
Keep purely pageable sections and paged but locked-on-demand sections separate.
Remember that MmLockPagableCodeSection and MmLockPagableDataSection should not be frequently called. These routines can cause heavy I/O activity when the memory manager loads the section. If a driver must lock a section from several locations in its code, it should use MmLockPagableSectionByHandle.
Paging an Entire Driver
A driver that uses the MmLockPagableXxx support routines and specifies paged and discardable sections consists of nonpaged sections, paged sections, and an INIT section that is discarded after driver initialization.
After a device driver connects interrupts for the devices it manages, the driver's interrupt handling path must be resident in system space. The interrupt-handling code must be part of the driver section that cannot be paged out, in case an interrupt occurs.
Two additional memory manager routines, MmPageEntireDriver and MmResetDriverPaging, can be used to override the pageable or nonpageable attributes of all sections that make up a driver image. These routines enable a driver to be paged out in its entirety when the device it manages is not being used and cannot generate interrupts.
Examples of system drivers that are completely pageable are the win32k.sys driver, the serial driver, the mailslot driver, the beep driver and the null driver.
A serial driver is typically used intermittently. Until a port it manages is opened, a serial driver can be paged out completely. As soon as a port is opened, the parts of the serial driver that must be memory-resident must be brought into nonpaged system space. Other parts of the driver can remain pageable.
A driver that can be completely paged out should call MmPageEntireDriver during driver initialization before interrupts are connected.
When a device managed by a paged-out driver receives an open request, the driver is paged in. Then, the driver must call MmResetDriverPaging before it connects to interrupts. Calling MmResetDriverPaging causes the memory manager to treat the driver's sections according to the attributes acquired during compilation and linkage. Any section that is nonpaged, such as a text section, will be paged into nonpaged system memory; pageable sections will be paged in as they are referenced.
Such a driver must keep a reference count of open handles to its devices. The driver increments the count at each open request for any device and decrements the count at each close request. When the count reaches zero, the driver should disconnect interrupts and then call MmPageEntireDriver. If a driver manages more than one device, the count must be zero for all such devices before the driver can call MmPageEntireDriver.
It is the driver's responsibility to do whatever synchronization is necessary when changing the reference count, and to prevent the reference count from changing while the pageable state of the driver is changing. That is, in SMP computers, the driver must make sure that MmPageEntireDriver cannot be in progress on one processor, while on another processor, an open call is causing interrupts to be connected and the reference count to be incremented.
How to Make Applets
This section covers JApplet — a class that enables applets to use Swing components. JApplet is a subclass of java.applet.Applet, which is covered in the Applets trail. If you've never written a regular applet before, we urge you to read that trail before proceeding with this section. The information provided in that trail applies to Swing applets, with a few exceptions that this section explains.
Any applet that contains Swing components must be implemented with a subclass of JApplet. Here's a Swing version of one of the applets that helped make Java famous — an animation applet that (in its most well known configuration) shows our mascot Duke doing cartwheels:
--------------------------------------------------------------------------------
Note: If you don't see the applet running above, you need to install release 6 of the JDK. You can find the main source code for this applet in TumbleItem.java.
This section discusses the following topics:
Features Provided by JApplet
Threads in Applets
Using Images in a Swing Applet
Embedding an Applet in an HTML Page
The JApplet API
Applet Examples
Features Provided by JApplet
Because JApplet is a top-level Swing container, each Swing applet has a root pane. The most noticeable effects of the root pane's presence are support for adding a menu bar and the need to use a content pane.
As described in Using Top-Level Containers, each top-level container such as a JApplet has a single content pane. The content pane makes Swing applets different from regular applets in the following ways:
You add components to a Swing applet's content pane, not directly to the applet. Adding Components to the Content Pane shows you how.
You set the layout manager on a Swing applet's content pane, not directly on the applet.
The default layout manager for a Swing applet's content pane is BorderLayout. This differs from the default layout manager for Applet, which is FlowLayout.
You should not put painting code directly in a JApplet object. See Performing Custom Painting for examples of how to perform custom painting in applets.
Threads in Applets
Swing components should be created, queried, and manipulated on the event-dispatching thread, but browsers don't invoke applet "milestone" methods from that thread. For this reason, the milestone methods — init, start, stop, and destroy — should use the SwingUtilities method invokeAndWait (or, if appropriate, invokeLater) so that code that refers to the Swing components is executed on the event-dispatching thread. More information about these methods and the event-dispatching thread is in Concurrency in Swing.
Here is an example of an init method:
public void init() {
//Execute a job on the event-dispatching thread:
//creating this applet's GUI.
try {
javax.swing.SwingUtilities.invokeAndWait(new Runnable() {
public void run() {
createGUI();
}
});
} catch (Exception e) {
System.err.println("createGUI didn't successfully complete");
}
}
private void createGUI() {
JLabel label = new JLabel(
"You are successfully running a Swing applet!");
label.setHorizontalAlignment(JLabel.CENTER);
label.setBorder(BorderFactory.createMatteBorder(1,1,1,1,Color.black));
getContentPane().add(label, BorderLayout.CENTER);
}
The invokeLater method is not appropriate for this implementation because it allows init to return before initialization is complete, which can cause applet problems that are difficult to debug.
The init method in TumbleItem is more complex, as the following code shows. Like the first example, this init method implementation uses SwingUtilities.invokeAndWait to execute the GUI creation code on the event-dispatching thread. This init method sets up a Swing timer to fire action events the update the animation. Also, init uses javax.swing.SwingWorker to create a background task that loads the animation image files, letting the applet present a GUI right away, without waiting for all resources to be loaded.
private void createGUI() {
...
animator = new Animator();
animator.setOpaque(true);
animator.setBackground(Color.white);
setContentPane(animator);
...
}
public void init() {
loadAppletParameters();
//Execute a job on the event-dispatching thread:
//creating this applet's GUI.
try {
javax.swing.SwingUtilities.invokeAndWait(new Runnable() {
public void run() {
createGUI();
}
});
} catch (Exception e) {
System.err.println("createGUI didn't successfully complete");
}
//Set up the timer that will perform the animation.
timer = new javax.swing.Timer(speed, this);
timer.setInitialDelay(pause);
timer.setCoalesce(false);
timer.start(); //Start the animation.
//Background task for loading images.
SwingWorker worker = (new SwingWorker() {
public ImageIcon[] doInBackground() {
final ImageIcon[] innerImgs = new ImageIcon[nimgs];
...//Load all the images...
return imgs;
}
public void done() {
//Remove the "Loading images" label.
animator.removeAll();
loopslot = -1;
try {
imgs = get();
} ...//Handle possible exceptions
}
}).execute();
}
You can find the applet's source code in TumbleItem.java. To find all the files required for the applet, including a link to a JNLP file that lets you run it using Java Web Start, see the example index.
Using Images in a Swing Applet
The Applet class provides the getImage method for loading images into an applet. The getImage method creates and returns an Image object that represents the loaded image. Because Swing components use Icons rather than Images to refer to pictures, Swing applets tend not to use getImage. Instead Swing applets create instances of ImageIcon — an icon loaded from an image file. ImageIcon comes with a code-saving benefit: it handles image tracking automatically. Refer to How to Use Icons for more information.
The animation of Duke doing cartwheels requires 17 different pictures. The applet uses one ImageIcon per picture and loads them in its init method. Because images can take a long time to load, the icons are loaded in a separate thread implemented by a SwingWorker object. Here's the code:
public void init() {
...
imgs = new ImageIcon[nimgs];
(new SwingWorker() {
public ImageIcon[] doInBackground() {
//Images are numbered 1 to nimgs,
//but fill array from 0 to nimgs-1.
for (int i = 0; i < nimgs; i++) {
imgs[i] = loadImage(i+1);
}
return imgs;
}
...
}).execute();
}
...
protected ImageIcon loadImage(int imageNum) {
String path = dir + "/T" + imageNum + ".gif";
int MAX_IMAGE_SIZE = 2400; //Change this to the size of
//your biggest image, in bytes.
int count = 0;
BufferedInputStream imgStream = new BufferedInputStream(
this.getClass().getResourceAsStream(path));
if (imgStream != null) {
byte buf[] = new byte[MAX_IMAGE_SIZE];
try {
count = imgStream.read(buf);
imgStream.close();
} catch (java.io.IOException ioe) {
System.err.println("Couldn't read stream from file: " + path);
return null;
}
if (count <= 0) {
System.err.println("Empty file: " + path);
return null;
}
return new ImageIcon(Toolkit.getDefaultToolkit().createImage(buf));
} else {
System.err.println("Couldn't find file: " + path);
return null;
}
}
The loadImage method loads the image for the specified frame of animation. It uses the getResourceAsStream method rather than the usual getResource method to get the images. The resulting code isn't pretty, but getResourceAsStream is more efficient than getResource for loading images from JAR files into applets that are executed using Java Plug-inTM software. For further details, see Loading Images Into Applets.
Embedding an Applet in an HTML Page
The recommended way to include an applet in an HTML page is using the APPLET tag. Here's the APPLET tag for the cartwheeling Duke applet:
< applet code="TumbleItem.class"
codebase="examples/"
archive="tumbleClasses.jar, tumbleImages.jar"
width="600" height="95">
Your browser is completely ignoring the <APPLET> tag!
< /applet>
To find out about the various < APPLET > tag parameters, refer to Using the applet Tag and Using the APPLET Tag .
The JApplet API
The next table lists the interesting methods that JApplet adds to the applet API. They give you access to features provided by the root pane. Other methods you might use are defined by the Component and Applet classes. See Component Methods for a list of commonly used Component methods, and Applets for help in using Applet methods.
Method Purpose
void setContentPane(Container)
Container getContentPane() Set or get the applet's content pane. The content pane contains the applet's visible GUI components and should be opaque.
void setRootPane(JRootPane)
JRootPane getRootPane() Create, set, or get the applet's root pane. The root pane manages the interior of the applet including the content pane, the glass pane, and so on.
void setJMenuBar(JMenuBar)
JMenuBar getJMenuBar() Set or get the applet's menu bar to manage a set of menus for the applet.
void setGlassPane(Component)
Component getGlassPane() Set or get the applet's glass pane. You can use the glass pane to intercept mouse events.
void setLayeredPane(JLayeredPane)
JLayeredPane getLayeredPane() Set or get the applet's layered pane. You can use the applet's layered pane to put components on top of or behind other components.
