<applet> tag vs. <object> tag - Java Applet Development

What's the current thinking on this? There was a huge effort a few years ago to get us all to use the object tag, with all its additional browser dependencies ... Seems to me that's all crazy, that all browsers will have to support the applet tag forever, and we should all just keep our lives simple. Is there anything against this? I'm investigating some problems with a pretty standard applet that just doesn't launch in some browsers, e.g. Chrome, ... 

To answer my own question, we did some experiments.
|*Tag*|*Browser*|*result*|
|applet|IE7|OK|
|applet|IE8|OK|
|applet|FireFox|OK|
|applet|Safari|Nothing|
|applet|Chrome|Nothing|
|object|IE7|Empty box|
|object|IE8|Empty box|
|object|FireFox|OK|
|object|Safari|OK|
|object|Chrome|OK|
Tested on Windows XP, Vista, and MacOS where possible.
So the <object> tag works in all browsers except IE, and in fact IE does support a different (needless to say) form of it requiring two tags.
I suspect the above is a bit skewed by the fact that we are using strict XHTML, for other reasons (i.e. to tame IE again in other ways), and <applet> isn't part of XHTML Strict. I would guess that otherwise the <applet> tag would have worked in all browsers. 

All the applets I have ever done have been used by windows users and I've only ever used the applet tag but...
isn't JNLP supposed to solve all this?
[http://download-llnw.oracle.com/javase/tutorial/deployment/applet/deployingApplet.html]
I mean it's JavaScript with a bunch of magical detection. 

ejp wrote:
What's the current thinking on this? It's all about minimum version, really. Do you have a target audience for the applets, with a set minimum JRE to work to? Or alternately are your applets provided on the World Wild Web for all comers?
If the former, I'd go with the applet element & HTML 4.01 Transitional for the web page.
-------------------
If the latter, ..
..There was a huge effort a few years ago to get us all to use the object tag, ....Sun's HTML Converter & later the deployJava.js were devised to create nested object/embed tags. I had not seen any pages that ever recommended just the object element. I've not known the <object> element to be workable on all browsers, but the last time I tested was a while ago. Your test results suggest it is about the same now.
AFAIU Sun's deployJava.writes either object or embed elements in a general form similar to what the HTML Converter tool used to write as a single nested element. The JS approach is superior in that:
- Pages will validate.
- Browser determination, downloading a JRE if necessary & writing the tag is 'all done for you' (after configuring the attributes & parameters).
- Sun supports it and updates it - encouraging developers to hot-link to their script.
Disadvantages:
- Subject to breakage by Sun (who arguably produce the worst JS that this novice in JS has ever seen).
- Requires Sun server up.
- Requires internet connection.
- Requires JS enabled. (1)
The middle 2 can be fixed by hosting a copy of the script at a location the user's browser can access - but you do not get 'free' updates of course.
---------------------
There is also the JWS embedded applet, as already mentioned.
GifAnim is an example of that. It uses the JNLP services to access the file system even when sand-boxed - with the user's specific permission at the moment it attempts to do so. 

It's an Internet deployment to unknown customers so coverage is all. Network engineers, so I think I can safely stipulate Java 1.5 and the top four browsers whatever they are, my guess is IE, Firefox, Safari, and Chrome.
I'd love to go for the JNLP solution but I just tried it - OK in FF/XP but big blank nothing on Safari/MacOS, which isn't encouraging. Still I will repeat the experiment using JNLP everywhere and update.
Another thing the investigation turned up is that AT&T is still using IE6 and nothing later. 

ejp wrote:
..I'd love to go for the JNLP solution but I just tried it - ..It would seem the JNLP embedded applet is ruled out by the requirement for 1.5. Why not deploy the applet free-floating? 

ejp wrote:
It's an Internet deployment to unknown customers so coverage is all. Network engineers, so I think I can safely stipulate Java 1.5 and the top four browsers whatever they are, my guess is IE, Firefox, Safari, and Chrome.
I'd love to go for the JNLP solution but I just tried it - OK in FF/XP but big blank nothing on Safari/MacOS, which isn't encouraging. Still I will repeat the experiment using JNLP everywhere and update.
Another thing the investigation turned up is that AT&T is still using IE6 and nothing later.One of the customers I support at my main job, who is one of the largest hospitals here, is using IE5.
Well then maybe the solution is a detection script. I normally use jquery and let it sort out the browser mess but in this specific case I have heard of issues with FF with jquery and applets on the same page. 

#Andrew, does that only work with 1.6?
#Max, the applet is inside a Facelets page so detection of the browser isn't a problem ... I just want to find the minimal answer. I have it now rendering the applet tag for IE and the object tag for everything else, and I'm using Sun's script from the link you posted to enforce at least Java 1.5, and I suspect that's how it will stay unless I can get a JNLP solution working. I suppose I could enforce 1.6 and then use JNLP if that's what the current problem is ... Depending on user feedback too ... 

ejp wrote:
#Andrew, does that only work with 1.6?JWS was available (for either applets or frames) as a separate download since 1.2. It was co-bundled with the JRE in 1.4 or 1.4.2 (hazy on the details). It should support 1.5+ machines with no problems. 

That's what I thought, and I thought that's what I read at the link Max provided as well. I was wondering why you said the JNLP embedded applet was ruled out by the requirement for 1.5. Also what exactly you meant by 'free-floating'? 

ejp wrote:
That's what I thought, and I thought that's what I read at the link Max provided as well. I was wondering why you said the JNLP embedded applet was ruled out by the requirement for 1.5. Also what exactly you meant by 'free-floating'?An applet is normally 'embedded' in a web page while a frame is normally 'free-floating'.
- JWS could launch applets free-floating like a frame since 1.2.
- Since 1.6.0_10, JWS and JNLP services are also available to embedded applets. 

Ah OK thanks. That might also explain why the JNLP embedded applet launch failed on Safari/MacOS as I described above: I'm not sure where the Java on that box is up to. 

Updated results, now including Opera and JNLP:
|*Tag*|*Browser*|*Result*|
|applet|IE7|OK|
|"|IE8|OK|
|"|FireFox|OK|
|"|Safari|Nothing|
|"|Chrome|Nothing|
|"|Opera|OK|
|object|IE7|Empty box|
|"|IE8|Empty box|
|"|FireFox|OK|
|"|Safari|OK|
|"|Chrome|OK|
|"|Opera|OK|
|JNLP|IE7|Unknown (not available over the weekend)|
|"|IE8|OK|
|"|FireFox|OK|
|"|Safari|Nothing|
|"|Chrome|Nothing|
|"|Opera|OK|
This is now with DOCTYPE = XHTML Transitional.
The fact that JNLP didn't work on two out of the five platforms is pretty alarming.
My conclusion is that the simplest solution is to use <object> everywhere and just detect MSIE as a special case (as usual ;-)), for which you should use either <applet> or the special double-<object> form, if you can be bothered. I cant. 

