`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Слухи о смерти апплетов сильно преувеличены

Статья опубликована в №39 (607) от 16 октября

0 
 

Около десяти лет назад, когда язык Java только начинал завоевывать место под солнцем и многими воспринимался лишь как модная новинка, основным его применением было создание апплетов. Именно благодаря им Java сперва приобрел репутацию «сетевого» языка, и лишь потом, с появлением сервлетов, JSP и средств J2EE, стало ясно, что его сфера гораздо шире. Он давно зарекомендовал себя как язык общего назначения и используется для самых разных целей, в том числе для создания корпоративных приложений. Апплеты же постепенно отошли на второй план.

С появлением технологии AJAX многие специалисты пришли к выводу, что дни апплетов сочтены, ведь интерактивность Веб-страниц уже обеспечивается более современными способами. По их мнению, о надоевших апплетах можно попросту забыть. Однако прежде чем отказаться от устаревшей технологии, неплохо бы сравнить ее с альтернативой, в качестве каковой Веб-разработчикам предлагают давно знакомый язык JavaScript, дополненный CSS и средствами для работы с XML-документами (напомним, что Ajax расшифровывается как Asynchronous JavaScript with XML).

Апплеты и асинхронное взаимодействие

Читая публикации, посвященные AJAX, невольно можно подумать, что объект XMLHttpRequest – единственное средство асинхронного взаимодействия клиента с сервером. Конечно, авторы упоминают и элемент <iframe>, но при подробном анализе становится ясно, что он существенно уступает XMLHttpRequest. Ведутся также споры о том, что лучше – AJAX или JSF, но практически никто не обращает внимания на еще один способ асинхронного обмена – с помощью сетевых средств Java, доступных в апплете.

Действительно, каждый опытный программист без труда напишет на языке Java код, позволяющий обратиться к серверу и получить документ, не прекращая работы с текущей страницей. Например, он может выглядеть, как в листинге 1.

Нетрудно заметить, что вспомогательный код (оформление класса, организация потока и обработка ошибок) занимает гораздо больше места, чем собственно обращение к серверу. Конечно, можно было бы обойтись и без формирования дополнительного потока, но, согласитесь, если апплет будет преимущественно находиться «внутри» метода read(), это слишком расточительно. Гораздо лучше параллельно с ожиданием очередного символа выполнять другие задачи.

Таким образом, асинхронное взаимодействие без использования класса XMLHttpRequest и элемента <iframe> вполне реально, но...

Листинг 1.
class AsyncrCall extends Thread
{
String address;
public AsyncrCall(String addr)
{
address = addr;
}
 
public void run()
{
try {
URL url = new URL(address);
HttpURLConnection request = (HttpURLConnection)url.openConnection();
InputStream reply = request.getInputStream();
 
int c;
while((c=reply.read()) >= 0)
{
// Выполняем необходимые действия с байтом,
// прочитанным из входного потока
}
 
}
catch(Exception e)
{
// Обрабатываем сразу все исключения
}
}
}
 
...
 
AsyncrCall callServer = new AsyncrCall(«http://myserver.com/
data.html»);
callServer.start();
...

Возможно – не значит целесообразно

Предвижу ряд возражений от сторонников JavaScript и, в частности, классических AJAX-решений. Главное: получив ответ от сервера с помощью объекта XMLHttpRequest, JavaScript-сценарий может включать принятые данные в состав текущей страницы. А как с этой же задачей справится апплет?

Еще в браузере Netscape 3.0 (согласитесь, по меркам Интернета это если и не каменный век, то как минимум глубокое средневековье) была реализована технология LiveConnect, которую почему-то незаслуженно забыли нынешние разработчики. Она позволяет обращаться из Java-апплетов к JavaScript-коду и наоборот, вызывать методы апплетов из JavaScript-сценариев. Доступ к функциям и переменным JavaScript обеспечивает объект JSObject из пакета netscape.javascript (в JDK 1.6 он находится в архиве plugin.jar; в предыдущих версиях – в jaws.jar. Кроме того, архив, содержащий пакет netscape.javascript, входит в поставку старых версий браузера Netscape). Так, если в рассмотренном выше примере мы хотим вызвать из апплета JavaScript-функцию insertFragment(), включающую принятый с сервера код в нужную позицию документа, мы можем сделать это, внеся незначительные изменения в метод run() класса AsyncrCall (листинг 2).

Листинг 2.
...
int c;
String replyData = new String();
while((c=reply.read()) >= 0)
{
byte mas[] = { (byte)c };
replyData.concat(new String(mas)));
}
Object args[] = { replyData };
JSObject win = JSObject.getWindow(this);
win.call(«insertFragment», args);
...

Данные и их обработка

В числе достоинств AJAX часто называют простоту обработки данных, полученных с сервера в ответ на асинхронный запрос. В JavaScript предусмотрена достаточно мощная поддержка DOM, позволяющая выполнять разбор принятой информации, анализировать структуру текущего документа и включать нужные фрагменты в требуемую позицию. С этим трудно не согласиться, если... подразумевать данные в формате XML. Если же ответ сервера имеет вид обычной строки символов, то JavaScript мгновенно теряет свои преимущества – по возможностям анализа строк он существенно уступает Java. А в случае двоичных данных «классические» средства AJAX совсем не подходят. Как известно, объект XMLHttpRequest возвращает информацию от сервера посредством двух свойств: responseText и responseXML. Последнее для работы с неструктурированными данными попросту непригодно, а с двоичными и подавно. Свойство же responseText, согласно документации, содержит ответ в виде строки текста, и кто поручится, что при передаче между различными платформами ее формат не будет откорректирован (что нередко приводит к полному искажению информации)?

Но даже при использовании XML-данных апплеты не уступят JavaScript-сценариям. Ведь поддержка DOM имеется в Java, и куда более мощная, чем в JavaScript. А если по каким-то причинам строить дерево, представляющее документ, нежелательно, то в распоряжении разработчика есть также средства SAX (Simple API for XML), которые позволяют анализировать XML-данные непосредственно из потока.

Предпоследняя ошибка

Если задача, решаемая клиентской частью Веб-приложения, нетривиальна, неминуемо возникает вопрос об отладке. А здесь JavaScript выглядит и вовсе неприглядно. Конечно, существуют дополнительные модули к некоторым браузерам, частично реализующие функции отладки JavaScript-кода, но они не идут ни в какое сравнение с полнофункциональными отладчиками. Что же касается Java, то перед программистами, использующими данный язык, открывается богатейший выбор. Как правило, они работают с отладчиком, интегрированным в применяемую среду. Для тех же, кто ограничивает свой арсенал пакетом JDK, доступен jdb. Разумеется, его интерфейс большинство специалистов вряд ли сочтут удобным, но в остальном это вполне профессиональный инструмент. Таким образом, ошибка в программе, которая, как известно, всегда бывает предпоследней, гораздо быстрее будет выявлена в случае применения Java.

Конкуренция или сотрудничество?

Хотя возможности Java достаточно широки, нельзя не признать, что часто окно апплета совершенно неуместно в составе Веб-страницы. Например, управляющие элементы, находящиеся в нем, оказываются сгруппированы в одной области. А если их надо «разбросать» по всему документу, «перемешав» с текстом?

Однако наличие в составе страницы апплета вовсе не означает, что интерактивное взаимодействие должно осуществляться именно через него. Как уже отмечалось, можно организовать двустороннее общение между JavaScript-сценарием и Java-апплетом, причем для этого не потребуются какие-либо дополнительные языковые конструкции. Посредством ссылки на апплет можно обратиться к любому из его общедоступных методов (листинг 3).

В данном случае метод func лишь вычисляет сумму двух целых чисел и возвращает результат. Но очевидно, что, получив управление, апплет в состоянии решать любые задачи: обеспечивать обмен по сети с сервером с использованием протоколов, отличных от HTTP, архивировать данные, преобразовывать строки с помощью регулярных выражений, выполнять шифрование, воспроизводить аудиоинформацию – перечень можно продолжать очень долго. Чтобы оценить вероятные применения апплетов, достаточно просмотреть список пакетов, доступных в JDK. Пожалуй, единственный инструмент Java, не пригодный в этой ситуации, – средства организации распределенных вычислений. Увы, правило, разрешающее апплету устанавливать сетевое соединение только с тем сервером, с которого он сам был скопирован, обойти не удастся. Но подобное же ограничение действует и для XMLHttpRequest, так что и здесь Java не проигрывает JavaScript.

Код, приведенный в листинге 3, имеет одну интересную особенность: в дескрипторе <applet> атрибуты width и height имеют нулевые значения, вследствие чего апплет на экране не отображается. Такой подход целесообразен в тех случаях, когда окно аплета «не вписывается» в дизайн Веб-страницы.

Листинг 3.
import java.applet.*;
 
public class DopApp extends Applet
{
public int func(int a, int b)
{ return a+b; }
}
 
<html>
<body>
<applet code=»DopApp.class» width=0 height=0 ></applet>
<form>
<input type=»text» name=»result» />
<input type=»button» value = «Calculate»
onClick=' document.forms[0].result.value = document.applets[0].
func(10, 5); ‘ />
</form>
</body>
</html>

Когда вычисления перестают быть тривиальными

Принимая решение о передаче части функций от JavaScript-сценария апплету, нельзя не учитывать объем кода и его быстродействие. С первым показателем в принципе все ясно. Поскольку исходный текст Java преобразуется в байтовый код, очевидно, что апплет окажется гораздо компактнее JavaScript-сценария, решающего ту же задачу. Следовательно, апплет занимает меньше памяти и при копировании создает меньшую нагрузку на сеть. Исключением могут быть разве что чрезвычайно малые программы, размер которых сопоставим с размером дескриптора <applet>, но для них объем занимаемой памяти никогда не будет проблемой. С производительностью сомнений тоже не возникает, поскольку байтовый код должен обрабатываться быстрее, чем текст JavaScript-сценария.

Тем не менее подкрепим эти умозрительные рассуждения конкретным примером. Для сравнения реализуем алгоритм «решето Эратосфена» нахождения простых чисел в виде апплета и JavaScript-сценария (хотя программы элементарны, все же их исходный код великоват для журнальной статьи, поэтому он будет размещен на ko.itc.ua). Результаты для интервала от 2 до 15 000 вполне оправдывают наши ожидания: JavaScript-сценарий выполняется в Internet Explorer 6 около 3 с, в Mozilla Firefox 2–7 с, а апплет в обоих браузерах завершает работу менее чем за 1 с. Конечно, эти оценки весьма приблизительны, но добиться большей точности на самом деле не так-то просто. Если мы попробуем увеличить верхнюю границу хотя бы до 30 000, эффект окажется совершенно неожиданным (понятно, лишь для тех, кто не имеет достаточного опыта Веб-программирования): получается, что браузеру «не нравится» сценарий, выполняющийся, по его мнению, слишком долго, и он выдает окно с соответствующим предупреждением, что, кстати, вряд ли уместно в профессиональном приложении. Таким образом, еще раз подчеркивается, что JavaScript – язык, предназначенный для создания очень простых программ и не ориентированный на более или менее серьезные вычисления.

Технология и мода

Что же из следует из вышесказанного? Может быть, надо вернуться к практике повсеместного использования апплетов? Или вовсе отказаться от JavaScript, CSS и реализовывать приложения, предполагающие асинхронное взаимодействие по сети, только средствами Java? Это, конечно, будет еще одной крайностью, а их следует всячески избегать. Однако некоторые программисты, чаще всего неопытные, услышав «модное» слово AJAX, напрочь забывают о других возможностях или даже делают вид, будто их вовсе не существует. И поступают очень неразумно. Не стоит бездумно преклоняться перед авторитетами, ведь мы сами формируем то самое «общественное мнение», к которому так любят прислушиваться не только пользователи, но и начинающие разработчики. Поэтому всегда стоит тщательно проанализировать все имеющиеся технологи и выбрать среди них наиболее подходящую для конкретной задачи. А тогда уже можно аргументированно поспорить и с «законодателями мод» в Веб-программировании.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

0 
 

Напечатать Отправить другу

Читайте также

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT