If you embed an applet dynamically via DOM, there is a 20% chance of a deadlock. Up on removal from the DOM tree, you get a NullPointerException with a stacktrace pointing to a method that is about to download a JAR.

Except if the FIRST connection made to your own server, is on the EDT. OK?

Then there is the problem that the orange preloader gets stuck at 50%, forever.Just reload the page, and try again.

And ofcouse the problem that truely nothing happens. The applet is white.Just reload the page, and try again.

Further, classes don't truely get unloaded. If you have classes that do a lot of precalculation, like creating a cos/sin lookup table and put it in a static field, and you refresh the page (and thus the applet) 10+ times, memory usage goes up very quickly, eventually slowing down your whole browser due to swapping. You can only restart your browser to get back to normal speed.Also leaving a page with a super tiny 1x1px applet, only drawing a black pixel, it takes 2 seconds longer than leaving a normal page.

The LiveConnect bugs in FireFox cause your fancy features to either not work at all, or hang your browser.

Loading an applet GRABS FOCUS the hostile way, even if it does not have any 'input components'. If you were just entering data in a form, or in the address bar, so what, now the applet consumes all your keystrokes, until you click somewhere else. It will even cause to window.toFront on your browser window.Last but not least, loading an applet freezes your browser for 2-3 seconds, it feels so 1990.

In conclusion:steer clear of applets if you are doing anything commercially

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

If you embed an applet dynamically via DOM, there is a 20% chance of a deadlock. Up on removal from the DOM tree, you get a NullPointerException with a stacktrace pointing to a method that is about to download a JAR.

Those DOM insertion/removal crashes are interesting. What code did you use to edit the DOM? innerHTML or the appendChild() methods? Did you see those Exceptions yourself or get them from users?

Nice... 91% is not too far away from the measurements already posted in this thread, and in the refered article.

Yep. And confirming that those numbers are correct per Sun directly.

Quote

The problem is that it is not guaranteed to work on 100% of that 91%, it's more like 35-55% out of that 91%, resulting in 33-50% of installations with problems.

And where do you get your numbers from? While that may be true in your particular case, I have not seen numbers like the 33-50% you have mentioned. Sorry, I have not personally seen it, not to say that there may be some Java applets out there that are more problematic than others.

Quote

I clearly recall Flash stuff on the www.java.com frontpage. Talking of which, the localisation of the current java.com pages is still CRAP, just like a year ago, it's offendingly stupid phrasing to any non-english visitor.

Yep, there is some stuff on the font page of Java.com. There are some things that Flash is good for, some that it is not. As for the localization issues, I forwarded the comments from this thread to the person who manages the site. She replied to me and said she will look into this right away.

And where do you get your numbers from? While that may be true in your particular case, I have not seen numbers like the 33-50% you have mentioned. Sorry, I have not personally seen it, not to say that there may be some Java applets out there that are more problematic than others.

It's a rather complicated Applet, however, the first thing I do in the Applet::init() is to 'ring home' to the hosting server. The URL that is requested, logs every request to a database.Further, with mod_rewrite (in apache), the mystuff.jar is not pointnig to the file, but to a script, that logs the request, and then streams the file. So the browser just gets the file, when the browser requests it.

Now the thing is, after 45 seconds (!), an AJAX call is made to the very same URL, with slightly different parameters, so that the server-script knows it's the AJAX call ringing home.

So... now we have 3 moments we log something to the database: - up on downloading the JAR file (which is 'optional' as it may be cached) - up on having the webpage loaded for 45s (surely the applet must be loaded by now?) - up on the invocation of Applet::init() -> new Socket("my.host", 80);

Down to some statistics:About 85% of our visitors (not hits, visitors!) downloads the JARAbout 98% of those indeed are 45s are longer on the page with the applet, so the AJAX call is received. (we seem to have very patient/relaxed visitors)About 66% of the hits that received the AJAX call (after 45s on the page), managed to launch the applet AND the applet was able to 'ring home'

In case you wonder, the target audience is: Spain, people that customize their furniture (fancy closets) so middle-age, I guess ?Spain is slightly lagging behind in the latest technologies, as for example MSIE 6.0 is still very widely used (like 40%), so that might explain the 85% vs 91% diff.

Note: the JAR requires java 1.4 or higher. Further, my stats are actually a bit too positive, as I record it as a success, if a visitor manages to launch the Applet 1 time, out of... all attempts - where the average hits per visit on that Applet-page it roughly 2,5.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

The problem is that it is not guaranteed to work on 100% of that 91%, it's more like 35-55% out of that 91%, resulting in 33-50% of installations with problems.

After reading so much here about how applets suck so bad, I wonder why I've never seen (or heard about) the JEmu2 applets to be not working other than because of not having java...

The JWS version on the other hand often fails for different reasons (most of the time OpenGL related issues though). I actually made the applets for compatibility reasons and so far that's working out quite well for me.

Am I lucky for doing something clever without knowing it, or am I just lucky for always being on the good 35% somehow, or is the applet too simple to trigger the plugin's suckyness? The applets are still played more than a 1000 times a day on average...I'm not saying that there are no applets that suffer from bad plugin related issues, but it's just not what I'm seeing.

EDIT: And then I read Riven's above post... I'm not doing complex things like that. I just have a straightforward applet (although it does contact the server to tell it ran or if it crashes)

I regularly get complaints about the JWS/OpenGL version not working, although the applets are more popular. In fact of the roughly 1 million visitors I had, I never had a complaint about the applet.

I don't know if the average user is a developer or not, but most of the feedback I receive is from people that just want to play the games and can't figure out (or can't be bothered with, or just don't know) MAME.

Oo, it's all doom and gloom today!If the failure rate was as high as 50% then no developer would ever touch applets at all!