It's really about <object> vs <embed> as <applet> is deprecated in HTML5.
I did quite a lot of work on this and created a page detailing [JNLP applets in XHTML|http://l0x.in/XML/XHTML/basic-applet.xhtml]
The method used on that page works on
Firefox
Chrome
Opera
IE9
But sadly not Safari, which I believe is a bug with Safari.
The page can't be viewed with IE7 or IE8 as it's XHTML and I've not tried JNLP's on either of those browsers. 

Thanks. The method I used, described above, works on them all.

Related

my applets can never be found...

I type in the following in my html document:
<applet code="Watch.class" height="50" width="345">
This program requires a Java-enabled browser.
</applet>
And then I make sure Watch.html and Watch.class are in the same directory...Whenever I load my html page in Internet Explorer it always tells me "load: class Watch not found"
How come it can't find it?
Tom Doganoglu
I am getting the same error message too.. but only on a Mac...(PC's work ok)
I used to get that message all the time when I was starting out, even on PCs.
Once I used the HTML Converter, which loads the java plug-in, all my applets worked. (and all but one worked on Mac, PC, and even Linux!).
It's really weird. Some applets work without the converter on the PC but need the converter for Mac (even though the Netscape version was the same!). Even java 1.1 programs seem to do this, despite the fact that N 4.7/ IE 5 are supposed to run it (without plugin).
Sometimes I find that I can run something in N 4.7 which doesn't run in IE 5 (but both work after using the plugin). (and vice-versa)
Try using the plug-in. The HTML Converter can be found in sun's web site. That puts out most (but not all) of the fires. If you've done that already, then I have no clue. I'm having the same problem
.
Hopefully there is someone on this forum who knows **why** all this weird behavior happens.
:-) JenMc 
It all depends on what you use in your applet. Applets using Swing (JButton, JPanels etc.) will need to be embedded into the HTML page differently than "ordinary" Java applets using the AWT (Panel, Button etc.)
There are tools and utilities (like the HTML Converter) that takes your applet code (<applet code=''....) and makes it suitable for Swing applets.
Ed 
But my Applet doesn't use Swing...and it still can't be loaded...
Tom Doganoglu
>
But my Applet doesn't use Swing...and it still can't
be loaded...
Tom DoganogluTom is absolutely right. I have NEVER used Swing in my applets, and I STILL got that error message. According to the docs, you should use the HTML Converter whenever you use **java 1.2**. (and if your browser is older) .
However, I have noticed that even this does not hold true. I have used purely 1.1 code (though my jdk is 1.2), and STILL got the message. I was testing an applet on my PC at home, and it worked fine without plugin. I went to school and tried it on a Mac, and it wouldn't even load (same netscape version 4.7!!).
Also I believe there is additional downloads you need to do for Swing. (That's why, even though I have the plug-in, I can't run any of the Swing-based applets in the tutorial/example section.) Am I correct?
I am totally sympathetic Tom.. I am in the same boat as you!
There are three things I do when I get this message:
-try different browsers. IE5 is somewhat more lax about security. Security is another thing that ties these buggers up! (You can also lower the security of your browser.) You should also check that your browser is Java enabled, Edit--> Preferences, Advanced.
-whenever I am trying to write an applet which will be viewed by lots of people, I ask the user to download the plug-in by using the HTML Converter. (I can make them do it.. I'm their teacher...) :-) hehehe. but this is sometimes impractical..
-painstakingly write in 1.0! (except now N 6 doesn't support that???) If you can identify 1.2 code and replace it with older code, you should (according to the docs) be able to view it with N3 IE5.
But as I wrote in my last post "Mac Trouble", writing in 1.0 is a drag, and java 1.2 doesn't always work even with the plug in (jre for mac is not yet up to 1.2???)
So what should we do, java gurus?
:-) JenMc

Applet testing / browser cache clearing

The applet forum returns nil. Google returns misinformation. Here's a Duke a browser.
I test an applet. Bug. Fix. Retest shows old result because browser cached applet and doesn't know that I've a newer version. Looking for a better solution than closing/reopening browser.
Netscape (Mozilla/Firefox)?
Opera?
Solved IE: Tools / Internet Options / General / Delete Files 
Open the Java console and clear the cache by typing x. 
Holding down the shift key while clicking on refresh used to work; don't know if it still does. 
the shift-reload thing only works on some browser for applets...
IF you are using the Java plugin, try disabling caching in the plugin control panel. Although that might not matter either...
Typically, what I do is just use IE for testing and do the quit/restart thing. Then when it's where I want it, I run it in Netscape or others just to make sure it's okay there.
It's annoying, but the only thing I found that works consistently. 
eminformatics:
Have a duke! Wish it was both dukes, but Opera (which has its own console) doesn't handle an 'x' in the java console. So this is the Netscape/Mozilla solution.
all:
The shift+reload trick is Google's favorite answer, but doesn't work in my browsers.
This is serious progress - there are a lot of reasons why I prefer to develop with Netscape and now it's working for me with applets. Too bad for me that I happen to like Opera best. Where are all the "mouse gesture" fans? 
too bad you like Opera the best and IE is still the most used browser by far in most circles. If you are writing an applet and it's just an applet which does nothing with Javascript/Live Connect, and you are using the Java plugin, then you shouldn't need to test in different browsers except to make sure that the HTML tags are correct and it loads. The other development effort is the same, as the plugin version is going to be a factor, not the browser. 
bsampieri:
Have you tried Opera's mouse gestures? Habit forming. Very habit forming!
My HTML tags are now written by my own javascript, a language that I first used this past week-end. Knowing how little experience the javascript programmer had when he wrote the tags, I still have no confidence in them, so test everything. So far, tho, I think you're right - once the applet works, it works. 
No, I haven't, but I never use Opera on a regular basis, so I can't be bothered to remember them when I do.
HTML and Javascript testing in different browsers, however, is critical. Of course, the reload problem doesn't generally exist for that like it does with applets.

htmlconverter

htmlconverter makes what type of changes in html file by which our browser support the java.
thankyou! 
AMIT_TIWARI wrote:
htmlconverter makes what type of changes in html file by which our browser support the java.It does not. Or rather, it does not make changes in HTML that make browsers support Java.
There are three things worng with that statement you made.
1) 'our browser' - the htmlconverter only ever helped Internet Explorer (not Firefox or Safari or Opera) on Windows (not IE on an Apple Mac.). So it only ever really helped install Java on IE on one OS. For the rest, it would simply redirect the end user to the download page for Java.
2) The htmlconverter does not itself make IE support Java, but instead prompts IE to download and install Java if the correct version is not found. What happens in IE is called 'auto download'. But the download can be vetoed (cancelled) by IE's settings, or (as I understand) the end user at the time it happens.
3) IE is not a browser (though it can act as one) it is an 'Operating System Component' (something that does a lot more, and a lot more dangerously, than any 'browser').
Interestingly, the 'OS component' part was probably one of the few truths to ever come out of Redmond.
Note that Sun was having trouble with auto-download for a while, and withdrew the autodl bundles, I do not know if they have brought the bundles back.
If you are interested in making sure the end user has a suitable minimum version of Java to run your applet, it would probably be a lot easier to launch it using webstart.
Edit 1:
But more to the point of your question. The changes made by htmlconverter. (sorry, almost forgot the question!)
htmlconverter transforms the simple applet element into a more complicated nested object/embed element. Most browsers ignore the object element and use the embed element, but IE uses the object element to both determine what Java version is needed, and to get URL of where it can be downloaded, if needed.
Try running htmlconverter on a simple applet HTML and look at the changed HTML (the source, not the web page itself).
Edited by: AndrewThompson64 on Mar 15, 2008 8:18 AM

