Java 32 бит майнкрафт виндовс 8.1. Организация системы безопасности Java и обновления
Вслед за стремительным развитием информации ВТБ, как и многие другие банки, стал внедрять функцию под названием «дистанционное банковское обслуживание». С этой целью специалистами ВТБ был создан специальный апплет – программа, через которую клиенты и получают доступ к своим счетам. Чаще всего, как и в этом случае, для этих целей используют язык программирования Java (произносится «джава» или «ява»). Чтобы начать пользоваться программой от ВТБ, необходимо скачать программу, установить и настроить ее.
Для чего нужен Java-апплет?Такой апплет работает, основываясь на трех китах. Их имена: Надежность, Производительность и Безопасность. Так что не удивительно, что апплеты на этой платформе используют не только финансовые организации вроде ВТБ, но и бухгалтерские отделы, научные предприятия, а также производители технической продукции для бытовых и коммерческих потребностей. Возможности платформы многогранны:
- простой способ сформировать и настроить сетевое приложение;
- доступность работы с базами данных;
- детальная проработка уникальных сценариев развития событий;
- возможность выбирать параметры фильтра на вводе и выводе;
- доступ к интернет-службам;
- автоматическое управление памятью;
- полноценная работа с форумами, онлайн-магазинами, опросниками, играми и приложениями в сети;
- одновременно выполняется несколько программ на любом из указанных языков;
- поддержка многопоточных приложений;
- возможные сообщения и ошибки, если он не загружен;
- различные классы для выполнения HTTP-запросов и обработки ответов.
Описанные преимущества делают платформу Java идеальной для ВТБ апплета.
Возможные ошибкиНиже собраны самые распространенные ошибки, с которыми сталкиваются клиенты ВТБ после установки апплета, и способы их устранения.
Апплет не запускается после обновления до Java 7 Update 65Эта проблема чаще всего касается обладателей Windows 7, 8 и 10, с версиями Java 7.0 или 8.0. Суть проблемы сводится к тому, что апплет ВТБ перестал запускаться. Причина кроется в отсутствии строки deployment.javaws.jre.0.args= в документе с именем deployment.properties. Разработчики устранили неполадки в Java 7 Update 67 (7u67), поэтому для большинства, решение проблемы – установка последней версии ПО. Загрузить программу можно по ссылке: https://www.java.com/ru/download/ . Главная страница выглядит так: 
В случае, когда обновление невозможно, существуют другие варианты. Конечным пользователям версии 7u65 стоит немного изменить параметры Java Control Panel. Сделать это можно следующим образом:
Следуя этому руководству любой может настроить свой апплет ВТБ довольно быстро.
Временно решить проблему можно, внеся поправки в код:
Так вы заставите апплет ВТБ работать и проблема с обновлением будет решена.
Апплет ВТБ не загруженВажная предыстория: из множества технологий, которыми пользовались компании, некоторые безнадежно устарели и уже не в состоянии выполнять свои функции как положено. Однако хозяевам больших предприятий очень жаль потраченных десятков/сотен тысяч долларов на разработку корпоративных приложений на основе упомянутых технологий. В связи с этим, некоторые клиенты, заходя в сервис, могут видеть ошибку с вышеуказанным названием.
Это касается и некоторых клиентов ВТБ: при попытке зайти в систему удаленного управления счетами отображается описанная ошибка апплета. Причиной может быть отсутствие апплета или его нерабочее состояние. Однако с этим легко справиться, достаточно последовать простым указаниям ниже.
Легче всего для начала установить апплет ВТБ с официального сайта Java. Сделать это стоит даже тогда, когда программное обеспечение у вас уже есть, но не включено: будет лучше, если на вашем компьютере будет установлена самая актуальная версия программы. Итак, следуйте указаниям:
Важная информация: начиная с 42-й версии Google Chrome официально не поддерживает апплеты на базе Java, в том числе апплет ВТБ.
Однако он доступен в любом другом браузере, к примеру, Mozilla Firefox. Включить апплет там можно следующим образом:
После этих нехитрых манипуляций можете свободно заходить на сервис ВТБ: апплет должен работать без перебоев.
Установка апплета ВТБЧтобы установить и настроить апплет ВТБ скачайте его по ссылке http://www.java.com⁄ru⁄ . Апплет подойдет под функционалы таких браузеров как FireFox, Opera, Internet Explorer (версия которого должна постоянно обновляться).
Апплет для работы с ВТБ устанавливается в две стадии:
- установка и настройка платформы SE Runtime Environment;
- установка самого апплета.
Если для доступа вы планируете использовать персональный компьютер, первый шаг вам не нужен. Порядок установки состоит из пяти пунктов:
Затем скрипт нужно настроить:
«Пуск» =› контрольная панель =› убрать галочки с протоколов TLS 1.1, TLS 1.2 и «Use SSL 2.0 compatible ClientHello format». Теперь вы имеете свободный доступ к апплету ВТБ.
Настройка браузеровОкно-предупреждение с сообщением «Внимание. Java апплет не загружен» может возникать по причине браузеров. Чтобы настроить их на взаимодействие с апплетом ВТБ, следуйте инструкциям в таблице ниже.
| Firefox | 1. Нажмите на иконку. |
| 2. В выпадающем меню выберите статус «Разрешить и запомнить». | |
| 3. Нажмите «ОК». | |
| 4. Зайдите в настройки браузера. | |
| 5. Выберите пункт «Дополнения», подпункт «Плагины». | |
| 6. Проставьте по всем подпунктам Java статус «Включать по запросу». | |
| Opera | 1. Откройте настройки браузера. |
| 2. В пункте «Плагины» (рекомендуется)» выберите «Запускать все содержимое плагинов». | |
| Safari | 1. На странице регистрации в системе ВТБ выберите меню «Safari» => «Настройки» => «Безопасность» => «Настроить веб-сайт». |
| 2. В левом списке диалога выберите «Java». В правом списке для сайта ВТБ задайте режим «Вкл.». | |
| 3. Нажмите и удерживайте ALT переводя курсор мыши ВКЛ. Затем нажмите кнопку мыши. Появиться выпадающее меню, в котором выбрать «Запустить в безопасном режиме». | |
| 4. Нажмите «Готово» и перезагрузите браузер. | |
| Internet Explorer | 1. В настройках браузера выберите «Сервис» => «Свойства обозревателя» => «Дополнительно». Снимите отметку SSL 2.0 и отключите использование протоколов TLS 1.1 и 1.2. |
| 2. В настройках браузера выберите «Настроить надстройки». | |
| 3. В появившемся окне выберите «Запуск без получения разрешения». | |
| 4. В списке надстроек найдите «Java Plug-in ». Состояние данной надстройки должно быть «Включено». |
Итак, апплет от ВТБ – штука очень полезная, поэтому важно знать, как правильно установить программное обеспечение для него. Для тех, кто любит наглядные демонстрации, посмотрите видео.
Привет всем! Сегодня я попробую написать масштабную статью про Java. Ведь многие приложения сейчас ей используют.
А во время работы возникают порой ошибки.
Java — что такое и для чего нужна эта программаJava — это язык программирования или технология, на которой пишут онлайн-приложения. Т.е. чаты на сайтах, игры, загрузка файлов (в том числе фото, видео) и многие другие вещи.
Преимущество данной технологии:
А из недостатков скорость выполнения, хотя и были усовершенствования.
Возможно ещё есть, но это основные из официальных источников.
А вот какая история:
Для того чтобы обновить java (или установить) необходимо перейти на официальный сайт приложения . И нажать загрузить java.
И ещё… В браузерах, которые разработаны на движке хромиум, java может не работать. Если версия старая, то можно попробовать в адресной строке введя chrome://flags/#enable-npapi далее пункт «Включить NPAPI».
Но скорее всего, придется скачивать старую версию браузера, искать дополнения или же использовать Intenet Explorer.
Установка простая, просто нажимаем инстал.
Обновить так же можно через панель управления:
А в приложении вкладка Update.
Кстати вот инструкция, по включению в браузерах.
Для проверки версии, так же можно зайти в панель управления, выбрать java.
Кнопка About.
В открывшемся окне видим версию.
Удаляется Java обычным способом, через средство удаления программ, однако если вы не смогли удалить, то воспользуйтесь утилитой .
Вот так выглядит удаление через JavaUninstallTool.
Тут я попробую разобрать частые ошибки при работе. Если вдруг у вас были ошибки и вы их решили, тоже не стесняйтесь пишите в комментариях, поможем друг другу, так сказать…
Java апплет не загруженДля начала, выполните обычные действия, убедитесь что установлена необходимая версия java, не блокирует и фаервол. Перезагрузка компьютера и роутера. Далее, если ничего не помогло, идем в панель управления, выбираем java.
Если вы используете прокси, то нужно в General — Network Settings — Use proxy server прописывать прокси.
Еще есть случаи, когда необходимо не хранить временные файлы java на компьютере, а хранить на сервере банка например, но это индивидуальная ситуация. В таких ситуациях нужно читать инструкции на сайтах банков. И вообще всегда, если настраиваете под банк java, то читайте индивидуальные инструкции банка.
Ошибка 1603: Обновление Java не завершеноВ этой ситуации удалите java с помощью приложения или можно попробовать вручную через панель управления. Далее устанавливаете заново.
- Тут так же попробуйте удалить если есть старая версия и заново установить. При установке пробуйте устанавливать от имени администратора.
- Убедитесь что у вас есть полный доступ до всех папок.
- Скачайте оффлайн установщик и попробуйте установить его.
- Если ничего не помогает, убедитесь что ничего не препятствует установке, например: антивирус, брандмауэр.
- Для работы всех приложений необходимы NET Framework и Microsoft Visual C++, попробуйте их обновить.
В этой ошибке копируем путь до программы, у меня это: C:\Program Files (x86)\Java\jre1.8.0_144\bin
Ищем PATH и нажимаем редактировать.
Тут теперь аккуратнее!
Например вот мой кусок кода: C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;
Т.е. каждый параметр должен быть отделен точкой с запятой. Если вы не уверены в своих силах, скопируйте на всякий случай эту строку куда-нибудь.
Итак, что мы делаем:
Так же можете попробовать вот такой путь: C:\ProgramData\Oracle\Java\javapath;
Проблема в следующем.
На странице размещен некоторый апплет, а также интерфейс для управления им, написанный на HTML + JavaScript. Требуется определить из JavaScript, что апплет загружен и готов к работе. Решение должно быть ПРЕДЕЛЬНО надежным - кросс-броузерным, нормально реагирующим на медленный Internet и т.п.
Комментирую. Пока апплет не загрузился, обращения из JavaScript к его public-методам и/или полям чреваты появлением весьма некрасивого сообщения примерно такого содержания: "Данный метод отсутствует". А апплет порой загружается намного дольше, чем сама страница. Более того, некоторые вещи иногда имеет смысл сделать автоматически (из JavaScript), как только апплет загрузится - скажем, подать ему некоторую команду.
Здесь проблема не столько в том, что нет способа проверить, что апплет уже загрузился, сколько в изобилии таких способов. Например: onload у апплета, onload у страницы, обращение к методу или полю апплета, "активное" информирование страницы о загруженности апплета специальным Java-кодом изнутри самого апплета, и т.д. А уверенности, что эти способы будут работать:
на всех мыслимых броузерах,
при всех настройках Security в броузерах,
в сочетании со всеми мыслимыми платформами,
со всеми JRE,
у меня нет. И получить такую уверенность почти нереально: слишком много комбинаций.
Хуже того, здесь, кажется, очень легко "перемудрить". Например, я вчера долго "боролся" с ошибкой - на чужом компьютере (XP+ MSIE +Java2) JavaScript ошибочно полагал, что апплет не загружен, хотя у меня на компьютере все было в порядке. Подозреваю, дело в том, что я тогда использовал для проверки доступности обращение к некой public-переменной апплета (не методу!). Все броузеры на моем компьютере (тоже XP) при обращении к такой переменной недозагруженного апплета возвращают null, а как только апплет загрузится - возвращают ее значение. (В отличие от этого, обращение к методу недозагруженного апплета выдает ошибку.) Боюсь, что на чужом компьютере броузер отказался считывать public-переменную. Доступ к переменным - вообще неочевидная вещь, работающая по-разному из-под разных броузеров и JRE. Надежен только вызов методов, но - лишь когда апплет загружен.
Пока что я написал следующую пару функций:
Function showMyErrorMessage(msg,url,line) { if (window.errorMessage != null) alert(window.errorMessage); window.onerror = window.onerrorSave; return true; } function getApp(name,notShowMessage) { window.errorMessage = null; var a = "Error while accessing applet information for the \"" + name + "\" Java applet."; var b = "Maybe, this applet is not correctly loaded.Please try to reload this page."; if (notShowMessage==null || !notShowMessage) { window.errorMessage = a + b; } window.onerrorSave = window.onerror; window.onerror = showMyErrorMessage; var app = eval("document."+name); var appInfo = app == null? null: app.getAppletInfo(); window.onerror = onerrorSave; if (app == null || appInfo == null) { if (window.errorMessage != null) { if (app == null) alert("Cannot access \"" + name + "\" Java applet." + b); else alert("Cannot access applet information for the \"" + name + "\" Java applet." + b); } return null; } return app; }
Используется достаточно древняя (по идее, кросс-броузерная) техника подавления сообщения об ошибках через window.onerror. Все работает под Mozilla 1.4, MSIE 6.0 и даже под древним Netscape 4.5, но, увы, не под (куда более популярной) Opera 7.23: последняя выдает сообщение об ошибке JavaScript. Обращение к некоторому методу апплета необходимо - ибо почти все броузеры (кроме Netscape) успешно возвращают ненулевой объект document.ИмяАпплета, как только в странице прочитан ТЭГ
Из прочих методов проверки всевозможные onload у меня вызывают недоверие - в свое время (на старых броузерах) мне часто приходилось отлаживать ситуации, когда onload без видимых причин отказывался срабатывать, например при нажатии Refresh для страницы или чего-нибудь подобного. Самым надежным кажется "активное" информирование страницы - когда Java-код апплета обращается к JavaScript. Но тут вроде бы единственное кросс-броузерное решение - showDocument в отдельное окно (или фрейм), что делает решение крайне громоздким.
Может быть, кто-нибудь подскажет надежный, желательно опубликованный и широко известный способ проверки загруженности апплета?
Для Opera, кстати, нормально работает конструкция try...catch. Но только эта же конструкция, если не ошибаюсь, приведет к ошибке синтаксиса в ранних MSIE , которые до сих пор, кажется, превосходят Opera по популярности. Как бы надежно удостовериться, что можно использовать try...catch? Условная компиляция MSIE -
/*@cc_on @*/ /*@if (@_jscript_version >= 5) (испольщуем здесь try..catch и другие хорошие вещи) @*/ /*@end @*/
Как водится, в Opera игнорируется:(
Надо полагать, имеется в виду пакет netscape.javascript.* ?
Это решение непереносимо - если не ошибаюсь, в MSIE со встроенным JRE 1.1.4 эта техника начала работать только где-то с версии 5.5 или даже выше. Я этим пакетом никогда не пользовался - по причине непереносимости; может быть, я не прав? Я писал про это выше: "тут вроде бы единственное кросс-броузерное решение - showDocument в отдельное окно (или фрейм), что делает решение крайне громоздким".
Апплеты я обычно компилирую в JDK 1.1.6 (самая ранняя версия, имеющаяся в архивах Sun); там этого пакета вовсе нет.
А если городить огород, учитывающий, что пакета netscape.javascript.* может не быть, то получится ничуть не лучше, чем, к примеру, отдельно проверять оперу и использовать для нее try...catch.
Давно дело было:) Варианты:
public void init() {
//....
getAppletContext().showDocument("js_page.htm", "another_frame");
}
Пример 1998 года - http://www.copris.com/optocontrol/home.htm - в IE5.5 и Мозилла 1.6 работает (делалось во времена NN3 и IE3) :)
function checkApplet() {
if (document && document["appletName"] && document["appletName"].isActive())
//Do something
else
setTimeout(checkApplet, 100);
}
isActive() - это метод класса java.applet.Applet.
Алексей Рюмин aka Dwarf[досье]
Спасибо большое. Но...
У меня, увы, страница по природе не фреймовая, и вводить туда фреймы только ради апплета очень неудобно. А вариант с IFRAME не кросс-броузерный - это будет ничем не лучше моего решения с window.onerror.
Собственно, уже сейчас мои апплеты с 3D-структурами присутствуют на нескольких наших страницах, а в будущем таких страниц будет гораздо больше (всевозможные галереи примеров структур и т.п.). Собственно, на нашем сайте апплеты будут занимать примерно то же место, что и картинки (): иллюстрация к тексту, которую можно заодно "покрутить" мышкой. И возле каждого такого апплета, возможно, будут некоторые простейшие управляющие JavaScript-кнопки: ну хотя бы для разворота повернутой трехмерной картинки в исходную позицию.
Отсюда - необходимость универсальной функции вроде моей getApp, которую можно положить в подключаемый js-файл и ради которой не надо перекраивать сайты на фреймы.
Пишем простой тест.
... alert(document.XXXX+""+document.XXXX.isActive());
После чего грузим эту страницу через любой не-мгновенный Internet, почистив предварительно кэш MSIE . Как и следовало ожидать, пока апплет реально не загрузился (серый квадрат), вызов isActive() порождает вышеупомянутое сообщение об ошибке. В то же время, обращение document.XXXX срабатывает нормально, в чем можно убедиться, изменив код на
alert(document.XXXX);
Раз объект страницы XXXX был уже отрендерен, броузер разрешает свободно обращаться к этому объекту.
Правда, тут выплывает один интересный нюанс. При превращении объекта-апплета в строку получаются разные результаты, в зависимости от того, загрузился апплет или еще нет. Именно, если апплет загружен, то преобразование DHTML -объекта в строку дает результат вызова "toString()" у апплета. По идее, написать бы в методе toString некое ключевое слово и проверять, присутствует ли это слово в строке document.имяапплета+"".
Было бы просто замечательно, очень просто и красиво, и даже в Opera работает. Но - УВЫ - на этот раз подкачала Mozilla. Показывает, зараза, дурацкое независимо от факта загрузки. Так что - не пойдет...
Пока что - подскажите, как надежно "обнаружить", что мы имеем дело с современной Opera - точнее, что работают try...catch? Opera, кажется, имеет обыкновение прикидываться другими броузерами. Если выяснить, что try..catch работают, можно бы вызвать через eval версию кода с этими операторами - она работает и под Opera.
Еще в эту же тему. Предлагаю разделить возможные решения проблемы на две группы.
Если можно, прошу ограничиться решениями второго типа.
Что-то вы не понимаете, уважаемые.
Нельзя ЯВНО вызывать toString()! У DHTML -объекта "апплет" НЕТ собственного метода toString, он появляется, только когда загрузится Java-класс. Соответственно, попытка вывести
alert(document.PackingSpheresForDesign.toString());
при незагруженном апплете приводит к ошибке JavaScript, в моем MSIE это "Unspecified error".
Неявно вызвать toString, разумеется, можно всегда - преобразованием DHTML-объекта в строку. И здесь, как я уже говорил, Mozilla ведет себя некрасиво: никогда не вызывает toString() апплета, даже когда апплет полностью загружен. Да и не документировано нигде, что броузер обязан использовать toString Java-класса. Решение, опирающееся на проверку строчного представления DHTML-объекта Applet, очевидным образом попадает в первую категорию: если некий броузер не захочет вызывать метод toString, то на таком броузере апплет ВСЕГДА будет считаться незагруженным, и пользователь вообще не сможет работать.
Как все-таки удостовериться в JavaScript, что броузер достаточно хорош, чтобы понять конструкцию try...catch? Я пока склоняюсь пойти по этому пути.
Даниэль Алиевский[досье]
Не, ну понятно, что в MSIE вызов toString() ошибка, но браузер-то в javascript легко определить. Если браузер mozilla, вызывайте toString(), если нет, просто applet.
Что касается вызова метода toString в браузере, то насколько я понимаю у любого объекта в javascript должен быть метод toString и если браузер не вызывает этот метод у апплета, тогда имеются сомнения в том, что в этом браузере вообще возможно вызывать методы апплета - безотносительно к поведению в данном случае mozilla.
Короче, надо сначала найти такой браузер и желательно чтобы он был достаточно распространен, ибо в противном случае я сам в состоянии достаточно быстро написать браузер, который бы саботировал все попытки определения загруженности апплета.
Ну да. Я просто не додумал. Действительно, надо просто в моей функции обратиться не к методу getAppletInfo, а к методу toString. В MSIE , правда, как и раньше, будет ошибка, но она благополучно ловится через window.onerror. Зато в Opera - и во всех броузерах, которые разрешают вызывать toString у недозагруженного апплета - никаких ошибок вообще не будет, просто toString вернет либо строку с кодовым словом, если апплет загружен, либо нечто умолчательное. При этом, вроде бы, не должно быть настолько странного броузера, чтобы у нормально загруженного апплета JavaScript-вызов toString не обратился бы к одноименному методу апплета.
Кажется, найдено неплохое решение. Спасибо за помощь. Дотестирую его под всякими кривыми броузерами вроде Netscape 3 - и предложу для FAQ .
Александр Самойлов[досье] "Что касается вызова метода toString в браузере, то насколько я понимаю у любого объекта в javascript должен быть метод toString и если браузер не вызывает этот метод у апплета, тогда имеются сомнения в том, что в этом браузере вообще возможно вызывать методы апплета..." - тут я не совсем вас понял, ведь как раз самый популярный MSIE считает, что никакого toString у объекта Applet нет, если апплет не загружен (к примеру, если указан неверный путь к классу). Я вообще не видел внятных указаний в документации, что КАЖДЫЙ JavaScript объект обязан обладать таким методом. Если таковые есть - ткните пальцем, если не трудно.
цитата из справки для JScript
The Object object is contained in all other JScript objects; all of its methods and properties are available in all other objects. The methods can be redefined in user-defined objects, and are called by JScript at appropriate times. The toString method is an example of a frequently redefined Object method.из нее, конечно нельзя однозначно сделать вывода, о том, что и для всех других интерпретаторов javascript подобное выполняется.
что касается MSIE , то он не считает, что у апплета нет метода toString, он считает, что произошла неопределенная ошибка во время выполнения этого метода.
например, если попытаться вызвать заведомо несуществующий метод у апплета то ошибка будет другой.
Черт! Вы будете смеяться, но MSIE + Java 2 ВООБЩЕ не желает вызывать toString() у НОРМАЛЬНО загруженного апплета. Устойчиво выдает Unspecified error. А при умолчательном преобразовании в строку, соответственно, мой перекрытый toString попросту игнорируется.
Может быть, конечно, у меня что-то не то с апплетом - надо бы, по идее, сделать чистый тест. Но в любом случае - если хотя бы на моем апплете это так, значит технология неверная.
Что б его. Вчера забыл проверить на этой ситуации (проверял под Java 1.1.4). Сегодня полчаса убил на таинственный глюк страницы. Хуже того, в качестве "побочного эффекта" MSIE принялся глухо зависать при открытии страницы (видимо, из-за разных моих вспомогательных скриптов). Ужасно.
Вернулся к старой методике с вызовом getAppletInfo().
Так что, господа, жду дальнейших предложений. В частности - как отловить Оперу (чтобы бороться с ней отдельно).
Владимир Палант[досье] Спасибо. Можно первоисточнк, если не затруднит? (Догадываюсь, что где-то на сайте opera.)
Мне бы хотелось не столько обнаружить Оперу, сколько проверить версию JavaScript, что он поддерживает try...catch - совместимым с Opera способом. Микрософтоский вариант такой проверки - условная компиляция - естественно, под Opera не работает.
На худой конец достаточно и проверки Оперы: в этом случае можно (надеюсь:-)) смело вызывать toString у апплета.
Даниэль Алиевский[досье]
а почему бы не использовать версию яваскрипт для отлова поддержки try catch
var try_catch = false
try_catch=true
if (try_catch) {}
правда в опере не проверял
Даниэль Алиевский[досье]
Нет, на opera.com рекомендуют проверять по User-Agent (http://www.opera.com/support/search/supsearch.dml?index=570) — ИМХО извращение. Проверять по window.opera надежней — никакой другой браузер это свойство поддерживать не станет.
Opera поддерживает try/catch как минимум с версии 4.0, так что можете считать, что поддерживает всегда.
Есть еще одна идея - пока не проверил. Обращение к свойствам DHTML -объекта (property), насколько я знаю, никогда не порождает исключений. Если такого свойства нет, просто возвращается null. Хорошо бы снабдить апплет неким свойством (к примеру, boolean iAmLoaded=true), и проверять, установлено ли оно. Насколько я понимаю, в случае Java 2 это не так просто - недостаточно завести public-поле, нужно объявлять пару методов get/set, как это полагается в JavaBeans (пока еще не изучил соответствующую документацию).
Как считаете, насколько это надежная и кросс-броузерная техника?
Не понял я, при чем тут JavaBeans, по-моему доступ к свойствам осуществляется без всяких get/set. Но в любом случае — проверять можно наличие метода, который для DHTML тоже свойство: if (typeof(applet.notifyAll) != "undefined") . А вот кроссбраузерность вам уже придётся самим проверить...
Владимир Палант[досье]
Намек на JavaBeans Introspection есть вот здесь: http://java.sun.com/j2se/1.4.2......loper_guide/compatibility.html
Как я понял, проблема имела временный характер: у меня на компьютере во всех броузерах и JRE доступ к public-полю чудесно работает. Причем совершенно нетрудно добавить в апплет "настоящее" public-поле типа boolean, тогда не потребуется прибегать к более экзотическим приемам типа typeof(applet.notifyAll). (Кстати, упомянутый typeof не работает у меня в MSIE ни с 1.1.4, ни с Java 2.)
Проблема в том, что раньше я применял как раз такую технику - проверку существования public-поля - и однажды столкнулся с проблемой, причем, очевидно, того самого неприятного первого типа: поле не обнаруживалось, апплет детектировался как незагруженный и начисто отказывался работать. Это произошло на 2 "чужих" компьютерах с вполне нормальной конфигурацией (MSIE + Java 2, что-то типа JRE 1.4.2_01), хотя на моем компьютере все работало. Естественно, я перестал пользоваться проверкой поля - от греха подальше.
Но, может быть, я просто сделал все недостаточно грамотно? Скажем, не объявил методов get/set "по-JavaBean-овски"? Если я не увижу в документации четкого описания этой проблемы с объяснением, почему на некоторых броузерах доступ к обычному public-полю не работает, и указанием, как делать это корректно, я, конечно, не рискну применять проверку поля - слишком высока цена ошибки.
Перехват сообщения об ошибке, как выяснилось, работает даже под Netscape 3. Но - немного не так, как нужно: этот древний броузер вызывает процедуру показа сообщения асинхронно с общим потоком JavaScript-кода, что приводит к тонким ошибкам. Пока не доотладил. Естественно, совместимость с Netscape 3 никому не нужна, но настораживает, что методика (обращение к методу апплета, или toString для Оперы, с перехватом ошибки) требует отладки "по новой" чуть ли не для каждого класса броузеров:(Видимо, все-таки техника кривая. А какая техника "прямая" - пока непонятно.
С Netscape 3.0 песня оказалась совсем в другом. Этот броузер вообще не сильно дружил с обращениями типа document.xxxx, где xxxx - имя апплета. Даже для реально загруженного апплета он имел обыкновение при таком обращении выдавать целую пачку ошибок:
Can"t reflect applet "(null)": not loaded yet
(Самое смешное, что это происходит и при проверках типа "if (document.getElementById != null)...".) Борьба с этим очень проста. Достаточно каждое обращение к любому document.xxxx обрамлять кодом наподобие:
var onerrorSaveLocal = window.onerror;
window.onerror = null; // - avoiding an incorrect exception in Netscape Navigator 3
var v = document.xxxx;
window.onerror = onerrorSaveLocal;
При этом, как и в Netscape 4, и во встроенном "броузере" из JavaBuilder, при недозагруженном апплете document.имяАпплета просто возврашает null.
В общем, я потратил некоторое время и отладил свою процедуру под всеми броузерами, до которых смог "дотянуться" - включая предыдущие версии MSIE . Вот что получилось:
Function showMyErrorMessage(msg,url,line) { if (window.errorMessageA != null) alert(window.errorMessageA+"(System error message: "+msg+")"+window.errorMessageB); window.onerror = window.onerrorSave; return true; } function getApp(name,notShowMessage) { // For compatibility with this function, all Java applets must override "toString()" method // and return a string containing "Successfully loaded Java applet" substring as it"s result. window.errorMessageA = window.errorMessageB = null; if (notShowMessage==null || !notShowMessage) { window.errorMessageA = "Error while accessing applet information for the \"" + name + "\" Java applet."; window.errorMessageB = "Maybe, this applet is not correctly loaded." + "Please wait until it will be completely loaded, " + "or please try to reload this page."; } var opera = window.opera != null; if (window.onerrorSave == null) window.onerrorSave = window.onerror; var app = null; var appInfo = null; var onerrorSaveLocal = window.onerror; window.onerror = null; // - avoiding an incorrect exception in Netscape Navigator 3 // ("Can"t reflect applet "(null)": not loaded yet") // sometimes appeared while accessing correctly loaded applets app = eval("document."+name); window.onerror = onerrorSaveLocal; var systemErrorMessage = null; /*@cc_on@*/ /*@if (@_jscript_version >= 5) try { // some MSIE (for example, MSIE 5.0) don"t understand onerror-based catching @else @*/ window.onerror = showMyErrorMessage; // catching exceptions while calling non-existing method /*@end @*/ appInfo = app == null? null: // a case of Netscape browser opera? app.toString(): // MSIE + Java2 cannot call applet"s toString app.getAppletInfo(); // MSIE and Mozilla (but not Opera) will catch an exception here /*@if (@_jscript_version >= 5) } catch(e) { systemErrorMessage = e==null || e.description==null? "unknown error": e.description+""; } @else @*/ window.onerror = window.onerrorSave; window.onerrorSave = null; /*@end @*/ if (app == null || systemErrorMessage != null || appInfo == null || (opera && (appInfo+"").indexOf("Successfully loaded Java applet")==-1)) { if (window.errorMessageA != null) { if (app == null) alert("Cannot find \"" + name + "\" Java applet." + window.errorMessageB); else if (systemErrorMessage != null) alert("An exception occured while accessing applet information for the \"" + name + "\" Java applet. (System exception information: " + systemErrorMessage + ")" + window.errorMessageB); else if (appInfo == null) alert("Cannot access applet information for the \"" + name + "\" Java applet." + window.errorMessageB); else alert("Cannot call \"" + name + "\" Java applet." + window.errorMessageB); } return null; } return app; }
Как водится, MSIE доставили максимум проблем. Из относящихся к делу: MSIE 5.0, как выяснилось, отказывается блокировать сообщения об ошибках через window.onerror. Пришлось специально для "капризного" MSIE написать ветку c условной компиляцией и try..catch. На первый взгляд, try..catch - самое надежное решение, так что вполне логично применять его в самом популярном семействе броузеров. При этом в MSIE 4 (где нет try..catch), а также в Mozilla продолжает работать блокировка ошибки через window.onerror. В Opera используется вызов toString и проверка "кодового слова" внутри результата. Еще попутно выяснилось, что в MSIE 4 лучше не пытаться обращаться к апплету из onbeforeunload - могут быть ошибки.
Я дошел даже до MSIE 3.0:-) Там, кажется, моя процедура не сработала, хотя, возможно, дело тут в том, что мои классы скомпилированы несовместимым с Java 1.0.2 способом, а поддерживать подобную совместимость у меня нет ни малейшего желания.
Теперь у меня есть огромная просьба ко всем присутствующим. Пожалуйста, протестируйте эту процедуру с каким-нибудь апплетом на всех своих броузерах. Например, работает ли это в Unix Mozilla/Opera, или на Macintosh? Вo всех ли вариантах Windows+MSIE? Что насчет более ранних версий Opera?
Я протестировал в следующих броузерах:
Windows XP: MSIE 6.0 c Java 1.4.2 и Java 1.1.4, Mozilla 1.4, Opera 7.23, Netscape 4.5, Netscape Navigator 3.0;
Windows NT 4.0: MSIE 5.0 с Java 1.4 и Java 1.1.4, Netscape 4.5, Netscape Navigator 3.0;
Windows-95: MSIE 3.0 (Java 1.0.2), Netscape 4.5.
Тестировать проще всего, указывая на странице заведомо неправильный путь к апплету (и, для сравнения, правильный) - по-моему, это достаточно похоже на ситуацию, когда апплет не догрузился. Если все нормально, то, по идее, процедура заслуживает помещения в FAQ .
На этой странице кнопка "Get JVM information" (использующая вышеописанную функцию) должна срабатывать, как только апплет загрузится, либо "ругаться", пока он не загружен.
(Кстати, в MSIE 3.0 эта техника таки не работает - в моей версии 3.02 JavaScript вообще отказывается что-либо делать, если апплет не загружен. И бог с ним.)