dmitryskiba/itoa-jnipp

JNI meets C++

itoa-jnipp's Issues

Remove LocalObject, add missing methods to LObject

By missing methods I mean comparasion operators.

Should functions check for NULLs?

Some JNI functions, for example GetObjectClass don't handle NULLs.
Should we pass NULLs to such functions and crash or check for NULLs and throw an exception (and don't call functions)?

Implement java::Synchronizer

While java::Object has methods like Wait and Notify, there is no monitor lock class to emulate Java's 'synchronized' construct.

Create java::Synchronizer class that would perform JNIEnv::MonitorEnter/MonitorExit.

bad_cast thrown from java::Cast should contain message

Currently bad_cast is thrown without any message.
It should be thrown with a message like ("Can't cast %s to %s.",object->GetClass(),Type::JClass()).

Document all functions

field & method declaration parser

Implement parser for field & method declarations, so one can write

Field(Tag,"private static int m_data")
Method(Tag,"public java.lang.Object doStuff()")

instead of

Field(Tag,"m_data","I")
Method(Tag,"doStuff","()Ljava/lang/Object;")

Use AbstractObject instead of jobject in all methods

Implement _RethrowException

java::ObjectArray<ObjectPointer> problem

java::Array<java::ObjectPointer<X>> will work, but with unpleasant effects.
Either disallow such constructs, or detect, infer and use type X.

java::String::NewString should rethrow jni exceptions

Add _RethrowException() before return.

java::String::GetLength should cache value

Currently each call to GetLength() results in a call to GetStringLength(). We should cache length and use it in other functions.

Quick calls

Sometimes overhead of declaring JNIpp class (via JB_ macros) is just too much.

There should some 'quick' way of doing calling methods or manipulating variables.

Something like this:

java::PString var = java::CallMethod("System","String getenv(String)", java::PString::New("MY_VAR");
int ival = java::GetField("MyClass", "int mVar", myObject);

Note that functions return generic object that has different conversion operators. However, only proper conversion will succeed, all others will throw. E.g. the following will compile but will throw:

java::PObject obj = java::GetField("MyClass", "int mVar", myObject);

Add support for arrays

It's a shame that library doesn't support them!