Using Images: Applet vs. Application

The following code works fine in an Application (uses main as entry point) when deployed to a jar file, but it doesn't work with an Applet (using init rather than main as the entry point) when deployed to a jar file.

ImageIcon image = new ImageIcon("pic.jpg", "Picture!");

It works fine inside of JDeveloper, but doesn't work with appletviewer at the command prompt. Appletviewer simply exits without complaining, but running it within a web browser cause the java console to report:

java.security.AccessControlException: access denied(java.io.FilePermission pic.jpg read)

Can anyone tell me why?

[637 byte] By [benobo] at [2007-9-27 19:49:43]
# 1

Applets need security authorization and must be signed to access files.

Check the subject in the Tutorial, or search the Forums fo more information.

The various ways of displaying (IDE, appletviewer, browsers) applets will result in various responses.

Applications are not subject to the same security restrictions, and so run unfettered.

This restriction is to prevent foreign "untrusted" applets from doing harm.

ChuckBing at 2007-7-6 23:20:35 > top of Java-index,Desktop,Core GUI APIs...
# 2
In an Applet you have to load from a URL not from a file.URL url = new URL(getCodeBase()+"pic.jpg");ImageIcon icon = new ImageIcon(url);Noah
noah.w at 2007-7-6 23:20:35 > top of Java-index,Desktop,Core GUI APIs...
# 3

Thanks for your replies, chuckbing and noah. I ended up using the following coding to find the images in the jar on the http server:

URL picURL = new URL(this.getClass().getResource("pic.jpg").toString());

Here are some miscellaneous notes for anyone. Hope they help, especially if your frustration reduced you to using keywords like "APPLETS SUCK!" or "APPLETVIEWER SUCKS!". Please forgive me if my perspective (or my analysis, for that matter) is skewed.

APPLETS AND APPLICATIONS

Applets have more restrictions than Applications. Basically, Applets

can only talk to the IP address that they came from, so if you

are trying to connect to a database, make sure that the applet

comes from the same IP address as the SQL server.

LOADING IMAGES FROM JARS IN APPLETS:

If you are trying to load images from a jar use an URL (either static or dynamically generated) that points to the jar on the server. Make sure to use a URL declares the http server's IP address.

Stupid Hint Question Number N: If you are trying to get images from a jar and some of your Images are loading and others aren't, are you sure that you are getting the loaded images from the jar? :)

NOTES ON USING NETSCAPE:

With the latest version of the Sun Java Plug-in, version 6.2 worked using <APPLET>, <OBJECT> or <OBJECT><EMBED> coding (see example below). Version 4.7 requires the <OBJECT><EMBED> coding (see example below).

NOTES ON USING the MS VM and the SUN JVM in MSIE 6.0:

Ultimately, How an applet performs depends upon the virtual machine

(VM or JVM) employed by the browser.

The native Microsoft IE VM displays feedback useful during

development in the Java Console under the View option. However, the MS VM doesn't know about JApplet and a lot of other classes, so if they aren't included in your Jar, you'll get class not found exceptions.

One may install the Sun JVM and subsequently find the Sun Java Console

selection under Tools. Once the Sun JVM is installed, one may switch back to the Microsoft VM setting by changing the setting under

