Talk:Java applet

From Wikipedia, the free encyclopedia

While this HowTo is usuful, it's incomplete. What is

appletviewer

and where is ist available? Is it a shell command?

Appletviewer is a command line program to view applets without a web browser. Swirlix 11:04, 16 September 2005 (UTC)

Appletviewer is included with the JDK. Plugwash 00:04, 15 December 2005 (UTC)

Do we need how to page? -- Taku 05:51 Feb 26, 2003 (UTC)

This is a terrible article. It assumes you know more than the average reader of a wikipedia.

1 APPLET tag
2 COMPATABILITY
3 Advantages section
4 Compatibility section
5 Removing cleanup tag
6 Access permissions
7 Irrelevant links
8 Signed applets
9 Mention that Java applets are on the verge of extinction?
10 Headline text

[edit] APPLET tag

Is it still bad to use the APPLET tag if you want to use a recent version of Java? - furrykef (Talk at me) 19:03, 25 Nov 2004 (UTC)

Last i checked applet was still allowed at least in the transitional versions (rather than the strict versions). on the other hand applet leaves you with a still real (though decreasing) chance of ending up running in the MS JVM which may not be very desirable. Plugwash 21:21, 15 January 2006 (UTC)

[edit] COMPATABILITY

This page is stated to be written in English. I´m not a Native English Speaker, but, anyway, I would like to know what means the word COMPATABILITY used on the page. By the context, I deduced that it seems to be something similar to the English word COMPATIBILITY, is that right? Is it a cognate from another language? —The preceding unsigned comment was added by 200.250.81.140 (talk • contribs) .

The word was misspelled. The correct word is compatibility. – Doug Bell ^{talk•contrib} 19:42, 14 February 2006 (UTC)

While we're on the compatibility section, my understanding is that the Microsoft JVM was incompatible because it was not in fact Java. Sun sued Microsoft and prevented them from distributing it because the Microsoft extend and absorb strategy amounted to an infringement of Sun's trademark. Either way, Java is no longer part of Windows in the same way that a hard disc isn't - it's up to the manufacturer to include it with their product as they see fit (and almost all do include it as standard).

As an aside, the MS "Java" 1.1 was faster than the subsequent Java versions, though more restricted eg programmable icons are a big improvement on later versions, and audio quality is much better too. Stephen B Streater 16:55, 22 February 2006 (UTC)

[edit] Advantages section

The tone of the article seems a bit negative to me. To ensure a NPOV, I suggest adding an advantages section.

Some possible advantages to include are: ((Supporting evidence in doubled brackets like this is not intended for the main article))

With modern internet connections, applet download time is quick compared to loading complex applications off a local disc. ((For example, my home internet is 4Mb/s, so a 50kB applet downloads in a fraction of a second. This compares with many seconds to start Word on my 3GHz PC))
Java applets cache in most web browsers so that the applet will be quick to load when returning to a web page.
Java allows real time applications. ((This "playerless" live video codec would not be easy in Javascript using Ajax: Live video demo served from UK so may not give full 320x240x25fps when viewed in US))
Java bytecode makes the source code harder to reverse engineer, so complex commercial projects are more attractive. ((For example, this video editing and publishing package, made by my own company))
Java applets can be made to work on "all" versions of Java, rather than the latest plug-in version only. ((See above examples))
Java applets can run without any security approval from the user - you don't need to trust the software author. ((This is not unique to Java applets, but is still an important advantage))
Cross platform. It is simple to make applets which work on PC, Mac and Linux

It's probably worth mentioning some more disadvantages too. I suggest:

The Java applet can only access the server it came from
The Java applet usually has no access to the local machine
Java has bugs, which need to be worked around. Different versions have different bugs.

—The preceding unsigned comment was added by Stephen B Streater (talk • contribs) .

I agree the article is negative. Really, the article is quite poor, there is a lot to be added. There are definitely things that can be done with applets that can't be done (or can't be done well) with the other technologies listed. Eventually, if nobody else gets to this I will probably fix the article, but I just haven't gotten around to it yet. Feel free to jump in and improve it.

BTW, to respond to the disadvantages you listed:

