Jump to content

Talk:Java applet

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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)[reply]
Appletviewer is included with the JDK. Plugwash 00:04, 15 December 2005 (UTC)[reply]

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.

Is this even English?

"Java applets run at very fast speeds comparable to, but generally slower than, other compiled languages such as C++, but until approximately 2011, it had been many times faster than JavaScript."

1st Comment: This sentence reads so poorly I can hardly understand it. 2nd Comment: For those versed in programming languages, this sentence is reasonably clear.

I think the problem is a missing or misplaced comma. If you like commas, it should be this:

"Java applets run at very fast speeds comparable to, but generally slower than, other compiled languages such as C++, but, until approximately 2011, it had been many times faster than JavaScript."

If you don't like commas (US?), it should be this:

"Java applets run at very fast speeds comparable to, but generally slower than, other compiled languages such as C++ but, until approximately 2011, it had been many times faster than JavaScript."

Personally, I think that it is much better to use an unambiguous symbol there that sets the precedence:

"Java applets run at very fast speeds comparable to, but generally slower than, other compiled languages such as C++; but, until approximately 2011, it had been many times faster than JavaScript."

Rick Jelliffe (talk) 00:25, 3 May 2018 (UTC)[reply]

It has nothing to with applets, explicitly. It should moved to an article about the Java platform general. 131.193.224.239 (talk) 19:28, 28 June 2011 (UTC)[reply]

I am under impression that at least Sun-Microsoft lawsuits were mostly about applets. Already present runtimes seem not very important for standalone programs as the installer can always bundles its own specific version Audriusa (talk) 08:57, 11 August 2011 (UTC).[reply]

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)

<object> is the prefered tag acording to the W3C, while tags like <applet>, <embed> and <bgsound> are all depreciated in the later XHTML spesifications. Actual browser support for this have up untill fairly recently been somewhat dodgy, but <object> should work with the latest version of most major browsers by now. Support for <applet> will probably not be removed any time soon though, so you can keep using it for a while still, it's just not "valid" (X)HTML acording to the latest standards anymore. --Sherool 22:45, 6 September 2005 (UTC)[reply]
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)[reply]
The root of all problems is that <object> must be different for Internet Explorer and Firefox, and the work-arounds are such that the final result does not look nice anyway. A typical problem of browser wars, I would think Audriusa (talk) 09:04, 11 August 2011 (UTC).[reply]
Would it not be a good idea to also include a valid HTML5 code example, with a nested <object> (IE) and <embed>(Firefox)? 108.22.250.31 (talk) 16:33, 31 August 2013 (UTC)[reply]

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)[reply]

While we're on the compatability 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)[reply]

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)[reply]

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)[reply]

"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)[reply]
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)[reply]
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)[reply]
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)[reply]
"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)[reply]
"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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
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 sExplorer, 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)[reply]
Added this, with a couple of refinements. Stephen B Streater 09:08, 3 March 2006 (UTC)[reply]

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)[reply]

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

Access permissions

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

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

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))[reply]

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))[reply]

Realised link was already there (Alexwright 21:13, 21 December 2006 (UTC))[reply]
I think it is better to upload some screen shoots because these links really die amazingly fast. This also filter out many advertisement - like stuff because (unless released by the software authors) a screen shoot is under free license only when the software also is. Audriusa (talk) 12:30, 10 October 2009 (UTC)[reply]

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)[reply]

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)[reply]


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)[reply]

Absolutely. I added a sentence to that effect and this JavaWorld link: http://www.javaworld.com/javaworld/jw-07-2001/jw-0706-webstart.html Cmccormick8 (talk) 03:25, 13 January 2009 (UTC)[reply]

The image Image:Java Logo.svg is used in this article under a claim of fair use, but it does not have an adequate explanation for why it meets the requirements for such images when used here. In particular, for each page the image is used on, it must have an explanation linking to that page which explains why it needs to be used on that page. Please check

  • That there is a non-free use rationale on the image's description page for the use in this article.
  • That this article is linked to from the image description page.

This is an automated notice by FairuseBot. For assistance on the image use policy, see Wikipedia:Media copyright questions. --23:33, 16 September 2008 (UTC)[reply]

Java applets in Wikipedia

A strategic proposal has been submitted to allow Java applets in Wikipedia. It contains interesting discussion and a number of applet examples. Maybe some material may be migrated into this article as well. The discussion is also evolving very interestingly Audriusa (talk) 09:39, 6 September 2009 (UTC)[reply]

Alternatives

I think that JavaFX can be also an alternative to java applet.--PhoneixS (talk) 14:42, 27 July 2010 (UTC)[reply]

It may be, and Java Web Start also. These are from the same company so less interesting. But of course you can add. Audriusa (talk) 21:10, 18 August 2010 (UTC)[reply]

I have added the MIT Curl as it is widely used in major corp's, a fact unknown outside perhaps Gartner Group, as it is used by Paisley div of Thomson Reuters financials and competes directly with s/w from IBM, Siemens and other major ISV's. Most information now in Japanese at www.curlap.com ; Curl was once evaluated as alternative to AIR and Silvelight in RIA, but had applets since first introduced in MIT spin-off. Curl features now present in Java 8 include closures, but Curl LISP-like macros remain distinctive : Curl applets have has signing options for the past few releases ( currently also in version 8.) In the interest of not abetting monopoly behavior by either Oracle or Microsoft, please retain this as an alternative ... I am not aware of any JavaFX code with similar penetration in Fortune 200, especially in banking. The Paisley Div of TR is best known for audit software used by some of the remaining global 4 audit firms ( And formerly used by Andersen at Enron ! See web archives on past customer conferences.) 142.162.44.93 (talk) 08:06, 1 April 2014 (UTC)[reply]

