Instead of specifying a class name per line, the new format uses the
.ini format, with each section name specifying the class, and each
property name specifying a member of the class. WrapForJNI options can
be specified with each class or member. Comments can be specified with
';' or '#'. For example,
# Generate bindings for Bundle using default options:
[android.os.Bundle]
# Generate bindings for Bundle using class options:
[android.os.Bundle = exceptionMode:nsresult]
# Generate bindings for Bundle using method options:
[android.os.Bundle]
putInt = stubName:PutInteger
# Generate bindings for Bundle using class options with method override:
# (note that all options are overriden at the same time.)
[android.os.Bundle = exceptionMode:nsresult]
# putInt will have stubName "PutInteger", and exceptionMode of "abort"
putInt = stubName:PutInteger
# putChar will have stubName "PutCharacter", and exceptionMode of "nsresult"
putChar = stubName:PutCharacter, exceptionMode:nsresult
# Overloded methods can be specified using its signature
[android.os.Bundle]
# Skip the copy constructor
<init>(Landroid/os/Bundle;)V = skip:true
# Generic member types can be specified
[android.view.KeyEvent = skip:true]
# Skip everything except fields
<field> = skip:false
# Skip everything except putInt and putChar
[android.os.Bundle = skip:true]
putInt = skip:false
putChar =
# Avoid conflicts in native bindings
[android.os.Bundle]
# Bundle(PersistableBundle) native binding can conflict with Bundle(ClassLoader)
<init>(Landroid/os/PersistableBundle;)V = stubName:NewFromPersistableBundle
# Generate a getter instead of a literal for certain runtime constants
[android.os.Build$VERSION = skip:true]
SDK_INT = noLiteral:true
For static final fields, generate a getter instead of a literal when
specified. Used to generate bindings for runtime constants whose values
are unknown at compile time.
Update the code generator and related classes in annotation processor to
use the new WrapForJNI flags. Also add some more sanity checking to make
sure the flags are used correctly.
clang complains that a constexpr definition of methods[] cannot refer to
members of the incomplete Impl template parameter, and rightly so.
Making these const is sufficient for our purposes, and that enables us
to move the declaration outside of the class, where it will be
instantiated lazily (presumably at the point when |Impl| is a complete
class definition). We also need to declare the length of methods[], as
other parts of the code require knowing the length of methods[] at
compile time.
The code generator uses == and != to compare two instances of Class, but
it really should be using equals because two distinct instances of Class
can refer to the same class type.
We try to generate a C++ constant for static final fields, but that
was failing for inaccessible fields. Now we set the field to be
accessible so that we do end up generating a C++ constant.
Right now, when we generate bindings for Java class A, and we encounter
a Java type B, we generate a corresponding C++ name only if A == B,
otherwise we generate a generic "jni::Object" C++ name. For example,
class Foo {
class Bar {
Foo getFoo(Bar bar);
}
}
In C++, Foo.Bar.getFoo would become,
class Foo {
class Bar {
jni::Object::LocalRef getFoo(Bar::Param bar);
};
};
This patch extends the code generator so that any Java class in the
chain of declared classes gets a corresponding C++ name. The above
example now becomes,
class Foo {
class Bar {
Foo::LocalRef getFoo(Bar::Param bar);
};
};
We try to generate a C++ constant for static final fields, but that
was failing for inaccessible fields. Now we set the field to be
accessible so that we do end up generating a C++ constant.
Right now, when we generate bindings for Java class A, and we encounter
a Java type B, we generate a corresponding C++ name only if A == B,
otherwise we generate a generic "jni::Object" C++ name. For example,
class Foo {
class Bar {
Foo getFoo(Bar bar);
}
}
In C++, Foo.Bar.getFoo would become,
class Foo {
class Bar {
jni::Object::LocalRef getFoo(Bar::Param bar);
};
};
This patch extends the code generator so that any Java class in the
chain of declared classes gets a corresponding C++ name. The above
example now becomes,
class Foo {
class Bar {
Foo::LocalRef getFoo(Bar::Param bar);
};
};
We try to generate a C++ constant for static final fields, but that
was failing for inaccessible fields. Now we set the field to be
accessible so that we do end up generating a C++ constant.
Right now, when we generate bindings for Java class A, and we encounter
a Java type B, we generate a corresponding C++ name only if A == B,
otherwise we generate a generic "jni::Object" C++ name. For example,
class Foo {
class Bar {
Foo getFoo(Bar bar);
}
}
In C++, Foo.Bar.getFoo would become,
class Foo {
class Bar {
jni::Object::LocalRef getFoo(Bar::Param bar);
};
};
This patch extends the code generator so that any Java class in the
chain of declared classes gets a corresponding C++ name. The above
example now becomes,
class Foo {
class Bar {
Foo::LocalRef getFoo(Bar::Param bar);
};
};
GeneratedJNIWrappers.h was updated in bug 1192079 to use inherited
constructors, which is a gcc 4.8 feature. Many people are still using an
older version of NDK which only comes with gcc 4.7.
To reduce verbosity of the generated code, this patch makes the code
generator use unqualified names when possible, e.g. use State::Ref
instead of GeckoThread::State::Ref. To accomplish that, function
prototypes now use the C++11 -> syntax for return types.
Currently, when we generate JNI wrapper for an inner class, the
resulting C++ class will not actually be a nested class of the enclosing
class. As a result, the class can be confusing to use. For example,
wrapping Java class GeckoThread.State results in two unrelated C++
classes, GeckoThread and State, and it'd be confusing to use State by
itself.
This patch adds support for inner classes. We start by scanning only for
top-level classes, and when processing each top-level class, we
recursively scan for inner classes through
JarClassIterator.getInnerClasses() and CodeGenerator.generateClasses().
For each Java inner classes, the resulting C++ class will be a nested
class. For example, wrapping GeckoThread.State will produce
widget::GeckoThread and widget::GeckoThread::State.
This patch adds AndroidBridge::HandleUncaughtException calls to generated JNI wrappers. Also, the JNI annotation now accepts the noThrow flag to indicate that the JNI caller wishes to handle Exceptions manually.
Jim Chen
Nathan Froyd
Carsten "Tomcat" Book
Wes Kocher
James Willcox
Chris Kitching
Kartikaya Gupta
Brad Lassey
Chris Peterson
Ehsan Akhgari
Ryan VanderMeulen
Chris Kitching