Add a BuildFlag annotation, which when specified for classes, will wrap
generated code in `#ifdef` or `#ifndef` blocks. This functionality is
used for conditionally excluding generated code when NIghtly becomes
Beta, without the need to regenerate bindings.
MozReview-Commit-ID: L2NFM8CHKqF
--HG--
extra : rebase_source : 6ebc82d11fd1aa4aeb57a46262e678480d23de83
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.
It looks like Google decided to split these jars out a bit, so we need to piece
them all back together.
We could probably just query the sdk version instead, but I'm not 100% sure
know when this setup changed - moreover we don't know when (if?) the paths
are likely to change again. SDK 26.0 still has lint 25.3.1, so the SDK and
lint versions don't appear to be tied.
It seems that only the lint* jars are needed to compile 'build/annotationProcessor',
however we need all the remaining jars in the classpath when running that code
in 'widget/android/bindings'.
MozReview-Commit-ID: GAKwMrVXW55
--HG--
extra : rebase_source : 4e790aaccae8ccc3f151c39bf1ef4404b2581d7a
Bug 1344892 - 1. Add option to dispatch to priority queue; r=snorp
For the regular "gecko" option, change to dispatching to the XPCOM event
queue, and add a new "gecko_priority" option that dispatches calls to
the widget event queue. GeckoThread.waitOnGecko is changed to wait on
both the widget queue and the XPCOM queue. nsAppShell::SyncRunEvent is
changed to avoid a possible deadlock condition involving locking
sAppShellLock twice.
Bug 1344892 - 2. Update dispatchTo = "gecko" options; r=snorp
Update some existing dispatchTo = "gecko" options to "gecko_priority",
which typically involve UI events or JNI management calls like
disposeNative. As a rule, disposeNative is dispatched to the queue with
the least priority among the queues that other native members of the
same class dispatch to (i.e. "gecko_priority" if all other native
members dispatch to "gecko_priority", or "gecko" if any native members
dispatch to "gecko").
Bug 1344892 - 3. Update auto-generated bindings; r=me
Bug 1344892 - 1. Add option to dispatch to priority queue; r=snorp
For the regular "gecko" option, change to dispatching to the XPCOM event
queue, and add a new "gecko_priority" option that dispatches calls to
the widget event queue.
Bug 1344892 - 2. Update dispatchTo = "gecko" options; r=snorp
Update some existing dispatchTo = "gecko" options to "gecko_priority",
which typically involve UI events or JNI management calls like
disposeNative.
Bug 1344892 - 3. Update auto-generated bindings; r=me
Bug 1344892 - 1. Add option to dispatch to priority queue; r=snorp
For the regular "gecko" option, change to dispatching to the XPCOM event
queue, and add a new "gecko_priority" option that dispatches calls to
the widget event queue.
Bug 1344892 - 2. Update dispatchTo = "gecko" options; r=snorp
Update some existing dispatchTo = "gecko" options to "gecko_priority",
which typically involve UI events or JNI management calls like
disposeNative.
Bug 1344892 - 3. Update auto-generated bindings; r=me
Let AnnotationProcessor accept an output prefix argument, so that we can
generate two different sets of bindings for different jars - one set for
GeckoView code and one set for Fennec code.
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.
Currently, auto-generated Java bindings are in the mozilla::widget
namespace, and that potentially conflicts with code under
widget/android. Moving the bindings to mozilla::java avoids conflicts
and makes it more clear that we're using Java bindings.
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Currently, auto-generated Java bindings are in the mozilla::widget
namespace, and that potentially conflicts with code under
widget/android. Moving the bindings to mozilla::java avoids conflicts
and makes it more clear that we're using Java bindings.
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.
Java allows a class field to have the same name as a superclass field,
but when we generate bindings for them, they'll end up with the same C++
name and cause an error. This patch makes the SDK processor filter out
any superclass fields that are hidden by a subclass field with the same
name.
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);
};
};
This commit is us getting out of our own way. We were specifying
-classpath twice, once in $(JAVAC) and once in java-build.mk. Only
the latter of these is active. This a problem for ANDROID_EXTRA_JARS
-- those JARs should be on the classpath and input to $(DX) -- and
JARs that should be on the classpath but *not* input to $(DX). This
commit removes the global flags to $(JAVAC) and adds
JAVA_{BOOT}CLASSPATH_JARS. This required some hijinkery moving
wildcards to moz.build files, but everything seems to work.
As well as clarifying some parts of the build, part 2 uses this work
to modify the classpath.
--HG--
extra : commitid : 25Ft0BFs88O
extra : rebase_source : 05e3d1da8d42fa89d06ef48baee17bb77df5bd59
extra : histedit_source : 95b82309aca15c5a3c5f5a0eafbdcf75c5e8dfc0
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.
The API version detection functionality was broken in SDKProcessor
because we were passing in "Lpackage/Class;" as the class name rather
than just "package/Class". Also, some classes have a weird situation
where some methods were moved around in later API versions. For example,
some put* and get* methods in Bundle were moved to BaseBundle in API 21.
If we only checked BaseBundle.put*, we would think they are API 21+
only. The workaround is to check both the top-level class and the
declaring class for a member, and choose the lower API level as the
minimal API level for that member.
This patch also fixes bugs in including the right class members.
For SDKProcessor we want to include all public members of a class,
including inherited members, because the private/protected members are
not part of the public API. For AnnotationProcessor, we want to include
all the members declared in that class, including private and
protected members, because we may want to access private/protected
members of our own Java classes from C++.
Jim Chen
Andrzej Hunt
Iris Hsiao
Sebastian Hengst
James Cheng
Nathan Froyd
Carsten "Tomcat" Book
Tom Tromey
James Willcox
Nathan Froyd
Nick Alexander
Wes Kocher
Mark Capella