import java.awt.*;
import java.applet.*;

public class GuiExample extends Applet
{

// A Button to click
Button okButton;

// A textField to get text input
TextField nameField;

// A group of radio buttons
// necessary to only allow one radio button to be selected at the same time

CheckboxGroup radioGroup;
// The radio buttons to be selected
Checkbox radio1;
Checkbox radio2;

// An independant selection box
Checkbox option;

public void init()
{

// Tell the applet not to use a layout manager.
setLayout(null);

// initialze the button and give it a text.
okButton = new Button(“A button”);

// text and length of the field
nameField = new TextField(“A TextField”,100);

// initialize the radio buttons group
radioGroup = new CheckboxGroup();

// first radio button. Gives the label text, tells to which
// group it belongs and sets the default state (unselected)
radio1 = new Checkbox(“Radio1″, radioGroup,false);

// same but selected
radio2 = new Checkbox(“Radio2″, radioGroup,true);

// Label and state of the checkbox
option = new Checkbox(“Option”,false);

// now we will specify the positions of the GUI components.// this is done by specifying the x and y coordinate and
//the width and height.

okButton.setBounds(20,20,100,30);
nameField.setBounds(20,70,100,40);
radio1.setBounds(20,120,100,30);
radio2.setBounds(140,120,100,30);
option.setBounds(20,170,100,30);

// now that all is set we can add these components to the applet
add(okButton);
add(nameField);
add(radio1);
add(radio2);
add(option);
}

}

// Thats’s it, you now have given the user visual options.
// However there are no actions related to these comonents.
// that makes it easier to place components.

Related Post

Q. How do I select a URL from my Applet and send the browser to that page?
A. Ask the applet for its applet context and invoke showDocument() on that context object.
URL targetURL;

String URLString
AppletContext context = getAppletContext ( );
try
{
targetURL = new URL ( URLString ) ;
}
catch ( MalformedURLException e )
{
/ / Code for recover from the exception
}
context. showDocument ( targetURL );

Q. How do I let an applet read a file?
A. Applets loaded into a Java-enabled browser can’t read files. Sun’s appletviewer allows applets to read files that are named on the access control list for reading. The access control list for reading is null by default, in the JDK.

You can allow applets to read directories or files by naming them in the acl.read property in
your ~ / . hotjava / properties file.
Note: The ” ~ ” ( tilde ) symbol is used on UNIX systems to refer to your home directory. If you install a web browser on your F : \ drive on your PC, and create a top-level directory named .hotjava, then your properties file is found in F: \ . hotjava \ properties.
For example, to allow any files in the directory home / me to be read by applets loaded into
the appletviewer, add this line to your ~ / .hotjava / properties file.
acl.read= / home / me
You can specify one file to be read:
acl.read= / home / me / somedir / somefile
Use “:” to separate entries:
acl.read= / home / foo : / home / me / somedir / somefile
Allowing an applet to read a directory means that it can read all the files in that directory, including any files in any subdirectories that might be hanging off that directory.

Q. How do I let an applet write a file?
A. Applets loaded into a Java-enabled browser can’t write files. Sun’s appletviewer allows applets to write files that are named on the access control list for writing. The access control list for writing is empty by default. You can allow applets to write to your / tmp directory by setting the acl.write property in your
~ / . hotjava / properties file:
acl.write= / tmp
You can allow applets to write to a particular file by naming it explicitly:
acl.write= / home / me / somedir / somefile
Use : to separate entries:
acl.write= / tmp: / home / me / somedir / somefile
Bear in mind that if you open up your file system for writing by applets, there is no way to limit the amount of disk space an applet might use.

Q. What system properties can be read by applets, and how?
A. In both Java-enabled browsers and the appletviewer, applets can read these system properties by invoking System.getProperty(String key):
key meaning
____________ ______________________________
java.version Java version number
java.vendor Java vendor-specific string
java.vendor.url Java vendor URL
java.class.version Java class version number
os.name Operating system name
os.arch Operating system architecture
os.version Operating system version
file.separator File separator (eg, ” / “)
path.separator Path separator (eg, ” : “)
line.separator Line separator

Applets are prevented from reading these system properties:
key meaning
____________ _____________________________
java.home Java installation directory
java.class.path Java classpath
user.name User account name
user.home User home directory
user.dir User’s current working directory
To read a system property from within an applet, simply invoke System.getProperty(key) on

the property you are interested in.
For example,
String s = System.getProperty(” os.name “);

Q. Can I use a “native” two-tier driver for a browser applet?
A. No. Within an unsigned applet, you cannot load native libraries over the wire, access the local file system, or connect to any host except the host from which you loaded the applet. The applet security manager enforces these restrictions on applets as protection against applets being able to do unsavory things to unsuspecting users.