Restricting access to the originating server is part of the sandbox model. A signed applet can access anywhere. The server can be configured to perform the operations on other servers for the applet, thus maintaining the sandbox model while allowing the applet to access other servers using its originating server as a proxy.
No access to the local machine is also part of the sandbox. A signed applet can access the machine if granted that permission.
Sure Java has bugs--so does the browser and the other technologies that can be used instead of applets. I'm not sure the current state of applets is any worse than the other issues web developers need to deal with.

However, I would add one other disadvantage:

Applets require the Java plugin, which isn't available by default on all browsers.

– Doug Bell ^{talk•contrib} 14:20, 17 February 2006 (UTC)

Yes - I'd forgot to mention that Java applets have more capabilities if signed (a double edged sword!). If I get to update the the article, I'll include this important fact. Stephen B Streater 16:29, 17 February 2006 (UTC)

"With modern internet connections, applet download time is quick compared to loading complex applications off a local disc. ((For example, my home internet is 4Mb/s, so a 50kB applet downloads in a fraction of a second. This compares with many seconds to start Word on my 3GHz PC))"

BULLSHIT download time may be quick but unless the JVM is already in cache its load time is significant. and i'd like too see an applet as capable as word that loaded faster than word.

Of course, after the first applet, the rest load quickly. I suppose you can make the same complaint about browsing a Web page since the first time you browse a page the browser has to start up and initialize, although I suspect the JVM is going to be slower starting up than the browser. A browser written in Java won't have the applet delay as the JVM is already running, and any browser that starts up the JVM as part of it's initialization will also not have a delay running an applet. After the first applet, bandwidth is probably the limiting factor, so I think the point Stephen makes still applies. – Doug Bell ^{talk•contrib} 17:25, 17 February 2006 (UTC)

Just an incidental point: on Windows, the JVM startup time seems to depend on what is in the Java web cache. Empty your Java web cache, and things will start a lot quicker. If you use Java a lot, or leave your machines on all the time, the startup time doesn't affect you very much. Also, Java 1.5 seems to use all its CPU redrawing its logo at the beginning. If you switch this off (a programmer option), have the applet cached, and have the JVM loaded, things are pretty fast! So perhaps a disadvantage could be the unpredictability of user time on start-up. Stephen B Streater 10:24, 18 February 2006 (UTC)

I still consider "compact applets start faster than bloatware like word" to be a dubious advantage at best. Has anyone ever seen an applet even half as complex as word?! Plugwash 10:35, 18 February 2006 (UTC)

If you mean badly written, I'd have to agree. An applet I have been developing, FORscene, is used for reviewing, logging, editing and publishing of video for TV broadcast. In a sense, this is word processing for video, and video is more complex than text. Adding more features will not impact that much on the applet size, as the codec infrastructure take most of the space. So perhaps we could debate whether this is half as complex as Word. Stephen B Streater 10:54, 18 February 2006 (UTC)

"Java applets cache in most web browsers so that the applet will be quick to load when returning to a web page."

Again assumes download time is the limiting factor and not things like JVM startup time and time for the applet code itself to go through its initilisation sequences.

"Java allows real time applications. ((This "playerless" live video codec would not be easy in Javascript using Ajax: Live video demo served from UK so may not give full 320x240x25fps when viewed in US))"

True java is going to be faster than scripting languages.

"Java bytecode makes the source code harder to reverse engineer, so complex commercial projects are more attractive. ((For example, this video editing and publishing package, made by my own company))"

Tried JAD lately? decompilers for bytecode systems like java and .net are way way more effective than those for native code!

Yes - if you have the right tools, it is easier to see what the code does. Of course, with a modern language, the structure makes it easier to understand how it works, too! Stephen B Streater 22:59, 17 February 2006 (UTC)

"Java applets can be made to work on "all" versions of Java, rather than the latest plug-in version only. ((See above examples))"

True

"Java applets can run without any security approval from the user"

True

"Cross platform. It is simple to make applets which work on PC, Mac and Linux"

This applies to all java code, not just applets.

Applets biggest problem though imho is the lack of an interface to allow untrusted code very limited access to the users system (like the classes java web start makes availible in javax.jnlp). Plugwash 17:14, 17 February 2006 (UTC)

