IE8 doesn't support Java Applets out of box - Java Applet Development

http://social.msdn.microsoft.com/Forums/en-US/iewebdevelopment/thread/bd2dea61-e878-4685-a494-33802ef539e8
Thought you folks would like to know that. It sure surprized me. But given MS' nature I guess that's par for the course. So what does an IE8 person do? Add a plug-in? Or just throw the browser out?
Thanks! 

It does not surprise me, and I do not believe there is any cause for alarm. The days of 'every browser should come with Java' (or any plug-in, for that matter) are long gone. It is up to the end user to decide what plug-ins their browser has, and the plug-in manufacturer's responsibility to make that installation as quick and painless as practical. FF on Ubuntu does not seem to have Java, until you install it.
To that end, Sun has developed the [deployJava.js|http://java.sun.com/javase/6/docs/technotes/guides/jweb/deployment_advice.html#deplToolkit]. If a page that uses that script fails in an IE 8, it would make me concerned, but it is really Sun's responsibility (and motivation) to fix it in that event. 

So don't do what I did, reloading Java and all the other configuration stuff (from the browser to try to get it to work). As it turns out W3C has deprecated the <applet> tag. Java applets apparently can still run, but... they must now be embedded in the <object> tag. So any legacy sites out there with <applet> code won't work with IE8. I'm sure you applet developers probably already know this but for the rest of us, take a look at this:
[Sun's own recommendation for using the <object> tag|http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/using_tags.html#object] 

>
So don't do what I did, reloading Java and all the other configuration stuff (from the browser to try to get it to work). As it turns out W3C has deprecated the <applet> tag. Java applets apparently can still run, but... they must now be embedded in the <object> tag. So any legacy sites out there with <applet> code won't work with IE8. I'm sure you applet developers probably already know this but for the rest of us, take a look at this:
[Sun's own recommendation for using the <object> tag|http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/using_tags.html#object]><dismissive>Peh!</dismissive>
Sun's own record on HTML compliance does not leave them in a credible position to inform on HTML 'best practices'. Added to that, the page you link to is related to Java 1.5, which is about '18 months south' of the latest 'best information' from Sun. I will not repeat that URL to the latest post, since it is quite obvious that you are some pathetic, wannabe troll. not worthy of serious consideration or riposte. Get a life.
PLONK! 

I was able to see applets after I checked the version of my IE8 and found it was not 64 bit. uninstalled the 64 bit, installed the 32 bit version (for IE -- there is a web page for it somewhere). and then was able to see applets.
Strange, because my computer is 64-bit. You'd think ie 8 would be also.

Related

Can't display swing in browsers

Hi everyone!
I'm writing some java applets using Visual Cafe. Now I can display
java awt and swing applets with no problem within Visual Cafe using
their applet viewer. I can also display awt applets fine in either IE
or netscape. However, I can't display the swing components in IE or
netscape. Netscape gives me the error 'class xxx already loaded', while
IE gives 'class xxx not found'.
I am using Win2K. I've also tried this on a Win95 computer with the same results. Anyone seen this before?
Thanks!
[Tim] 
If you are using a JDK or JRE before JDK1.4.0 beta 3 then you need to run the HTMLConverter on your HTML before it will work in Netscape and IE (any version). You may have to edit a bit to get it to work in the applet viewer though.
Good luck. 
1. Swing was added to Java in the API version 1.2.
2. M$ hasn't (couldn't have) started and will not start to use anything newer than 1.1.
3. Problems with M$.
4. Solution: get rid of M$ (by using a browser with better Java support or by installing the 1.4 JRE (though it's currently in beta)) 
yeah im frustrated with m$ its criminal that they still ship with 1.1. You get the feeling they are trying to kill us and impose c# on us to keep us sweet! Well it looks like Java prob based around it too copy cats!!!!
So on that note im stuck in a problem with using 1.1 features only.
If say I put the rt.jar file in my webserver dir along with my own could I use its features with the client having to download a new VM or plugins?
A solution to this problem would be nice since I have to implement SSL in my applet and securtity is soo ANAL at the client site they will not allow this is happen.
Any ideas folks? 
If you are using a JDK or JRE before JDK1.4.0 beta 3
then you need to run the HTMLConverter on your HTML
before it will work in Netscape and IE (any version).
You may have to edit a bit to get it to work in the
applet viewer though.
Good luck.I'm a newbie at Java programming, so where can I get the HTMLConverter? I did a search on my system and could not find it, so it must not be included with Visual Cafe.
Thanks
[Tim]
As mentioned earlier, the problem is not to do with HTMLConverter, but the fact that IE and NS do not support Swing. The solution is to install the Java Runtime Environment, which i believe comes with a plugin for IE/NS to run the latest java components including swing. Unfortunatly this is like a 30MB download, which end uses will balk at downloading. Other than that you can try to limit yourself to awt components only. 
30MB.... The download size of the file j2re-1_4_0-beta3-win.exe = 9,156,008 bytes..... You were off by a little.
I might suggest trying out Java Web Start to deploy your applications. It's not the greatest for everything, but if you user has to DL a JRE anyway. You might as well give them a stand alone app to use. 
HTMLConverter, that allows using the java plugin in browsers like IE and NN before version 6:
http://search.java.sun.com/Search/java?qt=HTMLConverter&x=26&y=5
(the search tool, on the top right corner...)
As mentioned earlier, the problem is not to do with HTMLConverter,
but the fact that IE and NS do not support Swing.They do support swing.... if you make them use the plugin. HTMLConverter enforces the use of plugin; problem solved.
You could put rt.jar (or swing.jar, a subset containing only the needed swing classes) on your site but your users wouldn't like it for two reasons: 1) it's a big thing to download (over 1MB) and 2) it will not be cached well so that it will be downloaded almost every time the users go to that page.
The plugin (whether 1.4 or 1.3) is the ultimate answer. 
Yeah but the whole point is to make it work in a browser 
err... plugins work in browsers? 
Yes I know but the whole point is not to use plugins.
A question though if they install the JRE via plugin it is persistant yes? IE they only need to do it once 
Yes I know but the whole point is not to use plugins.Is it? Looking at the OP the whole point is to get it run in browsers.
A question though if they install the JRE via plugin it is
persistant yes? IE they only need to do it once That's the general idea. You don't expect sun to be so stupid that they think users would love to download the frigging 6MB runtime environment every time they go to a java enabled site, yes?
If you want to you users to stick with the old classes, then you must also stick with the old classes. 1.1 is not that bad. 
Easy NOOOWW
Yeah I totally agree 1.1 is fine. However have u tried implementing SSL? Im shafted at the moment because I can not do this.
Unless you have done it or know of a site explaining it in terms of 1.1?
For us using plugins isnt a desired effect. Security is extremly tight on the machines this will work on. The company does not want to go down that route. I think they are being a bit anal but hey im just the hired help... 
Hmm... have you seen http://www.google.com/search?q=ssl+java ?
The first, third, and fift hit look quite promising...
Security is extremly tight on the machines this will work on.And the plugin does not provide enough security? 
Yeah i should mean
The clients DONT want to install the plugins.
Thanks for you help though I will have a look at the articles

java plugin for applets #2

Hi, Am I correct in saying that in order to run an applet developed with 1.4+ in Netscape
I have to use the following:
pluginspage="http://java.sun.com/products/plugin/1.4/plugin-install.html"in my EMBED tag? This is documented on
http://java.sun.com/j2se/1.4/docs/guide/plugin/developer_guide/using_tags.html
However when I actually go to the plugin-install.html I get a 404?
The idea is that I want to keep a local copy of whatever is referred in the pluginspage tag on the server so I dont have to go externally to fetch it. What exactly am I supposed to be getting a copy of? My environment consists of multiple browser types/versions on multiple OS types (Win/Mac/Linux)
If I understand plugins correctly I am supposed to be able to run applets with an "external" JVM. The word "external" in this context is meant as?
1) external to the browser?
2) external to the OS on which the browser resides?
I would have thought it is 2) otherwise I can't explain why 1.4 applets runs on classic MacOS with NS7..
Any thoughts would be appreciated!! 
O.K., firts let me start by saying that it may help you to offer Duke Dollars when you post a question, and then award those to someone who helps you out. This will help provide stimulation for feedback to your posts from others.
To answer your question, the URL
pluginspage="http://java.sun.com/products/plugin/1.4/plugin-install.html"
comes up 404 because of the Sun has swithced to version 1.4.1. The new URL is:
http://java.sun.com/products/plugin/index.html#download
This takes out the version number of the original page (1.4) so that in the future HTML coders will not have to change the page after every new plugin version change. Also, the more important entry for the <OBJECT> tag is:
codebase = "http://java.sun.com/products/plugin/autodl/jinstall-1_4_1-windows-i586.cab#Version=1,4,1,0"
which specifies where the browser can automatically download the plugin from. Note, this WILL change from version to version (or it can change by you, depending on the desired version). For advanced people, I'm sure you can specify your own .cab file in this entry and have people download from you (like on a local server). Although, as I have not done this I can't speculate as to the time this would require. It is better not to stray from Sun's downloads anyway.
Eric
P.S. - how about some Dukes?
Oh yeah, to answer your other question, the JVM is external to the browser, but, IS run by your OS.
Eric
P.S. - "show me the money" :) 
Your response seems to contradict your previous answers to my last thread.
Perhaps I wasn't being clear. I was wondering whether I can run 1.4+ applets in NS4 running on classic MacOs (which does not support JRE1.2+) using the plugin. Your response seem to suggest that I can't..? 
Yes, I misunderstood the direct implication of your questioning. What I originally meant was that you don't have to worry about a newer Plugin running older code. Also, the you can control which plugin is used for which browser, as long as the OS supports the JRE. I wasn't aware the classic MacOS issue.
So, as far as the classic MacOS, if it doesn't suppor the newer JRE then you cannot run code above that support.
To reiterate, the Plugin DOES run on your OS. Sorry for the misunderstanding.
One possibility (aleit a not always possible one) is too have a second version of your app that is written only in MacOs compatible code. This may be more work than it is worth. Will Sun offer future support for the classic system? If not, you can try (usually in vein) to convince the customer to upgrade.
Hope this helps.
Eric
P.S. - thanks for the Duke. 
Well I got 2 more dukes here to give away so
Yes, I misunderstood the direct implication of your
questioning. What I originally meant was that you
don't have to worry about a newer Plugin running older
code. Also, the you can control which plugin is used
for which browser, as long as the OS supports the JRE.
I wasn't aware the classic MacOS issue.
So, as far as the classic MacOS, if it doesn't suppor
the newer JRE then you cannot run code above that
support.This isn't quite making sense to me. I have the classic MacOS which probably doesn't support more than JRE1.1.5 but we have an applet built with 1.2 that works on classic MacOS..
Note that this applet is built with JBuilder7 but the JRE is 1.3.1b-24 or something like that.
To reiterate, the Plugin DOES run on your OS. Sorry
for the misunderstanding.
One possibility (aleit a not always possible one) is
too have a second version of your app that is written
only in MacOs compatible code. This may be more work
than it is worth. Will Sun offer future support for
the classic system? If not, you can try (usually in
vein) to convince the customer to upgrade.
Hope this helps.
Eric
P.S. - thanks for the Duke.

