Proposal talk:Java applet support/20 August 2009 - 2 November 2009

Front matter

The proposal will be altered, paying attention to comments that look reasonable.

I'm not sure where anyone got the idea that only some subset of people have the authority to edit the proposal but that isn't how things work here: The proposals are living documents which any contributor may make a good faith contribution to— you don't own your proposal. --Gmaxwell 15:56, 15 October 2009 (UTC)

This simply means that I am taking good things from discussion time to time and people should not be surprised that the proposal is evolving. AudriusA 11:10, 16 October 2009 (UTC)

I'd recommend that additions to a proposal should be recognizable as such, at least if made without a prior discussion. One can, for instance, use an Additions section to separate later modifications from the original proposal. --Fasten 14:30, 11 November 2009 (UTC)

Advogato discussion

This article has also been posted to Advogato at http://www.advogato.org/article/1017.html to discuss with the FOSS community. Who is interested, can follow the provided link to see the feedback there (feedbacks appear at the end of the article).

Discussion here (please add new topics to the end)

Proposal talk:Java applet support/20 August 2009 - 2 November 2009

There is some evidence that Flash is slightly more ubiquitous on some platforms, but I'm not sure overall, and in any case Javascript and especially entirely server-side solutions are far more client platform independent. Having said that, for a wide range of applications, there is no way to avoid Java or Flash, sadly. 99.35.128.135 15:54, 20 August 2009 (UTC)

Server side solution requires server to be involved that at least currently takes many seconds, far too much to be truly interactive. I think the general framework of educational visualization should have canvas where some graphical information (function graph, electronic circuitry with "live" current and voltage labels next to elements and so on) is painted plus user controls like buttons, text fields and sliders at the bottom to control the simulation process. Java provides a solution for this problem that is proved by a number of such applets on a web. If some other platform gives a good solution also, that is also great, please write one more proposal and post the links to examples. Audriusa 11:14, 22 August 2009 (UTC)

The claim that server side behaviour adds "many seconds" of delay is outrageously incorrect. JS + server side is the basis of most "web applications". Java may indeed be a useful tool, but you should not promote it by spreading misinformation about the alternatives. --Gmaxwell 22:24, 23 August 2009 (UTC)

That very much depends on the latency of your network connection ;) "Many seconds" are easily reached in not-so-ideal circumstances. Fact is, you would never want to delegate any real-time computational task (such as, say, rotating a 3D object in a visualization) to a remote server via an HTTP request. This would always be done on the client side. So it needs a kind of client-side application that can handle these complex tasks. JS won't do it I fear. Of course there are other alternatives than Java, and they're mentioned, but I do not see "spreading of misinformation" here. --B. Wolterding 22:37, 23 August 2009 (UTC)

It is common for me to wait for Wikipedia or any other server response in 2-5 seconds and at times much longer at work where connection is really good. At home where it is worse it is not unusual to wait for 10 seconds and more. From the other side, when visualizing function graph or manipulating object it is good to update it is as user moves the mouse - somewhat 20 -50 times per second. This is that I meant writing that the server side visualization is not as fast Audriusa 07:37, 24 August 2009 (UTC).

Typical backend service times from Wikimedia for cached content are in the milliseconds, and even uncached backend requests are fulfilled in tens of milliseconds[1]. On top of that you add your round trip time to the WMF datacenter, which shouldn't be higher than about 250ms anywhere in the world with good connectivity. Of course— a great many people have terrible connectivity (as you must if you're seeing 2-5 second responses) but downloading a Java applet on a weak network connection is no joy either. Server side operation is obviously not a solution for every need because the responses are much slower than client local operation, but it has its advantages. --Gmaxwell 16:05, 15 October 2009 (UTC)

Java applet typically has a size of the bigger image, several Mb. AudriusA 11:15, 16 October 2009 (UTC)

Is this proposal a joke? I thought the days of java applets ended at the turn of the century, and I don't think anyone has missed them. I can't even remember when was the last time I installed applet support in any of my desktops, certainly was many years ago. Flash, like all plugins, is awful, but Java applets would be an even further step backwards. Also as a user of Plan 9 and other 'esoteric' systems (both cpu architectures and OSes), Java and Flash are extremely unportable and should be avoided if wikipedia content is to remain universally accessible. -- uriel

No, it is not a joke. Surely people who are so skeptic do not have Java installed, do not see any applets and as a result may think the applets do not exist anymore or maybe are too limited to do anything with them. This is why I have uploaded screen shoots to the proposal page to show that this technology is widely accepted for illustrating scientific and other similar content. The alternative image can be provided for browsers without applet support. I would never be suggesting this without knowing that even Sun's Java is FOSS now so can be ported to the new platforms. If this seems too problematic, "esoteric systems" maybe could use gcjappletviewer from GNU Classpath that was written from beginning to be easily portable Audriusa 06:38, 10 September 2009 (UTC)

With all due respect, uriel - is your post a joke? These days, you'd have more problems finding a decent, up-to-date web browser for an "esoteric" platform than finding a Java VM. Does anyone have statistics about browser/client platform usage on Wikimedia's servers? I'd be interested which share platforms without available Java implementation actually have - probably, less even than people who disable stylesheets or image display. --B. Wolterding 23:57, 12 September 2009 (UTC)

By the way, as to sites using Java applets today, see for example en.wikipedia.org. --B. Wolterding 13:39, 13 September 2009 (UTC)

A perfect example— Java is used by Wikipedia as a last resort fall back if there is no other supported option to play the video/audio, and it still generates complaints about it crashing people's browsers. :( Not exactly a ringing endorsement for applying Java more broadly as a first-choice solution. --Gmaxwell 16:05, 15 October 2009 (UTC)

Well, let's stop saying Java is always crashing, does not sound seriously because it is not. People who propose applets have certain experience with this language. AudriusA 18:11, 16 October 2009 (UTC)

I certainly didn't say that it is always crashing but some people do say that: They say it because it frequently crashes for them. Some non-trivial percentage of users have broken JVM installs and most of the time they touch an applet or a particular applet their whole browser crashes. Even if the crashing were just a problem with the authors of some applets being written by inexperienced developers, we'd still be left with the sandbox being insufficient. By itself this isn't necessarily a killer flaw but the unwillingness to acknowledge and addresses these costs undermines this proposal. --Gmaxwell 07:27, 2 November 2009 (UTC)

Hacking

Integrating scripting or any kind of programming opens the door for hacking attacks. For this reason it is not very clever to open a frequently visited website for such measures. But there could be also an solution by limiting access to a selected group of user who review changes and additions before making them available.

In the early days there was a disbalance between implementing effort and need, but today this might have changed.

--93.213.174.89 15:54, 22 August 2009 (UTC) (aka de:User:Biezl)

