Ошибка запуска xxx: модуль 'xxx-4' имеет ошибку проверки 3337. (Codfile версия 78) в Blackberry?
Я реализовал приложение Blackberry с использованием JRE5.0, оно хорошо работает на любом устройстве с OS5.0 и OS6.0
Когда я пытаюсь открыть то же самое приложение на 9900 с ОС 7.0, я получаю следующую ошибку:
Ошибка запуска myAppName: модуль "MyAppName-4" имеет ошибку проверки 3337. (Codfile версия 78)
где myAppName - имя приложения (имя файла cod)
как на следующем изображении:
Я проверил регистратор событий, вот что он содержит (от старых к новым):
- Система - ВМ: ССЫЛКА MyAppName
- Система - ВМ:VECPs=my.Package.Name.Contained.Screens
- система - ВМ:VECCs=oneOfMyScreenClassNames
- Система - ВМ:VECMm=functionInOneOfMyClasses()
- Модуль 'MyAppName-4' имеет ошибку проверки 3337 (codfile версия 78)
- Ошибка компоновщика: "VerifyError" для MyAppName
- Ошибка запуска myAppName: модуль "MyAppName-4" имеет ошибку проверки 3337 (codfile версия 78)
Вот содержание: - E System - JVM: INFOp = 2100000a, a = "7.0.0.296",o= "4.0.0.127",h=7001204
1 ответ
Для тех, кто заинтересован, я нашел решение.
В логах было:
a System - VM:VECCs=oneOfMyScreenClassNames
a System - VM:VECMm=functionInOneOfMyClasses()
Я сделал следующие шаги во всем классе "oneOfMyScreenClassNames", указанном в журналах
Вот шаги:
Если вы начали с создания файла Java-архива (JAR), а затем использовали компилятор прикладных программ RIM (RAPC) для создания файлов.cod, обязательно отключите запутывание при создании файла JAR. Компилятор RAPC выполняет свою собственную запутывание, и могут возникнуть проблемы, если код уже запутан.
Удалите все вызовы System.out.*. Они обычно ничего не делают на смартфоне BlackBerry, но они могут вызвать ошибки проверки.
Удалить неиспользованные операторы импорта.
Явно укажите доступ для каждой функции или переменной. Например, убедитесь, что каждый из них указан как публичный, частный или защищенный.
Если вы работаете с мидлетом, убедитесь, что класс мидлета объявлен как открытый.
Ошибки проверки могут возникнуть, если файл COD поврежден или если он не был подписан правильно. Убедитесь, что вы выполнили чистую перестройку и переподписали свое приложение. Переустановите приложение на смартфоне BlackBerry.
Закомментируйте любой неисполняемый код. Ошибки проверки могут быть связаны с размером основного файла кода и файлов библиотеки. Если вы закомментируете неисполняемый код, размеры файлов изменятся, что может решить проблему.
Если вы создали какие-либо классы, которые наследуются от классов RIM, измените имя любых пользовательских методов и членов, которые вы создали в этих классах. Это гарантирует, что вы не назвали никакие методы или члены с одинаковыми именами во внутренних классах RIM.
Если ваше приложение использует BlackBerry® Device Software 3.8 или более поздней версии, ошибки проверки возникают, когда приложение, реализующее класс javax.microedition.rms.RecordStore, скомпилировано с использованием среды разработки BlackBerry® Java® (BlackBerry JDE) ранее, чем версия 4.0. Это происходит, если приложение использует методы addRecordListener или removeRecordListener класса RecordStore. Чтобы решить эту проблему, перекомпилируйте приложение с помощью BlackBerry JDE 4.0 или более поздней версии.
Существует проблема с тем, как виртуальная машина BlackBerry® Java® (BlackBerry JVM) обрабатывает ссылки на класс непосредственно в конструкторе другого класса. Ниже приведен пример: Class1 class1= новый Class1(Class2.class.getName()); Чтобы обойти эту проблему, не делайте вызов класса в конструкторе
Удалить ссылки на статическую переменную экземпляра из внутреннего класса. Есть несколько способов удалить эти ссылки, такие как создание методов get/set для var во внешнем классе или изменение логики для извлечения MyInnerClass из MyOuterClass.
Процедура сборки обычно компилируется из исходного файла java с помощью команды javac, а затем запускает файл preverify.exe и затем RAPC. Чтобы избежать проблем в более ранних версиях RAPC, добавьте следующие аргументы командной строки в javac: javac.exe -source 1.3 -target 1.1
Некоторые методы, которые очень длинные, могут вызвать ошибки проверки. Разбивая эти методы на вспомогательные, вы можете уменьшить вероятность ошибок проверки.
Хотя это не так вероятно, некоторые очень длинные определения методов (с 10 или более параметрами) и некоторые очень длинные постоянные определения (длинная структура пакета и / или длинные имена) также могут вызвать ошибки проверки.
PS, я также удалил использованиеinstanceOf в коде