Spec-Zone .ru
спецификации, руководства, описания, API
Содержание документации

Отметьте: Это руководство по развертыванию Java описывает функции, выпущенные до Java SE 6 обновлений 10 выпусков. См. Java Богатый документ Разработки и Развертывания Интернет-приложений для последней информации.

Проблемы совместимости апплета


Этот документ описывает все известные проблемы совместимости апплета между Microsoft Virtual Machine (VM) и Java Sun VM. Java термина SE, используемый здесь, отсылает к Платформе Java Standard Edition версию 1.2 или позже.


ClassFormatError

Эта ошибка вызывается байт-кодом, сгенерированным от старого JDK 1.0.2 или 1.1 компилятора. В прошлом много этих компиляторов сгенерированный байт-код, который не приспосабливает Java Спецификации VM. Так как верификаторы в недавних выпусках J2SE намного более строги о плохом формате class, ClassFormatError бросается VM, когда эти плохие файлы class загружаются.

Некоторыми типичными проблемами в некоторых более старых файлах class является следующий (отметьте, что этот список не является исчерпывающим):

Можно избежать этого типа проблемы, перекомпилировав Ваши классы с компилятором байт-кода Javac от текущего JDK. Если Вы хотите использовать сторонний obfuscator, убедитесь, что использовали тот, который производит файлы class, которые уважают надлежащий class - формат файла.

Чтобы позволить некоторым из апплетов с плохими файлами class выполнять в Java SE, Плагин Java содержит преобразователь байт-кода, чтобы преобразовать некоторые из плохих файлов class к хорошим. В настоящий момент, только плохие файлы class со следующим ClassFormatError может быть преобразован:

К сожалению, следующий ClassFormatError проблемы не являются закрепляемыми преобразователем байт-кода:

Таким образом любой файл class, имеющий любую из этих проблем, не будет выполнять под Java SE:

Исключение безопасности с sun.audio

sun.audio пакет был доступен апплетами в JDK 1.1. Однако, в Java SE песочница апплета была закрыта. Таким образом, апплеты, пытающиеся получить доступ к любым библиотекам class в sun.audio пакет приведет к SecurityException

Чтобы обеспечить максимальную совместимость апплета, песочница апплета в Плагине Java была открыта, чтобы позволить апплеты, снова получают доступ sun.audio пакет.

Неспособный найти ресурсы от AppletContext.getAudioClip() и AppletContext.getImage()

Для реализаций Microsoft и Sun, последовательности поиска ресурса в AppletContext.getImage() и AppletContext.getAudioClip() отличается. 

В реализации Microsoft ресурсы ищутся в следующей последовательности:

  1. Архивы определяются через HTML archive или cabbase параметры
  2. codebase URL

В реализации солнца ресурсы ищутся просто кодовой базой URL.

В результате некоторые апплеты, полагающиеся на последовательность поиска ресурсов Microsoft VM, возможно, не загружают ресурсы должным образом в Java SE. 

Чтобы обеспечить максимальную совместимость апплета, последовательность поиска ресурсов в Плагине Java была изменена следующим образом:

  1. Архивы определяются через HTML archive параметры
  2. codebase URL

ClassLoader совместное использование политики

ClassLoader совместное использование политики отличается в реализациях Microsoft и Sun. 

В реализации Microsoft, a ClassLoader объект совместно используется апплетами если и только если:

В реализации солнца, a ClassLoader объект совместно используется апплетами если и только если codebase значения являются тем же самым.

Некоторые апплеты, полагающиеся ClassLoader совместное использование политики реализации Microsoft, возможно, не выполняет должным образом в Java SE из-за потенциальных конфликтов определения class. 

Обеспечить максимальную совместимость апплета, ClassLoader совместное использование политики в Плагине Java было изменено. A ClassLoader объект теперь совместно используется апплетами если и только если:

Модель обеспечения безопасности — Java VS SE Microsoft

У SE Java есть новая модель обеспечения безопасности, которая обеспечивает намного больше возможности и гибкости чем JDK 1.1, в то время как модель обеспечения безопасности Microsoft VM основана на JDK 1.1 и его собственных технологиях. 

