Недостатки использования Собственного Интерфейса Java
Это действительно не преподается в университетах (или он в наше время?)
я не знаю о в наше время, но мне преподавали и Miranda и Lisp как часть моего курса CS в середине 1990-х. Несмотря на не использование чистого функционального языка с тех пор, это влияло на способ, которым я решаю проблемы.
Большинство приложений достаточно просто быть решенным в нормальном OO пути
В том же курсе CS середины 90-х, OO (преподававший использование Eiffel) преподавалось в значительной степени наравне с функциональным программированием. Оба были негосподствующей тенденцией в то время. OO может быть "нормальным" теперь, но это не было никогда таким образом.
мне будет интересно видеть, является ли F# вещью, которая продвигает FP в господствующую тенденцию.
6 ответов
Трудно отладить
- Для отладки машинного кода необходим отладчик C / C ++. Невозможно легко перейти от кода Java к коду C / C ++. (хотя можно отлаживать и то, и другое одновременно. Я сделал это с Eclipse и плагином CDT, но это больно)
Ошибки в JNI
- Плохой код C / C ++ в вашей собственной библиотеке может / приведет к тому, что ядро дампы / ошибки сегментации, от которых JVM не может восстановиться, поэтому все ваше приложение вылетает.
Вы потеряете одно из преимуществ использования Java, ваше приложение больше не будет независимым от платформы, и многие другие проблемы, вытекающие из этого: возможно, вы будете поддерживать библиотеки DLL для Windows и .so файлы для Linux, каждый со своим компилятором, разными инструментами отладки, разными зависимостями и, возможно, разными ошибками, большей сложностью для вашего процесса сборки, большим количеством кода для тестирования и т. д.
Трудно отладить ошибку времени выполнения в машинном коде
Вы когда-нибудь видели трассировку стека в Java? Ну, они очень удобны для пользователя и в большинстве случаев сообщают вам номер строки, метод класса и то, что не удалось. У вас их нет в собственном коде.
Ошибки в коде JNI приводят к отключению всей JVM и не обеспечивают никакого механизма для постепенного восстановления
Когда вы запускаете код Java, все выполняется под управлением JVM , если что-то пойдет не так, JVM справится с этим. У вас нет такого контроля с использованием собственного кода.
Я не уверен насчет JNI, но если вы используете JNA , вы можете установить Native.setProtected (true) , и он будет выдает ошибку вместо сбоя JVM, чтобы вы могли поймать ее в блоке try ... catch. Так что второй недостаток не проблема. (см. исходный код )
Хотя это не должно быть в теории, на практике код на основе JNI, который я обнаружил очень хрупким - я обнаружил, что это кошмар обслуживания. Небольшие изменения или даже просто обновления JVM вызывают неясные проблемы. Это могло быть улучшено с более свежими версиями Java (здесь я возвращаюсь к JDK 1.3 или более ранней версии).
Я не уверен, поможет ли это, но я использовал собственный метод, чтобы установить статический флаг в моем коде JNI / C на включить или выключить отслеживание отладки (по умолчанию выключено). Затем я использовал старые добрые вызовы printf () в начале каждой функции JNI, которая выполнялась только при установленном флаге. Это грубо, но работает.
Также неплохо обеспечить своего рода проверку версий между классом Java и его функциями JNI. Это можно сделать с помощью функции JNI, которая вызывается из блока инициализатора статического класса. Если у клиента неправильная комбинация библиотек (т. Е. Файл jarfile был обновлен, а разделяемая библиотека JNI - нет, или наоборот), вы можете вызвать исключение во время загрузки класса.