Applets on the Mac

I am getting royally confused as to how to deploy applets in a way that will work on the Mac platform. I already know that the plugin2 mechanism as described in the current Java Tutorial under "Developing an Applet", i.e.,
http://download.oracle.com/javase/tutorial/deployment/applet/deployingApplet.html
won't work. But what exactly is the "old" mechanism? Is it what is described under "Deploying With the Applet Tag" (still in the current tutorial), i.e.,
http://download.oracle.com/javase/tutorial/deployment/applet/html.html
or do I need to go all the way back to pre-1.6 times, e.g., to this description:
http://download.oracle.com/javase/1.5.0/docs/guide/plugin/developer_guide/contents.html
The discussion of the applet tag in these two documents is especially confusing. The current tutorial implies that it it still perfectly valid but the Java 1.5 plugin guide referenced above say: "The HTML specification states that the applet tag is deprecated, and that you should use the object tag instead. However, the specification is vague about how browsers should implement the object tag to support Java applets, and browser support is currently inconsistent. Sun therefore recommends that you continue to use the applet tag as a consistent way to deploy Java applets across browsers on all platforms." So, which is it: can we depend on the applet tag or not?
Thanks a lot for any enlightenment. 
I did some experiments on that last year. Basically the APPLET tag works on every browser on every platform with the exception of IE, where you have to use the OBJECT tag. It seems to me that the APPLET tag will be supported forever, with that exception, regardless of what it may say in the HTML standard. Provided you don't use HTML strict mode. I do, everywhere except in my one page that contains an applet tag. 
Thanks for the answer. I just coded a test applet without JNLP and using the applet tag and, glory be, it works in IE8! Presumably it works in IE9, too. As for IE7/6/5 etc, well, that's just too bad; it's high time to desupport these antiquities.
OTOH a friendly tester told me that the plugin2 version of the applet works even on the Mac but only with the Chrome browser. I am baffled by this since I don't see what would make Chrome special (AFAIK it doesn't bundle its own Java) and would like it double-checked but, not having a Mac myself, I cannot investigate. Can anyone confirm of deny? 
Backtracking a bit, it seems clear from the docs:
http://download.oracle.com/javase/1.5.0/docs/guide/plugin/developer_guide/contents.html
http://download.oracle.com/javase/6/docs/technotes/guides/plugin/developer_guide/contents.html
that the applet/object/embed tag issue is orthogonal to the new vs. classic plug-in issue. So my question still stands: if you want to use the classic plug-in, exactly what must you do/not do? I can't find any clear write-up on that anywhere. 
That's what I answered. I also included JNLP in those tests but found, like you, that contrary to its claims it doesn't work on all browsers and platforms. What I said above does, at least for all the platforms I tested. That wasn't exhaustive, as I didn't test all operating system or browser versions, but it did include Windows and Mac, and IE6/7/8, Firefox, Opera, Safari, Chrome, and I think others.