Old Jdk1.1.6 Applet suddenly crashing IE

I have applets posted on my webpage for five years. These have been working fine for years. Now suddenly I have complaints coming in that these old applets are crashing IE (variations of IE 5.5).
Looking thru the archives of this Forum I am seeing a sudden requirement to use object tags and CLSID specification with the HTML files presenting my applets. These approaches seem to only accomodate a single target hardware platform at a time.
Am I missing something here? Is there suddently a severe cross platform instablity?
Do I have to go back and recompile every applet I've written for the last five years and rewrite each associated HTML file to support object tags?
Here are some reference URLs for the benefit of other troubled programmers:
http://forum.java.sun.com/thread.jsp?forum=31&thread=34676
http://java.sun.com/products/plugin/versions.html
If I have to generate unique HTML wrappers for my applets depending on the target platform or browser I would consider this the beginning of the end for JAVA.
Please someone tell me that I misunderstand. 
The problem is that your applet was probably written for and tested under Microsoft's Java implementation in IE. Now people are starting more and more to have SUN's Java Plugin installed. It is often the case that those old applets are incompatible with the newer versions of Java from SUN.
So you have two options:
1) Tell your users to disable SUN's Java Plugin.
2) Figure out what exactly is wrong with your code and fix it so that it can run properly with SUN's Java Plugin.
The first option is easy. Just go to Control Panel and choose Java Plugin and under the tab Browser uncheck Internet Explorer.
The second option may be easy or may be very hard. It depends on what exactly is the problem with your code. I can tell you that we gave up on it with our applet and have started rewriting it completely. 
Thanks for the explaination. This does help, but I can't understand how there could be either a problem with the code or incompatiblity issue with Sun's JVM. These applets were all developed and compiled within Sun's JDKs, (at the time the most recent JDK). Each ran using Sun's appletviewer, which I believe uses Sun's JVM (please correct me if I'm wrong). How is it possible now that they suddenly would not work with Sun's JVM.
My understanding is that the solutions in the cited URLs indicate that we should identify CLSID within an object tag, and a path to the required version in the codebase paramater. The path indicated by the codebase parameter can only refer to the java plug-in for one type of machine (eg. JRE1_2_2-001-win.exe... note the .exe), and for this reason becomes an HTML page tailored for that type of client. If that's true, unless I misunderstand, the days of a single webpage containing an applet that will run on all platforms may be behind us.
Again, please tell me I am wrong. 
These applets were all developed and compiled within
n Sun's JDKs, (at the time the most recent JDK). Each
ran using Sun's appletviewer, which I believe uses
Sun's JVM (please correct me if I'm wrong). How is
it possible now that they suddenly would not work with
Sun's JVM. Like I said, you have to test them and see what actually causes them to crash. Everything else would be guessing. I am just saying that it is perfectly normal that an applet working with Microsoft's Java doesn't work with SUN's Java.
My understanding is that the solutions in the cited
URLs indicate that we should identify CLSID within an
object tag, and a path to the required version in the
codebase paramater. The path indicated by the
codebase parameter can only refer to the java plug-in
for one type of machine (eg. JRE1_2_2-001-win.exe...
note the .exe), and for this reason becomes an HTML
page tailored for that type of client. If that's
true, unless I misunderstand, the days of a single
webpage containing an applet that will run on all
platforms may be behind us. All that talk about CLSID and the object tag isn't really relevant to your problem right now. You can worry about that once you have fixed your code so that it works with SUN's Java. 
Please don't take this the wrong way, because I do appreciate that someone is taking the time to discuss this.
Again, I was assuming that the appletviewer provided with the JDK is employing SUNs JVM. Is this not true?
Was it your intent to suggest that, knowing that the applet certainly work with some version of the JVM, that I should work along the lines of finding which versions of the Sun JVM would cause a crash? 
It would help if you could find out what's causing the crash. Is anything being shown in the Java console, for example? You need to replicate the conditions that cause the crash, and investigate from there.
If the applet was originally developed with Sun Java, then it could just be a bug in the JVM. If the JVM is an M$ JVM, I wouldn't be at all surprised if there's a problem, but the Java plugin has been known to break old code occasionally.
Unless you give us more information, there's not much more we can do except shrug. 
Now I'm beginning to understand. I wil try to get more details tomorrow on the exact error message. The users are indicating that with this new IE download, when visiting the website the old applets immediatly shut down the IE browser. As I recall, the error is a general protection fault. These are not Java savy users, so I'm assuming they would work in the default configuration - probably the Microsoft VM I guess. If that is so, as you are saying, this could be a bug in the MSVM. This seems very likely, in which case I have been barking up the wrong tree in assuming Java was failing me. I hope you're right.

