This section describes the command-line options that can be used with jview.
Invokes the Microsoft AppletViewer. Applets that are run with the applet viewer behave the same as when run by a browser host application, including loading, sound, and security. The applet viewer accepts applet parameters and class names in addition to URLs and HTML files.
When the /a option is used, any remaining command-line tokens become parameters for the applet viewer.
You can load an applet either by using an HTML file to specify parameters, or by loading parameters directly from the command line. The following example shows how to load an applet from an HTML source file with the applet tag:
<applet code=MyApplet.class width=100 height=200> <param name=SomeName value=SomeValue></applet>
The same applet can run in the applet viewer with the following command line information:
jview /a width=100 height=200 SomeName=SomeValue MyApplet
The following example shows how to run more than one applet at a time:
jview /a width=200 height=400 MyApplet height=300 MySecondApplet
This displays the first applet in a 200 x 400 frame, and the second applet in a 200 x 300 frame. If no height and width are specified on the command line, the applet's default size is one-third of the size of the screen.
The following code shows that any parameter, including HTML files, can be loaded from the class path:
jview /a /cp \src\bvt MyApplet.html
Sets the CLASSPATH environment variable. This option specifies the path where jview can find system and user-defined classes. The Java interpreter uses a platform-dependent default location and the CLASSPATH environment variable to find system classes. For more information, see CLASSPATH Environment Variable. The directories in the class path are separated by semicolons on a Microsoft® Windows® system; on UNIX, by colons.
For example, on Microsoft® Windows NT®, the class path might be as follows:
jview /cp x:.;x:\java\classes
In this example, jview searches in and beneath the directories on the path for system and user-defined classes.
Appends the path entered to the end of the existing class path and inserts a semicolon (;) between them.
Note The value for the existing class path can come from the CLASSPATH environment variable or from the /cp option. When multiple /cp:a switches are entered, the paths are concatenated.
For example, the following command concatenates the directories myproj1 and myproj2, and appends the resulting path to the end of the existing class path:
jview /cp:a myproj1 /cp:a myproj2
Prepends the path entered to the beginning of the existing class path and inserts a semicolon (;) between them. When multiple /cp:p switches are entered, the paths are concatenated.
Note The value for the class path can come from the CLASSPATH environment variable or from the /cp option. When multiple /cp:p switches are entered, the paths are concatenated.
For example, the following command concatenates the myproj1 and myproj2 directories, and inserts the resulting path before the existing class path:
jview /cp:p myproj1/cp:p myproj2
Sets a system property, which can be read using the java.lang.System.getProperty or java.lang.System.getProperties methods. See these methods for descriptions of system properties.
For example, you can use the following command line to set the user.dir property to some arbitrary value:
jview /d:user.dir=c:\java\test myapp
You can also set user-defined properties. For example, you can set a property called myprop with the following command line:
jview /d:myprop=12 myapp
Specifies a namespace to run the application in. Separate namespaces allow Java packages with identical names to exist without conflict. The Microsoft Java Package Manager stores packages in a global namespace and searches there for packages if no namespace is specified to its API elements (for example, the contents of classes.zip is stored in the global namespace). Be aware that applications running in the namespace specified with the /n switch cannot access other namespaces.
Causes jview to pause before exiting if an error occurs. You can use this to determine the user interface state just prior to the error when debugging an application.
/prof[:<parameter>, <parameter>, …]
The parameters shown in the following table can be used.
Parameter | Description |
call[time]s[=<methods>] | Shows time execution in the specified methods. |
calltrace[=<methods>] | Prints entry and exit messages. |
callparams[=<methods>] | Prints parameters and return values. |
permethodalloc | Counts per-method allocations. |
perclassalloc | Counts per-class allocations. |
gc | Prints per-garbage-collection heap information. |
heapdump | Dumps a list of live objects at each garbage collection. |
file=<filename> | Appends profiling output to the specified file. |
sample[=<frequency>] | Samples method locations with the given frequency. |
verbose | Prints class loads and thread creations. |
table | Prints tabular output in simple space-delimited form. |
For examples of how to use /prof with its parameters and view the profiler results, see the Jview Profiler Sample in the \Samples\Profiler\jviewprf directory (Samples Overview).
Causes jview to verify all invoked methods. Without this option, only methods from untrusted loaders are verified. The verification process is applied to bytecode that is loaded from the class files. This ensures that they don't pose a security threat. For remotely loaded class files, the Microsoft virtual machine (Microsoft VM) only allows a subset of the total functionality possible with bytecode. Verification enforces this: If your class files attempt to do anything illegal, they are rejected.
For performance reasons, local system classes are not normally verified. The /v option forces the verifier to process these. Use this option to ensure that a set of class files will pass the verifier.
Prints verbose stack traces; must be used with debug classes.
Displays jview usage information including a list of command-line options.