HTML for multi-archive applet

Could someone point me to some sample HTML for running an applet? Examples litter the web but I can't find anything that meets the following criteria:
1. Valid XHTML 1.1 (uses 'object' tag).
2. References multiple JAR files.
3. Applet class not in default package.
4. Executes successfully on latest versions of both Internet Explorer and Firefox. 
Why not save yourself a whole heap of trouble and deploy the applet using [Java Web Start|http://java.sun.com/javase/technologies/desktop/javawebstart/index.jsp] (JWS)? You might call the [deployJava.js|http://java.sun.com/javase/6/docs/technotes/guides/jweb/deployment_advice.html] from within the (X)HTML to check for a suitable JRE.
JWS uses the JNLP (a form of XML) file to configure the launch, and adding archives (and specifying an applet class in a package) is relatively simple. JNLP files can be validated using YAXV or JaNeLA. 
I've made the app available via JNLP as well but was hoping to provide a version that would not require any user confirmations and will remain embedded in a web page. I don't understand why such a seemingly straightforward task entails a "heap of trouble" anyway. I got it working in Firefox with the following:
<object
codebase="."
archive="jar1.jar, jar2.jar, jar3.jar"
codetype="application/java"
classid="java:com.mycompany.MyApplet"
width="750"
height="550">
     <param name="draggable" value="true"/>
     Fail.
</object>I'm probably just missing some minor tweak for IE? 
>
I've made the app available via JNLP as well but was hoping to provide a version that would not require any user confirmations ..>Any JWS app. that requires 'user confirmations' would also require the end user to 'confirm' the digitally signed applet code.
>
..and will remain embedded in a web page. >From 1.6.0_10+, an applet configured by JNLP can remain 'embedded in a web page'.
>
..I don't understand why such a seemingly straightforward task entails a "heap of trouble" anyway. I got it working in Firefox with the following:
...
I'm probably just missing some minor tweak for IE?>Out of just two browsers, probably on a single OS, you are already experiencing 'technical difficulties' with 50% of the target browsers. Multiply that to 4 major browsers across 3 OS' and you end up with 12 browser/JRE combos. Add to that odd little eccentricities in particular browser builds (e.g. at one time an entire page and applet would be reloaded in FF if the user scrolled 'up' - that is just one of my favourite quirks, not so much a rare one).
That is (the tip of the iceberg) of why I mentioned it was a "heap of trouble" embedding an applet in a web page.
Having said that, I am not able to advise on any tweak for IE. I am running Ubuntu, and on the occasions I deploy applets, I do it in HTML 4.01 Transitional (HTML 3.2 with styles added), and use the applet element. 
hwaite,
Sometimes I use <applet></applet> tags instead of <object></object> tags and IE6 seems pretty happy. Unfortunately, IE7 prompts "Click to Activate this Control" and [further work-arounds|http://www.amarasoftware.com/flash-problem.htm] are needed.
Often I see a proposed solution to use a JavaScript wrapper-script for embedding an applet. I think there's a couple of them out there that actually write the HTML tags for you depending on what browser you are using. Some even auto-install java for you. Here's the first search result for "applet object cross-browser". It has some good discussion and is a good "heap-of-trouble" example around the subject.
[http://bytes.com/groups/html/523396-applet-vs-object-vs-embed|http://bytes.com/groups/html/523396-applet-vs-object-vs-embed]
I'd like to add that we all get frustrated with these types of things. Just make sure to channel that frustration at the browsers themselves, not the generous developers here on the forums. HTML standards get extremely tough to work-around when it comes to Internet Explorer.
Here's java's 1.4.2 standards:
[http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/using_tags.html|http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/using_tags.html]
-Tres
Edited by: FBL on Jun 29, 2009 1:32 PM - Added tag link

Categories

Resources