NullPointerException in Parser and poor Unicode support #70
Comments
|
Try with the latest on the master branch. There's been a lot of fixes since 1.1. |
|
Same error with JavaCPP version 1.2-SNAPSHOT |
|
A quick and dirty fix: diff --git a/src/main/java/org/bytedeco/javacpp/tools/Parser.java b/src/main/java/org/bytedeco/javacpp/tools/Parser.java
index 9b3c8bc..2cfe4d1 100644
--- a/src/main/java/org/bytedeco/javacpp/tools/Parser.java
+++ b/src/main/java/org/bytedeco/javacpp/tools/Parser.java
@@ -1002,7 +1002,10 @@ public class Parser {
}
info = infoMap.getFirst(cppType += ")");
- String functionType = Character.toUpperCase(originalName.charAt(0)) + originalName.substring(1);
+ String functionType = null;
+ if (originalName != null) {
+ functionType = Character.toUpperCase(originalName.charAt(0)) + originalName.substring(1);
+ }
if (info != null && info.pointerTypes.length > 0) {
functionType = info.pointerTypes[0];
} else if (typedef) {It seems that the error is related to the following line: void (*(*xDlSym)(sqlite3_vfs*,void*, const char *zSymbol))(void); |
|
Thanks!! The parser is (not so) quick and (but quite) dirty anyway. (BTW, the first thing I'd like to try at this point for the parser is to see if we couldn't use Clang for that: #51) |
|
In any case, if you get sqlite working, let me know and we'll start a "presets" out of that! Thanks |
|
I've created a branch here. |
|
Thanks! I'll try to get a look at that sooner rather than later... |
|
Ok, May I ask you two questions: public static final Destructor TRANSIENT = new Destructor() {
{
this.address = -1; // SQLITE_TRANSIENT
}
@Override
public void call(Pointer p) {
throw new UnsupportedOperationException();
}
};with no success. |
|
Ok, Regards. |
|
Great, thanks! Are you by any chance comparing the overhead of each tool (JNA, JNR, etc)? It would be nice to have some benchmarks as reference. For the function pointer, I was starting to consider adding support for void sqlite3_result_blob(sqlite3_context c, Pointer p, int i, FunctionPointer destructor);
void sqlite3_result_blob(sqlite3_context c, Pointer p, int i, @Cast("sqlite3_destructor_type") long destructor);It's not type safe, but it isn't in C anyway. Does it still make sense to try to cram that into As for the character encoding, |
|
Sorry, I have no benchmark between the different binding tools. And SQLite don't like the "modified UTF-8" produced by JNI. So only the BytePointer can be used. |
|
From what I see on your branches, it doesn't look like the other tools found a better way to pass strings in a different encoding, right? BTW, if |
|
It seems that both |
|
Right, but we still need to allocate bytes on the heap. It doesn't do it in native code somehow. Or are you saying there would be an advantage in setting the default encoding used by |
|
Maybe I am biased but I want my program to preserve data integrity (data not corrupted by a bad encoding) even if there is an additional cost. Something like that static native void foo(@Encoding("UTF-8")String bar);would be perfect. |
|
Some benchmarks using the BenchmarkDriver available here: Java version: 1.8.0_60, vendor: Oracle Corporation
OS name: "mac os x", version: "10.11.3", arch: "x86_64", family: "mac" |
|
So, the wrapper based on JavaCPP is on average faster than the custom JNI? Cool :) Thanks for taking the time! Of course, I understand the need to use standard UTF-8, but it's not just about UTF-8. Specifying the encoding info in an annotation like that prevents the end user from using any other encodings. In the general case, not in the case of SQLite, we often need to be able to set it at runtime, don't we? |
|
There are other libraries supporting only utf-8:
|
|
Ah, why did the JDK go with "modified UTF-8"... |
|
BTW, if you make a blog post or something about your experience using JNA, JNR, JNI, JavaCPP, BridJ, etc let me know! Thanks |
…IFIED_UTF8_STRING` for old behavior) (issue #70)
|
About UTF-8 encoding, I've switched to The calls are a bit slow, about 300 ns, but Let me know if you encounter any problems with that! Thanks for all the tests you've done :) |
|
Sorry, but for me, it is useless: |
|
Well, ok, say we had an annotation and we could write something like the following: static native void foo(@Encoding("UTF-8") String bar);Other than saving a couple of keystrokes (that we could save using the parser anyway) what is the rationale for not doing it the way we already can as below? static native void foo(BytePointer bar);
static void foo(String bar) { foo(new BytePointer(bar, "UTF-8")); }Where we could wrap In any case, if it's important enough, please do send a pull request, but unless I understand the benefit it's not something I'm going to take time to implement and maintain myself. |
|
I've just had an idea though. We could hard code the encoding used for all |
|
Good idea. |
|
Right, but you have to understand that in general there isn't any good options with standard Java types like primitive arrays, String or even direct NIO buffers. For example, we can't resize a ByteBuffer or modify the content of a String, so when we need to support a native function with an output argument like that, it's just easier (and more efficient than whatever hack we can come up with) to just use BytePointer (or CharPointer for UTF-16 or IntPointer for UTF-32). There are other things Java can't do, like arrays with more than Integer.MAX_VALUE elements. We could go on and on, but the ultimate solution to everything remains the same: Use an appropriate subclass of Pointer. :) |
saudet
changed the title
|
There is a good reason to provide UTF-16 support through JNI functions though: performance, see issue #442 (comment). Thanks to @equeim, we should have this implemented soon! (Including "modified UTF-8" while we're at it.) |
|
Ok, it's done! Thanks to @equeim and his contribution in pull #460, we can now map |
|
BTW, we may want to update the guide here with a new section for that: |
|
Thanks. I will try to use |
|
These changes have been released with JavaCPP 1.5.5. Enjoy!
You can also provide overloads with |
With JavaCPP 1.1:
The text was updated successfully, but these errors were encountered: