Использовать JNI вместо JNA для вызова собственного кода?
надеюсь, что у вас все хорошо. вы можете использовать мой код для обрезки изображения. Вам просто нужно сделать класс и использовать этот класс в своих классах XMl и java. Изображение обрезки . вы можете обрезать выбранное изображение в круг и квадрат во многих вариантах. надеюсь, что это будет работать для вас. Потому что это полностью управляемо для вас, и вы можете изменить его в соответствии с вами.
наслаждаются вашей работой:)
6 ответов
- JNA does not support mapping of c++ classes, so if you're using c++ library you will need a jni wrapper
- If you need a lot of memory copying. For example, you call one method which returns you a large byte buffer, you change something in it, then you need to call another method which uses this byte buffer. This would require you to copy this buffer from c to java, then copy it back from java to c. In this case jni will win in performance because you can keep and modify this buffer in c, without copying.
These are the problems I've encountered. Maybe there's more. But in general performance is not that different between jna and jni, so wherever you can use JNA, use it.
EDIT
This answer seems to be quite popular. So here are some additions:
- If you need to map C++ or COM, there is a library by Oliver Chafic, creator of JNAerator, called BridJ. It is still a young library, but it has many interesting features:
- Dynamic C / C++ / COM interop : call C++ methods, create C++ objects (and subclass C++ classes from Java!)
- Straightforward type mappings with good use of generics (including much nicer model for Pointers)
- Full JNAerator support
- works on Windows, Linux, MacOS X, Solaris, Android
- As for memory copying, I believe JNA supports direct ByteBuffers, so memory copying can be avoided.
So, I still believe that wherever possible, it is better to use JNA or BridJ, and revert to jni if performance is critical, because if you need to call native functions frequently, performance hit is noticeable.
В моем определенном приложении JNI оказался намного легче использовать. Я должен был считать и записать непрерывные потоки в и от последовательного порта - и ничто иное. Вместо того, чтобы пытаться изучить очень включенную инфраструктуру в JNA, я нашел намного легче моделировать собственный интерфейс в Windows с DLL специального назначения, который экспортировал всего шесть функций:
- DllMain (требуемый взаимодействовать через интерфейс с Windows)
- OnLoad (просто делает OutputDebugString, таким образом, я могу знать, когда код Java присоединяет)
- OnUnload (так же)
- Открытый (открывает порт, запускает чтение, и потоки записи)
- QueueMessage (данные очередей для вывода потоком записи)
- GetMessage (ожидает и возвращает данные, полученные потоком чтения начиная с последней возможности)
- You are writing code a few years ago before there was JNA or are targeting a pre 1.4 JRE.
- The code you are working with is not in a DLL\SO.
- You are working on code that is incompatible with LGPL.
That is only what I can come up with off the top of my head, though I am not a heavy user of either. It also seems like you might avoid JNA if you wanted a better interface than the one they provide but you could code around that in java.
It's not a direct answer and I have no experience with JNA but, when I look at the Projects Using JNA and see names like SVNKit, IntelliJ IDEA, NetBeans IDE, etc, I'm tend to believe it's a pretty decent library.
Actually, I definitely think I would have used JNA instead of JNI when I had to as it indeed looks simpler than JNI (which has a boring development process). Too bad, JNA wasn't released at this time.
На такой общий вопрос сложно ответить. Я полагаю, что наиболее очевидное различие состоит в том, что в JNI преобразование типов реализуется на внутренней стороне границы Java / native, тогда как в JNA преобразование типов реализовано на Java. Если вы уже чувствуете себя достаточно комфортно с программированием на C и вам нужно реализовать собственный код самостоятельно, я бы предположил, что JNI не будет казаться слишком сложным. Если вы программист на Java и вам нужно только вызвать стороннюю собственную библиотеку, использование JNA, вероятно, самый простой способ избежать, возможно, не столь очевидных проблем с JNI.
Хотя я никогда не тестировал какие-либо различия, я бы сделал это, потому что проекта, по крайней мере, предположим, что преобразование типов с помощью JNA в некоторых ситуациях будет работать хуже, чем с JNI. Например, при передаче массивов JNA преобразует их из Java в нативные в начале каждого вызова функции и обратно в конце вызова функции. С помощью JNI вы можете контролировать себя, когда создается собственное "представление" массива, потенциально создавая только представление части массива, сохраняя представление через несколько вызовов функций и, в конце концов, отпустите представление и решите, хотите ли вы сохранить изменения (возможно, потребуется скопировать данные обратно) или отменить изменения (копия не требуется). Я знаю, что вы можете использовать собственный массив для вызовов функций с помощью JNA, используя класс Memory, но это также потребует копирования памяти, которое может быть ненужным с JNI. Разница может быть несущественной, но если ваша первоначальная цель - повысить производительность приложения за счет реализации его частей в собственном коде,
Если я чего-то не упускаю, главное отличие JNA от JNI в том, что с JNA вы не можете вызывать Java-код из собственного (C) код?