Эта проблема не является закрепляемой. Таким образом апплет, который полагается на модель обеспечения безопасности Microsoft, не будет выполнять должным образом в Java SE.

Упаковка апплета

Упаковка апплета в Java SE и JDK 1.1 через .jar файлы, тогда как Microsoft VM поддерживает упаковку апплета через .jar файлы и его собственное .cab (корпус) файлы. 

Эта проблема не является закрепляемой. Таким образом апплет упаковывается в Microsoft .cab формат файла не будет загружен в Java SE.

Строгость спецификации языка Java (null по сравнению со строкой нулевой длиной)

В JDK 1.1 спецификация языка Java была свободна имея дело с null и строки нулевые длиной в библиотеках class. Некоторые API могут обработать строку нулевую длиной как null, в то время как другие API могут обработать null как это. В Java SE спецификация языка Java была сжата, чтобы определить, каково точное поведение должно быть.

Эта проблема не является закрепляемой. Таким образом, в Java SE апплет, который полагается на API, чтобы обработать null поскольку строка нулевая длиной может привести к исключению.

Подписание апплета — RSA по сравнению с Authenticode

В Java SE подписание апплета поддерживается через RSA и .jar файл, тогда как Microsoft поддерживает апплет, подписывающийся через его собственный Authenticode и .cab технологии файла.

Эта проблема не является закрепляемой. Таким образом апплет, который полагается на Authenticode Microsoft и .cab технологии файла, возможно, не загружают должным образом в Java SE.

Реализация изменяется в библиотеках class AWT

В прошлом некоторые программисты предполагали, что AWT был ориентирован на многопотоковое исполнение. Поэтому некоторые апплеты были записаны, используя библиотеки AWT, которые взаимодействовали с GUI в многократных потоках, предполагая, что библиотеки class заботились о проблемах синхронизации. Фактически, ни AWT, ни Swing не ориентированы на многопотоковое исполнение. Поэтому, весь код, который обновляет GUI или обрабатывает события, должен произойти на потоке диспетчеризации события. Отказ сделать так может привести к мертвой блокировке или состоянию состязания. Для получения дополнительной информации см. Concurrenecy в Swing в Учебном руководстве Swing. Хотя это учебное руководство определенно касается Swing в этом экземпляре, те же самые правила применяются ко всем Components.

Передача Java/JavaScript

В реализации Microsoft методы апплета и свойства, представленные в JavaScript в странице HTML, являются точно тем же самым как методами и свойствами объекта апплета. В Плагине Java методы апплета и свойства представляются в JavaScript в странице HTML через Самоанализ JavaBeans, который анализирует методы и свойства через соглашения о присвоении имен в объекте апплета. Побочный эффект состоит в том, что поля апплета обрабатываются по-другому.

Эта проблема будет решена в будущем выпуске Плагина Java. Тем временем доступ JavaScript к полям в объекте апплета, возможно, не работает должным образом в Java SE.   

Microsoft собственные классы Java, методы, и переменные

Microsoft предоставила многим собственным библиотекам class в своей реализации VM, включая J/Direct, AFC, WFC, и т.д. Для других классов методы, и переменные, видят, Как избежать потенциальных ловушек нестандартного SDK Microsoft для Java.

Эта проблема не является закрепляемой. Таким образом апплеты, которые полагаются на любую Microsoft собственный Java библиотеки class, не будут работать должным образом в Java SE.

Пробельные символы в строках, возвращенных из Applet.getParameter()

В реализации Microsoft являются неизолированными пробельные символы прежде, чем строка возвращается к апплету в Applet.getParameter(). С другой стороны реализация Sun возвращает строку, поскольку это определяется в параметрах HTML. В результате некоторый JDK, 1.1 апплета отказываются выполнить в Java SE, потому что логика апплета не принимает пробел во внимание.

Обеспечить максимальную совместимость апплета, реализацию Applet.getParameter() в Java Плагин был изменен, чтобы снять изоляцию с пробельных символов в возвращаемом значении.

Конструктивные изменения в java.util.Hashtable.hashCode()    