All this proposal is about how to have a security in place. Many things can be solved by allowing applets only from selected group of people with real names, introducing reviewing process with source code and further restricting the list of available language features by removing that Wikipedia applet is unlikely to need. Also, we may require users to opt-in to see applets. The ultimate mean is to provide the set of fixed applets for that only parameters can be customized but this may limit too much that we can do with them. From the other side, Trojans are not very common in FOSS, so after we filter clear vandalism they may not be common in the remaining applets as well Audriusa 18:51, 22 August 2009 (UTC)

I agree that there is at least a theoretical risk of hacking attacks. On the other hand, software additions to Wikipedia are quite common even today - namely in the form of bots and client-side scripts - and while security concerns exist, they do not seem to be so much of an issue in practice. Some review and approval processes exist, but they are surprisingly weak (at least surprising to me), which has so far not been an issue of concern. For the Java applets, it might be reasonable to require the source code to be open; maybe they should be compiled on the side of Wikimedia from the published source. Apart from making development independent of the individual user, this would also address most security related issues. --B. Wolterding 21:09, 23 August 2009 (UTC)

Another remark: the "fixed set of applets" proposal seems too rigid and inflexible to me. --B. Wolterding 21:11, 23 August 2009 (UTC)

Import declarations

The proposal currently says, in the discussion about security, that "Java code needs to declare the packages it uses in the beginning of every file." This is not true - you can use fully qualified names in the source without importing them. It's still possible to check which classes are used, but unless you want to write a full parser the easiest way is to process the .class files produced by the compiler. HenryAyoola 18:14, 24 August 2009 (UTC)

Definitely miss. I see we would likely need to use JavaCC or something like that. Updated. Audriusa 19:59, 24 August 2009 (UTC)

I think that the point "Restricting the set of Java classes" is quite weak anyway, maybe it should be removed altogether. For most of the libraries, any "malicious" programmer could just upload them under a different name. For the core ones, a brute force restriction might not actually be what you want - quite probably there are applets that want to use java.net for legitimate purposes, e.g., talking back to their own wiki. I'd say: leave it to the sandbox - which is probably much harder to break than any homebrew restriction created ad hoc. --B. Wolterding 21:21, 24 August 2009 (UTC)

Leaving it to the sandbox is brushing it under the carpet, because we all know that users will blindly click "Ok" on the security dialogs without reading them. If that's what the community wants then fine, but it's as well to be realistic about the implications. HenryAyoola 22:19, 24 August 2009 (UTC)

But the person so careless likely already has many viruses in his computer... Audriusa 06:10, 25 August 2009 (UTC)

The point is: properly written applets do not trigger security dialogs. Why would someone submit an applet which does networking or file io without evil things in mind? The java sandbox is compared to other client based technologies (like flash) *very* restrictive. IMO applets which require full system access (signed applets) should be forbidden in wikipedia (except there is a very good reason for a particular applet). There is no need for bytecode checks or whatever - the java runtime already has a strict security model. Please don't re-invent the wheel ;) mbien [edit] honestly I think most of the "reduce risk" section is invalid if you only allow unsigned applets which live in the sandbox anyway mbien

The better. Absolutely, no idea to allow applets with full system access on Wikipedia. All applets should be checked if they have internal signature and signed ones should not be allowed. If some applet triggers security dialog, it should be eliminated during approval process. Also, while this may be dependent, security box shows without "allow" button in my system (see File:Spopup.png) Audriusa 14:52, 25 August 2009 (UTC).

The Java security model is ill-fit for sites to accept and host potentially hostile code. For example, an unsigned applet can not make network connections to random locations— an important feature because otherwise the ability to upload Java to Wikipedia would allow you to command a multi-million user DDOS botnet. Except the Java security model doesn't prohibit networking entirely: Unsigned applets can connect back to their origin host. This is an essential function for most applets, otherwise they couldn't send or receive data to process... but in the case of a hostile applet it means that an uploader commands a multi-million user DDOS botnet which can only attack Wikimedia. The browser vendors have put in an enormous amount of work in their JS and HTML code at preventing XSS attacks. The Java security model provides little to no protection against this class of attack and, in fact, abusing holes that allowed users to slip totally unsigned Java applets on to websites by masquerading as permitted file types (i.e. zip) is a recently popular mode of XSS attack. There are things which can be done to mitigate these risks: For example— hosting Java applets on their own isolated domain will prevent some XSS but retains the DDOS issues… but you simply can not claim that the Java sandbox removes the security problems and that wheel reinvention is not required. Cheers. --Gmaxwell 15:45, 15 October 2009 (UTC)

Dedicated domain looks a good idea, added to proposal. Also, server may stop delivering misbehaving applet automatically (may be possible by matching applet download/data request IPs). By the way, how these mentioned bots work against restriction that they can only talk with the parent server? Maybe they are actually signed somehow? AudriusA 11:26, 16 October 2009 (UTC)

Imagine You run a forum. I trick it into showing users an applet that I uploaded as an image. Now your users DDOS *you* or they control your clients to make them make posts without the operators knowledge or consent. That is an XSS attack. To DDOS a third party site you need to evade the sandbox. There have been a number of attacks to do that in the past, but I don't know of any that work against the most recent JVM versions, but since pretty much no one allows java to be uploaded that doesn't also allow JS and you can DDOS using pure JS (imagine adding 1000 hidden img src="http://victim.com/" to enwp main page via JS) there has not been much incentive for people to try to find holes in the sandbox network policy enforcement.

Unless every applet gets its own IP I'm not sure how you could reliably detect misbehavior, but thats an interesting idea. --Gmaxwell 07:36, 2 November 2009 (UTC)

Applets must exists in they own read only domain where it not possible to do any changes that persist after the browser is closed. Apart that, brief look into the applet source code will likely disclose such attempts and a simple scanner can help putting hint in the code review page that network classes are used. Apart that, maybe it is possible to correlate DOS attacker IP with the list of applets that IP has recently downloaded. JavaScript I do not know and do not care, who wants this language in Wikipedia pages should discuss in a separate project. AudriusA 12:21, 2 November 2009 (UTC)

To merge and not to merge

The topic of this proposal are Java applets, the end. Please do not propose to merge this proposal with articles that list multiple solutions, mentioning Java just by the way. The proposal that suggests to combine multiple technologies inevitably has completely different resource and likely timeline sections so it is a different proposal. I myself think that at the end at most two technologies should be chosen, and alternative platforms must be discussed separately. If you think the proposal is relevant, put into "see also". Audriusa 18:42, 26 August 2009 (UTC)

Scripted SVG

Except in computationally intensive cases, could not similar results be achieved by scripted SVG? Globbet 22:51, 22 September 2009 (UTC)