Q. Why doesn’t my browser applet connect to the database?
A. If Appletviewer works and Netscape does not, it is an indication that you are violating a Netscape security restriction. In this case, the violation is that an applet cannot open a socket to a machine other than the one from which it loaded the applet. To solve this problem, you will have to serve your applet code from the same machine that hosts the DBMS.

Q. How do I hide system properties that applets are allowed to read by default?
A. There’s no way to hide the above ten system properties from applets loaded into a Java-enabled browser. The reason is that the browsers don’t consult any external files as part their Java configuration, as a security precaution, including the ~ / .hotjava / properties file.
From the appletviewer, you can prevent applets from finding out anything about your system by redefining the property in your ~ / . hotjava / properties file. For example, to hide the name of the operating system that you are using, add this line to your ~ / .hotjava / properties file:
os.name=null

Q. How can I allow applets to read system properties that they aren’t allowed to read by default?
A. There’s no way to allow an applet loaded into a Java-enabled browser to read system properties that they aren’t allowed to read by default. To allow applets loaded into the appletviewer to read the property named by key, add the property
key.applet=true to your ~ / .hotjava / property file. For example, to allow applets to record your user name, add this line to your ~ / .hotjava / properties file:
user.name.applet=true

Q. How can an applet open a network connection to a computer on the internet?
A. Applets are not allowed to open network connections to any computer, except for the host that provided the .class files. This is either the host where the html page came from, or the host specified in the codebase parameter in the applet tag, with codebase taking precendence.
For example, if you try to do this from an applet that did not originate from the machine foo.com, it will fail with a security exception:
Socket s = new Socket(“foo.com”, 25, true);

Q. How can an applet open a network connection to its originating host?
A. Be sure to name the originating host exactly as it was specified when the applet was loaded into the browser. That is, if you load an HTML page using the URL
http: / / foo.state.edu / ~ me / appletPage.html
then your applet will be able to connect to its host only by using the name foo.state.edu.
Using the IP address for foo.state.edu won’t work, and using a “shorthand” form of the host name, like foo.state instead of foo.state.edu, won’t work.

Q. How can an applet maintain persistent state?
A. There is no explicit support in the JDK applet API for persistent state on the client side. However, an applet can maintain its own persistent state on the server side. That is, it can create files on the server side and read files from the server side.

Q. Can an applet start another program on the client?
A. No, applets loaded over the net are not allowed to start programs on the client. That is, an applet that you visit can’t start some rogue process on your PC. In UNIX terminology, applets are not allowed to exec or fork processes. In particular, this means that applets can’t invoke some program to list the contents of your file system, and it means that applets can’t invoke System.exit() in an attempt to kill your web browser. Applets are also not allowed to manipulate threads outside the applet’s own thread group.

Q. What is the difference between applets loaded over the net and applets loaded via the file system?
A. There are two different ways that applets are loaded by a Java system. The way an applet enters the system affects what it is allowed to do. If an applet is loaded over the net, then it is loaded by the applet class loader, and is subject to the restrictions enforced by the applet security manager. Java-enabled browsers use the applet class loader to load applets specified with file: URLs.
So, the restrictions and protections that accrue from the class loader and its associated security manager are now in effect for applets loaded via file: URLs. This means that if you specify the URL like so:
Location: file : / home / me / public_html / something.html
and the file something.html contains an applet, the browser loads it using its applet class loader.

Q. What’s the applet class loader, and what does it?
A. Applets loaded over the net are loaded by the applet class loader. For example, the appletviewer’s applet class loader is implemented by the class sun.applet.AppletClassLoader. The class loader enforces the Java name space hierarchy. The class loader guarantees that a unique namespace exists for classes that come from the local file system, and that a unique namespace exists for each network source. When a browser loads an applet over the net, that applet’s classes are placed in a private namespace associated with the applet’s origin. Thus, applets loaded from different network sources are partitioned from each other.
Also, classes loaded by the class loader are passed through the verifier. The verifier checks that the class file conforms to the Java language specification – it doesn’t assume that the class file was produced by a ” friendly ” or ” trusted ” compiler. On the contrary, it checks the class file for purposeful violations of the language type rules and name space restrictions. The verifier ensures that
• There are no stack overflows or underflows.
• All register accesses and stores are valid.
• The parameters to all bytecode instructions are correct.
• There is no illegal data conversion.
The verifier accomplishes that by doing a data-flow analysis of the bytecode instruction stream, along with checking the class file format, object signatures, and special analysis of finally clauses that are used for Java exception handling.
A web browser uses only one class loader, which is established at start-up. Thereafter, the system class loader cannot be extended, overloaded, overridden or replaced. Applets cannot create or reference their own class loader.