JREs in the wild

Hi folks,
It seems very hard to find out the following basic information. If anyone can direct me to statistics or reports or sites on this, I'd be very grateful.
Simply, what JREs are out there still operating for Java applets?
Is there guidance for me as a developer on how far back toward 1.1 I should make my code compatible? What is the most common JRE - 1.5?
I've tried Nielson and others about this but they have no idea. Sun does not seem to have stats on this either - even the number of downloads for each JRE over the years.
Cheers,
Craig. 
I only produce Applets compiled for 1.1. It is the only JDK that you are likely to find in IE which as you are aware is what most of the world uses. 
I believe all of the MS products prior to XP SP 2, have 1.1.8 -- MS's JRE. Many of the new computers do not have any JRE loaded, or will be shipping in that condition very soon. So it is going to be interesting to see what happens with Java and applets, there will not be any JRE you can develop for that will be guarenteed to be on a machine, the user will just have a dead box and will have to choose to load a jre when they figure out what is going on.
Even though I have JDK for 1.3, 1.4, and 1.5 on my box, I see it is using the MS JRE for the browser and is required for some of the applications we use here.
Essentially if you are making an applet and you want it to run seemlessly, then you're going to have to make it for the point MS's JRE supported Sun's standards. 
I only produce Applets compiled for 1.1. It is the
only JDK that you are likely to find in IE which as
you are aware is what most of the world uses.That may no longer be true. See this link:
http://www.javalobby.org/java/forums/t19156.html
where he says that as of last May, 51% of the browsers connecting to his site (doesn't say what it is) use a Sun JVM and only 45% use the MS JVM. This trend is likely to continue. 
That may no longer be true. See this link:
http://www.javalobby.org/java/forums/t19156.html
where he says that as of last May, 51% of the
browsers connecting to his site (doesn't say what it
is) use a Sun JVM and only 45% use the MS JVM. This
trend is likely to continue.I hope I was wrong and this is the case! 
Thanks for this -
Your browser choosing MSJVM over Sun - isn't that your use of <applet> over <embed><object> in IE|Moz? 
Thanks for this -
Your browser choosing MSJVM over Sun - isn't that
your use of <applet> over <embed><object> in IE|Moz?No. It is the client's decision on which plugin they have. Most users won't care, or know how to change the plugin they have. If it isn't done for them, and their version doesn't support your code, then as far as they are concerned, your code is broken, not their browser.
One of the reasons Applets tend to be harder to deploy then they are worth... 
Your browser choosing MSJVM over Sun - isn't that
your use of <applet> over <embed><object> inHonestly unless you can do a lot of testing against several versions of java, you may be best off going with an object tag so you can specify the java version.
EVEN BETTERER
Java Web Start is pretty kickin'. I'd recommend that in almost all cases vs. applets 
No. It is the client's decision on which plugin they
have. Most users won't care, or know how to change
the plugin they have. If it isn't done for them, and
their version doesn't support your code, then as far
as they are concerned, your code is broken, not their
browser.I would like to just make this comment on stevejluke's post: EXACTLY!!!!!!!!!

Plug-In Versions

Before I get flamed, yes I posted this to one other forum. I thought the first forum fit the question better, but it seems pretty dead and I am looking for an answer sooner than later. Since I see other posts here regarding the java plug-ins, I figured I would try here as well and hope for a bit quicker response.
I have an issue with Java's browser plug-ins, and I am hoping someone has had this problem and found a solution. We utilize web-based applications (Applets) from our various providers. The problem is that each vednor requires a different version of Java to run their Applet. If our CSRs don't have their browser configured to use the exact version of Java that the vendoir requires, the Applet will not run (that is how it is programmed). Thus far we have only had two vendors, so we set IE to work for one vendor and NS to work for the other. We have just added a third vendor though, and they require a third version. Now we either have to load a third browser, or we need a different solution.
That said, does anybody know of a way to set which java plug-in an applet uses based on say profiles (in NS or FF) or based on website? 
This doesn't sound right to me. Applets are out there on the web, surely targeted for different versions, yet people get to them all the time. The latest version of the plugin should be compatible with these "older" version applets. If it doesn't, that might be one reason applets kinda suck in the first place. 
... applets kinda suck in the first place.That cuts to the chase. Applets suck. Java Web Start lets you specify which VM the application needs and will make sure its available on the client. One solution is to ditch applets and use JWS. I don't know any other solution because I never use applets. Because they suck. 
The html that is use to initiate an applet can specify if a certain JVM/Plug-in version(s) are needed to run the applet - and can initiate download and install of the needed Jvm version if it's not installed. This information is in the Plug-in Developer's Guide. Here is the Java 5 document:
http://java.sun.com/j2se/1.5.0/docs/guide/plugin/index.html
(check chapter 3 first) 
Maybe I did not make this clear in my first post. The webpages/applets are programmed by our vendors....we have no control. I agree that a newer VM should execute an older applet. The problem is that our vendors require us to have s specific version of the jre to execute their applet. Essentialy they are polling System.getProperty("java.version") and if the resulting String does not match what they expect they do not init the applet.
Unfortunately I cannot change the applet code nor the html that loads the applet. 
The problem is that our vendors require us to have s specific
version of the jre to execute their applet.
Essentialy they are polling
System.getProperty("java.version") and if the
resulting String does not match what they expect they
do not init the applet.That's just plain stupid. You really should raise this as a bug in their design and implementation. Get them to fix it, rather than have you run around in circles trying to work around the flaw. 
I'm pretty sure you could do it if you wrote your own browser. 
I agree 100% ... it is just plain stupid. Especially considering one of our vendors requires a version of JRE1.3.
We have contacted them, and their reasoning is they have not had the opportunity to test for full compatibility between their Applet and deprecations/changes made in the newer JRE versions. 
I aggree with warnerja. As the customer, why can't you tell them to correct their html so that it correctly specifies the needed version?
Checking the property "java.version" is not, as far as I am aware, sanctioned by Sun as a valid requirement for applets.

Categories

Resources