if you mean SVG Canvas? yes. and there is an even better way: use the GWTCanvas API, which is abstracted out and, on IE / Trident platforms, utilises VML instead of GWT, thus guaranteeing that an application that is conformant to the GWTCanvas API will operate cross-browser. there is even a port of GWTCanvas to the Pyjamas toolset (see Pyjamas GWTCanvas Demo. bottom line: except in computationally-intensive cases, there is absolutely ZERO need for a java plugin. Lkcl 12:34, 24 September 2009 (UTC)

No. I mean SVG. Globbet 00:13, 28 October 2009 (UTC)

As I see from W3 it is simply a proposal to use JavaScript or other very similar technology for the picture visualization. JavaScript is a good alternative technology to discuss and this idea without any doubt deserves its own proposal (especially Pyjamas seems making a lot of sense). It is absolutely better than having nothing at all as it is now. However in comparison to Java, JavaScript is slower and may put limits on the most interesting visualizations (write a chess applet in it!). I also evaluated the mentioned GChart - it makes good first impression and I would definitely recommend it for charting in Wikipedia instead of putting chart pictures like now. However I also see that the sine graph that does not do anything complex is already sluggish when moving the mouse faster. The Mandelbrot set viewer in JavaScript that I found on a web also looks worse than Java applet in the proposal, both in terms of performance and resolution. Applets with heavy 3D usage (like World Wind) may be also be difficult with JavaScript alone. Finally, while bar charts look awesome with GCart, even for pie charts the used technology is already difficult (see the site itself), and how it will be with arbitrary graphics?. Well, I like JavaScript as well and think these two languages have different enough focuses to coexist. Maybe some parts of the evaluation/approval infrastructure could be shared, reducing synergism between these two projects Audriusa 11:26, 25 September 2009 (UTC).

yes, you have to take extreme care in what you do, and yes, the users have to upgrade to a modern "Web 2.0" browser such as firefox 3.5 or a webkit-based one (safari, iphone, chrome, nokia s60, android etc.). also, HTML5 firefox and webkit now do actually have support for 3gl - 3D HTML - so things _are_ moving along. and, when you look at the recent thing that google did by providing ChromeFrame, which is the entire google chrome browser as a plugin for IE6, IE7 and IE8, and you join the dots to the fact that chrome is a webkit-based browser and thus will also gain the 3D OpenGL HTML5 support - the technical argument for inclusion of java because it can "do graphics" is much, much reduced. Lkcl

Seeing some other platform is evolving and expecting it may produce comparable results in the future is not an especially strong argument to avoid Java that is already available for over ten years. But I would rather like to see JavaScript support evolving than stay without anything as it is now. Audriusa 21:59, 26 September 2009 (UTC)

Impact?

Some proposals will have massive impact on end-users, including non-editors. Some will have minimal impact. What will be the impact of this proposal on our end-users? -- Philippe 00:11, 3 September 2009 (UTC)

This proposal will likely have a big impact on articles where illustration with Java applets is reasonable (physics, some mathematics, maybe some programming topics and also some games). Not all applets that would efficiently supplement existing static images are difficult to write. The proposal will also have an impact to the middle to high level Java programmers that could contribute to Wikipedia in the way they now cannot. The total scale of the impact depends on the number of incorporated applets and can be boosted by collecting existing applets under appropriate license from the web. It looks that the project will not have big impact to the editors that only use Wiki language to design the pages. Audriusa 06:46, 4 September 2009 (UTC)

The impact of deployment of java will have a massive negative impact both on reach and on accessibility, from several perspectives:

• contributors who wish to make corrections to an incorrect implementation of an "authoritative" wikipedia page which HAPPENS to be written in java will be FORCED to install, deploy and learn this stupid language. in this way, contributions to wikipedia, via java, can become "elitist". here are some of the kinds of circumstances, which is by no means a complete list, under which willing contributors will not be able to contribute:
  • if the contributors do not have 150mb of spare disk space (for the java / eclipse development environment);
  • if the contributors do not have sufficient internet connection to download the development environment (150mb costs £3 of a 1gb/month 3G connection, and that's JUST the European prices; a VAST percentage of New Zealand is still on 56kbaud Dialup; etc.);
  • if the contributors do not have access to machines with the resources capable of deploying a java development environment
• affordable netbooks (such as the £120 CNM MIPS-based life book, available from Maplin's) and other embedded systems will not only not have the resources to run high-powered java applets but if someone actually tried, they would have a bitch of a job getting an interoperable / compatible version. illustration: can you GET sun java 5 compiled for linux on the MIPS processor?
• does the wikipedia foundation want to get involved in the task of picking out and testing the lowest-common-denominator java development and deployment environment?

i'm going to leave it at that, because the number of reasons why this is such an incredibly bad idea are so numerous that it would take hours to list them all.

Maybe I could pay your attention at least that Java JRE (1.6.16) is 19.39 Mb only and also I do not understand why do you want to download it through GSM network. Is this how all operating system is supposed to be downloaded? Development environment will be more likely to be installed from some distribution that is already on CD or DVD, especially in places where network is expensive. If you do not like Sun's proprietary solution (this is understandable) and think it is too much work to port OpenJDK, GNU Classpath + JamVM will build rather easily everywhere where you have the usual gcc toolchain. Machines with less than 150 Mb hard drive likely make a real minority now so they impact is unlikely to be 'massive' Audriusa.

User:Audriusa, please read again all of the points above "as a whole", not "individually". also, please ignore "me", personally, as a weird statistical sample of "one", and substitute "10% of the world's population" into the question "I do not understand why do you want to download 19.39mb over a 28kbaud GSM or 56kbaud dialup connection?" and you automatically have the answer. also, please look up the availability of modern hardware in emerging countries and third world countries: you'll find that they are one to two DECADES behind, in terms of accessibility to computing resources. we, the first world countries, send them our utterly-polluting energy-consuming cast-offs, and they are forced to make do. in this context, 150mb is a lot.

overall, then, the entire proposal's viability rests on the assumption that the resources of the modern computing era can be made magically available to the rest of the world. unfortunately, the only reason that the technology of modern computing has been created and deployed is because it was created by countries with a world population percentage of under 20 percent consuming something insane like over fifty percent of the world's non-renewable resources. to think that that is sustainable is sheer madness and, far from assuming that it will continue, it is necessary to assume the complete opposite. consequently, it is imperative to take advantage of the opportunity that this glut of wealth and resource mis-management represents to do a complete U-Turn and start planning how to drastically cut resources. that means cutting energy usage, and cutting computer resource usage. in this context, proposing to deploy something that would drastically increase energy consumption and resource usage, both for wikimedia page editing and entry and wikimedia page viewing, is unacceptable. User:Audriusa, when i said that the number of reasons why this proposal is a bad idea are overwhelming, i absolutely wasn't kidding about. Lkcl 17:40, 5 October 2009 (UTC)

I still think that resources, needed to run Java and develop for Java are not so huge and majority of machines over world do have sufficient resources for that. These low power old computers you mention were very expensive at the time they were manufactured so I do not expect to find a lot of them in pure countries. The only rationale I see here is that maybe some cheap but highly resource limited computers might be produced and spread through the world near for free; then it is good to have the client as thin as possible. I however am not sure if we should build Wikipedia around these future machines that may never be massive. I understand your point of view and do not share it. Audriusa 11:15, 6 October 2009 (UTC)

audriusa, your comments indicate that you still haven't read the objections "as a whole". whilst some "machines" might have the capable resources, individual users will not. programming takes a lot to learn - too much for the average user - and the risk of making pages "elitist" by forcing contributions to be in the programming language "java" instead of "plain readable text" is too great. there is enough objection to wikipedia pages being in an "unreadable" wiki-markup for "ordinary" people to "understand". forcing the average person to write code and learn an advanced programming language, just to contribute to a wikipedia page, is such an anathema that i'm surprised and dismayed that you are continuing to advocate this proposal as workable. it isn't fun or funny to me to have to continue to return to this page to find that there is yet another "i don't see why" comment, but this proposal is all round detrimental to wikipedia on every front, and, being able to recognise that, i feel that have a duty and responsibility to ensure that this proposal never sees the light of day. Lkcl 22:13, 11 October 2009 (UTC)

Somebody talks above about spending a lot of money to download the Java Development Kit, which is obviously a nonsense. Anyway if you want to contribute photos you will need to spend much more money in order to have a decent digital camera. Best regards, Alpertron 22:59, 8 October 2009 (UTC)

alpertron: it's "obviously a nonsense" if you live in the first world, have first world resources and access to first world university training, first world information and more. and regarding cameras: have you looked up the price of 1.3 mega-pixel CCD-on-a-chip devices? you can pick them up now as "keychain" toys, for under £15, from Asda's and Tesco's supermarkets. such devices, which are actually the same technology as used in £20 webcams, are a considerably better investment, and considerably easier to learn to use, than a Java Development Environment. Lkcl 22:13, 11 October 2009 (UTC)

The points that Lkcl tries to make could, almost literally, be made about any multimedia technique (say, inclusion of videos). However, these techniques have been used on WP for long, and apparently they don't present a problem. --B. Wolterding 23:00, 10 October 2009 (UTC)

yes - and i take issue with the inclusion of video in wikipedia, as well, for pretty much exactly the same reasons (with the additional reasons for java and other programming languages being that pages written solely and exclusively in java - or other programming language - become elitist and thus reduce reach). external linking to video i see as acceptable; actually embedding the video as uploadable data into wikipedia.org: no. see comments at Proposal_talk:Better_Video. Lkcl 22:14, 11 October 2009 (UTC)

Translations

It is clear that for translations of the texts that appear on applets the source code must be given, as expressed above for other concerns. The translators must also be trusted, because they could introduce a bug (or non-intended feature) in the executable image (class files or JAR file).

If the source is kept inside Wikimedia server it would be interesting to tag the texts somehow so the translators only change these texts and not the Java instructions, for example a MediaWiki extension could present boxes with the English language (or applet original language) text at the left and the translated one at the right of the screen. Then the code can be recompiled inside the Wikimedia server. In this case there is no risk to introducing bugs while translating text.

What do you think of this idea? Best regards, Alpertron 14:01, 23 September 2009 (UTC)

A part of the Java applet can be a single file where all text strings are stored. It is trivial to have an id to string function to get a required text through this id to string table. Then only this file needs to be translated and this can be safely done without risking to harm the application. For applets, compliant with this design, the server could support submission of "translation" in the form of the id to string table for the particular language and after checking that all ids are present package the .jar itself. The id to text string can also be embedded into HTML page as applet parameters - while this may not be convenient for huge texts, it is very trivial to implement and support and most of applets likely will not contain a lot of texts. As most of the text labels are single words or short phrases maybe even automate Google translator would work at least in some cases Audriusa.

Alternatives

(moved from proposal page)

JavaScript and ActionScript are two other languages that may also be discussed. For the author of this proposal, Java seems more suitable for generating user-driven visualizations

no it's not in the slightest bit "more suitable". see GWT and Pyjamas for a perfectly acceptable rich media development systems, which are perfectly well capable of producing highly complex GUI applications (e.g. GChart). see GChart for GWT and GChart for Pyjamas as an example. 217.147.94.29 12:19, 24 September 2009 (UTC)

and also similarity to C allows to port code from research projects more easily.

While Java may be not as fast as C (that is not possible to embed into browser), it seems notably faster than JavaScript[2] and can be used in computation intensive visualizations like Mandelbrot set in the figure. Differently, the primary use of JavaScript is to interact with the whole page layout (DOM model). This is not necessary for visualization of objects and processes but very good for many other goals. The application areas are so different that Java and JavaScript might coexist without competing. 217.147.94.29 12:19, 24 September 2009 (UTC)

User:Lkcl - 217.147.94.29 is the IP address of my HTTP proxy. it looks therefore that the above comments are credited to me, which is dead-wrong. i conclude therefore that in the process of moving this text, it has become garbled. i will therefore re-iterate my views on this subject, in the above context:

The whole issue of expressing wikipedia pages in code is elitist, is a complete anathema, and utterly goes against the principles of "accessibility" and "reach" which this entire strategic planning session is designed to encourage, not stifle. It does not matter what the percentage of developers who know java are (or any other programming language for that matter): the number of people who know programming languages period is a minute fraction of the world's population. this fact alone should be sufficient, i believe, to reject this proposal absolute outright without a moment's hesitation. and, sadly, after a week's reflection, even any other proposals which recommend any _other_ programming languages, even my own favourite ones, python and javascript, should likewise be rejected on the same grounds: 99% of the world's population aren't programmers, but (near as makes no odds) 100% of the world's population can express words as "text", even if it means that someone else has to type it or read it out aloud to them. Lkcl 17:22, 5 October 2009 (UTC)

(end of moved text)

See my evaluation under Proposal talk:Java applet support#Scripted SVG Audriusa 20:32, 25 September 2009 (UTC)

No way

Absolutely without a shadow of doubt: java should never, not within one million years, be considered for inclusion in day-to-day wikipedia application / pages. About the only thing that should be considered is javascript, using either GWT or Pyjamas to compile java or python into javascript, respectively if the developer would like to do something a little more complex than throw a few random scripts together off the internet, but other than that: absolutely not. (the only reason for considering the use of javascript is because every single well-known web browser of the past fifteen years has had javascript in it, by default).

the only thing worth considering would be to use wikipedia for archival purposes, storing the source code of a scientific java applet (basically doing the same job as http://archive.org) but that's about all.

the number of reasons for _not_ allowing java to be run through wikipedia are so numerous that it is too time-consuming to go through them all, here.

Sorry but without explaining these reasons properly your talk is not as usable as it could be. Arguments are needed to persuade somebody. Audriusa 08:32, 25 September 2009 (UTC)

the short answer is this: at present, you can even use a text-based web browser to view and edit web pages. contributing wikipedia is all about making the "lowest common denominator" as the absolute top priority. java is elitist in its deployment, elitist in its development, elitist in its development environment - it is in fact the complete opposite, in every way shape and form, of "lowest common denominator". never mind the security issues: those are secondary considerations to the simple fact that java plugins and the development of java plugins DRASTICALLY cuts out massive proportions of contributors. on this basis alone - elitism - java should ... i can't even think of the words to emphasise this enough, java is _that_ much at odds with wikipedia's goals. Lkcl 20:33, 26 September 2009 (UTC)

If Wikimedia projects use the lowest common denominator as you say above, why does it supprt graphics? They are not needed on text-based browsers. Please think about the educational aspects of applets on end users, which are very important as explained by others. Best regards, Alpertron 01:57, 5 October 2009 (UTC)

i have. the risks and the costs drastically outweigh the benefits. i don't understand why you don't understand this. additionally, your reply indicates that, throughout all this discussion, where i have repeated time and time again the importance of treating "end users" as "contributors", you (or whoever you are) have ignored this and are implicitly viewing "end users" as "passive consumers". so - answer this very important question: how is an ordinary "end user", especially one in a third world, supposed to contribute to a page that's written in java? Lkcl 22:33, 11 October 2009 (UTC)

According to the Wikimedia server statistics, the vast majority of accesses are not done by contributors, so while there is a lot of changes on Wikimedia projects, that is nothing compared to the hits the Web servers receive only to retrieve the articles, files, etc. Best regards, Alpertron 02:19, 12 October 2009 (UTC)

this answer does not answer the question. Lkcl 16:01, 14 October 2009 (UTC)

questions:

• does the image "replace" the text? answer: only on some very stupidly designed web sites or for captchas.

The applets would not replace the text. They would be used to enhance the articles, as the images do.

• is wikipedia a stupidly-designed web site, where images are allowed to be the sole exclusive replacement for text? answer: no.

Right, because images do not replace the text.

• does wikipedia require captchas, for the purposes for which captchas are deployed? answer: yes.
• will an image be perfectly sufficient as a LCD substitute for a java interactive plugin? answer: in most cases, yes.
• will an image along with a sufficiently clear and precise explanation as an LCD substitute for a java interactive plugin? answer: in virtually every single case: yes.

The correct answer for this one is no: interactive applets can teach the subject better than static images.

against the background of the rest of the objections, you are entirely missing the point (whoever you are). in a full cost-benefit analysis where the cost to contributors is higher because they have to write a complex subject in plain text, augmented with static images, against the cost of elitism, the high cost of learning an elitist programming language, the high cost of resources required to develop in the elitist programming language... are you getting the point yet? Lkcl 22:27, 11 October 2009 (UTC)

Contributions are not compulsory. You contribute what you want. Most people only read and do not contribute at all. Then some people writes text and other people adds pictures/diagrams/audio/etc. to enhance the text, so I see no problem that other group of people contribute their programming experience for free in order to make Wikimedia projects a more educative experience. Best regards, Alpertron 02:13, 12 October 2009 (UTC)

• is there a risk that allowing java will result in java becoming an elitist method of expressing knowledge, over-and-above plain and simple text (augmented potentially by images)? answer: yes.

No. Creating images need us to buy digital cameras or scanners, so that means that photographs are elitist also.

invalid and irrelevant objection (whoever you are). it should be blindingly obvious that the training required to press a button on a £15 1.3mega-pixel integrated camera is nothing as compared to the training cost of learning java, plus the cost of a machine capable of developing java, plus the cost of evaluating the java applet for security problems, plus the cost of evaluating the java applet for interoperability with an unknown and unquantifiable "lowest common denominator" java runtime and VM. Lkcl 22:27, 11 October 2009 (UTC)

I don't know where you buy your digital cameras but here in Argentina my 6.2 megapixel camera costed me more than 200 dollars, while learning and downloading Java was free, so it is more than 200 dollars cheaper to contribute Java than contributing images. You can see some applets I've written in Java here: http://www.alpertron.com.ar/JAVAPROG.HTM . Best regards, Alpertron 02:06, 12 October 2009 (UTC)

• is that risk acceptable? answer: when hell freezes over (translation: no.)

?????

• are there other ways to express the same educational concepts WITHOUT using java? answer: of course there are.

Examples, please.

• is there any good reason to include java? answer: none whatsoever.

Read the answers above.

i'm really sorry but it's absolutely necessary to go over this in quite some detail. several people have indicated that they consider this proposal to be a joke, but i don't consider it to be a joke, at all. the risk that this proposal presents to the reach and accessibility of wikipedia is: extremely detrimental. therefore i have the rather unfortunate responsibility to answer the questions being raised, so that there is no risk that this proposal be accepted. Lkcl 17:11, 5 October 2009 (UTC)

I think that this proposal can be quite beneficial to Wikimedia projects. Best regards, Alpertron 22:12, 8 October 2009 (UTC)

you need to substantiate that, and you have a considerable amount of work to do, to do that. you will need to show that an average person in a third world country, with only the resources available in that country can, from scratch, be able to easily download, view, edit, compile and upload contributions in "java" format. Lkcl 22:27, 11 October 2009 (UTC)

You forgot the most expensive component on contributing Java: the computer. But almost any person who is reading/contributing to any Wikimedia project already has one. The other stuff can be downloaded and learned free (I've never bougth books on Java). Best regards, Alpertron 02:06, 12 October 2009 (UTC)

Unobtrusive use of Java

Unobtrusive use of Java could show a PNG file as a placeholder for an applet. A user could be required to

• login
• configure his preferences to allow Java applets
• click on the placeholder image to launch the applet

Together with a limited selection of applets made available by a volunteer team that should address all security and usability problems. The team could evaluate applets according to security and quality policies and reject unwanted interactive content. --Fasten 11:40, 10 October 2009 (UTC)

This can also be configured via browser settings but in general I agree. Replacing image is surely necessary for browsers without Java but it may be just an ordinary image, not a screen shoot of the applet. Maybe it could have something like a tiny button at the corder to launch the underlying applet if preferred. Audriusa 12:04, 10 October 2009 (UTC)

I wasn't referring to browser settings. A wikipedia article shouldn't start an applet without any way for the user to avoid it. The Wikipedia user preferences could be used to select between an image and an applet and even if the applet is selected it should only launch on request. The image (screenshot or other image) can be shown instead, which would allow to keep a rectangle of the same size for the applet. The exchange between image and applet can be initiated from JavaScript. --Fasten 15:24, 10 October 2009 (UTC)

I'm not sure whether such extra configuration steps are necessary, and will enhance user experience. By the way, it is interesting to note that at the moment, opening a Wikipedia page like this example, and then doing one mouse click, will start a Java applet. This may be browser dependent though. --B. Wolterding 23:15, 10 October 2009 (UTC)

Yes, that is probably the WikimediaPlayer. A similar setup could allow to launch other Java applets. --Fasten (Wikinews: Aktion Deutschland Hilft asks for donations after the earthquake in Indonesia) 14:25, 11 October 2009 (UTC)

Maybe then the [Lauch] and also [Discuss] buttons at the corner of the replacing image would be a solution. This would allow to avoid applets by the people who do not want them. Putting everything to user preferences does not actually look great as this may eliminate a big percent of users who just will not be aware that applets are possible and can be enabled somewhere in they settings Audriusa 09:53, 11 October 2009 (UTC).

Yes, instead of expecting people to click on an image that may or may not imply that it can be used to launch an applet a link or button in a common design could suggest that there is interactive content. --Fasten (Wikinews: Aktion Deutschland Hilft asks for donations after the earthquake in Indonesia) 14:25, 11 October 2009 (UTC)

Most readers do not use the editor interface, so they do not login. This means that for these people any effort to add interactive contents would be worthless using the approach cited in this section. So if the applets are trusted there is no need to login. Just pressing a button somewhere (if the applet is not allowed to start immediately) should work. Best regards, Alpertron 16:43, 11 October 2009 (UTC)

True, I was trying to recommend a very unobtrusive use. --Fasten (Wikinews: Aktion Deutschland Hilft asks for donations after the earthquake in Indonesia) 09:12, 12 October 2009 (UTC)

JavaFX and Jigsaw

Opponents of Java should probably read up on Jigsaw and JavaFX. --Fasten (Wikinews: Aktion Deutschland Hilft asks for donations after the earthquake in Indonesia) 14:45, 11 October 2009 (UTC)

Questions Requiring Answers

Advocates of this proposal are requested to provide satisfactory answers to all the questions in this section. For each question, a complete run-through of all the steps and stages, outlying the time taken, the resources required and the costs, including financial and time. Any assumptions made must also be listed.—Preceding unsigned comment added by Lkcl (talk • contribs) --Fasten (Wikinews: Aktion Deutschland Hilft asks for donations after the earthquake in Indonesia) 08:57, 12 October 2009 (UTC)

I'm sorry but I do refuse to answer your questions because they don't make enough sense. Pages aren't written in Java and there is no need that everybody can edit Java applets. The problem is the opposite: There must be a guarantee that appropriate quality is maintained by refusing unqualified people to edit Java applets (the same applies to the MediaWiki software as you will probably agree). An obvious solution is a project team of volunteers who are responsible for maintaining quality and a set of policies that regulate the work of the team. The policies should probably require the applets to be under acceptable open source licenses. People with very slow links don't load images and consequently wouldn't load applets either. The text alone should be sufficient as the content of an article, of course. You haven't responded to #JavaFX and Jigsaw, by the way. You probably should read more and give more consideration to your postings. --Fasten (Wikinews: Aktion Deutschland Hilft asks for donations after the earthquake in Indonesia) 09:08, 12 October 2009 (UTC)

Support. AudriusA 09:16, 13 October 2009 (UTC)

"Pages aren't written in Java and there is no need that everybody can edit Java applets." WRONG. absolutely DEAD wrong. this is why you keep pushing this proposal when you should have given up, a long time ago. to state that "not everybody need edit java applets" is ELITIST and is in DIRECT contravention of the wikipedia charter. Lkcl 15:08, 14 October 2009 (UTC)

"The text alone should be sufficient as the content of an article, of course." ASSUMPTION. the risk is too great that editors will place the majority of an article's information in the java applet, once again making access to information ELITIST, and directly contravening the wikipedia charter. Lkcl 15:08, 14 October 2009 (UTC)

No need to get excited. I'm not really pushing the proposal. Actually I'm quite indifferent because Java applets aren't important for Wikipedia. I'd recommend that you should get a mentor because your behavior seems somewhat exaggerated to me.

If you are worried that the majority of an article's content may end up in a Java applet you could demand a policy for the "Java Applet Approval Team" that this has to be prevented. I don't even know how you imagine that to be sensibly possible. Theoretically you could put the text into an applet but language localization would probably put it into a text resource outside the actual applet code again. So what is really your problem? --Fasten (Wikinews: Aktion Deutschland Hilft asks for donations after the earthquake in Indonesia) 10:00, 16 October 2009 (UTC)

when a java applet is submitted, how is it to be guaranteed that anyone can edit the java applet?

Source code must be available. Who does not want to learn Java, can treat applet as an image (these are seldom edited by community). From the other side, applet is unlikely provide POV - releated issues (if it does, really must be treated as an image and removed if community goes on consensus on that) AudriusA 06:37, 12 October 2009 (UTC)

"Source code must be available". think it through, providing absolutely clear unambiguous unequivocable instructions, Audri - what's the next step? how and where should this source code then be compiled to a java applet? who or what does the compiling? what is the cost of doing that compiling? Lkcl 15:08, 14 October 2009 (UTC)

During heavy development process applet should be compiled on the developer machine, Wikipedia only needs to compile it once it is finally uploaded. A typical non trivial applet may contain 5000 - 7000 lines of code of about that may take seconds or tens of seconds to compile. To avoid server overload, I suggest to introduce applet compilation queue. A single core of any desktop machine should be enough to compile all stream of new applets I expect to get. AudriusA 07:40, 17 October 2009 (UTC)

Development of the applets should be an open source community process of some kind. Anybody with the necessary technical skills should be able to contribute. In order to ensure quality of the output, some restrictions will need to be imposed (ensuring that contributors do have the skills, and use them wisely). Note that this is not unlike to the - very complex - MediaWiki templates that are currently in use on Wikipedia. In principle, everybody could edit these. In practice, they are maintained by a relatively small group of trusted users that are experienced in the template script language; in parts this is enforced, namely, by means of page protection. More illustratively: while anybody can edit Wikipedia, not everybody should (and can) edit w:Template:Ambox. --B. Wolterding 21:30, 13 October 2009 (UTC)

"In practice, they are maintained by a relatively small group of trusted users that are experienced in the template script language". PRECISELY.. that is EXACTLY why all proposals that recommend that programming languages be allowed as part of the expression of wikipedia pages should be thrown out, without a moment's hesitation. Lkcl 15:08, 14 October 2009 (UTC)

I'm expecting you to provide a full set of steps, along with a cost analysis for each. Please fill in these steps:

1. User sees java applet
2. User clicks on java applet
3. User receives source code of java applet
4. ...
5. ...
6. User uploads modified source code of java applet
7. ...
8. (java applet source code is vetted? by whom? who pays for that?)
9. (java applet is compiled by farm of wikipedia servers, at extortionate cost to the wikimedia foundation?)
10. ...
11. User's modified java applet goes live, on wikipedia

I leave this as an exercise to you. Let me just point out again that "programming" for Wikipedia is already happening today: There are users who make complex templates. user who code bots, users who contribute to the MediaWiki code or to its extensions (think of the timeline extension!). My impression is that this work is typically seen as very helpful to the project, not as a danger, or something to be "thrown out". --B. Wolterding 22:33, 14 October 2009 (UTC)

how is an ordinary "end user" supposed to contribute to a page that's written in java?

See above. AudriusA 06:39, 12 October 2009 (UTC)

As others have said: Pages are not written in Java. They would still be written in MediaWiki markup. Applets would be embedded into them like a graphics, a navigation box, a video, a timeline, etc. Developing the applets would need programming skills, embedding them would not. --B. Wolterding 21:33, 13 October 2009 (UTC)

ok. the question still has not been fully answered / you still have not understood. how is the APPLET supposed to be contributed to, by an ordinary "end user"? how should the END USER make changes to THE APPLET? in other words, in addition to the above steps, there are additional steps "End User learns java". please answer the question and fill out the necessary steps. Lkcl 14:28, 14 October 2009 (UTC)

An applet is, basically, a piece of programming code. In order to contribute to it, a user needs to understand the programming language, which is the case for only a few. Users without programming skills can use the applets (which were made by others) and embed them into pages. Example: For making an applet that displays 3d models of molecules, it needs a programmer. However, for configuring the finished applet so that it display a 3d model of Ethanol, it needs a user who is proficient in chemistry (but not in programming languages). In short, not every Wikipedia editor would be expected to learn Java, nor to study chemistry. --B. Wolterding 21:49, 14 October 2009 (UTC)

The same question can be said about images. How can someone edit THE IMAGE (paraphrasing Lkcl)? Well, he will need to find a graphics program (that cannot be downloaded to cellular phones and in general are larger than the Java SDK), then learn how it works, learn graphics/photo enhancement techniques, etc. In a few words we can find that images are elitist (again paraphrasing Lkcl) and should be erased as well. Best regards, Alpertron 12:25, 22 October 2009 (UTC)

how should someone in a third world country, with access to 56k dialup or less, contribute to a page that's written in java?

With such a connection, it is difficult to upload and use any multimedia. The optimal pages in this case would be very different and limit the majority of usual users with normal Internet access. I would say, in such cases just turn all images and applets also off - it is illustrative material only, after all. AudriusA 06:46, 12 October 2009 (UTC)

It may seem surprising, but applets are not necessarily large, since most libraries are actually distributed with the JDK. A reasonable applet need not be larger than a typical graphics, and would certainly be much smaller than e.g. a video clip. And when the first applets came up (15 years ago?), 56k dialup lines were quite common. That said, if resources are really limited, viewing the article text only is always an option. --B. Wolterding 21:44, 13 October 2009 (UTC)

this is not a full and complete answer. i am expecting a complete break-down of all steps, along with costs, time and materials, starting:

1. "the third world user downloads java development environment" over a 56k dialup connection.

   No problem, I did that about 10 years ago with a 33k modem.

2. the third world user downloads information on how to program java

   No problem because that are tons of Web sites about programming Java in a lot of languages. There are also libraries which have books on Java in their own language.

3. the third world user learns english in order to understand the instructions on how to program java

   Read above

4. ...
5. ...
6. the third world user finally contributes a modified java applet

   The third-world users have no mental problems as you are trying to suggest. The cost is only a small fraction of the value of the personal computer they are using. Best regards, Alpertron 12:10, 22 October 2009 (UTC)

I actually think that opportunity to use a real programming language seriously is the best we can give for the third world. I prefer first to help people who have nothing to do with they knowledge after they learn. I see them capable to google online Java tutorial, understand it and build an applet with command line tools without paying a price of XO-1's for all village for the corresponding course that I see available across the street. I never needed such courses myself, why should they do? AudriusA 06:44, 23 October 2009 (UTC)

this is the level of detail i am expecting. please fill in the gaps, along with a complete break-down and analysis of the costs of each step. Lkcl 14:33, 14 October 2009 (UTC)

how should someone in a third world country, with a device with limited input and resources, contribute to a page that's written in java?

For the purposes of answering this question, consider "a device with limited input and resources" to be the following (but not restricted to the following). Answers are required for each type of device:

• A WAP-enabled GSM/GPRS mobile phone, with no touch-screen, only a number-pad, and the usual T8 predictive dictionary.
• An e-Book (possibly with a USB keyboard plugged in). e-Books such as those from http://txtr.com or | Irex are typically 500mhz ARM-based, have 2.5G or 3G, 64mb or 128mb of RAM, and no touchscreen. Only the txtr device has an "open source" policy, so it cannot be assumed that the device can have any software installed on it.
• A restricted e-Book such as the Kindle, where Wikipedia Internet Access is "allowed", but access to the internals of the device are considered "proprietary", and so it cannot be assumed that the device can have any third party software installed on it.
• An OLPC XO-1 in a remote location with access to a single landline, offering a maximum of 28kbaud shared dialup for the entire village.
• A 15-year-old "donated" PC (800x600 VGA screen; AT Keyboard; 500mhz Pentium II or 800mhz Pentium III; 64mb of RAM; maximum of a 350mb Hard Drive)
• A wikireader device - http://www.thewikireader.com/ - recently created by the OpenMoko team.

See my answers above. AudriusA 06:48, 12 October 2009 (UTC)

I wrote my first applet on a Pentium "I" machine with 32 MByte of RAM. Things were a bit slow though. Also, it might be worth noting that JVMs ("Java ME") are rather frequently found on mobile phones. These differ significantly from the "standard" Java though, and serving mobile phones would require additional development effort, just because the user interface is physically very different (small screen, no keyboard etc.). It might be worthwhile to fall back to a text-only version for mobile devices. This would however apply to any visualization technique. --B. Wolterding 21:58, 13 October 2009 (UTC)

WAP phone answer

Phones also have many other limitations, most important small screen size, lack of the proper keyboard and expensive network connection. I think mobile devices should not put constraints on Wikipedia content discriminating desktop machines; if they are really important than it must be a separate project. AudriusA 06:39, 12 October 2009 (UTC)

ok. so now you understand that such devices, the use of which could easily become a prominent and low-cost method for accessing and contributing to wikipedia in countries where computer resources are scarce, would be completely impractical for editing of, and learning about, anything that's written in java, yes? thus, the risk is that a large proportion of the world's population would be cut off from contributing or potentially even cut off from _viewing_ knowledge that was written exclusively in java. this is a risk that is too great to take. Lkcl 15:08, 14 October 2009 (UTC)

Excuse me, this is becoming slightly silly. Such devices, due to their limited screen size, also do not allow for reasonable viewing (let alone editing!) of high-resolution graphics. Should Wikipedia therefore abandon all graphics? --B. Wolterding 21:56, 14 October 2009 (UTC)

e-Book with limited resources "open source" policy answer

This E-Book looks like built for Java applets, they will flourish there (plugging in USB mouse would be great). GNU Classpath stack runs with ARM processor and IceTea I think can be ported. Some development theoretically may be possible but this is just not a right device to contribute to Wikipedia in any way: it is just designed to be a highly efficient, portable reader instead AudriusA 06:49, 12 October 2009 (UTC)

precisely. whilst it could be just about practical to use the "touch slider" to do keyboard entry, in a similar way to phone T8 predictive text (see Nokia designer phone, which had a jog-wheel and no number-pad) the deployment of low-cost long-battery-life e-Paper devices in third world would be absolutely ideal for viewing wikimedia text, just about ok for images and completely useless for colour video and fast-moving colour java applets. not to mention completely useless for doing complex programming such as java. thus, should these devices become the popular method for third world and emerging countries to interact with wikipedia, any pages written in java would be impossible for end users to contribute to. the risk of this happening is too great, and it is better that java (or any other programming language) not be even considered as an option, in order that this risk be mitigated. Lkcl 15:08, 14 October 2009 (UTC)

also note: whilst the exact specs are not known (but the price is: $99), the recently announced "wikireader" device pretty much falls into the category described above. as it is the first device of its kind, i expect other similar knock-off devices to follow, and the prices to plummet as a result to $25 within 12 months. Lkcl 15:08, 14 October 2009 (UTC)

proprietary e-Book answer

Any software will appear very quickly on such machines as soon as customers will start asking for it. If not, they will just go bankrupt and will not be a problem anyway AudriusA 06:49, 12 October 2009 (UTC)

OLPC XO-1 answer

With 256 Mb of RAM, this "one laptop per child' should be able to run Java applets without any problems, including Java development tools like text editor and compiler. Unlike J2EE, applets do not necessarily need NetBeans or Eclipe and many early official tutorials were assuming only editor and a couple of command line tools. 16 Mb or about [3] is enough to run applets in a browser. I would use plain text only with such a connection. AudriusA 06:51, 12 October 2009 (UTC)

please complete the answer by outlining the full set of steps by which an OLPC user (possibly with very little english language skills) would, over a village-shared 28k unreliable dialup connection, download the necessary development software, learn and/or be taught how to use it, and then go through the contribution process, resulting ultimately in the java applet being updated. please outline all costs and the resources required. Lkcl 15:08, 14 October 2009 (UTC)

With very little English skills, how he can read Wikipedia first of all? AudriusA 12:58, 16 October 2009 (UTC)

Um. Wikipedia exists in over 200 languages. More than a couple are comparable in size with the english version. You can read more about (the lack of) Java on the OLPC here. Mostly the problem is disk space for the java runtime. OLPC is very very storage constrained. --Gmaxwell 07:40, 2 November 2009 (UTC)

Read yourself! I read [4]. Be I administrator would block you for such a methods in discussion. AudriusA 13:23, 2 November 2009 (UTC)

I have no idea what you are complaining about here. Can you please elaborate? --Gmaxwell 13:58, 11 November 2009 (UTC)

15-year-old PC answer

I used such computers to develop my first applets without any issues. AudriusA 06:52, 12 October 2009 (UTC)

_you_ did. what about third world users? please complete the answer by describing all steps by which a third world user, with no prior knowledge of java and very little command of the english language, must go through, in order to ultimately contribute to the java applet on wikipedia servers. Lkcl 15:08, 14 October 2009 (UTC)

I guess the third world users are just as me, only have no recent hardware. If I did, how it can be they cannot? There are tutorials on a web how to develop applets, also with command line tools that even may not be needed here. AudriusA

A Wikireader device

I even cannot figure out how much memory does it have and on which processor does it run. However adding Java runtime to some content renderer seems even easier than to implement in a browser and it general I think such devices would highly benefit from running Java applets inside as long as mouse or touchscreen interface is possible. If it is very resource constrained, some applets with higher memory demand and of course applets need the host site to work may need to be dropped during the initial selection process. AudriusA 12:52, 16 October 2009 (UTC)

Cart before the horse

Much of this comes across me like techno-fetishism. To be ruthlessly unfair to the other side:

Lets support Java applets!— Um. Why? — It can do neat stuff!—Doesn't adoption Java present serious problems for security, participation, accessibility, compatibility, etc? — There are solutions to the pitfalls of supporting applet submission, we'll simply bounce a graviton particle beam off the main deflector dish…

What I think are interesting are proposals to add features that add useful capabilities for education, and thats not what Java is (except in the niche area of educating about Java)… Java is just a programming language and virtual machine environment. Can Java be used to create educational tools? Absolutely, but for any example tool you could suggest there is certainly a way to accomplish it without Java some of which may be much better.

I think an example of the proposals we should instead have is ".PDB viewer available on Wikipedia pages" (pdb = molecular diagrams of proteins). A proposal like this could outline a strategy which uses a Java applet perhaps in isolation or in combination with other technology. Many of the concerns about Java go away when it is used for a focused purpose and as part of a broader solution. For example, in this .PDB example the same rendering functionality could be provided by server-side rendering + ajax; client side rendering with Javascript+canvas, client side rendering with Java, and the availability of simple static images... With the best method automatically selected based on the client's capabilities and preferences.

Unfortunately in a discussion about Java for the sake of Java we don't get to discuss these kinds of alternatives in a substantive way.

The Wikimedia sites use Java in one capacity today— The cortado applet is used as one of the fallback methods of multimedia playback support for users with browsers which lack HTML5 <video> and <audio> tag support. In this specific role Java makes a lot of sense: it doesn't have the security, editability, or compatibility problems mentioned above and the alternatives to using Java in this role were to either to simply not support inline playback for the large number of users which don't have another supported mechanism or to adopt some of the widely supported proprietary and patent encumbered multimedia technology.

Yet even though I started the use of cortado for video fallback on the sites I am opposed and would have been opposed to accepting Java applet submissions in the general case— for all the significant reasons raised in the sections above. Adding features for the sake of features isn't a good strategy for Wikimedia— the focus at the strategy level should be on direct educational capabilities and long term social effects and not technical tools, like Java, except as required to facilitate those capabilities and effects.
--Gmaxwell 15:30, 15 October 2009 (UTC)

I think the problem we try to solve is covered enough, also not in this one proposal but also in some others that suggest different solutions. The goal of adding advanced technologies is to improve interactivity; any learning and understanding is much easier when interactive experiments with immediate results are possible. Current Wikipedia does not support this well but there are many alternatives to achieve this goal. This proposal is about Java applets, one of many technologies available, all with they own advantages but it seems none without limitations and security issues. Of course it makes a lot of sense to submit and discuss other proposals. AudriusA 11:31, 16 October 2009 (UTC)