Q. What’s the applet security manager, and what does it?
A. The applet security manager is the Java mechanism for enforcing the applet restrictions described above. The appletviewer’s applet security manager is implemented by sun.applet.AppletSecurity. A browser may only have one security manager. The security manager is established at startup, and it cannot thereafter be replaced, overloaded, overridden, or extended. Applets cannot create or reference their own security manager.

Q. If other languages are compiled to Java bytecodes, how does that affect the applet security model?
A. The verifier is independent of Sun’s reference implementation of the Java compiler and the high-level specification of the Java language. It verifies bytecodes generated by other Java compilers. It also verifies bytecodes generated by compiling other languages into the bytecode format. Bytecodes imported over the net that pass the verifier can be trusted to run on the Java virtual machine. In order to pass the verifier, bytecodes have to conform to the strict typing, the object signatures, the class file format, and the predictability of the runtime stack that are all defined by the Java language implementation.

Related Post

appletviewer .class or .html file

Q. Should applets have constructors?
A. We don’t have the concept of Constructors in Applets. Applets can be invoked either through browser or through Appletviewer utility provided by JDK.

Q. What are the Applet’s Life Cycle methods? Explain them? –
A. Following are methods in the life cycle of an Applet:
• init() method – called when an applet is first loaded. This method is called only once in the entire cycle of an applet. This method usually intialize the variables to be used in the applet.
• start( ) method – called each time an applet is started.
• paint() method – called when the applet is minimized or refreshed. This method is

used for drawing different strings, figures, and images on the applet window.
• stop( ) method – called when the browser moves off the applet’s page.
• destroy( ) method – called when the browser is finished with the applet.

Q. what are Standalone Java application ?
A. Java program that is run by invoking the java interpreter.
For example, java coolApplication Server. The computer that hosts the web page that contains an applet. The .class files that make up the applet, and the .html files that reference the applet, reside on the server. When someone on the internet connects to a web page that contains an applet, the server delivers the .class files over the internet to the client that made the request. The server is also known as the originating host.
Client The computer that displays the web page that contains an applet. The terms server and client are sometimes used to refer to computers, and are sometimes used to refer to computer programs.

Q. How do Applets differ from Applications?
A. Following are the main differences: Application: Stand Alone, doesn’t needweb-browser. Applet: Needs no explicit installation on local machine. Can be transferred through Internet on to the local machine and may run as part of web-browser. Application:
Execution starts with main() method. Doesn’t work if main is not there. Applet: Execution starts with init() method. Application: May or may not be a GUI. Applet: Must run within a GUI (Using AWT). This is essential feature of applets.

Q. Can we pass parameters to an applet from HTML page to an applet? How?
A. We can pass parameters to an applet using <param> tag in the following way:
• <param name=”param1? value=”value1?>
• <param name=”param2? value=”value2?>
Access those parameters inside the applet is done by calling getParameter() method inside the applet. Note that getParameter() method returns String value corresponding to the parameter name.

Q. What is AppletStub Interface?

A. The applet stub interface provides the means by which an applet and the browser communicate. Your code will not typically implement this interface.

Q. What tags are mandatory when creating HTML to display an applet?
A.
1. name, height, width
2. code, name
3. codebase, height, width
4. code, height, width
Correct answer is d.

Q. Can applets on different pages communicate with each other?
A. No, Not Directly. The applets will exchange the information at one meeting place either on the local file system or at remote system.

Q. Which classes and interfaces does Applet class consist?
A. Applet class consists of a single class, the Applet class and three interfaces:
—>AppletContext, AppletStub, and AudioClip.

Q. What are applets prevented from doing?
A. In general, applets loaded over the net are prevented from reading and writing files on the client file system, and from making network connections except to the originating host. In addition, applets loaded over the net are prevented from starting other programs on the client. Applets loaded over the net are also not allowed to load libraries, or to define native method calls. If an applet could define native method calls, that would give the applet direct access to the underlying computer. There are other specific capabilities denied to applets loaded over the net, but most of the applet security policy is described by those two paragraphs above. Read on for the gory details.

Q. Can applets read or write files?
A. In Java-enabled browsers, untrusted applets cannot read or write files at all. By default, downloaded applets are considered untrusted. There are two ways for an applet to be considered trusted:
The applet is installed on the local hard disk, in a directory on the CLASSPATH used by the program that you are using to run the applet. Usually, this is a Java-enabled browser, but it could be the appletviewer, or other Java programs that know how to load applets.
Sun’s appletviewer allows applets to read files that reside in directories on the access control lists.
If the file is not on the client’s access control list, then applets cannot access the file in any way. Specifically, applets cannot
• check for the existence of the file
• read the file
• write the file
• rename the file
• create a directory on the client file system
• list the files in this file (as if it were a directory)
• check the file’s type
• check the timestamp when the file was last modified
• check the file’s size

Random Posts