I'd find this very useful too. Most of our users are not allowed to trust us - they work on locked down systems within big organisations. Of course, if the Java web cache worked, our video editing application could store the video on the disc without direct access. Stephen B Streater 22:59, 17 February 2006 (UTC)

I've put something in the article. I've tended to leave out the advantages and disadvantages which cancel each other out (ie something which may be an advantage and a disadvantage, or something which has a work round), and the more contentious ones too. Stephen B Streater 20:05, 20 February 2006 (UTC)

[edit] Compatibility section

I'm planning a major reworking of this section. Most of the issues here are (or could be) discussed in disadvantages section. Microsoft Java 1.1 has been replaced by Java 1.2, 1.3, 1.4 and 1.5 (5.x). MS Java is not legally Java, resulting in a trademark case and the effective banning of sales of MS Java some years ago. In practice the issues concerning MS Java are more to do with its limited functionality eg no programmable icons and limited sound quality, rather than incompatibility issues. Finally, although Java Webstart has its advantages, it requires user permissions, and contrary to what is implied here, it is not necessary in practice for almost all applications. Stephen B Streater 11:31, 1 March 2006 (UTC)

The main issue with the MSJVM is that the sun vs ms settlements killed its development but did not immediately stop its distribution (it did eventually). This meant a HUGE number of IE deployments were made with an extremely old JVM and if you wan't compatibility with it you effectively have to stick to the horrible java 1.1 with no swing (unless you wan't your users to have to download a huge jar).

And the lack of the ability for unsigned applets to save files or use the clipboard (with user permission ofc) is undoubtablly an extremely major limitation. Plugwash 11:55, 1 March 2006 (UTC)

I agree that the MSJVM issue should be borne in mind - some major broadcasters in the UK still use it on their standard configuration. We support it at a cost of a few percent in applet size - in a world where internet speed increased 100% in the last year. Most of the code in a complex applet is in its internals, not calls to the Java libraries. If you run the applet once per day (and have it running all day), downloading a few Mbits once over a broadband connection once is an irrelevance. In practice, it doesn't take much effort to make something work on all Java versions. As part of the tidy up, we could add this to the disadvantages section though, as it cannot be ignored.

The sandbox model, which limits file access, is already referred to in point 5 of the disadvantages. I can make this clear that it includes (in particular) file access. Stephen B Streater 13:21, 1 March 2006 (UTC)

Has compatibility has been a major obstacle in adopting Java applets? This is not my experience - do you have any sources you can cite for this?

I think this more closely reflects reality for the first sentence of the compatibility section:

For example, Microsoft's Internet Explorer, the most popular web browser since late 1990s, used to ship with Microsoft's own JVM as the default. The MSJVM had some extra non-Java features added which, if used, would prevent MSJVM applets from running on Sun Java (but not the other way round). Sun sued for breach of Trademark, as the point of Java was that there should be no proprietary extensions and that code should work everywhere. Development of MSJVM was frozen by a legal settlement, leaving many users with an extremely outdated Java virtual machine. Later, in October 2001, MS stopped including Java with Windows, and for some years it has been left to the computer manufacturers to ship Java independently of the OS. Most new machines now ship with official Sun Java.

What do you think? Stephen B Streater 14:15, 1 March 2006 (UTC)

Added this, with a couple of refinements. Stephen B Streater 09:08, 3 March 2006 (UTC)

[edit] Removing cleanup tag

I'm thinking of removing the cleanup tag. This article is a lot more complete than previously, and organic updates will probably be enough to sustain it. Stephen B Streater 15:33, 5 March 2006 (UTC)

Removed tag. Stephen B Streater 08:56, 8 March 2006 (UTC)

[edit] Access permissions

I've copied this discussion from the Java Web Start talk pages. Stephen B Streater 08:47, 8 March 2006 (UTC)

