Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
ClassFormatErrorЭта ошибка вызывается байт-кодом, сгенерированным от старого JDK 1.0.2 или 1.1 компилятора. В прошлом много этих компиляторов сгенерированный байт-код, который не приспосабливает Java Спецификации VM. Так как верификаторы в недавних выпусках J2SE намного более строги о плохом формате класса, ClassFormatError бросается VM, когда эти плохие файлы класса загружаются.
Некоторыми типичными проблемами в некоторых более старых файлах класса является следующий (отметьте, что этот список не является исчерпывающим):
Можно избежать этого типа проблемы, перекомпилировав Ваши классы с компилятором байт-кода Javac от текущего JDK. Если Вы хотите использовать сторонний obfuscator, убедитесь, что использовали тот, который производит файлы класса, которые уважают надлежащий формат файла класса.
Чтобы позволить некоторым из апплетов с плохими файлами класса выполнять в Java SE, Плагин Java содержит преобразователь байт-кода, чтобы преобразовать некоторые из плохих файлов класса к хорошим. В настоящий момент, только плохие файлы класса со следующим ClassFormatError может быть преобразован:
К сожалению, следующий ClassFormatError проблемы не являются закрепляемыми преобразователем байт-кода:
Таким образом любой файл класса, имеющий любую из этих проблем, не будет выполнять под Java SE:
sun.audio sun.audio пакет был доступен апплетами в JDK 1.1. Однако, в Java SE песочница апплета была закрыта. Таким образом, апплеты, пытающиеся получить доступ к любым библиотекам классов в 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 из-за потенциальных конфликтов определения класса.
Обеспечить максимальную совместимость апплета, 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 и строки нулевые длиной в библиотеках классов. Некоторые 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 в многократных потоках, предполагая, что библиотеки классов заботились о проблемах синхронизации. Фактически, ни AWT, ни Swing не ориентированы на многопотоковое исполнение. Поэтому, весь код, который обновляет GUI или обрабатывает события, должен произойти на потоке диспетчеризации события. Отказ сделать так может привести к условию гонки или мертвой блокировке. Для получения дополнительной информации см. в . Хотя это учебное руководство определенно касается Swing в этом экземпляре, те же самые правила применяются ко всем Components.
В реализации Microsoft методы апплета и свойства, представленные в JavaScript в странице HTML, являются точно тем же самым как методами и свойствами объекта апплета. В Плагине Java методы апплета и свойства представляются в JavaScript в странице HTML через Самоанализ JavaBeans, который анализирует методы и свойства через соглашения о присвоении имен в объекте апплета. Побочный эффект состоит в том, что поля апплета обрабатываются по-другому.
Эта проблема будет решена в будущем выпуске Плагина Java. Тем временем доступ JavaScript к полям в объекте апплета, возможно, не работает должным образом в Java SE.
Microsoft обеспечила много собственных библиотек классов в своей реализации VM, включая J/Direct, AFC, WFC, и т.д. Для других классов методы, и переменные, видят.
Эта проблема не является закрепляемой. Таким образом апплеты, которые полагаются на любую Microsoft собственные Библиотеки классов Java, не будут работать должным образом в 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 и 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 элемент в апплете.
