Spec-Zone .ru
спецификации, руководства, описания, API
|
Отметьте: Это руководство по развертыванию Java описывает функции, выпущенные до Java SE 6 обновлений 10 выпусков. См. Java Богатый документ Разработки и Развертывания Интернет-приложений для последней информации.
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 ресурсы ищутся в следующей последовательности:
archive
или cabbase
параметрыcodebase
URLВ реализации солнца ресурсы ищутся просто кодовой базой URL.
В результате некоторые апплеты, полагающиеся на последовательность поиска ресурсов Microsoft VM, возможно, не загружают ресурсы должным образом в Java SE.
Чтобы обеспечить максимальную совместимость апплета, последовательность поиска ресурсов в Плагине Java была изменена следующим образом:
archive
параметрыcodebase
URLClassLoader
совместное использование политики ClassLoader
совместное использование политики отличается в реализациях Microsoft и Sun.
В реализации Microsoft, a ClassLoader
объект совместно используется апплетами если и только если:
codebase
значения являются тем же самым,archive
значения являются тем же самым, иcabbase
значения являются тем же самым.В реализации солнца, a ClassLoader
объект совместно используется апплетами если и только если codebase
значения являются тем же самым.
Некоторые апплеты, полагающиеся ClassLoader
совместное использование политики реализации Microsoft, возможно, не выполняет должным образом в Java SE из-за потенциальных конфликтов определения class.
Обеспечить максимальную совместимость апплета, ClassLoader
совместное использование политики в Плагине Java было изменено. A ClassLoader
объект теперь совместно используется апплетами если и только если:
codebase
значения являются тем же самым,cache_archive
значения являются тем же самым,java_archive
значения являются тем же самым, иarchive
значения являются тем же самым.У 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.
null
по сравнению со строкой нулевой длиной)В JDK 1.1 спецификация языка Java была свободна имея дело с null
и строки нулевые длиной в библиотеках class. Некоторые API могут обработать строку нулевую длиной как null
, в то время как другие API могут обработать null
как это. В Java SE спецификация языка Java была сжата, чтобы определить, каково точное поведение должно быть.
Эта проблема не является закрепляемой. Таким образом, в Java SE апплет, который полагается на API, чтобы обработать null
поскольку строка нулевая длиной может привести к исключению.
В Java SE подписание апплета поддерживается через RSA и .jar
файл, тогда как Microsoft поддерживает апплет, подписывающийся через его собственный Authenticode и .cab
технологии файла.
Эта проблема не является закрепляемой. Таким образом апплет, который полагается на Authenticode Microsoft и .cab
технологии файла, возможно, не загружают должным образом в Java SE.
В прошлом некоторые программисты предполагали, что AWT был ориентирован на многопотоковое исполнение. Поэтому некоторые апплеты были записаны, используя библиотеки AWT, которые взаимодействовали с GUI в многократных потоках, предполагая, что библиотеки class заботились о проблемах синхронизации. Фактически, ни AWT, ни Swing не ориентированы на многопотоковое исполнение. Поэтому, весь код, который обновляет GUI или обрабатывает события, должен произойти на потоке диспетчеризации события. Отказ сделать так может привести к мертвой блокировке или состоянию состязания. Для получения дополнительной информации см. Component
s.
В реализации Microsoft методы апплета и свойства, представленные в JavaScript в странице HTML, являются точно тем же самым как методами и свойствами объекта апплета. В Плагине Java методы апплета и свойства представляются в JavaScript в странице HTML через Самоанализ JavaBeans, который анализирует методы и свойства через соглашения о присвоении имен в объекте апплета. Побочный эффект состоит в том, что поля апплета обрабатываются по-другому.
Эта проблема будет решена в будущем выпуске Плагина Java. Тем временем доступ JavaScript к полям в объекте апплета, возможно, не работает должным образом в Java SE.
Microsoft предоставила многим собственным библиотекам class в своей реализации VM, включая J/Direct, AFC, WFC, и т.д. Для других классов методы, и переменные, видят
Эта проблема не является закрепляемой. Таким образом апплеты, которые полагаются на любую 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.
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 SE. Некоторые API разъясняются, некоторые обесцениваются, и некоторые изменили реализации. Следующее заставило некоторые апплеты, выполненные в Microsoft VM приводить к сбою в Java SE:
java.awt.Graphics.drawString()
drawString()
обработки null
как пустая строка в Microsoft VM. В Java SE, drawString()
обработки null
как это и бросает NullPointerException
.java.awt.Graphics.drawImage()
drawImage()
игнорирует null
изображение в Microsoft VM. В Java SE, drawImage()
обработки null
как это и бросает NullPointerException
.java.awt.Color
конструкторыColor
конструктор заставит VM распечатывать предупреждающее сообщение в консоли, но значения будут сброшены к максимальному / минута автоматически. В Java SE, Color
конструктор проверяет на недопустимые значения и броски IllegalArgumentException
.Thread.stop(), Thread.suspend(), Thread.resume()
AccessControlException
. Апплеты, на которые влияют эти проблемы, приведут к исключениям и, возможно, не выполняют должным образом в Java SE.
Это - собственная технология Microsoft, которая не поддерживается Java SE.
object
атрибут с PARAM
элементСо стандартным форматом апплета называют использование атрибута object
с a PARAM
элемент вызовет исключение с Sun VM: 'Или "код" или "объект" должны быть определены, но не оба.' С Microsoft VM не будет выдано никакое исключение. Это - проблема совместимости. Чтобы избежать исключения с Sun VM, не используйте названный атрибут object
с a PARAM
элемент в апплете.