The article lists some advantages over applets, but I was wondering if there are any disadvantages. Is it true, for example, that Java Web Start programs cannot run without the user giving permission? In contrast, applets (like Clesh should run automatically. Stephen B Streater 21:08, 5 March 2006 (UTC)

well testing with a java web start app i wrote (http://www.p10link.net/~plugwash/picsim.jnlp) it seems in firefox i get the "open with" dialog and in IE (xp but not sp2) it just opens immediately. I don't have XP SP2 handy to try it in. Plugwash 22:57, 5 March 2006 (UTC)

I ran your example Web Start program on my Mac (OS X) and it starts running without a problem. But if I try "save", it pops up a permissions box, and if I refuse, it doesn't save or load eg "load is not possible due to security restrictions". In other words, untrusted code does not have access to the file system.

There is an option which says, effectively, "always trust this code", but if I don't select this and trust the code, it never saves. I think your code can save because you have said to trust it. So, unless you can save something on my Mac without me trusting you, I suggest we change the words in the Java applet entry "from untrusted code" to "from trusted code". Stephen B Streater 02:34, 6 March 2006 (UTC)

No the apps code is still running untrusted, allowing a java web start app access to a single file is like uploading a single file for a website. the website is still untrusted even though you let it have a specific file. Plugwash 13:24, 6 March 2006 (UTC)

There is a difference, though I can see that it may be more a difference in quantity than quality. I'll explain what I mean. If you go to the Clesh guest account, you run an applet where you can "save" data or "load" it (in fact it is stored on our server). In practice, no dialog box comes up asking for permission, and you don't have to trust me to load and save - or at all in fact.

With your example, following your explanation, I know enough about Web Start to know that I don't have to trust you very much to save a file - a malicious application could eventually fill my disc and stop my machine working though. Before your explanation, I just said "No" to the big scary box. So I can see that, technically, I don't have to trust you very much (if I have perfect knowledge about Java Web Start and how it works), but in practice, a normal web user who didn't trust you may not use this feature just in case it was dangerous.

I see the applet version is qualitatively similar because a user still in principle has to know that Java applets are safe, but it is quantitavely different because his machine will be configured by default to work in the applet case but not the the Web Start case. So if the Clesh guest account were to run in Java Web Start and save to the local disc, lots of people would refuse to use it (or not be allowed to by their company IT department guidelines).

So in conclusion: if the question is whether disc access requires trust, given that a Web Start program could fill the disc and break my computer, if I don't trust it at all, I shouldn't allow it disc access. However, not much trust is required, though typical users may not know this. The default configuration of popping up a scary box makes a lot of difference in practice. The applet requires no trust. I think this difference should be reflected in some way, though if the only thing a malicious program can do is write a big file, this should also be reflected. Stephen B Streater 14:34, 6 March 2006 (UTC)

[edit] Irrelevant links

I think some of the links are irrelvant. Specifically to various links to examples and possibly the java virtual machine page. If no one objects I might delete some of them. (Perhaps leaving one example as a reference). Alternatively one could list various examples separately. (Alexwright 22:19, 20 December 2006 (UTC))

I removed the links to random examples of java applets. Many were dead and some seemed to have a definite air of advertising about them, and added a link to suns demonstration examples (these include source code which the original links didn't seem to which make them somewhat more useful). Thinking about it the link to the java virtual machine should probably stay to respond to the "what exactly is a java applet and why isn't this working" line of reasoning.

THe links removed are shown below in case someone wanted to selectively include some of them with less effort.

(Alexwright 21:08, 21 December 2006 (UTC))

Realised link was already there (Alexwright 21:13, 21 December 2006 (UTC))

[edit] Signed applets

I think there should be something about signed applets, which run outside the JVM standard sandbox. Look at this signed applet example [2] --88.161.150.94 21:42, 15 January 2007 (UTC)

I agree, there needs to be some info on Signed Applets.

Here's some more info on signed applets:

http://java.sun.com/developer/technicalArticles/Security/Signed/

And here's an article about the creation of signed applets:

http://www.developer.com/java/data/article.php/3303561

jarsigner documentation from Sun, has useful information about signed applets:

http://java.sun.com/j2se/1.3/docs/tooldocs/win32/jarsigner.html

Can anyone verify that signed applets are able to open up connections and act as servers? Serialized 19:12, 11 May 2007 (UTC)

[edit] Mention that Java applets are on the verge of extinction?

I think it would be appropriate to mention in this article that Java applets nowadays are generally not considered to be a useful technique in web design? Also state why such techniques as javascript and flash have grown more popular. 84.217.134.191 16:52, 1 June 2007 (UTC)

[edit] Headline text

$-$