Security Issues

I find it hard to believe there is no mention of the numerous viruses and trojans that exploit security flaws in the java platform. You can get viruses/trojans simply by visiting a seemingly innocuous website that has a java applet on it. Darktangent (talk) 09:20, 22 August 2010 (UTC)[reply]

It is now covered that there are multiple reports on finding and closing security holes, same as with any other more complex system. The Calendar bug has been already referenced. However I doubt if any Java virus or trojan have ever managed to spread massively through the world. Audriusa (talk) 12:35, 6 September 2010 (UTC)[reply]
Security issues such as these change rapidly; more exploits are found, they're patched, it's a continual cycle and very difficult to keep up-to-date with. By the time wikipedia is aware of how an exploit works, it's most likely been patched in a newer version, or about to be patched. GiftigerWunsch [TALK] 12:45, 6 September 2010 (UTC)[reply]

Jars vs classes

Not much mention is given to the method by which applets are embedded on web pages. On my computer, I experience some slowdown from the decompression of a jar file, vs the instant initialization of a class file. However, Jars download much quicker because they're compressed. This speed curve should be graphed somehow. 75.170.45.99 (talk) 04:44, 15 September 2010 (UTC)[reply]

This depends on both connection speed and processor performance. On my laptop, it takes 0.018 s to unzip an average applet (time unzip neuron.jar, applet size 41K compressed) and 0.268s to download it (time wget http://ultrastudio.org/upload/Neuron-1.0a-372480bd-cfbc-30b2-8a0f-184648212b0c.jar), so I am not sure if any slowdown because of decompression should be noticeable at all Audriusa (talk) 18:39, 27 October 2010 (UTC).[reply]

Lawsuit

I doubt the lawsuit between Oracle and Google or the Open Handsets Alliance belongs here. As of my understanding it's in no way related to Java applets, which are - ditto as of my understanding - just an ordinary Java program with a special entry point. Maybe that would fit better into Java (programming language), JVM or so? --88.67.217.103 (talk) 21:23, 13 November 2010 (UTC)[reply]

The "game collections" linking to the page "Kurnik" seems inappropriate. You don't expect a page about a specific Polish gaming website when you click on "game collections" and this page doesn't even mention the word Kurnik. —Preceding unsigned comment added by 193.190.253.146 (talk) 12:45, 5 December 2010 (UTC)[reply]

Embed nonstandard?

The article says "A non standard embed element can be used with Mozilla family browsers." I realize this was probably true when it was written, but embed is in the HTML5 draft standard, and that should probably be mentioned. - Jmabel | Talk 16:02, 28 April 2011 (UTC)[reply]

It has been deprecated in HTML 4 and is standard again (added back) in HTML 5. The article has been corrected. Thanks for pointing this out. Audriusa (talk) 11:06, 2 September 2011 (UTC)[reply]

Example

i tried the example i cant get it to work. Every time it tries to load the java applet it crashes my web browser. all i see is "A Java applet example Here it is:________" I know i have java installed — Preceding unsigned comment added by 67.230.138.227 (talk) 18:57, 26 February 2012 (UTC)[reply]

um wut?

The introduction seems deliberately to obscure the distinction between compiled and interpreted languages. The implication that Java programs function in any way like C++ programs inside the computer is simply false. In this context the lede is reminiscent of an advertisement. Foogus (talk) 22:36, 3 July 2015 (UTC)[reply]

I've removed the unref sentence and the advert tag. Didn't look like an advert to me anyway.  —SMALLJIM  10:17, 11 July 2015 (UTC)[reply]

Hello fellow Wikipedians,

I have just added archive links to one external link on Java applet. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers. —cyberbot IITalk to my owner:Online 07:43, 26 August 2015 (UTC)[reply]

Hello fellow Wikipedians,

I have just added archive links to 2 external links on Java applet. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 14:12, 22 March 2016 (UTC)[reply]

Hello fellow Wikipedians,

I have just modified one external link on Java applet. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 16:53, 31 March 2016 (UTC)[reply]

Depreciation of the Java Applet API

The whole article ignores that as of 2017 the technology behind java applets is dead. Google Chrome and Mozilla Firefox have dropped npapi support and AFAIK there is no way to run an applet in a popular modern browser.

Maybe the article should be even rewritten in past tense - "A Java applet *was* a small application...", "Applets *were* written..." and so on. Emergie (talk) 08:56, 8 March 2017 (UTC)[reply]

I have done this. The deprecation is referenced and the head is in the past tense.Rick Jelliffe (talk) 00:19, 3 May 2018 (UTC)[reply]

and I have done it MORE! The entire article, with the exception of the security section, is now in the past tense. Calumapplepie (talk) 23:49, 25 November 2021 (UTC)[reply]

Hello fellow Wikipedians,

I have just modified one external link on Java applet. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 23:33, 19 April 2017 (UTC)[reply]

Security section POV problems

The security section has serious POV issues: the author seems to be determined to state that Java applets are perfectly secure, and that the push for signing them was silly and unnecessary. I don't have the energy to track down who did this, or why, nor fix it. I redid the tenses in the rest of the article and did some heavy copyediting, but I'm done for the day.

The new section should ideally cite articles about specific vulnerabilities and their impact, as well as how they were exploited. We need to find those articles about how much of a security nightmare applets were now, before they are slain by bitrot. The audience of this article will now be young internet historians learning about the wild world of the old net: we need to give them further reading materials on the fall of applets. Calumapplepie (talk) 23:54, 25 November 2021 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Java_applet&oldid=1201399130"