Java Applet

Използване на Java аплет за изчисление – визуализация на множество на Манделброт

Скоростта на аплета е достатъчна за компютърна игра на шахмат.

Джава аплет (на английски: Java applet) е малък приложен софтуер написан на Джава или друг език за програмиране който може да се компилира до специфичен за езика код, наречен байт код, подаващ команда към виртуалната машина на програмния език Java. Програмата се компилира във вид на .class файл или съвкупност от такива компилирани Java класове, записани в .jar файл.

Аплетът се изпълнява от Java виртуална машина JVM и затова браузърите, които поддържат аплети, имат вградена или допълнително инсталирана виртуална машина. Програмата като междуплатформен софтуер се вгражда като обект в уебстраница и по време на разглеждането на тази страница се изпълнява от уеб браузъра или от приставки на други клиенти. Потребителят може да влияе на програмата без да изпраща информация към сървъра.

За графичния си потребителски интерфейс аплетът може да използва правоъгълната област, която браузърът ѝ е дал; нов приложен прозорец; самостоятелен интерфейс с команден ред от Sun (на английски език: Sun's AppletViewer) или самостоятелен инструмент за тестване на аплети.

Джава аплетите притежават почти цялата мощ на Java платформата, но с известни ограничения, наложени главно от съображения за компютърна сигурност. За да се осигури безопасността на потребителя, на аплетите е позволено да извършват само операции, които не могат да осъществят достъп до потребителската информация на машината, на която се изпълняват.

Освен Джава аплет има и програма Джава сървлет, която роботи върху уеб сървър.

Преглед

Аплетът е малко приложение, което изпълнява специфична задача в рамките на друга по-голяма програма. Джава аплетите се използват за интерактивни функции на уеб приложенията, които не могат да бъдат предоставени само от HTML. Те могат например да улавят движенията на мишката, или да получават входни данни от бутони, полета или квадратчета с отметки. В отговор на действията на потребителя, аплетът може да промени своето графично изображение. Това прави аплетите много подходящи за демонстрации, визуализации и обучения. Съществуват онлайн колекции от аплети за изучаване на различни теми – от физика до сърдечна физиология.

Аплетът може да представлява и само текстов прозорец, например осигуряващ междуплатформена връзка с отдалечена система посредством интерфейс с команден ред. Ако е нужно, аплетът може да работи в отделен прозорец. Въпреки това, аплетите имат много малък контрол върху съдържанието на уеб страницата извън тяхната зона, затова не са много полезни за подобряване на външния вид на сайта, за разлика от други типове разширения на браузъра. Аплетите могат също да стартират медийни файлове във формати, които по подразбиране не се поддържат от самия браузър.

В страниците, написани на HTML, могат да се вграждат различни параметри, които се подават към аплета. Така един и същи аплет може да изглежда различно в зависимост от подадените му параметри.

Аплетите са познати още преди CSS и DHTML да бъдат стандартизирани. Били са използвани за тривиални ефекти като бутони за временна визуализация (т.н. rollover buttons). Силно критикувани, днес използването им все повече намалява.

Техническа информация

Джава аплетите се изпълняват по начин, който разделя изпълняващите се програми една от друга (т.нар. Пясъчник). Това пречи да се достъпва информация от клипборда или файловата система. Кодът на аплета се тегли от уебсървър, след което браузърът или закрепва аплета към уебстраницата, или отваря нов прозорец, показващ потребителския интерфейс.

Първите имплементации са включвали теглене на аплет клас по клас. Макар че класовете са малки файлове, често те са много, затова аплетите имат репутацията на бавнозареждащи компоненти. Но след въвеждането на .jars, аплетът обикновено е представен като един-единствен файл с размер, подобен на този на изображение.

Домейнът, от който изпълнимият файл на аплета се изтегля, е единственият, с който аплетът може да си комуникира. Този домейн може да е различен от домейна, на който е хостнат основният HTML документ.

За да може да се пише код, който може да се изпълни и на текущи и на бъдещи версии на Джава виртуалната машина, се ползват Джава системни библиотеки и рънтайм.

Подобни технологии

Много джава разработчици, блогове и списания препоръчват вместо джава аплети да бъде използвана Java Web Start технология. Тя позволява пускането на непроменен аплет код, който после се изпълнява в отделен прозорец (не се закрепва за браузъра).

Понякога Джава сървлет е неформално сравняван със server-side аплет, но той има различен език, функции и характеристики от описаните тук.

Пример

Долният пример илюстрира използването на Java аплети посредством „java.applet“ пакета. Примера използва класове и от java.awt, за да изпише „Hello, world!“.

import java.applet.Applet;
import java.awt.*;

// Applet code for the "Hello, world!" example.
// This should be saved in a file named as "HelloWorld.java".
public class HelloWorld extends Applet {

    // Print a message on the screen (x=20, y=10).
    public void paint(Graphics g) {
        g.drawString("Hello, world!", 20, 10);

        // Draws a circle on the screen (x=40, y=30).
        g.drawArc(40, 30, 20, 20, 0, 360);
    }
}

Прости аплети се споделят свободно в интернет за персонализиране на приложения, които поддържат плъгини.

След компилацията се получава .class файл, който може да бъде поставен на уеб сървър и да бъде стартиран от HTML страница чрез таговете <applet> или <object>. За пример е даден следният HTML код:

<!DOCTYPE html>
<html>
<head>
  <title>HelloWorld_example.html</title>
</head>
<body>
  <h1>A Java applet example</h1>
  <p>Here it is: <applet code="HelloWorld.class" height="40" width="200">
    This is where HelloWorld.class runs.
  </applet></p>
</body>
</html>

При отваряне на страницата ще се изпише:

A Java applet example

Here it is: Hello, world!

За да се съкрати времето за сваляне аплетите могат да бъдат доставени под формата на jar файл. В текущия пример ако всички необходими класове са поставени в компресиран архив example.jar, може да се използва следният код:

<p>Here it is: <applet archive="example.jar" code="HelloWorld" height="40" width="200">
  This is where HelloWorld.class runs.
</applet></p>

Вграждането на аплети е подробно обяснено на официалната страница на Сън относно APPLET таговете.

Предимства

Джава аплет може да притежава няколко или всички от следните предимства.

• Лесно съвместими са за работа на FreeBSD, Linux, Microsoft Windows и OS X. Аплетите се поддържат от повечето уеб браузъри.
• Един и същ аплет може да работи на всички инсталирани версии на Джава в едно и също време, отколкото само на последните плъгин версии. Ако даден аплет изисква най-новата версия на Java Runtime Environment (JRE), лиентът ще бъде принуден да чака по време на продължителното сваляне.
• Повечето уеб браузъри кешират аплети, за да може бързо да бъдат заредени, когато се връщат към уеб страница. Аплетите също така подобряват използването: след като първия аплет се стартира, JVM вече работи и стартира бързо (JVM се обновява всеки път, когато браузърът стартира отначало). Трябва да се отбележи това, че версиите 1.5 и на горе на JRE спират действието на JVM и го рестартират, когато браузърът навигира от една HTML страница, съдържаща аплет, към друга с аплет.
• Може да измести работата от сървъра към клиента, с цел уеб решение да бъде по-приспособимо с бройката на потребителите/клиентите.
• Ако самостоятелна програма (като Google Earth) коренспондира с уеб сървъра, същият сървър обикновено трябва да поддържа всички предишни версии за потребители, които не са актуализирали своя клиентски софтуер. В противен случай, правилно конфигурираният браузър зарежда (и кешира) последните аплет версии, така че да няма нужда от поддръжка на утвърдени версии.
• Аплетът обикновено поддържа промяната на потребителското състояние, като фигура позиции на шахматната дъска.
• Разработчиците могат да развиват и дебъгват директно чрез създаване на основна routine(или в клас аплета или в отделен клас) и извиква init() и start() върху аплета, като по този начин дава възможност за развитие в любимия си среда за разработка на Java SE. След това, всичко което трябва да се направи е да направи ре-тест на аплета в програмата AppletViewer или в уеб браузър, за да се гарантира, че отговаря на ограниченията за сигурност.
• Ненадежден аплет няма достъп до локалната машина, а единствено само до сървъра, от който идва. Това прави такъв аплет много по-безопасно да се изпълнява, отколкото самостоятелно изпълним такъв. Въпреки това, подписан аплет може да има пълен достъп до машината, на която се изпълнява, само ако потребителят е съгласен.
• Джава аплетите са бързи-дори може да имат подобни резултати с тези на вградения инсталиран софтуер.

Недостатъци

Джава аплетът може да притежава и някои от следните недостатъци, свързани с други уеб технологии от страна на клиента:

• Джава аплетите зависят от Java Runtime Environment (JRE), който е тежък и сложен софтуерен пакет. Обикновено също така изисква плъгин за уеб браузъра. Някои организации позволяват инсталирането на софтуер само от администратор. Като резултат от това някои потребители могат да виждат аплети, които са достъчно важни, за които е необходимо свързване с администратора, за да поиска инсталиране на JRE и приложението.
• Ако аплет изисква по-нова JRE от тази, която е достъпна на системата или специфична JRE, при стартирането му потребителят трябва да изчака дългото JRE сваляне да завърши.
• Някои браузъри, като мобилните браузъри на Apple iOS или Android, не поддържат Java аплети изобщо.
• За разлика от стария applet таг, object тагът се нуждае от допълнителна работа за написване на HTML документ за различните браузъри.
• Няма стандарти, по които да се правят аплетите позволени за екранни четци. Ето защо, аплетите могат да навредят на достъпността на уеб сайт от потребители със специални нужди.
• Ако се инсталира JDK (Java Development Kit) няма нужда от плугин за браузъра.

Съдебни дела, свързани със съвместимост

Сън Майкросистъмс е положила значими усилия, за да осигури обратна съвместимост между различните версии на Java, докато те се развиват. Oracle прилагат същата стратегия.

1997 „Сън Майкросистъмс“ срещу „Майкрософт“

Делото през 1997 е било образувано след като Майкрософт създават своя модифицирана версия на виртуалната машина на Java. Те добавят около 50 метода и 50 полета към класовете в пакетите „java.awt“, „java.lang“ и „java.io“. Други модификации включват премахването на Java RMI, както и превключването от JNI към RNI. RMI е бил премахнат, защото поддържа лесна комуникация единствено от Java към Java и се конкурира с технологията на Майкрософт MS DCOM. Аплетите, които разчитат на тези технологии, започват да работят само на майкрософтската Java система. Сън съдят за нарушаване на търговската марка, тъй като целта на Java е да няма патентовани разширения и кода да работи на всякакви платформи. Майкрософт се съгласяват да платят на Сън 20 милиона долара, а от своя страна Сън се съгласяват да дадат на Майкрософт ограничен лиценз за използване на Java без модификации.

2002 „Сън Майкросистъмс“ срещу „Майкрософт“

Майкрософт продължават да използват своя немодифицирана Java виртуална машина, като през годините тя става все по морално остаряла и въпреки това остава зададена „по подразбиране“ за Internet Explorer. По-късно проучване показва, че аплетите от това време използват свои собствени класове, които копират Swing и други по-нови функционалности. През 2002, Сън подава ново дело, твърдейки че опитите на Майкрософт за нелегална монополизация са навредили на Java платформата. Сън настояват Майкрософт да разпространява текуща бинарна имплементация на Java технологията на Сън като част от Windows, както и като препоръчително софтуерно обновление за по-стари Майкрософтски операционни системи. Също така настояват да се спре разпространението на виртуалната машина на Майкрософт поради изтекъл лиценз (за чийто срок се споразумяват на предишното дело през 1997). В крайна сметка Майкрософт плащат 700 милиона долара неустойки, 900 милиона за нарушени патенти и 350 милиона долара на Сън за правото да използват техния софтуер в бъдеще.

2010 „Оракъл“ (Oracle Corporation) срещу „Гугъл“

Гугъл създават своя собствена платформа – Андроид, която използва Java функционалности и концепции, без да е съвместима със стандатни библиотеки. Това може да е нарушение на условията, според които Сън дава OpenJDK патенти, с които всички могат да създават Java проекти с „отворен код“. През 2010 Оракъл съдят Гугъл за използване на Java „погрешено“, твърдейки че „Андроид на Гугъл се конкурира с Java на Оракъл“ и че „Гугъл са били наясно с патентното портфолио, тъй като са наели определени бивши Java инженери от Сън“. През май 2012 журито решава, че Гугъл не нарушава патенти на Оракъл, както и че технологиите използвани от Гугъл не подлежат на авторски права.

Сигурност

Моделът за сигурност на Джава аплет е създаден с цел защита на потребителя от злонамерени аплети . От създаването му до момента са откривани и поправяни много проблеми по сигурността.

Аплетите биват SANDBOX (пясъчник) или PRIVILEGED (поверителни). Поверителните аплети могат да работят извън пясъчника и имат достъп до клиента.

Относно тяхната сигурност могат да се разделят на неподписани, подписани и самоподписани.

Неподписани

Аплети, които не са подписани, се изпълняват на безопасен пясъчник, който им позволява ограничени операции и работят след приемане от страна на потребителя. Те имат достъп само до сайта, откъдето са качени, ограничени са откъм достъп до локалната файлова система.

Въпреки че се рамкират самостоятелно, те носят информация, че са ненадеждни аплети. Сигурността осигурява цялостна проверка на инициализирания стек, за да се увери, че не идва от неподходящо място.

Непотвърдените аплети могат да бъдат много опасни, ако работят директно в сървъра, защото те могат да изпращат кодове към сървъра, но докато работят в него, те могат да заобиколят защитата. Някои аплети могат да пробват атака за отказ на услуга към сървъра, където работят, но в повечето случаи хората, поддържащи страницата, поддържат и аплета и това става нелогично.

Непотвърдените аплети могат да опитат да свалят злонамерен софтуер хостван на началния сървър. Той може да съхранява информация само във временни папки (тъй като данните са временни) и няма способността да завърши атаката, след като я изпълни.

Подписани

Това са аплети, потвърдени със сертификат от разпознаваем източник, и те могат или да работят в пясъчника, или извън него. Във всеки един от случаите потребителят трябва да приеме сертификата за сигурност на аплета. В противен случай аплетът блокира работата си.

Потвърдените аплети притежават математична схема (подпис), доказваща автентичността на цифровото съобщение. Този подпис предизвиква различни способи за взаимодействие с поддръжката и сигурността на сървъра. След като бъде проверен, потребителят също трябва да приеме аплета, тогава той придобива повече права и става равностоен на самостоятелна програма.

Този подход позволява на подписаните аплети да изпълняват много задачи, които не биха били възможни за клиент ползващ скриптов език. Този подход възлага повече отговорност върху потребителя относно дали да им се довери.

Самоподписани

Самоподписващите аплети, които са аплети доказали идентичността си от самия разработчик, могат да бъдат потенциална заплаха за сигурността. Джава приставките представят предупредителен сигнал при изискването на одобрение за самоподписващ аплет, тъй като функционалността и сигурността му са гарантирани от разработчика му и не се потвърждават с проверка.

Такива самоподписани сертификати се използват най-често по време на разработването преди пускането, когато допълнително потвърждаване на сигурността е маловажно, но повече разработчици ще търсят допълнително потвърждаване на сигурността, за да се гарантира, че потребителя се доверява на безопасността на аплета.

От 2014 насам самоподписващите и не подписаните аплети не се признават от разпространените Джава приставки или DjavaWS, следователно разработчиците нямат друг избор, освен да изискат одобрен сертификат от търговски източници.