I've never done any serious analysis, but for a simple applet (1.4, no networking) I seem to get a failure rate of about 3-5% ('just doesn't work'). More people (~5%) report 'poor performance' but I've no way of knowing what else their machines are doing and as my apps tend to be processor-heavy I'm guessing that users multi-tasking is the problem.I work on the assumption that 5-10% of people with java installed will have problems, which is not great but not a disaster for me.

A quick glance at the Runescape tech support forum suggests only moderate problems given the size of their user-base and that their major issues are loading resources & networking.

Unfortunately the J2AS3 utility (which attempts to automatically port code) doesn't actually seem to be available - the download links are all broken. So I couldn't see how well it works. If it's anything like other automatic porting tools I've seen, it doesn't do much more than a literal source-level translation, which means there's a lot of patching up that needs to happen after the fact (for any sort of advanced syntax tricks as well as for any and all library calls). I'm not sure, though, it's possible I'm underestimating the utility - the fact that the website is down probably doesn't bode well for the utility receiving much development love, though!

I once implemented a similar logging system at my gamesportal. From the stats I gathered ~ 75-80% of the users could play without the jvm bugging them. But this higher success rate could be explained because all the applets are jre 1.1 compatible. The userbase consist mainly from casualgamers, so should be pretty representative. I also received little complaint about games not working, while the logs tell something different, I guess people just dont bother (and probably leave forever )

It hurts to say this, but if I where to develop online *casual* games again, I'd probably go with flash... Luckily Bruno and I have some cool game prototypes cooking to demonstrate the (potential) power of java applet games

EDIT: 75-80% of the people having a JVM installed that is... I didnt log the people without a JVM

Unfortunately the J2AS3 utility (which attempts to automatically port code) doesn't actually seem to be available - the download links are all broken. So I couldn't see how well it works. If it's anything like other automatic porting tools I've seen, it doesn't do much more than a literal source-level translation, which means there's a lot of patching up that needs to happen after the fact (for any sort of advanced syntax tricks as well as for any and all library calls). I'm not sure, though, it's possible I'm underestimating the utility - the fact that the website is down probably doesn't bode well for the utility receiving much development love, though!

Well, even literal conversion is difficult. There are some key differences in AS3, such as having no abstract classes, private constructors, or multiple threads. The language itself is quite nice IMO, but it's too different from Java to justify a straight and painless conversion.

Recently i had to deal with a business application that used a very simple applet, and guess what, the applet didn't work under Java 1.4 (it should have). It just presented a blank area. After the client upgraded to Java 1.6 the applet worked. I guess its the same situation with Java applet games. "It just doesn't work". No popup to upgrade to newest Java, no automatic plugin download, "It just doesn't work". I think that's the biggest problem. Oh, and the security popup. And the startup time of the applet. And the user shouldn't even know he is interacting with a Java applet.

This is a very important topic.

I have had the same experience.

My sister just got a new laptop, and she's using it for her school. So she's trying to use this school web system to submit her assignments, but it doesn't work! My sister calls me and needs my help, so I drive to her place and try to fix it. Guess what, the school web system uses some Java Applets that enable users to upload files.

My sister is not very computer savvy, what she failed in doing was approving all those kazillions of dialogs about security and trust that popped up to allow her to run that Java Applet. She had just closed them before or minimized, not knowing what they were for.Even I was startled at learning how complex this was. It was on Windows Vista, and the whole screen is dimmed down and this dialog appears like a virus is trying to take over your system. Scary, complex and time-consuming.

My sister is not very computer savvy, what she failed in doing was approving all those kazillions of dialogs about security and trust that popped up to allow her to run that Java Applet. She had just closed them before or minimized, not knowing what they were for.Even I was startled at learning how complex this was. It was on Windows Vista, and the whole screen is dimmed down and this dialog appears like a virus is trying to take over your system. Scary, complex and time-consuming.

<sarcasm>Yeah, maybe we should just get rid of the sandbox and let any applet do whatever it wants, like scanning your drives for creditcard numbers or turning on your webcam and publishing it on the internet. That should get rid of that nasty security dialog just fine.</sarcasm>

Seriously though, there's something wrong about designing a website with a kazillion security-dialog-popping-up applets. IMHO that's not really the fault of applets or security dialogs, it's the fault of whoever designed the website to work like that.

I have a feeling that Java's security is rather poorly implemented from a user's perspective these days. To be perfectly honest I think the security should come solely from the OS and browser these days, presenting the user with a consistent approach to security on their platform of choice. Java's built-in security should only be called upon for standalone Java applications that wish to download remote code and put up a cross-platform security dialog, eg. a Java browser.

I have a feeling that Java's security is rather poorly implemented from a user's perspective these days. To be perfectly honest I think the security should come solely from the OS and browser these days, presenting the user with a consistent approach to security on their platform of choice. Java's built-in security should only be called upon for standalone Java applications that wish to download remote code and put up a cross-platform security dialog, eg. a Java browser.

Cas

I think what your saying would come across as alot cleaner. But I think with things like JNLP it would be annoying to try get the end user to allow restricted access to ports and such for online gaming (by going through the OS just for java gaming, the disabling after use) . I think thats really the one reason I really like the current certificate setup in Java.

I have a feeling that Java's security is rather poorly implemented from a user's perspective these days. To be perfectly honest I think the security should come solely from the OS and browser these days, presenting the user with a consistent approach to security on their platform of choice. Java's built-in security should only be called upon for standalone Java applications that wish to download remote code and put up a cross-platform security dialog, eg. a Java browser.

Cas

I think better OS support (particularly in presending dialogs to the user) would go a long way. What with each different browser, anti-virus, firewall, webstart etc. presenting an entirely different security dialog to the user it's not surprising that users get confused.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org