Java Applet

Използване на Java аплет за изчисление - визуализация на Mandelbrot set

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

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

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

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

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

Преглед

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

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

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

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

Пример

Долният пример илюстрира използването на 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 таговете.

Преглед

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

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

Недостатъци

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

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

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

Сън Майкросистъмс е положила значими усилия за да осигури обратна съвместимост между различните версии на 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(поверителни). Поверителните аплети могат да работят извън пясъчника и имат достъп до клиента.

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

Неподписани

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

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

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

Подписани

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

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

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

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

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

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

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