В JDK 1.1, Hashtable.hashCode() был реализован основанный на объектных идентификационных данных; таким образом, каждый Hashtable возразите возвращает его уникальное значение когда hashCode() вызывается. В Java SE, реализация Hashtable.hashCode() был изменен, чтобы быть основанным на значении как часть Платформы Набора Java. A Hashtable возразите возвращает его значение хэш-кода, основанное на объектах, которые это содержит.  

Это изменение повреждает некоторый JDK 1.1 апплета, если они добавляют a Hashtable объект в себя, который повреждает фундаментальный проект Платформы Набора и причин StackOverflowError. Это повреждает логику в некотором коде апплета, который полагается Hashtable.hashCode() возвратить постоянную величину из того же самого Hashtable объект.

Обеспечить максимальную совместимость апплета, реализацию Hashtable.hashCode() был изменен, чтобы проверить на этот особый случай, чтобы избежать переполнения стека.

Доступ к фрейму от апплета

Чтобы отследить события от нажатия мыши или по некоторым другим причинам, апплет может иногда пытаться получить доступ к своему фрейму. В реализациях Microsoft и Sun, числе контейнеров между фреймом и апплетом отличается.

Апплет, который полагается на фрейм, являющийся на определенном уровне включения в Microsoft VM, не перемещаясь по всему иерархическому компонентному дереву AWT, вероятно, приведет к сбою в Java SE. Наиболее распространенный признак ClassCastException от AWT Диспетчеризируют Поток События.

Эта проблема не является закрепляемой. Таким образом апплет с этой проблемой, возможно, не выполняет должным образом в Java SE.

MAYSCRIPT

В Навигаторе Netscape и Плагине Java, апплет, получающий доступ к JavaScript, обязан определять MAYSCRIPT атрибут в элементе апплета. Реализация Microsoft, однако, не соблюдает этот специальный параметр; это позволяет апплету получать доступ к JavaScript при всех условиях. Так как большинство интернет-апплетов предназначается для VM Microsoft вместо Netscape, MAYSCRIPT не определяется в этих апплетах.

Обеспечить максимальную совместимость апплета, MAYSCRIPT проверка была удалена из Плагина Java.

HTTP User-Agent

В реализациях Microsoft и Sun, различном HTTP User-Agent строки передают к серверу, когда HTTP-соединение требуют. Большинство веб-сайтов предназначается для VM Microsoft вместо Sun и не распознает HTTP Sun User-Agent.Это может привести к отказу.

По этой причине, HTTP User-Agent строка, используемая в Плагине Java, была сделана подобной Microsoft один. Таким образом большинство веб-серверов распознает просьбы, обращенные от апплетов, работающих в Плагине Java.

События во время запуска апплета и завершения работы

В реализациях Microsoft и Sun события, происходящие во время запуска апплета и завершения работы, возможно, не точно то же самое. Например, логика в апплете может положиться на апплет, являющийся видимым когда Applet.start() или Applet.stop() вызывается, который может быть истиной в реализации Microsoft, но не в реализации Sun.

Апплет, который полагается на определенные события во время запуска апплета и завершение работы в Microsoft VM, возможно, не функционирует должным образом в Java SE. Наиболее распространенный признак NullPointerException от AWT Диспетчеризируют Поток События.

Эта проблема не является закрепляемой.

Java совместимость библиотек class 

Есть много изменений в Java библиотеки class и Java SE. Некоторые API разъясняются, некоторые обесцениваются, и некоторые изменили реализации. Следующее заставило некоторые апплеты, выполненные в Microsoft VM приводить к сбою в Java SE:

Апплеты, на которые влияют эти проблемы, приведут к исключениям и, возможно, не выполняют должным образом в Java SE.

Моникер Java

Это - собственная технология Microsoft, которая не поддерживается Java SE.

object атрибут с PARAM элемент

Со стандартным форматом апплета называют использование атрибута object с a PARAM элемент вызовет исключение с Sun VM: 'Или "код" или "объект" должны быть определены, но не оба.' С Microsoft VM не будет выдано никакое исключение. Это - проблема совместимости. Чтобы избежать исключения с Sun VM, не используйте названный атрибут object с a PARAM элемент в апплете.


Oracle и/или его филиалы Авторское право © 1993, 2012, Oracle и/или его филиалы. Все права защищены.
Свяжитесь с Нами