Tools/Internet Options/Advanced (restart req'd). Using the native IE 6.0 VM setting in MS IE may not work in some cases unless the applet is designed to run in that environment. It may SEEM to work if the Sun JVM is installed and the html <OBJECT> tag that points to the JRE that does work. The <APPLET> tag is deprecated, and perhaps does not allow one to point to another more suitable VM, so the applet will not be able to run unless the applet is compatible with the MS VM.

Here follows and example of the <OBJECT> coding (with the <EMBED> coding required for Netscape 4.7), as follows:

<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"

width="700" height="400" align="middle"

codebase="http://java.sun.com/products/plugin/1.4/jinstall-14-win32.cab#Version=1,4,0,mn"

alt="This is a test applet with a picture of Lea Anna Davis and some DB output">

<PARAM NAME="code" VALUE="Appletname.class">

<PARAM NAME="images" VALUE="Jarname.jar">

<PARAM NAME="codebase" VALUE=".">

<PARAM NAME="archive" VALUE="FourthProject.jar">

<PARAM NAME="type" VALUE="application/x-java-applet;version=1.4">

<COMMENT>

<EMBED type="application/x-java-applet;version=1.4"

width="700" height="400" align="middle"

alt=" This is a test applet "

code="Appletname"

archive="Jarname.jar"

codebase="."

pluginspage="http://javaweb.eng/plugin/1.4/plugin-install.html">

<NOEMBED></COMMENT>

No Java 2 SDK, Standard Edition v 1.4 support for APPLET!!

</NOEMBED></EMBED>

</OBJECT>

JDeveloper 3.1 will automatically set up an html file for your applet using the <APPLET> tag even though it is not able to point to the correct JVM. Setting the IE browser to use the Sun JVM (as does the SUN installation) allows for the more simple, but deprecated coding, as follows:

<APPLET CODE = "Applename" ARCHIVE="Jarname.jar" WIDTH = 700 HEIGHT = 400 ALIGN = middle NAME="VLookup" >

In general, the Sun Java Console provides more feedback, but unless one uses the <APPLET> tag there will be no output to the Sun Java Console unless an exception is thrown. In the absence of thrown exceptions, one may not be able to open the Sun Java Console even if there is output from something like System.out.println.

If during testing, you are switching back and forth between a page with <APPLET> and a page with <OBJECT> coding (proceeding from one to the other directly or indirectly with other pages intervening),

the Sun Java Plug-in will detect a JRE collission. There will be an error message requesting to start a new instance of the browser to resolve the difficulty. If you say no the "Java Plug-in

detected JRE collision" message will simply appear in the applet's place.

NOTES ON APPLETVIEWER: Within and Without JDeveloper

Outside the JDeveloper environment Appletviewer seems to

prefer the <OBJECT> tag. It doesn't seem to work with

the html <APPLET> tag ... no complaint, just exits quietly.

Using the <object> tag seems to work and feedback is

is echoed to the console.

If you use the <EMBED> tag within the <OBJECT> tag, the .class

extension on the Appletname seems to confuse Appletviewer:

Leave it off unless you want a class not found exception.

Running Appletviewer from within JDeveloper will

successfully use the <applet> tag and JDev (apparently)

will call Appletviewer with the priviledges of

an application, so connection to a database using

Appletviewer within JDeveloper is possible.

Appletviewer is used as follows:

appletviewer FourthProject.html

or

appletviewer http://205.223.179.81/danm/FourthProjectx.html

or if you want debug mode

appletviewer -debug FourthProject.html

Debug mode provides a command prompt, so you'll have to enter "run".

Other available options are displayed by entering "help" but as a beginner I found the debug mode to be meaningless in an interesting sort of way.

IE also has debug .dlls for its native VM which may be downloaded from MS but so far I haven't found the output to be significantly different from that of the retail .dlls

benobo at 2007-7-6 23:20:35 > top of Java-index,Desktop,Core GUI APIs...
# 4

Thanks for your replies, chuckbing and noah. I ended up using the following coding to find the images in the jar on the http server:

URL picURL = new URL(this.getClass().getResource("pic.jpg").toString());

Here are some miscellaneous notes for anyone. Hope they help, especially if your frustration reduced you to using keywords like "APPLETS SUCK!" or "APPLETVIEWER SUCKS!". Please forgive me if my perspective (or my analysis, for that matter) is skewed.

APPLETS AND APPLICATIONS

Applets have more restrictions than Applications. Basically, Applets

can only talk to the IP address that they came from, so if you

are trying to connect to a database, make sure that the applet

comes from the same IP address as the SQL server.

LOADING IMAGES FROM JARS IN APPLETS:

If you are trying to load images from a jar use an URL (either static or dynamically generated) that points to the jar on the server. Make sure to use a URL declares the http server's IP address.

Stupid Hint Question Number N: If you are trying to get images from a jar and some of your Images are loading and others aren't, are you sure that you are getting the loaded images from the jar? :)

NOTES ON USING NETSCAPE:

With the latest version of the Sun Java Plug-in, version 6.2 worked using <APPLET>, <OBJECT> or <OBJECT><EMBED> coding (see example below). Version 4.7 requires the <OBJECT><EMBED> coding (see example below).

NOTES ON USING the MS VM and the SUN JVM in MSIE 6.0:

Ultimately, How an applet performs depends upon the virtual machine

(VM or JVM) employed by the browser.

The native Microsoft IE VM displays feedback useful during

development in the Java Console under the View option. However, the MS VM doesn't know about JApplet and a lot of other classes, so if they aren't included in your Jar, you'll get class not found exceptions.

One may install the Sun JVM and subsequently find the Sun Java Console

selection under Tools. Once the Sun JVM is installed, one may switch back to the Microsoft VM setting by changing the setting under

Tools/Internet Options/Advanced (restart req'd). Using the native IE 6.0 VM setting in MS IE may not work in some cases unless the applet is designed to run in that environment. It may SEEM to work if the Sun JVM is installed and the html <OBJECT> tag that points to the JRE that does work. The <APPLET> tag is deprecated, and perhaps does not allow one to point to another more suitable VM, so the applet will not be able to run unless the applet is compatible with the MS VM.

Here follows and example of the <OBJECT> coding (with the <EMBED> coding required for Netscape 4.7), as follows:

<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"

width="700" height="400" align="middle"

codebase="http://java.sun.com/products/plugin/1.4/jinstall-14-win32.cab#Version=1,4,0,mn"

alt="This is a test applet with a picture of Lea Anna Davis and some DB output">

<PARAM NAME="code" VALUE="Appletname.class">

<PARAM NAME="images" VALUE="Jarname.jar">

<PARAM NAME="codebase" VALUE=".">

<PARAM NAME="archive" VALUE="FourthProject.jar">

<PARAM NAME="type" VALUE="application/x-java-applet;version=1.4">

<COMMENT>

<EMBED type="application/x-java-applet;version=1.4"

width="700" height="400" align="middle"

alt=" This is a test applet "

code="Appletname"

archive="Jarname.jar"

codebase="."

pluginspage="http://javaweb.eng/plugin/1.4/plugin-install.html">

<NOEMBED></COMMENT>

No Java 2 SDK, Standard Edition v 1.4 support for APPLET!!

</NOEMBED></EMBED>

</OBJECT>

JDeveloper 3.1 will automatically set up an html file for your applet using the <APPLET> tag even though it is not able to point to the correct JVM. Setting the IE browser to use the Sun JVM (as does the SUN installation) allows for the more simple, but deprecated coding, as follows:

<APPLET CODE = "Applename" ARCHIVE="Jarname.jar" WIDTH = 700 HEIGHT = 400 ALIGN = middle NAME="VLookup" >

In general, the Sun Java Console provides more feedback, but unless one uses the <APPLET> tag there will be no output to the Sun Java Console unless an exception is thrown. In the absence of thrown exceptions, one may not be able to open the Sun Java Console even if there is output from something like System.out.println.

If during testing, you are switching back and forth between a page with <APPLET> and a page with <OBJECT> coding (proceeding from one to the other directly or indirectly with other pages intervening),

the Sun Java Plug-in will detect a JRE collission. There will be an error message requesting to start a new instance of the browser to resolve the difficulty. If you say no the "Java Plug-in

detected JRE collision" message will simply appear in the applet's place.

NOTES ON APPLETVIEWER: Within and Without JDeveloper

Outside the JDeveloper environment Appletviewer seems to

prefer the <OBJECT> tag. It doesn't seem to work with

the html <APPLET> tag ... no complaint, just exits quietly.

Using the <object> tag seems to work and feedback is

is echoed to the console.

If you use the <EMBED> tag within the <OBJECT> tag, the .class

extension on the Appletname seems to confuse Appletviewer:

Leave it off unless you want a class not found exception.

Running Appletviewer from within JDeveloper will

successfully use the <applet> tag and JDev (apparently)

will call Appletviewer with the priviledges of

an application, so connection to a database using

Appletviewer within JDeveloper is possible.

Appletviewer is used as follows:

appletviewer FourthProject.html

or

appletviewer http://205.223.179.81/danm/FourthProjectx.html

or if you want debug mode

appletviewer -debug FourthProject.html

Debug mode provides a command prompt, so you'll have to enter "run".

Other available options are displayed by entering "help" but as a beginner I found the debug mode to be meaningless in an interesting sort of way.

IE also has debug .dlls for its native VM which may be downloaded from MS but so far I haven't found the output to be significantly different from that of the retail .dlls

benobo at 2007-7-6 23:20:35 > top of Java-index,Desktop,Core GUI APIs...
# 5
So what about the dukes ?Noah
noah.w at 2007-7-6 23:20:35 > top of Java-index,Desktop,Core GUI APIs...